Incremental search and incremental command

[lobre]

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.

[mcepl]

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!

[lobre]

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.

[mcepl]

I would think that the email list is better suited for the open-end discussion.

[lobre]

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).

[rnpnr]

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.

[ninewise]

I think the first request, preview the search result while typing, could be doable. The second would require an overthrow of the command parsing and interpreting code, so I don't think it should be considered for now.

[mcepl]

On 10/10/23 16:39, Loric Brevet wrote:

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 know, but let me share here my experience of somebody who spend last seventeen years dealing with various ticket systems, six of those as a bugmaster for the Desktop team at Red Hat (so full time on bugzilla.redhat.com and bugzilla.mozilla.org).

1. The absolute death of the project is IMHO situation of neovim (or vim): https://github.com/neovim/neovim/ with 1,382 open tickets (resp. 1,332 for vim) and 275 (or 150) open pull requests. I have absolutely no idea, how maintainers of neovim deal with this avalanche, but I challenge anybody to sit down in the morning and decide which of 1300+ open tickets is the one which requires her concentration and work this day (500+ of Firefox/Thundebird bugs in BZRH was more than enough for me) and which of those roughly two hundred pull requests is the one which deserves her attention.

2. The fastest way towards cleaning up the issue tracker is if every issue report is short, sweet, and actionable: when I do foo, I expect bar, but blah happens; here are the logs indicating where the problem could be (or, even better, a patch). Analysis, fix, testing/QA, done, ticket closed. The opposite is a big problem. Worse than just mere 1300+ tickets is large number of them are non-actionable: long never-ending discussions of something very abstract without any solution on the horizon. That’s what made Linus famously shout “Show me the code!” (with the implied threat of being sent away). Email lists are much better for such discussions (or perhaps GitHub Discussions, but I don’t like them and fortunately vis doesn’t have them switched on).

3. Not only long lists of non-actionable tickets make it hard to find the right one, but they are also thoroughly demotivating. After an hour spending opening tickets and finding that I cannot do anything about them, I feel drained, forced, angry, and thoroughly discouraged.

4. Actually, https://github.com/martanne/vis/issues/1117 is not so bad. There is an attempt for solution attached, and after couple of back and forth, I believe, we can be done (we just have to find out what is such logo good for). On the other hand see how quickly ninewise stopped https://github.com/martanne/vis/issues/1109, because again it is something thoroughly non-actionable.

Please, continue on the email list.

Best,

Matěj -- https://matej.ceplovi.cz/blog/, Jabber: @.*** GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

The Schleswig-Holstein question is so complicated, only three men in Europe have ever understood it. One was Prince Albert, who is dead. The second was a German professor who became mad. I am the third and I have forgotten all about it. -- Lord Palmerston

[lobre]

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.

[mcepl]

On Wed Oct 11, 2023 at 10:16 AM CEST, Loric Brevet wrote:

In my opinion, this should be summed up on the README or somewhere to be seen before creating issues.

If you can write a pull request changing README.md, it could help a lot. Generally, my idea is that issue tracker should be more like a To-Do list and less like a discussion forum.

Thank you,

Matěj

-- https://matej.ceplovi.cz/blog/, Jabber: @.*** GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

How many Bavarian Illuminati does it take to screw in a light bulb? Three: one to screw it in, and one to confuse the issue.

[lobre]

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