Re: [Man-db-devel] [PATCH v2] man(1): add .N names

[Mihail Konev]

In Oct 2016, Colin Watson wrote:
> On Mon, Oct 03, 2016 at 08:50:11PM +0000, Mihail Konev wrote:
> > `man chmod..` is now the same as `man -f chmod`
> > `man chmod...` is now the same as `man -k chmod`
> > `man chmod....` is now the same as `man -K chmod`
> 
> I'm afraid I really don't like this at all, sorry.  It's much too weird
> and idiosyncratic, and it means that the way the whole command line is
> parsed depends on the content of a single non-option positional
> argument.  Fixing that part of it would require quite a bit more code to
> switch behaviour for each positional argument, and in some cases it's
> not obvious how that could be done in a way that wouldn't be excessively
> confusing.
> 
> In any case, I don't think this pulls its weight.  At best it saves a
> single character, and at worst it's actually more characters.  That
> isn't worth complicating man(1)'s already-labyrinthine argument handling
> further.

On Sun, Nov 20, 2016 at 04:26:30PM +0000, Colin Watson wrote:
> On Sat, Oct 29, 2016 at 07:11:45AM +0500, Mihail Konev wrote:
> > On Mon, 3 Oct 2016 23:05:11 +0100, Colin Watson wrote:
> > > On Mon, Oct 03, 2016 at 08:50:11PM +0000, Mihail Konev wrote:
> > > > `man chmod..` is now the same as `man -f chmod`
> > > > `man chmod...` is now the same as `man -k chmod`
> > > > `man chmod....` is now the same as `man -K chmod`
> > > 
> > > In any case, I don't think this pulls its weight.
> > 
> > All five are doable in ~/.bashrc with sed+grep or perl,
> > which is then portable.
> > 
> > So probably 'man chmod.2' should not go either,
> > because it would be unique to 2016+ Linux/Hurd then.
> 
> I'm not averse to new features as long as I think they decrease rather
> than increasing confusion :-), hence why I accepted the .N part of it.
> 

> At best it saves a single character, and at worst it's actually more 
> characters.
Yes; but then once page title is found, no need to go back an argument,
and delete the switch there;
backspace is enough, and if search term has to be added to, then also
no need to go to end of line.

> Unmemorable way to avoid using an option
But only one way vs. three options.
And it covers absolute majority of use cases.
Also, it means no need to bother about 'apropos' vs 'whatis' vs man -
just dot it.

> it means that the way the whole command line is
> parsed depends on the content of a single non-option positional
> argument
Dots should be restricted to a single argument not to interfere with
other options.
I.e. ignore them if argv != 2.

Manpage could be patched first, reviewed, then the patch changed.