Incremental search and incremental command
lobre opened this issue · comments
Visual feedback can improve the experience when dealing with search and replace, or with SAM commands.
In Neovim for example, there are those options:
incsearch: While typing a search command, show where the pattern, as it was typed so far, matches. The matched string is highlighted.
inccommand: When nonempty, shows the effects of |:substitute|, |:smagic|, |:snomagic| and user commands with the |:command-preview| flag as you type.
The first one highlights searches as you type when using /.
The second is even more powerful and would be incredibly useful with SAM structural regular expressions. It allows highlighting the result of a regex is a command live while being typed.
And it will also show live the outcome of the command while being typed, before being validated when the option is set to nosplit.
When set to split, it even goes further and opens a preview window that shows as a list the outcome of the command for all lines for which the regex matches. This way, even changes outside the viewport can be quickly reviewed before applying the command.
I don't know what is technically doable in vis but those features really improve the development experience in my opinion.
I understand what you mean, but I am slightly hesitant to fill this issue tracker with nice ideas which are nowhere near to be actionable.
Show us the code!
I am not creating this issue to "fill the issue tracker" with dreams, but more to open a discussion around those interactive features that feel interesting to me for an editor to have.
I don't know if they fit with vis' design and philosophy, nor if the implementation is trivial or not. This issue is here for this matter.
And before starting to implement any "big feature", I think that discussing whether they would bring value or not to other users is important.
And remind also that people might not be familiar with the codebase. Many people are not in fact. So knowing if it is "near to being actionable" is not that obvious to me, hence this issue.
I would think that the email list is better suited for the open-end discussion.
I think I am confused about what should be an issue, and what should be discussed on the email list then.
I see other issues on GitHub such as about the creation of a new logo, "Vim-like command prompt/history" or "Vis for Prose" that feel way more "open-ended" than my concern here.
Can you please describe the purpose of the issues and the purpose of this email list?
It seemed to me that "incremental search" was a precise enough topic and that the issue could be used as a medium to talk about the design first, then the feasibility and then about the technical details of an implementation (or non-implementation if it is estimated as non-worth-it).
I think its fine to have this discussion here. However, I also agree
that flooding the issue tracker with "Editor x has feature y, where
is it in vis?" is not the best. At the moment vis is maintained by
its users. Most of us have limited time for adding features we have
little interest in. We can test and review code when its provided
but spending time bikeshedding about nonexistent code isn't useful.
I get that not everyone wants to contribute code but in that case
it is preferred if they limit themselves to 1 or 2 feature requests
at a time.
Thanks for taking the time to detail this.
In my opinion, this should be summed up on the README or somewhere to be seen before creating issues.
GitHub is public. Projects published on GitHub are public. People come around and use the same interface to interact with thousands of different projects, each having a different number of maintainers and a different story. You cannot assume that people know the roots of the projects, and know how it is being developed and maintained.
Vis is a project that was started by someone who somehow stopped spending energy on it and left it to the community. So I understand that the current "workforce" available to maintain the project is not extensible, and the philosophy and ideas of martanne may not have been properly transferred (that is a guess, correct me if I am wrong). The project seems to be in a handover phase, trying to find new roots.
Neovim has got a different story. It has core maintainers, a huge community and a different workflow of development. I suppose the issue tracker is the public-facing interface to discuss various topics. I don't think it is anything close to a roadmap or the source of truth that maintainers use as a primary tool. They obviously maintain their separate list of upcoming topics, and link that to issues or something like this.
All of this is just to explain that if the story, past, current state and ambitions of the project are not clearly stated, users don't know. They come here, and try to contribute the same way they are used to contributing to other projects and they use the "New issue" button which is at their disposal (and it is what I did). It also makes the users discouraged to contribute when they are being rejected by a "please go discuss that somewhere else".
I understand what you mean now and why you don't want such issues, but other users will do the same as I did, and you will probably feel drained again if they are not guided. Maybe some issue templates could also be setup also, to clearly state that only bugs and small-actionable issues should be filled.
I will prepare a PR for the README to explain at least the purpose of the issues as I understood it from your explanation.
But then maybe someone having context about the past, current state and current ambition of the project could also write a short sentence at the beginning of the project to explain the situation, especially since martanne has retired?
See for example the README of the Xi project (which was another editor which has switched from active development to more of a maintenance mode). There is at the beginning a short sentence to explain the current state. While Vis is not exactly discontinued, it seems the development is running at a slow pace, and the focus is at the moment only on bug fixes, and small/focused/actionable evolutions.
https://github.com/xi-editor/xi-editor/blob/master/README.md
Two other suggestions that I have. First, while being closed, maybe you could pin this issue that gives some context about this handover phase.
Finally, you could set up some "templates" in the issues so that people can only create issues for "Bug fixes", "Documentation" and "Small evolutions" or something along those lines. It will restrain people from requesting something too big. It will also help you filter issues more precisely and avoid the draining situation with the increasing number of total PRs. Instead, you can focus on what really needs attention.
See the template chooser of neovim for example: https://github.com/neovim/neovim/issues/new/choose