hi marc andré
thank you very much for your reply and for implementing so many of the
features i've mentioned!
being still in digest modus and since i'm not getting the mails from
the archive it's a bit of a pain to reply...
> 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.
indeed, the pace you're adding features seems to be an indicator that
you did a good job!
> These should now all be fixed. If you (or somebody else) finds the
> time to test it, it would be appreciated.
i will do my best and test what has been implemented!
> These should now all be fixed. If you (or somebody else) finds the
> time to test it, it would be appreciated.
seems to be fixed, thanks!
> 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.
personally, i think i would prefer it as an editor setting...
> I know vim has other related options (shiftwidth, softtabstop) I
> never really understood why they are necessary. Therefore they are
> not implemented.
fine for me.
> smart indenting
well, mostly, i could work with a simple implementation that respect
some basic cases:
- if a line is indented the next line will be indented the same (except
one of the cases below applies)
- "{$" starts an indent and "^\s*}" finishes it (c languages)
- "^\s*- " starts an indent (text files and markdown... if no
programming language uses a dash followed by a space at the beginning
of a line... of course!)
- ":$" starts an indent (python)
- eventually "($" and "^\s*)" could behave like {s
there might be other cases. still, i would mostly concentrate on getting
a sane implementation that is helpful and always correct in the most
common cases, rather than implementing fancy rules that cover every
possible case.
if implemented, there should be an easy way to turn it off.
> > 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)
there is no intelligent behavior for finishing the comments.
> zz and zb are kind of hard to implement given the way vis works. Are
> they really needed?
well, yes. searches often end up with the result being at the
bottom of the screen.
zz puts it in the center and it's easy to see the context.
this is the one of the three i use the most.
when jumping to the beginning / end of a function with %, it happens to
me to use zt, sometimes zb.
> > 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.
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 line char.
not really what i would expect.
also, $ moves to the last char, then i can move right to the end of
line.
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.
> > 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
> > 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)
> > :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...)
something like this:
+--------+--------+---------+
| | | |
+--------+--------+---------+
| | | |
| | | |
| | | |
+--------+--------+---------+
normally fills my fullscreen terminal on the big imac at work...
i would suggest to restrict it to full rows and columns and not allow
+--------+--------+---------+
| | | |
+ | +---------+
| | | |
| | | |
| | | |
+--------+--------+---------+
which also does not work well in vim either.
[long pause to have a look at the vis code]
and, well, personally i'd like to have hjkl to move in the four
directions and not just previous and next...
but, for this, the list of windows should be a table and not a list...
> > 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 ...
i wouldn't mind if it would work across buffers.
but the implementation is probably the same for both cases.
> > - 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 :-)
finally, attached you find four small patches... i hope you'll find
them usable.
ciao
a.l.e
Received on Thu Sep 25 2014 - 13:35:11 CEST