On Tue, Sep 23, 2014 at 08:03:45PM +0200, ale rimoldi wrote:
> hi marc andré
>
> as announced a few days ago, here is my write down about vis.
Thank you! This is very useful.
> you probably won't agree with each point in there...
Yes, see the inline comments.
> for many years now, i've been using vim as my main text editor. both for code and for typing text.
>
> while i consider myself a vim heavy user, when i browse through the vim manual, i have to accept the fact that i probably do not use more than 10% of the features.
> it's proably rather around the 1% or 5%, but i don't see a way to really count it...
> and this bothers me: how bloated is a software when a heavy, and curious, user only knows (and cares about) a tiny fraction of the features?
>
> (something maybe important to say: i use vim as distributed, with no plugins, with very few lines in the .vimrc file)
>
> on top of that, while i never had a look at the vim source code, i've read scaring tales about it.
>
> this made me curious about how "good" a suckless version of vim would be for me.
>
> and while testing vis, i started fearing that each of the many heavy users out there uses a different small subset of all the vim goodness: this could explain, why it's so bloated. let's hope that it's not true.
While this is true to some degree, I still think that it can be implemented
much better than to what vim evolved over the years.
> i did a vis test drive, i was rather happy with the result, but i also noticed many "every day features" that are missing... and a few ( really not many) bugs.
>
> and i also found some features that i liked to see not implemented (like U, the linewise undo; ex; K)
>
>
> here in details the result.
>
>
> first, there are two features that you explicit do not plan to implement but are (very) important to me
>
> - macro recording (really really really... except if you implement multiple selections... but even then... or at least macro playback!)
> - visual block mode (very practical for reformatting text; sometimes useful for code, too)
Ok, these seem to be important for a lot of vim users. Still I personally
don't really use them which means they have low priority. Patches welcome!
> the four "bugs" that most annoyed me while typing this text with vis:
>
> - o does not go into insert mode (how easy it is to switch my habits to oi?)
> - a does not append
> - end of line is not the last char in the line but the end of line character
> - P does not paste before
These should now all be fixed. If you (or somebody else) finds the time to
test it, it would be appreciated.
> and here the only real bug i noticed:
>
> - <count>> indents count+1 lines
Can't reproduce this. Could you please recheck with the latest git version?
> and then there is a longer list of commands i really missed (i mean: things that really slow down my workflow and i'd probably need all -- or at least most -- of them, if i want vis to to replace vim...
> some of them have already been mentioned, other not.
>
> :sav filename
Should work now.
> expandtab mode with :set ts and :set sw; eventually :retab
vis now supports ':set tabwidth 4' and ':set expandtab true'. If enabled,
tab expansion replaces ever tab character with a tabwidth spaces. Maybe
for compatibility reasons tabwidth should be renamed to tabstop?
I know vim has other related options (shiftwidth, softtabstop) I never
really understood why they are necessary. Therefore they are not implemented.
> :se si for smart indenting
> == automatically indent the current line
I'm not a big fan of 'smart indenting' which tries to outsmart me and then
more often than not doesn't work the way I want it. To make them useful
they would have to support indention as well as alignment which isn't that
trivial. Therefore currently not supported.
> automatically insert the comment sign at the beginning of the next line (it's about the #s and *s)
How does this work in vim?
> :paste :nopaste modes (if the commands above are implemented)
>
> zt zz zb redraw the current line at the top, center or bottom of the screen
zz and zb are kind of hard to implement given the way vis works. Are they
really needed?
> o O should go into insert mode after adding the line
> a appends at the current cursor place
Fixed
> . should also repeat insert actions
Yes, not completely trivial to do. I have some ideas ...
> $ should jump to the last char in the line not on the hidden return char
Fixed
> in normal mode, when the cursor is at the end of the line it should be on the last char.
Fixed
> x should not delete the end of line character (but this might be solved with the placement issue above)
I (and a few others? Christian Neukirchen?) actually like the fact that
the newline is treated like a normal character.
> implement the difference between word and WORD
The reason this is not yet implemented is that I personally almost never
use it. Furthermore coming up with a naming schema which is not totally
ugly is not that easy. The base infrastructure should be in place though.
> allow changing buffer without first saving the current buffer
> :b# go to the previous buffer
> :bd to delete a buffer
> :ls list of buffers
> :bd <int> delete <int> buffer
> :b <int> go to <int> buffer
Ok, I never use these. In vis a buffer is never hidden. It is always displayed
in some window. Otherwise the associated ressources are released.
> :vnew :new to create new windows
> ctrl-w lhkj to move among windows
These should work. Although no hierarchical window management is implemented.
> in command mode, deleting the : should go back to normal mode
> up and down arrows / ctrl-n/p to browser the command mode history
I agree.
> in insert mode ctrl-p and ctrl-n should propose an autocompletion with all known words from the open buffers
Yeah this is a long term goal. Although probably not across buffers. It
will be done as an external process. Not sure whether performance will be
an issue ...
> :! to run a command
> !! to run a command and insert its result as the current line
I agree, those are needed. I think Gregor Best mentioned he would look
into them ...
> dd does not work on the last line
dd works, the cursor is just not placed one line up, correct? I don't
consider this to be that important for now ...
> pasting a full line should put the cursor at the beginning of the pasted line
> P should paste before the cursor
> xp should switch the position of the characters at the cursor
> gU and gu for uppercase and lowercase
> g0 gm g$ moves to the begining/center/end of the screen line
> V for line selection
These should now all work, please retry. I just found out that my latest
commit places the cursor not at the same location as vim in the 'xp' case.
I think vim's behaviour is inconsistent, others might disagree.
> ctrl-v for visual block selection
>
> q to register macros
> _AT_ to play macros
Maybe in the long run ...
> gk / gj should keep the last set column (if it moved to a shorter line and then again to a longer one)
I agree.
> <num>gg should go to <num> line
Fixed
> ctrl-o and ctrl-i should jump to the previous cursor position (if possible, only inside the current buffer)
Can someone explain how vim manages the jumplist? What happens if you
go back a couple of times then perform new movements where are they
ordered relatively to the ones which were just skipped over?
> show where the file content ends (the vim's ~, but it can be solved in a different way!)
Maybe, I will think about it.
> /pattern/e modifier to move the cursor to the end of the match
> ,; for the next/previous match in the character find
> * finds the next matching word
Ok, seems doable.
> and here a few nice to have:
>
> - digraphs
I see no need for those.
> - "special" registers (calculation, current filename)
I also think that using environment variables for those (if needed at
all) makes more sense.
> - inserting registers with ctrl-r (ctrl-r% inserts the filename in the file itself)
CTRL-R [reg] should work in insert mode, no special registers are
implemented though.
> - optional syntax highlighting
do you mean a way to disable it?
:set syntax off
should work?
> - i'm not sure that having j/k behaving like gj/gk is a good idea
Yes, I will give the other option a try. The lines however will always
be wrapped. Horizontal scrolling will not be supported.
Thanks again for your valuable feedback! I hope some issues are already
fixed and others will hopefully be in the future.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Received on Wed Sep 24 2014 - 21:21:45 CEST