Skip to content

Include keybindings for common clients in documentation #2613

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
michaelpj opened this issue Jan 20, 2022 · 3 comments
Closed

Include keybindings for common clients in documentation #2613

michaelpj opened this issue Jan 20, 2022 · 3 comments

Comments

@michaelpj
Copy link
Collaborator

See e.g. #2603 (comment)

This would make things more user-friendly, but it has a few issues:

  • Lots of clients: which ones are we going to include docs for?
    • Even worse: emacs alone has two LSP packages, and those only provide the functions, the keybindings are to some degree up to users, and common emacs distributions pick different ones!
  • "Wrong" dependency: we then depend on the clients; if they change the keybindings our docs will be out of date, etc.
@Anrock
Copy link
Contributor

Anrock commented Jan 20, 2022

Even worse: emacs alone has two LSP packages [...]

Same for vim/nvim. And one of the major clients is also builtin and so we will also depend not only on clients, but on nvim itself too. Also, for nvim at least but maybe also true for other editors, given rapid-changing nature of APIs, plugin landscape and plugin APIs any docs will quickly go stale and will stop representing current "best practice" for specific editor.

IMO, overall best (not ideal) option is to just provide a list of client plugins with something like "consult plugin readme for keybingings". Maintaining a list of active/popular plugins per editor would be much easier.

@nartamonov
Copy link

  • Lots of clients: which ones are we going to include docs for?

I think the least experienced users benefit the most from the documentation. I have no statistics, but it is reasonable to expect such users to use VSCode. Newcomers and Haskell learners, as well as those who migrate from other languages, are unlikely to use Emacs or Vim immediately. They’ll choose a more familiar environment. Those who use Emacs and Vim have more ability (because of their experience, first of all) to understand how their editor interacts with HLS, event without comprehensive docs.

Of course, I’m not saying that documentation for other editors is less important (it's not!), but I’m sure it’s better to start with VSCode. Disclaimer: I'm on the side of Haskell learners so I can be biased 😃

@michaelpj
Copy link
Collaborator Author

Nobody has asked for this in a long time, and I think the arguments for it being a bad idea are compelling.

@michaelpj michaelpj closed this as not planned Won't fix, can't repro, duplicate, stale Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants