Open GReagle opened 3 years ago
Looking at config.h, I see that x is a normal keybinding, not an operator. Anyway, my question still applies to P.
Hi, suggestions for improvement/patches are always welcome.
x
is an alias for dl
, I wouldn't list them all.P
can probably be addedv
and V
mapping in operator pending mode have been removed in e34b829bbb284972dd391ae00b22274e47d55f16, and should be removed from the man page.Thanks for your feedback. I'll make a branch and changes and a pull request. I see that ~ needs to be changed to g~ in the man page.
Why are J and gJ not listed as operators in config.h, but are listed as operators in vis.1? Is there a meaningful difference between bindings_operators[]
and bindings_normal[]
?
I would like to list ZQ
in the man page since it is significantly easier for me to type than :q!
. Where in the man page should it go?
It seems you are working with an outdated copy, 408fbe2e7b0acab616d1140f74deeb2378f68586 removed the reference for operator pending mode modifiers and ef7f3ec0c53fc8b7ec193d292b4555d162219d8b updated ~
.
J
and gJ
are a bit special in that they don't take a motion, i.e. from normal mode they don't switch into operator pending mode, but instead use an implicit range up to the next line. In that sense they are not typical operators.
In fact, in a more selection oriented workflow they could probably be implemented as a mapping for a structural regexp command. So it also depends on the definition of operator. For example gu
, gU
and g~
no longer take a motion/text object either, but instead operate on the existing selections.
Thank you for your response. Yes I was using an older version; I'm sorry about that. I am now working with the latest git version.
Is it true that in vis the selection can never be empty, i.e. it must be at least one character?
The "operators" don't do anything when first pressed, i.e. they wait for a motion or text object to be entered. These operators include c, d, y, <, >, and in config.h they follow the pattern of ACTION(OPERATOR_
. Vim shows in the status (bottom) line the name of the operator when it is waiting for more input, which I think is helpful visual feedback. Why doesn't vis do this?
Some of the commands (maybe the rest of them?) act immediately, such as =, gu, gU, g~, J, gJ, p, P. This seems to be different than vim where gU and =, for example, do not act immediately. Why the difference from vim? Should vis's documentation somewhere include which commands are immediate and which ones wait for more input?
For example
gu
,gU
andg~
no longer take a motion/text object either, but instead operate on the existing selections.
So they used to act like gu, gU, and g~ in vim, but they were changed so now they don't. Why were they changed, and why make them different from the vim commands? There seems to be a consistency problem in vis in that some of the commands wait and others are immediate, when invoked from normal mode. When invoked from visual mode, they seem to be consistent in that they all work on the visual selection.
Greetings. Before I start investing time into making changes and submitting a pull request, I want to know if you want the kind of improvements that I plan.