Skip to content

ghcide master? #173

Closed
Closed
@alanz

Description

@alanz

A lot has happened since Bristol, and we have made a lot of progress, in ghcide and hls.

In the hls world, there was a time when ghcide did not have multi-cradle support, and had some performance issues, so we used a separate fork. This had some major differences, driven primarily by the alternate build process put forward by @mpickering.

My understanding is that the issues in ghcide have largely been resolved, and it is settling in as the primary development point for "vanilla GHC" features. This makes sense.

But hls is still running a fork of ghcide that is a long way from ghcide master.

Is there still any reason to do this? I would personally prefer the gap to be as small as possible, so we can proceed as two parts of one project, each addressing a different constituency.

Metadata

Metadata

Assignees

No one assigned

    Labels

    old_type: metaPlaning and organizing other issuesstatus: in discussionNot actionable, because discussion is still ongoing or there's no decision yet

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions