Smarter matcher-list: skip previous sets

Smarter matcher-list: skip previous sets

[Daniel Hahler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've noticed that my matcher-list setup causes a (possibly expensive)
completion function to be called multiple times, although the input was
not be changed by the matcher-list substitution.

The functrace is:

    _manage.py:4 _manage.py:465 (eval):1 _dispatch:63 _normal:40 _complete:117
    _main_complete:194 _zsh_highlight_widget_complete-word:0 zsh:1

My matcher-list setup:

    zstyle ':completion:*' matcher-list '' '+m:{a-z}={A-Z}' '+m:{A-Z}={a-z}' \
      '+r:|[._-]=* r:|=*' '+l:|=* r:|=*'

I think it would be smart if these calls would be skipped in case the
input has not changed (because it was all lower-case in the beginning).


Regards,
Daniel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iD8DBQFVWmOkfAK/hT/mPgARAoJ2AKCM8iSQ8kaL92BTCT3ojQaxYHp1ywCgzz8Z
GEJGEy+nvPR9VBEbfrdfUDc=
=Q/cu
-----END PGP SIGNATURE-----

Re: Smarter matcher-list: skip previous sets

[Bart Schaefer]

On May 19, 12:11am, Daniel Hahler wrote:
}
} I've noticed that my matcher-list setup causes a (possibly expensive)
} completion function to be called multiple times, although the input was
} not be changed by the matcher-list substitution.
} 
} I think it would be smart if these calls would be skipped in case the
} input has not changed (because it was all lower-case in the beginning).

Unfortunately the matcher-list is handled as a loop in the shell code in
_main_complete, which has no way to tell whether the "input" is or is not
"changed" by any particular matcher.  You're assuming an implementation
of matchers that doesn't (ahem) match what actually happens internally.

Matchers don't "change" the input in any way; they alter the comparison
of the input to the set of possible results, and each such comparison is
independent of those that preceded it.  The *output* may be changed based
on which elements of the result set are selected.

-- 
Barton E. Schaefer

Re: Smarter matcher-list: skip previous sets

[Daniel Hahler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19.05.2015 02:44, Bart Schaefer wrote:
> On May 19, 12:11am, Daniel Hahler wrote:
> }
> } I've noticed that my matcher-list setup causes a (possibly expensive)
> } completion function to be called multiple times, although the input was
> } not changed by the matcher-list substitution.
> }
> } I think it would be smart if these calls would be skipped in case the
> } input has not changed (because it was all lower-case in the beginning).
>
> Unfortunately the matcher-list is handled as a loop in the shell code in
> _main_complete, which has no way to tell whether the "input" is or is not
> "changed" by any particular matcher.  You're assuming an implementation
> of matchers that doesn't (ahem) match what actually happens internally.
>
> Matchers don't "change" the input in any way; they alter the comparison
> of the input to the set of possible results, and each such comparison is
> independent of those that preceded it.  The *output* may be changed based
> on which elements of the result set are selected.

But is it necessary then to call the completion function multiple times?
Couldn't the matchers just loop over the result that has been collected
once?

If I understand it correctly, the possible results would be the same
every time?  (at least that's the case for the expensive completion
function, where I've noticed it).

Where is the $_matcher used?
Is it in Completion/Base/Core/_description, in the opts to compadd?

What would be a possible solution to improve handling with many
completers/matchers?


Regards,
Daniel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iD8DBQFVWvlGfAK/hT/mPgARAigUAKCiubdTM7JYYRlA1d2muHFm4O/v0ACg/IvO
xHLF7p+ny8de/8RwASKHMjc=
=AsuP
-----END PGP SIGNATURE-----

Re: Smarter matcher-list: skip previous sets

[Bart Schaefer]

On May 19, 10:50am, Daniel Hahler wrote:
}
} But is it necessary then to call the completion function multiple times?
} Couldn't the matchers just loop over the result that has been collected
} once?

Every (completer, matcher) pair might call different completion functions
or make different changes to the context.  _main_complete doesn't know
what the internals of a completer are going to do, so it has to make the
call for each possible pair.  It does attempt to break out of the loops
as soon as the exit status indicates that matches have successfully been
generated.

} If I understand it correctly, the possible results would be the same
} every time?

No, not necessarily.

} Where is the $_matcher used?
} Is it in Completion/Base/Core/_description, in the opts to compadd?

Yes, but also in _path_files.  More often _matcher_num is referenced,
so that completers that don't care about _matcher can become no-ops
after the first attempt.  Cf. Completion/Base/Completer/_menu 

} What would be a possible solution to improve handling with many
} completers/matchers?

There's no generic solution, this was discussed in agonizing detail
back when the completer/matcher loops in _main_complete (and in _prefix
and in _ignored) were put in place.  It's up to individual completers
or completion functions to avoid doing redundant work, which may be a
point that (a) should be made in the doc somewhere and (b) has been
forgotten in more recently-invented functions.