Heyho Marc,
Marc André Tanner wrote:
> On Sat, Jan 16, 2016 at 07:09:26PM +0100, Markus Teich wrote:
> > - 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?
Actually it did not help. Here is a screenshot of the new standalone build of
vis with the solarized.lua file opened in st:
http://fs.tum.de/~teichm/Media/vis_wrong_colors.png
My st already has the solarized theme set up for the first 16 color slots, so
setting theme to default-16 kind of works (background color is base02 instead of
base03, but I might figure that out myself).
> > - 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.
Thanks.
> > - 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>')
Thanks, I missed that in the README. However there should be a few examples. I
just tried to insert the vis.command in global context and got a SEGFAULT. After
moving it to the win_open event handler context, it worked. :)
> > - 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.
Maybe a global default 'syntax highlighter' applied regardless of file type
could do the job?
> > - Using `set show newlines 0` (also for tabs and spaces) does not work.
>
> Use `set show newlines=0` for now.
Still does not work. After enabling one of the `show` settings, I am unable to
reset it again. I have to restart vis.
> > - 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.
Thanks.
> > - 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.
I have a pretty wide screen (>250 symbols in default zoom levels), where editing
long blocks of text becomes much easier with the automatic wrap after 80
columns. Without it, navigating gets a little tedious without running the
formater manually each time I have to jump around in the text. Maybe an event
could be introduced as well here, so you can enter the newline from lua?
> > - 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 ...
Thats right, `s` is a little different, since it is an instantaneous action. For
applying an opperand to the whole current line, there is already the "double"
shortcut (e.g. `dd`, `yy`, …), so I thing changing Y to only yank until EOL is
at least making it consistent with D and C. If you want "s until EOL", you
should use `C`. The only reason for `s` to exist would be to have a shortcut for
`cl`. `S` can also be done with `cc`.
> > 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:
>
> …
>
> Not sure if it is the right thing to do though.
I tried to do it with an alias in config.h, but it was recursive and therefore
vis froze. (aliasing `>` in visual to `>gv`). Adding something like nonrecursive
aliasing or allowing to chain two actions together (OPERATOR_SHIFT_… and
SELECTION_RESTORE) would solve the issue without the hardcoded fix.
Another possibility would be to implement movements for jumping to the beginning
or end of the last visual selection.
I also tried aliasing `>` in visual to `I>><Escape>gv` with multi-cursors, but
they seem to create their own selection so the `gv` at the end does not work as
I thought it would.
Basically I don't think hardcoding the fix is correct.
> > - `*` 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).
I also was surprised, `\<view\>` works as it should. I propose to change
CURSOR_SEARCH_WORD_… to use `\<WORD\>` as regex instead of just `WORD` to
achieve the same functionality as in vim.
> > - 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.
This might be done with the global "syntax highlighter" mentioned above. It has
to do the matching once per window change and then it should complete reasonably
fast. As a sidenote: The hlsearch should of course be disableable (nice word!)
and reenableable (even nicer word!) on the fly.
> > - 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 ...
Might be done in lua as well, I only use decimal with that feature. Is it
already possible to call lua from keybindings?
> > - 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.
Sounds good to me.
> > - 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. ;)
You seem to have missed that question. This behaviour is fairly new to vim as
well.
> > - 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.
Ah, I didn't notice it behaves like a normal file.
> > - 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.
Okay, makes sense.
> > - 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.
Interesting, I just noticed when entering `tX` multiple times vim will not go to
the next match, but when entering `fX` multiple times it will.
> 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.
Hm, maybe changing the imlementation of TO_…/TILL_… to ignore the one character
under/after the cursor is less of a workaround?
> > - 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
> ...
I think I've read about some dmenu port to (n)curses, but I can't find a
reference.
> > - 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 ...
Wow, if we actually meet some time (slcon 2016?), you are eligible for a free
beer for actually pointing out a reasonable use-case of this "feature"!
--Markus
Received on Sun Jan 17 2016 - 18:03:32 CET
