> 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: > > > 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! > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/1c781a06-24f3-45aa-b177-104c001165b3n%40googlegroups.com.
