Giters

martanne / vis

A vi-like editor based on Plan 9's structural regular expressions

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

improving man page

GReagle opened this issue · comments

commented

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"?
commented

Looking at config.h, I see that x is a normal keybinding, not an operator. Anyway, my question still applies to P.

commented

Hi, suggestions for improvement/patches are always welcome.

  • As you noted, x is an alias for dl, I wouldn't list them all.
  • P can probably be added
  • The v and V mapping in operator pending mode have been removed in e34b829, and should be removed from the man page.
commented

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.

commented

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

commented

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?

commented

It seems you are working with an outdated copy, 408fbe2 removed the reference for operator pending mode modifiers and ef7f3ec 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.

commented

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?

commented

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?

commented

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.