zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: dana <dana@dana.is>
Cc: Zsh workers <zsh-workers@zsh.org>
Subject: Re: [PATCH] Completion: Improve _man
Date: Sun, 10 Jun 2018 15:07:34 +0200	[thread overview]
Message-ID: <17923.1528636054@thecus> (raw)
In-Reply-To: <9B2A476B-3C9F-4757-9818-4815A9417253@dana.is>

dana wrote:
> Here's a *much* more complicated change. It enhances _man as follows:

This looks like a big improvement, thanks.

> * Complete all options to most major man variants
> * More accurately match sections
> * Better handle certain edge cases (see below)
> * Show descriptions for sections (suggested by Mikael i think)

Those look useful.

> Notes:
>
> * The function would previously use the provided section name as the leading
>   part of a directory pattern, so that on Solaris for example if you gave it 3p
>   it would also complete pages from 3pool, 3proc, &c. I couldn't think of a
>   reason this functionality would be desirable (man won't show you a page from a
>   section it's not in anyway), so i made it match exactly

Is this the line where you removed * from:
  dirs=( $^_manpath/(sman|man|cat)${^sects}*/ )

I think I've seen systems with directories named man1.Z/cat1.Z etc.
HP/UX perhaps. Perhaps also locales have occured such as man3f.fi_FI
I suspect the * was to handle something like that rather than for the
undesirable functionality you describe.

> * I chose sections to describe pretty arbitrarily. Solaris variants have 9034234
>   different sections and i didn't want to enumerate every single one, but some

I'm only seeing 270 sections, still too many to start enumerating them.

It looks like the sections will be changing with Solaris 11.4:

https://blogs.oracle.com/solaris/normalizing-man-page-section-numbers-in-solaris-114-v2

>   of them seem like they might come up a lot in regular use. It may be nice in
>   the future to give separate tags to the described and undescribed ones, so
>   that navigation is a little nicer for people with `group-name ''`

Am not so sure about that. Navigation seemed fine without. And _describe
doesn't currently support a mix of tags.

> * Could someone please review the way i return from _arguments? I don't think
>   it's correct (because it doesn't account for prefix-needed?), but i've been
>   looking at this for too long

Indeed, with the prefix-needed style set, _arguments adds the options
and then we should also add man pages in the state. (I use this with
_approximate to handle mistakes in the prefix itself). As it is, by
doing a return, the function ends before the state can be handled.
Usually, this is solved with a ret variable, but care would be needed
not to disturb the existing ret variable used later in the function. A
lazy alternative is to use $compstate[nmatches]

> I've tested this on several different platforms, but it's still a pretty major
> alteration to a function that i imagine sees a lot of traffic, so i'm a little
> nervous about it. If someone else could try it out that might be a good idea

For the most part, this looks great. I'll push it as-is for now. Any
further tweaks can then be done as incrementals diffs.

> +   '(-X --gxditview)'{-X-,--gxditview=-}'[display output in gxditview using specified DPI (default: 75)]::DPI' 

It's a minor thing but I find it more useful to put hints on the
arguments (units, defaults) etc in the heading for them.

  '(-X --gxditview)'{-X-,--gxditview=-}'[display output in gxditview optionally using specified resolution]::resolution (DPI) [75]'

> +  [[ $state == sects ]] && {
> +    local s
> +    local -a specs
> +
> +    (( $#sects )) || {
> +      _message 'manual section'

This should use _message -e and a tag so that it honours the user's
setting of the format style with the descriptions tag. And, to allow
the user to add some matches with the fake style.

> +      return 1
> +    }
> +
> +    # Build specs from descriptions
> +    for s in $sects; do
> +      specs+=( "${s}[${(b)sect_descs[$s]}]" )
> +    done

This results in all sections for which we don't have a description
getting an empty description. The descriptions that we have are then
pushed right over to the right like this:

3zonestat    5openssl  5oldap   4b                                          
7openssl     8oldap    7ipp            --                                     
1openssl                               -- OpenSSL commands                    
1t                                     -- Tcl/Tk features  

Try:
  _values x {a,b,c,d,e,f}'[]' 'g[description]'
vs.
  _values x {a,b,c,d,e,f} 'g[description]'

I'd suggest using _sequence wrapping _describe instead.
Initialise sect_descs in _describe format to begin with and then it can
be filtered like this:

  sect_descs=( 1:one 2:two )
  sects=( 1 2 3 4 )
  remove=( ${sect_descs%%:*} )
  sect_descs+=( ${sects:|remove} )

_describe also makes it easier to apply a more useful tag than just
values which can match the one from _message -e mentioned above.

Oliver


  reply	other threads:[~2018-06-10 13:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-10  6:06 dana
2018-06-10 13:07 ` Oliver Kiddle [this message]
2018-06-10 14:02   ` dana
2018-06-11 10:48     ` [PATCH] Completion: Improve _man (2) dana
2018-06-14  9:50       ` Daniel Shahaf
2018-06-14 10:20         ` dana
2018-06-15 13:59           ` [PATCH] Completion: Improve _man (3) dana
2018-06-15 14:05             ` Daniel Shahaf
2018-06-15 14:21               ` dana
2018-06-15 14:39                 ` Mikael Magnusson
2018-06-15 14:55                   ` Daniel Shahaf
2018-06-15 15:14                     ` dana
2018-06-15 15:36                       ` Peter Stephenson
2018-06-15 17:27                     ` Mikael Magnusson
2018-06-15 14:47                 ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17923.1528636054@thecus \
    --to=okiddle@yahoo.co.uk \
    --cc=dana@dana.is \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).