Re: psychiatric help

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 2026-04-06 09:43, Bart Schaefer wrote:
> Ir replaces zle-line-finish with _tt.  There's another mechanism
> called "hooks" for chaining together a series of functions all run at
> the time of the zle-line-finish event, but get your head around the
> single function first.
That's fine.  If zle-line-finish is auto-executed, cool that one can 
assign another function in loco parentis, sorta.  Comparable to an alias.
> You're probably looking in the wrong place.  Widgets aren't in the
> same namespace as shell functions.  To see the widget, use
No matter, it's a small thing.
> but what you really want is
>    BUFF=( ${(z)BUFFER} )
Right!  Gotta remember the outer parenthesis.  Easy to let that slip.

> BUFF is already a global (because you didn't declare it local).  You
> don't want or need to export it.
Right.  Just starting off with a belt and suspenders to be sure.
> > }
> > zle -N zle-line-finish ttt
> If that's all you're going to do you might as well stick with precmd.
> The point of using zle-line-finish would be to eventually assign
> something back to BUFFER again.
Na, all I want is to be able to *read* the unexpanded tail.
> You're asking for two mostly-incompatible things.  ZLE and history can
> be thought of as both working on units of user input, "tails" are in
> units of individual commands.
Right.  Maybe not so easy to isolate.
> It's a lot more complicated than this, but you can think of it as
>    1) Accept the input from the current prompt
>    2) Expand all the aliases
>    3) Repeat:
>      a) Gather everything up to a command separator
>      b) Expand all the globs and variables
>      c) Run the command from the first word
>
> You are looking for a cross of what's just after (1) with what's just
> after (3a), except that you want to access it in the middle of (3c).
> That doesn't exist anywhere.
I suspect I'd be happy at 3a).  The alias thing wouldn't be an issue.  
Come to think -- that's as it should be.
> Your current hack uses "noglob" at (2) to bypass some of (3b) and then
> "eval" inside (3c) to run a different command than what appeared at
> (1).  That may be the best you can do, but as you've noted it tends to
> be fragile around quoting and doesn't really get you exactly what
> you're seeking.
Well neither of us like  it, but it does work.  All my functions have 
been robust for a few years now, until  my: > % l 'test\ ?' < issue came 
up and it was trivial at worst and it's fixed anyway. As I said, I 
wasn't even sure if I should be worried about it at all.   Any further 
work on this is purely on principle.
> You're implementing a shell command parser in shell commands.  Ask the
> folks who implemented zsh syntax highlighting in ZLE how easy that
> was.
Right, I'm contemplating reinventing the wheel, and no doubt it would be 
harder than I expect.  BUT, if I could get hold of your '3a)' above, 
that would do it.  Dunno, I guess it can't be explained, but I feel in 
my C guts that a command should be able to interrogate it's own 
invocation string as a matter of first principles.  But in the shell 
universe that's just not considered important.  Not arguable.  Hebrew is 
written right to left and they aren't going to change that.

But if I could just sneak a peek at 3a) ...  If I had the skill I'd even 
hack that in the sources -- find 3a) in the code and just assign that to 
a global and voila, any function could see it's own invocation string.  
Could be useful, could open doors.  Could be functions that need to know 
what expansions might have taken place. If you've never seen a hammer 
you don't know how useful nails can be.  But it's not important.