Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

redrawhook: Effect on third-party plugins #735

Closed
danielshahaf opened this issue May 22, 2020 · 5 comments
Closed

redrawhook: Effect on third-party plugins #735

danielshahaf opened this issue May 22, 2020 · 5 comments

Comments

@danielshahaf
Copy link
Member

danielshahaf commented May 22, 2020

@ericfreese points in zsh-users/zsh-autosuggestions#529 (comment) that merging feature/redrawhook will break not only zsh-autosuggestions (#579) but possibly other plugins as well.

In a nutshell, suppose that with today's versions of everything (zsh, z-sy-h, and the third-party plugin) the third-party plugin wraps widgets and adds to region_highlight after z-sy-h runs. Once z-sy-h begins to use redrawhook, z-sy-h's hook will run after the third-party widget wrapper, and without the proposed region_highlight owner= feature (zsh-users/zsh#57) will trigger issue #418.

Brainstormed solutions include:

  • Announce an upcoming breaking change before merging redrawhook
  • Merge redrawhook but default it to disabled unless the owner= functionality is available
  • Use dummy region_highlight entries (see next comment)

Between the two options listed thus far, I would vote for the second. It's not ideal but it avoids breakage for users who also use third-party plugins until those upgrade to pre-redrawhook as well.

Does anyone see a third option?

@phy1729
Copy link
Member

phy1729 commented May 31, 2020

It's not pretty, but it's possible to add a noop highlight (e.g. 0 0 fg=17,bg=29) into region_highlight to demark the start and end of z-sy-h controlled highlights (assuming other plugins prepend or append to the array and don't insert in the middle). Could be used as a fall back if owner= isn't available.

@danielshahaf
Copy link
Member Author

Nice ☺

In addition to fg=, bg=, and the three booleans (underline, standout, bold), we can also set start and end to different random values such that start >= end. start and end are at least 31 bits wide each, so using them would provide more than enough different values for as many plugins to use this trick as want to.

So, here are magic numbers for us:

% perl -E 'print map "$_ ", reverse sort { $a <=> $b } map { int rand (1<<31) } qw/start end/; print join ",", map { "$_=" . int rand (1<<8) } qw/fg bg/; say join "", map ",$_", grep { int rand 2 } qw/bold standout underline/'
1037776018 929459019 fg=100,bg=191,underline

However, I would prefer to start by implementing "If memo= (née owner=) is supported, use redrawhook, else use the incumbent code", then merge redrawhook, and implement the noop highlighting trick after merging (which would fix #418 for pre-memo= zsh). Makes sense?

@phy1729
Copy link
Member

phy1729 commented Jun 10, 2020

Complete agreement on the plan. Just giving a fallback.

I kinda thought the 16 bits of fg and bg values would have been sufficient. I don't think there are even 256 region_highlight modifying zsh plugins much less 65 thousand.

@danielshahaf
Copy link
Member Author

To a cryptographer, using an order of magnitude more bits of key space than conceivably required is second nature :P

But yeah, we can leave some of the bits as "reserved, must be set to zero". How about leaving end as zero?

(I suppose this is how the designers of IPv6's address space must've felt.)

@danielshahaf
Copy link
Member Author

Merge redrawhook but default it to disabled unless the owner= functionality is available

Implemented; see #579 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants