Haskell-language-server: Consider renaming to haskell-ide

[ndmitchell]

I appreciate I was one of the people involved in picking the name, but the install binary must be haskell-ide (we can't be everyones IDE), having a binary name that doesn't match the cabal package is confusing (the apply-refact binary made this mistake and it's caused additional support load), and talking about this project on Twitter etc where context is limited and expensive calling it IDE is not enough. As a result, I'd consider renaming to haskell-ide as the name of the github repo, Cabal package, binary and handle we use to talk about things.

[fendor]

Isnt haskell-ide a bit close to haskell-ide-engine? Explaining the difference between haskell-ide and haskell-ide-engine might be confusing.

[alanz]

@fendor I actually think that is a plus. The ghcide side has been adding, we are removing, in the name.

I agree that calling it haskell-ide makes sense. And the name seems to be available on hackage. I had an idea it was already in use by fpcomplete / commercialhaskell though.

[alanz]

And I just namesquatted it at http://hackage.haskell.org/package/haskell-ide-0.1.0.0/candidate

[Anrock]

haskell-ide-engine: The engine for haskell ide-integration. Not an IDE
Okay. IDE Engine is not an IDE

haskell-ide: Not an IDE
Wait, what. IDE is not an IDE?

That's probably a little late, given that the name was already squatted, but couldn't we all think of some better naming? Looks like haskell-ide (this package) is going to be even more popular and thus confusing name will definitely make some WATs for users.

How about haskell-ide-platform, haskell-ide-server, haskell-language-server, haskell-ide-engine-prime, haskell-ide-engine-ng? My personal favourite here is haskell-language-server. There are a lot of other <languagename>-language-server things already and haskell language server or language server for haskell is probably the first thing someone would google.

[alanz]

Well, from that wealth of names I am happy with any of

• haskell-ide, because it ties back to the prior project
• haskell-lsp-server
• haskell-language-server
• haskell-ls (to tie up with erlang-ls

Maybe vote with 👍 for the first, 🎉 for the second, ❤️ for the third, 🚀 for the fourth or add another option.

Edit: added late entrant haskell-ls

[Anrock]

Additional thing I have against having ide piece in project name - this project isn't going to be IDE (obviously) and it is usable not only by IDEs, so that's a false and confusing connection.

[jneira]

I rather like hyde, short, searchable and based in a novel character :laughing:

[alanz]

@jneira mostly this executable will be started by a client IDE, so it does not have to be short. In fact, it is more important that it is descriptive, because you will only really care about it when you are setting things up.

And I guess the other usage is in dev discussions. And that could easily be shortened to hls

[dysinger]

Given that it is launched from an editor, it doesn't really matter what it's named.

[lorenzo]

haskell-language-server is easy to discover and google for.

[fendor]

Did we make this poll public to the rest of the community? E.g. on discourse, discord, irc and reddit (and whatnot)? Currently the poll was open for less than 24 hours. Which I am personally fine with, but with an announcement, more people have a chance to voice their opinion.

[alanz]

I considered that, but the new name is such a clear outlier I do not really think it makes a difference. And the original name was chosen by the inner circle too. It is not a controversial name either.

[Rizary]

haskell-intellisense
haskell-language-agent
haskell-analyzer (well it's similar to rust-analyzer)

haskell-code-environment

[ocharles]

I only wonder if haskell-language-server should be ghc-language-server. Depends how much we want to continue the "Haskell = GHC" connection.

[alanz]

@ocharles that is valid, but the intention is that this forms a broader platform, and does not rule out other compilers. It can also include tools that are not specifically GHC based.

Also, the language server is part of the critical support for early users. As such it is vital that it is discoverable. Someone who has heard of haskell is not going to search for a LSP client on their favourite IDE called GHC.

[ocharles]

Very reasonable points!

[jneira]

I've just discovered a caveat: the longer new name triggers the max path issue in windows being the project dir D:\haskell\ws\haskell-language-server :worried:
Changing to D:\haskell\ws\hlsfix the issue
Another note to add in the README

[Anrock]

Welp, we already have similar note in hie. God, I hate Windows.

[fendor]

I think I remember that somewhere something started to change the tooling to avoid the windows max-path issue, I think it was ghc?

[Anrock]

It was both GHC and stack, iirc. But for some reason it didn't resolve the issue completely, so we still have this section in hie