Incremental search and incremental command #1145
Comments
|
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 I get that not everyone wants to contribute code but in that case |
|
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.
|
|
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, #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
#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
|
|
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. |
|
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.
|
|
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 |
Visual feedback can improve the experience when dealing with search and replace, or with SAM commands.
In Neovim for example, there are those options:
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.
The text was updated successfully, but these errors were encountered: