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

Highlight and fade with multiple windows #180

Closed
Agentlien opened this issue Sep 26, 2014 · 2 comments
Closed

Highlight and fade with multiple windows #180

Agentlien opened this issue Sep 26, 2014 · 2 comments

Comments

@Agentlien
Copy link

The issue occurs when the active buffer is visible in a window other than the active one.

Issue

It would appear that when EasyMotion is highlighting results and fading the rest, this is done precisely for the text visible in the active window. In windows other than the active one, the hits which are visible in the active window are replaced by their labels, but neither the fade nor the highlight shows up. This is inconsistent and confusing.

Example

Imagine using easymotion-s to do a search for the letter 'X' in the active buffer, while another window displays the same buffer. In this second window, no fading or highlighting occurs. Still, all occurrences of the letter 'X' which also appear in the active window will be replaced by their jump label. Occurrences of 'X' which lie outside of the active window, however, will remain unchanged.

Solution

I can imagine three reasonable resolutions to this issue:

  1. Implement fading and highlighting for all windows which contain the active buffer. For simplicity, fade occurrences of the search-string which lie outside the active window. The rationale for this behaviour would be that you should see the same thing when viewing the same buffer in multiple windows and that the plugin only supports jumping to occurrences within the active window.
  2. Implement fading and highlighting for all windows which contain the active buffer. Implement fading as well as correct labeling and highlighting of all search results which can be seen in any window displaying the open buffer. This would make it possible to quickly jump to a match from any window (displaying the active buffer), which could be a very useful feature.
  3. Let other windows displaying the active buffer remain unchanged while the active one is labeled. Since we aren't jumping in the windows which aren't active, it might make sense to leave other windows entirely unchanged. That is: don't fade, don't label and don't highlight. The advantage of this approach is that, with the same section open in another window, you can quickly cast a glance at this other window to see the original text, unchanged by the labeling.

Of course, each of these present different challenges in implementation. Without having looked at the implementation, I would guess that 1 is the easiest to implement and 3 the hardest. My personal preference is for 1, as it seems like a quick fix and still provides a reasonable resolution to this problem.

@haya14busa
Copy link
Member

Thanks for the detail report, @Agentlien. It really helped me.

2

I don't like this, because if shade and target highlights in other window were same as active window one, it's confusing that you couldn't jump to other window even if the user see other windows target and hit it.

If I implement 2 like feature, I want to implement it regardless of the active window, but as far as I know, it's hard to implement. related: #130

3

Let other windows displaying the active buffer remain unchanged while the active one is labeled

It's impossible to implement with current easymotion implementation.
If I support this feature, I have to change easymotion drastically, and I don't want to because it's not some cool new feature but just a fix for this issue.

1

I guess it's the best solution, but I think I don't need to support target highlights, just fading other window is enough to fix it.

But, in the first place, is this problem really too annoying to fix it with the drastic code change?
EasyMotion has not touch the other window until now, so even the solution 1 seems easy to implement, it breaks current implementation.

Please let me think more deeply before implement it. (but I guess I should try to implement solution 1 withoug target highlights at least)

@haya14busa
Copy link
Member

I don't have any plan to work on this now. close

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

No branches or pull requests

2 participants