[META] Suggestions and remarks from the community survey

[lenormf]

Hi,

The results of the community survey are out, and some suggestions/remarks from respondents didn't make it into the final report.

I've gone over all replies, and compiled a collection of points that are worth logging into the tracker. The respondents of the survey haven't created any issue about their concerns, so I did. Or they did create an issue, had it closed, but other users later complained about the same point, in which case I want to make sure we're not missing out.

Note that in most of the issues below, I merely forwarded the claims/suggestions, some might not have merit. Bug reports are all made without reproduction instructions or additional information.

General

• [ ] Built-in clipboard integration #3935
• [ ] Indentation guidelines #3937
• [ ] Allow the completion candidates menu to be displayed elsewhere #3938
• [ ] Startup time is slower than Vim with an equivalent configuration #3939
• [ ] The documentation should be organised better #3940
• [ ] Improve commands discoverability #3941
• [x] There's no visibile difference between two focused/unfocused clients in Tmux panes #3942
• [ ] The built-in multiplexing commands lack flexibility #3943
• [ ] The borders on the info window conflict with the colorscheme #3944
• [ ] On-demand documentation/information about a primitive/command #3945
• [ ] Support Right To Left text #3946
• [ ] Difficult to get started on Windows #3947
• [ ] Allow getting the server to expand arbitrary strings more easily #3948
• [ ] Allow :git to select or revert hunks #3953

Bugs:

• [ ] Command completion with a remote filesystem in PATH is slow #3949
• [ ] Allow cancelling highlighting on huge buffers #3950
• [ ] Movement primitives scroll the screen even when the target line is in the view #3951
• [x] When EditorConfig is enabled, spaces are never inserted, always tabs #3952

[lenormf]

It doesn't really fit in this repository, but below are the suggestions that would be suitable for plugins.

Note that users mention a heavy Git wrapper (like Fugitive or Magit) in overwhelming majority.

• [ ] advanced Git wrapper
• [ ] dumb-jump.el implementation
• [ ] arbitrary REPL (probably means arbitrary target command, not window environment)
• [ ] better marks (no details)
• [ ] kill ring https://www.gnu.org/software/emacs/manual/html_node/emacs/Kill-Ring.html
• [ ] save commands history
• [ ] code tree (list of functions, definitions etc.) | tagbuf, tagbar
• [ ] prose plugins (unspecified)
• [ ] maintained tree-sitter implementation
• [ ] buffer narrowing to fence primitives into a given part of the buffer
• [ ] modify a post-processed view of arbitrary data, saved back into the buffer automatically (e.g. JSON as YAML)
• [ ] have :make support multiple compiler error formats
• [ ] integrated Python debugger
• [ ] mergetool with Mercurial support
• [ ] undo/redo tree
• [ ] Graphical User Interface
• [ ] autoload manager plugin (could be an external tool)
• [ ] support for something like gqip
• [ ] support for something like :cfdo %s/foo/bar
• [ ] more colourschemes

[Ordoviz]

„code tree” is basically tagbuf or tagbar.

[lenormf]

I've added these two plugins to the item, though I think users expect something that doesn't rely on a specific tool like CTags.

[Screwtapello]

Is this the list of all the things requested by the survey, or just the things that didn't already have issues? I'm a little bit surprised that #1451 didn't make the list.

[lenormf]

The items are suggestions received via the survey that I found interesting, and that I didn't recall seeing in the tracker.

Display-line based movement was requested by a couple respondents, so I didn't add it to the list since it's been brought up already (and even has a PR going).

There's also a chance that some items in the list already have an issue (I haven't checked), if that's the case I'll remove them from the list.

[andreyorst]

I've added these two plugins to the item, though I think users expect something that doesn't rely on a specific tool like CTags.

I think this can be done by inspecting syntax highlighting information in current buffer, and everything that is highlighted as a function can be put into the tree. IIRC Emacs' imenu works this way, although Emacs usually highlights only function definitions, not usages, so this may have a lot of false-positives if highlighting is incorrect or too general. With something like tree-sitter it would be more correct, I guess.