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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 1, 11:50am, Oliver Kiddle wrote:
} 
} 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.

Another possibility is that "zle -f" or whatever letter we assign is
one of those special variants like "zle -R" / "zle -I" which only
have an effect when run from inside another widget.  This hypothetical
zle-switch could set the flags that are to be in effect at the time
the widget completes.

This would make "zle auto-suffix-retain" equivalent to (for example)
"zle -f auto-suffix-retain" and then we just add other strings for
the other flags, rather than adding more special widgets (which
clutter the namespace and can be uselessly overridden with "zle -N").

} 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.

Agreed that this is less good than being able to control the effect
from inside the widget implementation.

} 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.

I'm not sure I understand this one.  Do you mean that any time one
of the yank-related widgets is called, its flags would "stick" to the
calling widget (at least until there was another later yank call)?

Still, it'd be nice if one could do e.g.

    LBUFFER+=$SOMENEWTEXT
    zle -f yank

to indicate that the insertion into LBUFFER should be treated like a
yank even though it wasn't actually using the kill ring.  Maybe there
is no valid reason for that.

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

Yes, that is an issue.  Probably I'd say than any future changes to
the content of BUFFER invalidate the whole yank state.  But that may
be an awful lot of new record-keeping.