Zero cmdheight

[Bram Moolenaar]

It takes a lot of effort to make zero 'cmdheight' work properly.
Various bugs and corner cases keep popping up.

I added the message window, so that various informative messages do not
get lost, and that helps. But it also makes it more complicated.

There is also one bug that I don't know how to reproduce yet, which
makes the window frames too tall. The last statusline goes missing.

So, I was wondering who will actually want to use this? It gives you a
line of extra space, at the cost of various side effects. Especially
the last status line jumping up when typing ":" or "/". Is this worth
the extra work and making the code more complicated?


--
Wi n0t trei a h0liday in Sweden thi yer?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[tooth pik]

if we're voting put me down on the side of less work, less complicated code

i tried a zero cmdheight and immediately didn't like it

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220829102404.A8A9B1C0907%40moolenaar.net.

[Romain Lafourcade]

I don't have links at hand but in my ten or so years spent answering Vim questions in various forums I have seen that request quite a few times. But are those drive-by askers from six years ago still here? Will they use the feature?

From where I stand, the only use of a zero cmdheight would be in combination with a floating window à la "command palette/quake terminal". I have zero interest for such a feature and I think that there are more productive things to do.

[Egor Zvorykin]

I think people asking for it don't understand all the implications that go with it. I do want to try it out. So far the workarounds for corner cases I've seen look fine. Jumping last status line doesn't seem to bother me.

понедельник, 29 августа 2022 г. в 22:24:14 UTC+3, Romain Lafourcade:

[puremo...@gmail.com]

I tried it out and quite liked it initially. though I'm not sure if I would use it permanently. I think I would miss `showcmd` too much.

That said, I did a quick GitHub search. As many users put their vimrc in GitHub we can search for it. This probably covers only users that either tried the new setting or used the version (I presume) from neovim, and it's only a sample, but : https://github.com/search?q=%22cmdheight%3D0%22&type=commits

 (Note the code search didn't work, that's just commits where people have mentioned `cmdheight=0` in their commit message).

So I think that says a nonzero number of users will enable this, but how that compares as a percentage, and if that makes it worthwhile or not is difficult to say. Perhaps another way of looking at it - does the set of code changes required to make this possible open up any other opportunities that were previously difficult, e.g. as a refactoring does it help maintenance in the future, or the addition of future features? I'm guessing not, judging by the additional complexity being added.

[Shougo]

The patch author is here.
Of course, I like the feature.

The feature means users can customize Vim UI like this.

https://www.reddit.com/r/neovim/comments/vc75v7/cmdheight0_vimtpipeline_a_match_made_in_heaven/

Users can replace the command line by plugin like this.

https://github.com/VonHeikemen/fine-cmdline.nvim

The feature may add the code complexity, because
Vim didn't expect that functionality.

The message area is used for both command line and messages.

> Especially the last status line jumping up when typing ":" or "/".

Another implementation exists in neovim.
It makes command line area position to above the status line.

I don't choose the implementation.  Because it is more complicated and buggy.

https://github.com/neovim/neovim/pull/4382

2022年8月30日火曜日 19:26:29 UTC+9 puremo...@gmail.com:

[Bram Moolenaar]

> I tried it out and quite liked it initially. though I'm not sure if I
> would use it permanently. I think I would miss `showcmd` too much.

That is exactly the thing. It seems like a nice feature at first, but
once using it you find out disadvantages. It will be different for each
user. For me I'm missing the size of the Visual area, I often use that
to measure the size of text.

The advantage of having one more line of space is minimal (only on a
small laptop it would matter).

> That said, I did a quick GitHub search. As many users put their vimrc in
> GitHub we can search for it. This probably covers only users that either
> tried the new setting or used the version (I presume) from neovim, and it's
> only a sample, but :
> https://github.com/search?q=%22cmdheight%3D0%22&type=commits
>
> (Note the code search didn't work, that's just commits where people have
> mentioned `cmdheight=0` in their commit message).
>
> So I think that says a nonzero number of users will enable this, but how
> that compares as a percentage, and if that makes it worthwhile or not is
> difficult to say.

I don't think that statistics mean much for a feature that is new.
Regular users may only pick it up a year later.

> Perhaps another way of looking at it - does the set of
> code changes required to make this possible open up any other opportunities
> that were previously difficult, e.g. as a refactoring does it help
> maintenance in the future, or the addition of future features? I'm guessing
> not, judging by the additional complexity being added.

While trying to fix some problems I found that there are many corner
cases. Many places in the code need to be aware of when 'cmdheight' is
zero and decide whether messages go on the command line or in the
messages window. Especially when overwriting a previous message or not,
which currently is aimed at avoiding the hit-Enter prompt. This feature
adds a new state and doesn't make anything simpler.

I do like the messages window. It can be used for informational
messages, and avoid the hit-enter prompt. Also for asynchronous work.
E.g. when you start a build in the background, the messages window is
perfect for reporting it's done (or failed). A message with ":echo"
might very well interfere with what the user is doing.

--
SOLDIER: What? Ridden on a horse?
ARTHUR: Yes!
SOLDIER: You're using coconuts!

[Shougo]

> That is exactly the thing. It seems like a nice feature at first, but
once using it you find out disadvantages. It will be different for each
user. For me I'm missing the size of the Visual area, I often use that
to measure the size of text.

For the modeline problem, you can use the config.

au ModeChanged n:* set cmdheight=1

au ModeChanged *:n set cmdheight=0

> The advantage of having one more line of space is minimal (only on a  small laptop it would matter).

I don't think it is just one line.
It is like zen-mode.
Users can disable both statusline and command line.
The whole screen is the text.

2022年8月30日火曜日 20:45:27 UTC+9 Bram Moolenaar:

[Bram Moolenaar]

> > That is exactly the thing. It seems like a nice feature at first, but
> > once using it you find out disadvantages. It will be different for
> > each user. For me I'm missing the size of the Visual area, I often use
> > that to measure the size of text.
>
> For the modeline problem, you can use the config.
>
> au ModeChanged n:* set cmdheight=1
> au ModeChanged *:n set cmdheight=0

To me that is an indication that cmdheight=0 is a problem. Switching
it on and off causes a redraw and the display changing. Similar to how
":" and "/" do this, but then at least your eyes go to the command line.
With entering/leaving Visual mode that is not the case.

Anyway, this is the price to pay for an extra line to use for windows.

> The advantage of having one more line of space is minimal (only on a
> small laptop it would matter).
>
> I don't think it is just one line.
> It is like zen-mode.
> Users can disable both statusline and command line.
> The whole screen is the text.

The example I have seen relies on tmux, which takes away a line for
its status. I hardly ever use tmux and I don't think we want a feature
that is only useful inside tmux.

--
ARTHUR: The swallow may fly south with the sun, or the house martin or the
plover seek warmer hot lands in winter, yet these are not strangers to
our land.
SOLDIER: Are you suggesting coconuts migrate?

[Bakudankun]

At least, with `:set cmdheight=0 laststatus=0 showtabline=0` you can view only the code on the screen.

I do neither use that ordinarily, but I think that is valuable.

2022年8月30日火曜日 21:19:57 UTC+9 Bram Moolenaar:

[Gianmaria Bajo]

Just my 2 cents.

For me it's utterly useless.

You lose the messages, even if they show up somewhere else, they would show up in a wrong/more difficult place to read, it would be distracting. For messages, the most natural place is the bottom line. This reason alone would be enough for me never to use it.

You lose the feedback about the size of the visual area as Bram said, I also use it.

You lose feedback from commands. For example I have

nnoremap \W :noau wall<cr>

and in the command line I can see if some file was actually written.

The advantage is zero, one more line is nothing if you lose the message area that you'll need to reimplement necessarily in some other form. And I'm not counting the bugs, the added complexity to the code, etc.

Even if it worked perfectly I would not use it.

That some people express desire for it means nothing. Many new users that come from other programs, instinctively want things to look as in their old favorite program. Except that they won't use the feature either, once they realize it's bad. Other people say yes only because it looks shiny, but maybe they use the editor 2 minutes a day in average, or just go away the day after. Surely it's possible to ignore the desires of such audiences?

I was already disappointed that neovim merged it just to please the brainless masses. I hope you don't do the same mistake. With all respect to the author of the patch, I understand it's interesting to try to implement new things, but this is just a bad idea, IMHO.

[Gianmaria Bajo]

Another thing you would lose, and that I could not accept losing, is the partial command you've typed, as when there is some pending operator, or the 'f' key. It couldn't even be shown somewhere else with a plugin, as far as I know.

[Tony Mechelynck]

To each his choice. Personally I set 'cmdheight' to at least 2 to
avoid it bobbing up and down too much; OTOH for the sake of screen
space I set 'winminheight' to zero, 'winheight' to 9999, 'helpheight'
to 9999 and 'noequalalways', so all non-current windows get reduced to
just a status line and nothing else (that's what I call "Rolodex Vim"
as in an old-fashioned Rolodex card file where the current card is
open in full and all others are reduced to only an index each at top
or bottom).

So I'm not going to :set ch=0 ; but if Bram is willing to provide it
and some people want to use it that's OK for me: one of the things I
like a lot in Vim is its customizability: each user may use it in
his/her own way, and indeed several people may obtain the same result
by means of different commands.

The problem when you start providing some feature is that people are
going to use it, and then you need an extremely good reason to remove
it (not just "I asked around the office and no one was using it"). As
a counter-example, some years ago (a decade or two maybe) the Firefox
developers removed the ability to go to the Firefox "home page" at
Mozilla by clicking an icon at the top right corner of the Firefox
window. A very little thing, but immediately several users raised the
hue and cry, saying (the equivalent of) "Why did you remove that
feature? I was using it and I liked it a lot". The "official" answer
was "It isn't discoverable and no one is using it, it won't come
back". The bug was RESOLVED WONTFIX — that or maybe INVALID, I don't
remember. Happily enough for us, AFAIK Bram is conscious of this, and
he is very cautious about removing an established feature (and when he
does it's always with good reason). To the point that when introducing
the floating-point feature he felt obliged to explain that "if you
compile with +float, the expression 7.5 (with no spaces around the
dot) will mean 'the floating point seven-and-a-half' and no longer the
string '75' i.e. '7' concatenated with '5'". He even asked around if
anyone was using this old meaning of that same expression, to make
sure that this "compatibility break" would bother approximately
nobody. I approve of that: Better overdoing it a little than failing
to notice how people, if any, are using what you're going to remove.

Best regads,
Tony.

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/6ea6bb33-fa10-4c87-923e-ebaf7f0b0c2en%40googlegroups.com.

[Bram Moolenaar]

Well, this is not an easy decision. But in my opinion it is better to
not support zero 'cmdheight'.

Short version: I expect only a few people to use this, and it is mainly
for cosmetic reasons. The maintenance burden will be quite high, bugs
will keep popping up, and for some problems there is no perfect
solution.

Longer version.

When I first included the patch it seemed like a good idea to support.
But once using it, it becomes clear it has many side effects. Some of
them could perhaps be fixed, but some are a compromise. Therefore I
don't think this is going to be a popular feature in the long term.

The maintenance burden is quite big. Every command that has output in
some form will have to decide where it goes. If it's on the command
line it requires the hit-enter prompt, even if it is only one line. If
it can go into the newly added message window, it shows for a short
time. Perhaps not long enough to read it. And then paging doesn't
work, thus it can only be used for short messages. We can keep tuning
this forever and it will never be perfect.

Also, since few people are going to have 'cmdheight' set to zero, new
features will likely first not deal with it properly and have to be
fixed later. Thus it's not a one-time maintenance burden, but forever.

I'm going to roll back the changes. Of course it is possible to make a
branch and keep developing it, if someone likes to put in the effort.
But since the changes are in many places it will take time to keep it in
sync with the master.

--
"Lisp has all the visual appeal of oatmeal with nail clippings thrown in."
-- Larry Wall

[h_east]

Hi Bram,

Thanks for your big decision.


Link to my first comment about this.
https://github.com/vim/vim/pull/10675#issuecomment-1202090885

--
Best regards,
Hirohito Higashi