reopen issue, feature request :dq => Discard changes and Quit

[6lj6]

    Sorry, I'm having a hard time understanding you. Thanks for your suggestion, but I'm going to close this.

Originally posted by @dead10ck in #5271 (comment)

[6lj6]

If I don't have time understanding something, I may leave but won't destroy it.

Let someone who can understand it to handle this issue.

[6lj6]

update:

1. I don't need thanks or sorrys.
2. I am not saying closing issue is not right.
3. I am saying a reasonable reason. Just leave a reason to close this which is reasonable, like it is low priority in todo-list, like may optimize these concepts in tutor, like need more learning on new cmd, BUT CAN'T BE THAT "Having a hard time understanding me", you could choose to not understand instead closing it. If you waste the power and the rights that helix gave to you about closing Issue, then I will waste the rights on reopening the issue.

[6lj6]

Come back to the main topic.

1. :dq is more consistent with :wq than :q!. Consistency means less confusion, less memory burden , less operation err, less learning time,
2. :d will became a single atom operation, like :w and :q, can't be more elegant. Let's compare it to ugly :q!
3. dead10ck said that "visual indicator". It is not true, reasons are as follows:
   1. Users hardly watch the bottom bar when they quit the helix, does't it?
   2. :wq is also a risky operation, cuz it broke the original text, but there is no ! in :wq. How can :dq need an exclamation while :wq need not?
4. Less is more.
   1. less press times on keyboards, it will protect our fingers. Though it is a small optimization, but we can improve similar key designs to make it better and better.
   2. less modals of learning, Discard changes or Write changes or with Quit. Like rust to C++. What existed is not the best, e.g. the ugly :q!
5. for more info about this design, more pros and cons, go check the issue that was closed by @dead10ck => :dq => Discard and Quit #5271

We are making the masterpiece for the world, forget about historical vim and backward-compatibility.

[gabydd]

For number 2. :reload already exists for discarding changes, the benefit reload has over just discarding the changes to a document is you can undo the reload and still have your past undo states as well meaning you don't lose work if you :reload something and realize you want to go back. Moving on to the rest of the issue I think the best solution is either configurable aliases for commands or being able to create custom commands. Then you would be able to configure :dq to being :quit!/:q! (relevant issue #4423). It's valid to prefer a different command name for doing something, but we can't realistically provide everyones preference in core, that's why there is configurable keybindings and when someone gets the time to do it configurable commands.

[6lj6]

The issue also reflects the fact that there is no serious designing process of helix. All concepts and patterns are mixed up in a chaos logic. It drive us to face so many new issues to rethink and optimize the original code.

Your practical explanation is admirable. It is you so that more and more people will be attracted to join helix.

I'm going to offer my views as a materials of helix official tutor in next days. It's about the concise models that helix uses but didn't tell users. It may help people to find a beautiful way to learn, think and use helix.

See you in next issues.

[6lj6]

Good idea about "configurable commands".

Since helix support a color theme, it can also offer a cmd theme, kbd binding theme to customize in the settings.

And since default theme do matters for anyone who first learn helix, think more about new features added to helix next time( what exactly it is, in this case,

• Quit is quitting helix
• Write is writing changes to disk(Text)
• Discard is discarding changes to disk(Text)
• What about quit Text instead quit helix?
• And what the hell about :q! since we can't use :qw ?
• Also :q! is an action about discarding everything:
  1. temporary changes on text
  2. temporary customization of helix settings, views
  3. some unfinished in-running tasks/threads

so :q! could be contained in helix, but not only mean discard changes of text. It means discard everything, stop warning me, stop ceasing me and just let me quit! Whatever has been discarded is not concerned, is a side-effect, not the main purpose.

1. but for now, :q also discard customization about modification of views, settings.
2. no task/script in helix.
3. but we can keep this for preparing future of helix.

Thus this issue could be closed and added to future-todo-list. ( the info has been recorded, and maybe it will never be implemented)

[gabydd]

I think the most actionable part of this issue is explaining how :q and :q! work better in the tutor, I agree this can be a bit confusing to beginners. What I think could work well is an explanation of how buffers and views work, could probably be a whole chapter in the tutor. With an understanding of buffers and views quiting can be explained better, as well as close and quite all. And yes I think this issue can be closed and I or you can open a new issue about the tutor stuff.

[archseer]

Good idea about "configurable commands".

We will probably support custom :command bindings in the future yeah. It should work similar to keybinding