Re: "drop-in replacement" and transpose-words-match

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 19,  9:28am, Sebastian Gniazdowski wrote:
} Subject: Re: "drop-in replacement" and transpose-words-match
}
} On 19 January 2016 at 07:31, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > [I would probably save CURSOR and MARK, set CURSOR to zero, then loop
} > on "zle forward-word" until I reached or passed the old CURSOR, rather
} > than try to match up the results of (Z:n:) to $BUFFER.  Then restore
} > CURSOR and MARK, of course.]
} 
} This would miss spaces. zew-pb remembers white space before each word.

Forward-word advances past the whitespace, so you just have to split it
off the end of each region as you advance.

} My point is
} that Zsh could provide more information (besides LBUFFER) to Zle and
} compsys, and also zsh-syntax-highlighting.

Of course the $words array etc. is supplied to compsys for exactly this
reason; you are merely asking for a different scope and definition of
"word".  In fact a huge amount of information is supplied to compsys,
way more than most completion functions need to use.

Beyond that, the information you're looking for doesn't exist.  The
parser is not activated until accept-line or the equivalent occurs.
To get what you seem to want requires an entire separate-but-lesser
implementation of the parser, kept in sync with the real one.

Which I guess is what zsh-syntax-highlighting has attempted to do,
except by writing the second parser in the shell language itself.

} Zsh-syntax-highlighting can be slow, which can be seen by editing ~400
} lines function with zed -f. Maybe it's because it's doing various
} things to compensate not that rich information provided by Zsh.

It's mostly because it's re-analyzing the entire buffer every time any
change is made, if I recall correctly from the few times I've tried it.