> > vis now supports ':set tabwidth 4' and ':set expandtab true'.
>
> ":set expandtab 1" works correctly
>
> ":set tabwidth 4" set the width of the tab but i always get 8 spaces
> when expandtab is enabled
>
> i've checked in the code, and the set is writing the value in window
> and get reading it from editor.
>
> currently, expandtab is defined at editor level, tabwidth both at
> editor (unused) and window level.
Should be fixed.
> > smart indenting
>
> well, mostly, i could work with a simple implementation that respect
> some basic cases:
That is already a rather more complicated than I'm comfortable with.
Just press tab a few times.
> > > 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?
>
> in my .vimrc i have:
>
> :se formatoptions=tcqlro
>
> the "r" is for enabling the auto-commenting of new lines and "o" for
> adding it when in typing "o" or "O".
>
> see :help fo-table for more details
>
> the idea is that if a line starts with "//" or /* or * the next line
> will also be commented (with "// " in the first case, with "* " in the
> second one)
Again this seems way too complicated and doesn't seem to warrant the
saving of 2-3 keystrokes.
> > zz and zb are kind of hard to implement given the way vis works. Are
> > they really needed?
>
> well, yes.
Those are now implemented, although they (zb in particular) might not
always work as expected if wrapped lines are involved.
> > > 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.
>
> well, i will have to get used to it, then.
>
> but the current implementation, with parts of "my wishes" in it and
> parts missing, needs some more tweaks and thoughts to be reliable.
Probably, but at least now the multiple options can be tried easily.
> currently, with $ i get on the last char. if i type "x" i delete it.
> but if i type again the "x" i delete the end of li.
> not really what i would expect.
Why wouldn't you expect that? If you want to preserve the newline use 'X'.
> also, $ moves to the last char, then i can move right to the end of
> line.
Yes the same works in vim's insert mode. I don't want the cursor placement
to be dependent on the current mode. Therefore it is always possible to
do that.
> i'm not sure what is the use of having the end of line to be
> selectable, but if you chose to have it that way, $ should probably jump
> to it.
Yes, maybe. I'm not yet sure ...
> > > 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.
>
> well i think that eE, wW and bB are good enough
I was more thinking about the internal function names. Anyway should
work now. Although this turned out to be rather fiddly, not sure whether
all corner cases are handled correctly.
> > > 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.
>
> depending on what i'm doing, i tend to have many files open... and
> switch among them.
>
> most of the time i have multiple windows and the way to close file is
>
> :b#
> :bd#
>
> (:q or :bd would close the window, which is not what i want)
I added :bd with slightly different behaviour: it closes all windows
which display the same file as the currently focused one.
Hope you can live with that.
> > > :vnew :new to create new windows
> > > ctrl-w lhkj to move among windows
> >
> > These should work. Although no hierarchical window management is
> > implemented.
>
> well done... but...
>
> i really need a three column layout on big screens... and i like to
> have three columns with a small row on top.
> (the main reason being, that Y and P do not work across terminals...
> for obvious reasons...)
Not going to happen (at least not for now). Window management should be
the task of your window manager (or dvtm if you are working over ssh /
on a frame buffer).
In the long run, introducing a client/server architecture would allow
us to share the editor state (registers etc) across different terminals.
Anyway at the moment there are more important things to do. Therefore
the window layout code of vis is intentionally very simple (about 20 LOC)
and only supports equally sized windows arranged either horizontally or
vertically.
> > > - optional syntax highlighting
> >
> > do you mean a way to disable it?
>
> well, since there were some talks against syntax highlighting around
> here, i was thinking about a way of enabling it :-)
Eventually there should be a way to run a set of commands upon startup.
This way one could configure syntax and tab releated settings.
> finally, attached you find four small patches... i hope you'll find
> them usable.
Thanks! I applied the first 3 in one way or another. The pwd command
makes in my opinion not much sense. It should be done in a more generic
way, which allows to run arbitrary shell commands (e.g. :!pwd).
Thanks again for your feedback,
Marc
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Received on Sat Sep 27 2014 - 20:33:56 CEST