search

martanne / vis

A vi-like editor based on Plan 9's structural regular expressions
Other
4.22k stars 256 forks source link

improving man page #886

Open GReagle opened 3 years ago

GReagle commented 3 years ago

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.

  1. In the list of vi Operators, I do not see P or x. Shall I add them to the man page?
  2. How about changing "Operators can be forced to work line wise by specifying V" to "Operators can be forced to work line-wise by prepending V"?
GReagle commented 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.

martanne commented 3 years ago

Hi, suggestions for improvement/patches are always welcome.

GReagle commented 3 years ago

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.

GReagle commented 3 years ago

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[]?

GReagle commented 3 years ago

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?

martanne commented 3 years ago

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.

GReagle commented 3 years ago

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?

GReagle commented 3 years ago

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?

GReagle commented 3 years ago

For example gu, gU and g~ 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.