zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Marlon Richert <marlon.richert@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH 2/3] Make dynamic dir completion easier to implement
Date: Mon, 15 May 2023 11:04:21 +0200	[thread overview]
Message-ID: <87849-1684141461.166701@hHTP.8k7X.OiI5> (raw)
In-Reply-To: <20230505114154.76547-2-marlonrichert@users.noreply.github.com>

Sorry for not reviewing this sooner. Thanks for following up to Aaron's
reply with a bit more detail as that does help.

On 5 May, Marlon Richert wrote:
>
> In the pre-patch example, the recommended way of implementing this was
> as follows:
>   _wanted dynamic-dirs expl 'dynamic directory' compadd -S\] ...
>
> However, this is problematic for the following reasons:
> - The proper place for handling _wanted or other tag logic is in the
>   completion function _dynamic_directory_name, not in each dynamic dir
>   name function separately.

That's questionable. Adding a tag loop outside as in your patch probably
makes it easier for someone to setup dynamic directories. It does
simplify the example. And it doesn't stop people using their own tag
loop - that can be necessary where the dynamic names are broken down
into components for the purposes of completion. So I've no objection
to the change. There are aspects of having nested tag loops that isn't
ideal but it's better than no tag loop.

> - The naming styles of the tag and group are not consistent with those
>   used for non-dynamic named directories, namely 'named-directories' and
>   'named directory', respectively.

That's specific to the example in the documentation. For many real
cases, the text used for dynamic directories can be more usefully
described in some other way. Such as 'recent directory index' in the
cdr example.

> - The example always inserted a `]` suffix, even if the suffix was
>   already present on the command line, leading to a double `]]` on the
>   command line.

Yes, that's not good. And passing the suffix to the function as a
parameter is a good approach to take.

> -local func
> -integer ret=1
> +if (( $#dirfuncs )); then
> +  local -a expl=()
> +  local -i ret=1
> +  local func=

There's no need to explicitly assign empty values. The function isn't
even relying on the initial value and local does reset the value to be
empty anyway.

> +  local tag=dynamically-named-directories
> +  [[ -z $ISUFFIX ]] &&
> +      local suf=-S]

This will only declare the variable suf local if the condition evaluates
to true. If it is false, we could be picking an unwanted value and
pass it to compadd.

Aside from that, I don't think the condition is correct because the user
could be completing in the middle of a word. zsh_directory_name_cdr uses

  [[ $ISUFFIX = *\]* ]] || addsuffix='-S]'

Within _dynamic_directory_name, I think it should be just
  [[ $ISUFFIX = \]* ]]

> -if [[ -n $functions[zsh_directory_name] || \
> -  ${+zsh_directory_name_functions} -ne 0 ]] ; then
> -  [[ -n $functions[zsh_directory_name] ]] && zsh_directory_name c && ret=0
> -  for func in $zsh_directory_name_functions; do
> -    $func c && ret=0
> +  _tags "$tag"
> +  while _tags; do
> +    while _next_label "$tag" expl "$descr"; do
> +      expl+=( $suf )

You can simply add $suf to the end of the call to _next_label and it
will add extra options to $expl:

  while _next_label "$tag" expl "$descr" $suf; do

The cdr functions that Bart mentioned need their own descriptions but at
least zsh_directory_name_cdr could be tweaked to take advantage of the
suffix now being passed to it.

I don't see this breaking any existing dynamic directory functions which
was my initial worry before looking at the changes more closely.

Oliver


  parent reply	other threads:[~2023-05-15  9:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-29 18:07 Patch 1/3: Fix prefix insertion logic Marlon Richert
2023-04-29 18:08 ` Patch 2/3: Make dynamic dir completion easier to implement Marlon Richert
2023-04-29 18:09   ` Patch 3/3: Fix subscript completion bugs inside ~[...] Marlon Richert
2023-04-29 18:58 ` Patch 1/3: Fix prefix insertion logic Felipe Contreras
2023-04-29 19:02   ` Marlon Richert
2023-04-29 19:17     ` Bart Schaefer
2023-05-01 21:08     ` Aaron Schrab
2023-05-01 22:03       ` Bart Schaefer
2023-05-05 11:41         ` [PATCH 1/3] Fix _prefix " Marlon Richert
2023-06-07  6:03           ` Marlon Richert
2023-06-08 12:41             ` Jun. T
2023-06-15 14:11             ` Marlon Richert
2023-05-05 11:41         ` [PATCH 2/3] Make dynamic dir completion easier to implement Marlon Richert
2023-05-06 17:28           ` Bart Schaefer
2023-05-13 17:30             ` Bart Schaefer
2023-05-15  9:04           ` Oliver Kiddle [this message]
2023-05-05 11:41         ` [PATCH 3/3] Fix subscript completion bugs inside ~[...] Marlon Richert
2023-05-01 22:37     ` Patch 1/3: Fix prefix insertion logic Felipe Contreras
2023-05-01 22:52       ` Bart Schaefer
2023-05-02  4:49         ` Felipe Contreras
2023-05-02 19:16           ` Bart Schaefer
2023-05-02 20:14             ` Felipe Contreras
2023-05-05 11:51           ` Marlon Richert
2023-05-05 12:38             ` Felipe Contreras
2023-05-05 15:04             ` Mikael Magnusson
2023-05-06 17:23               ` Bart Schaefer
2023-05-01 23:36       ` Vin Shelton
2023-05-18 20:44 [PATCH 2/3] Make dynamic dir completion easier to implement Marlon Richert

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=87849-1684141461.166701@hHTP.8k7X.OiI5 \
    --to=opk@zsh.org \
    --cc=marlon.richert@gmail.com \
    --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).