> > > - 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. :)
Yes I agree documentation is lacking. Also error reporting is almost
inexistent. We should open a new buffer showing a backtrace when a Lua
error occurs etc.
> > > - 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?
Maybe, yes. However you probably want these features in combination with
regular syntax highlighting. Maybe a layered approach would somehow work
> > > - 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.
Strange, seems to work fine here.
> > > - 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?
Yes maybe that would work. The Lua API is still in its infancy.
> > > - 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`.
Ok, I do tend to agree. Changed.
> > > 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`).
The vis way of doing this would be an alias to `<vis-operator-shift-right>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.
This is another part which is underdocumented. As you noticed all mappings
in vis are recursive. Instead of non recursive mappings you can use all the
names of KeyAction as found in main.c to refer to their function by means
of these special keys. This for example allows to completely unmap all core
operators, I don't think this is possible in vim?
> 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.
Yes selections are currently per cursor and once the cursor is removed it
together with its selection can not be restored.
> 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.
Yes I agree.
> > > - 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?
No currently it is not.
Some people also wanted to build/use vis without Lua (hi pancake if you are
reading this ;) Therefore it is currently optional. However I generally think
the benefits outweight the costs of additional size/dependency etc.
> > > - 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.
Sorry, should be implemented now.
> > > - 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?
But this would break the entering `tX` multiple times use case ...
> > > - 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.
It is called slmenu and is currently used by vis-open to provide a basic
file name completion. Make sure you have vis-open and either slmenu or
dmenu somewhere in your $PATH and try `:e .`
> > > - 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"!
Thanks for the offer, I will gladly accept it when the occasion arises.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
Received on Sun Jan 17 2016 - 20:04:58 CET