Re: PATCH v2 (complete): Implement zle -P

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Mikael Magnusson wrote:
> 
> Indeed, I'm not sure if a user can figure out which widgets are useful
> to override in this way.  Would it be more useful to just do what Wayne
> did originally and let zle -N take some flags that specify which specific
> flags the new widget should have after all? The advantage of this method
> is that if we add more flags, users can wrap those widgets without us
> remembering to add a new zle -N flag as well.

I think that approach is better than the prototypes. Otherwise, users
will end up needing to dig into the source code to find arbitrary
widgets that happen to have the right combination of flags. It is a
lot easier to document a list of flags. It would also make it easier
to only offer a subset of the ZLE_ flags. Allowing a flag requires us
to do the work of fully checking the implications of making that flag
user-tweakable. It might also constrain us in the future as we preserve
backward compatibility if we don't limit those that are available.

If we do go down the route of allowing flags to be set for widgets, it
needn't be specific to user-defined widgets. I currently use the
following:
  vi-cmd-suffix-retain () {
    zle auto-suffix-retain
    zle vi-cmd-mode
  }

That might just be zle -f auto-suffix-retain vi-cmd-mode
That should not be possible for the dot variants - .vi-cmd-mode
The opposite might also be needed with +f or a no- prefix.
That could also lead to a way to make self-insert not clear the current
region by making that behaviour a flag. See 33626

As Bart mentions in 28560, the auto-suffix-retain precedent would
suggest that we should perhaps consider another yank-pop-enable widget
(or perhaps hold-yank-state given that this now affects highlighting and
not just yank-pop). An advantage of that approach over the flags is that
the full implementation of the widget is contained within the function
definition file. With the flags, we might end up needing something like
#compdef so you can put #zledef -f yank as the first line of the
function definition. Another possibility would be to try to make
something like hold-yank-state automatic - assuming that hypothetical
widget was called after every yank/yank-pop/vi-put-* in a user-defined
widget.

Either way, how can we be sure that yankb/yanke are even vaguely
sensible after the user-defined widget has finished?

Oliver