On Sat, Jan 16, 2016 at 07:09:26PM +0100, Markus Teich wrote:
> Marc André Tanner wrote:
> > Did you (or anyone else) try it? First impressions? Which features did you
> > miss the most?
>
> Heyho Marc,
>
> I built the standalone version and tried some stuff. I also went through my
> vimrc to find any features I would like to use. Here are my comments in no
> particular order.
Thanks! Exactly the kind of constructive feedback I was looking for.
> - Why did you choose to use full black instead of the base03 color from
> solarized?
>
> - Even after "fixing" the above the colors don't look like solarized in any way.
> If you don't know about this yet, I can provide a screenshot.
Yes I noticed this too and it is the reason why full black was used (to increase
the contrast). As vis currently uses curses there seems to be no clean way to
support true colors[0]? What happens at the moment is that the given 24bit color
is converted to the closest color of the terminal 256 color palette. This color
conversion code was imported from tmux.
Strictly speaking we do not need to display many colors we just want to specify
them as RGB values. Curses provides a init_color(3) API to change the
defintion of the color palette. However I'm not sure how many terminals actually
support these color chaning capability.
Anyway up until now I didn't realize solarized had a 256 color degraded
version[1,2]. I changed the default 256 color theme to that. Is it better now?
> - Could you make `~` an instant action? Changing stuff to upper xor lower case
> can already be done by `gu` and `gU` and switching case on more than one
> character rarely makes sense. Also you could use visual mode for that.
I personally don't really care, but it was requested before. Changed.
> - How am I supposed to set my default theme/tabwidth/relativenumber/… settings?
> I could not find the option in config.h.
By changing visrc.lua:
vis.command('set <your-option>')
> - In vim I have setup tabs not to display a special "tab" character, but to use
> a slightly different background color (base02 instead of base03). This also
> applies to whitespace at EOL. How could I achieve that with vis without
> patching every syntax lexer?
At the moment this can not be done easily. The tab replacement symbols are
currently hard coded in view.c and there is no distinction made between "regular"
whitepace and trailing whitespace.
In the long term it might be a good idea to move the implementation of all
these display related things (i.e. :set show tabs newlines spaces, cursorline,
colorcolumn etc.) from the C core into Lua.
> - Using `set show newlines 0` (also for tabs and spaces) does not work.
Use `set show newlines=0` for now.
> - I miss the vim-like commandline shortcuts (`:e` instead of `:edit`)
In general this is already implemented i.e. a shortest unique prefix
match is used. The problem was that `:e` was ambiguous it could either
refer to `:edit` or `:earlier`. I have now added an explicit alias
to break the tie.
> - What about automatic text wrapping?
Are you referring to the automatic insertion of new lines? Not a big fan.
I prefer an external tool such as fmt(1) which is hooked up to the `=`
operator.
> - Why do you keep the default vim behaviour of `Y`? Please make it consistent
> and just yank until EOL and not the whole line.
Is this really consistent? For example `S` also operates on the whole line ...
> Also with `<` and `>` in
> visual mode: It should not loose the visual selection, so you can (un)indent
> the lines multiple levels without using `gv` inbetween.
I agree that the current vis behaviour is not ideal. The cursor placement
after those shifting operators is off. Furthermore vis does not support
any form of visual-repeat hence the dot `.` command is rather useless in
this case.
Special casing the operators `<` and `>` would be possible:
diff --git a/vis.c b/vis.c
index ba220c0..1474f96 100644
--- a/vis.c
+++ b/vis.c
_AT_@ -546,7 +546,10 @@ void action_do(Vis *vis, Action *a) {
} else if (vis->mode == &vis_modes[VIS_MODE_OPERATOR_PENDING]) {
mode_set(vis, vis->mode_prev);
} else if (vis->mode->visual) {
- vis_mode_switch(vis, VIS_MODE_NORMAL);
+ if (a->op != &vis_operators[VIS_OP_SHIFT_LEFT] &&
+ a->op != &vis_operators[VIS_OP_SHIFT_RIGHT]) {
+ vis_mode_switch(vis, VIS_MODE_NORMAL);
+ }
}
text_snapshot(txt);
vis_draw(vis);
Not sure if it is the right thing to do though.
> - `*` does not behave the same as in vim. When using star on `view->bla` it
> should search for `\<view\>`, but it also found `view_draw`, so there seems to
> be something wrong with the word delimiters when used by `*` (searching for
> `\<view\>` produces the expected result.
There are no word delimiters used at all for the search string. In this case `*`
is identical to `/view`. I'm actually surprised `\<view\>` works, does POSIX
specify that (vis currently uses regex(3) function from libc to implement the
search functionality).
> Also the search string generated by
> pressing `*` should be added to the search history.
Ok, history support is fairly new (see also related comments below).
> - Is hlsearch planned?
Not concretely, but it was requested before and seems like a useful thing to
have. incsearch was also mentioned.
In general search suffers from some architectural limitations. It is
not cancelable (some kind of async job framework to run long running
task might be handy) and doubles memory consumption because the complete
buffer is copied.
> - I frequently use C-a and C-x to do basic addition/subtraction in vim.
Really? Never used them. Vim seems to support all kinds of formats
(decimal, hex, octal) which is road to madness ...
> - Any possibility to hook up a setting depending on the currently active mode? I
> like to have relativenumber in normal+visual mode while having normal line
> numbers in insert mode. Changing all the bindings in config.h seems a little
> tedious.
This is currently not possible. If we want this kind of functionality
it should probably be done by exposing certain events to Lua scripts.
> - Could you replace the `0` in relativenumber mode with the actual line number?
> Moving up/down 0 lines is not that hard without having the `0` in front. ;)
>
> - Could you explain the concept behind the commandline history? When I used it
> to run a slightly changed previous command, the history was changed as well.
It is fairly new and not completely thought through ;) It is a regular file,
if you select an entry by pressing `<Enter>` the line will be moved to the
end of the file. At the moment if you want to keep the old version you would
have to <Escape> to normal mode copy it and change it.
> - Why the `:saveas` command? Couldn't you just use an optional argument to `:w`?
It is not the same. `:w` will write to the given file but keep the old name,
that is the next `:w` will save to the old/previous name. Whereas `:saveas`
will change the associated file name.
> - Are you planning to implement buffers / having multiple files open at the same
> time? I often use the `switch to last used buffer` feature of vim.
Maybe. I haven't really missed it so far. Hence it wasn't a priority.
> - I noticed `d2tX` is not working as it is in vim. Is there a way to achieve the
> same deletion within vis in >= 4 keystrokes or is this also the "bug"
> mentioned in the README?
With the current design the motions do not know about the given count.
Instead the motion is performed a second time from the resulting postion
of the previous one. Unfortunately this does not work for motions
which are idempotent. What vis does is equivalent to `vtXtXd` in vim.
The fix is to adjust the cursor position before performing the subsequent
motions similarly to how it is done for text objects with a count.
> - What about word/file/line completion in insert mode?
Yes, not entirely trivial, should probably done via an external process?
Will probably need quite some architectural changes, a proper main loop
for a start ...
> - Why you no implement `g?`? ;)
Did not yet miss it. Although I have heard of people who use it for
interactive tutorials/exercise sessions. Where the questions are written
in plain text and the corresponding answers are rot13 encoded until
revealed ...
> I can probably help implementing a few of the mentioned features, but I would
> like to hear your oppinion on them first. Great work so far, I planned to check
> vis out quite a while ago and finally found the time.
Thanks for your useful feedback, more people reviewing/improving the
code are certainly welcome!
Marc
[0]
http://invisible-island.net/ncurses/ncurses.faq.html#xterm_16MegaColors
[1]
http://ethanschoonover.com/solarized/vim-colors-solarized#important-note-for-terminal-users
[2]
https://github.com/altercation/vim-colors-solarized/blob/master/colors/solarized.vim#L301
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Received on Sun Jan 17 2016 - 14:06:05 CET