Use the current document and view for mode-change hooks #3508
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I've pushed e4c9d40 but I think this PR should be applied as well. |
archseer
reviewed
Aug 23, 2022
helix-term/src/ui/editor.rs
Outdated
Comment on lines
1213
to
1217
| // The focused view has changed. Consume the event and do not execute mode | ||
| // transition hooks. | ||
| if view.id != focus { | ||
| return EventResult::Consumed(None); | ||
| } |
There was a problem hiding this comment.
Actually, with the changes in master, these hooks should still run (if the doc exited from insert mode, we do want a history state).
We just need to fetch the doc matching the original focus rather than current!
When changing focus, the lookup with `current!` may change the view and end up executing mode transition hooks on the newly focused view. We should use the same view and document to execute mode transition hooks so that switching away from a view triggers history save points.
the-mikedavis
force-pushed
the
md-consume-focus-transitions
branch
from
638e8ba
to
b963657
Compare
the-mikedavis
changed the title
Merged
thomasskk
pushed a commit
to thomasskk/helix
that referenced
this pull request
Sep 9, 2022
…ditor#3508) When changing focus, the lookup with `current!` may change the view and end up executing mode transition hooks on the newly focused view. We should use the same view and document to execute mode transition hooks so that switching away from a view triggers history save points.
jdrst
pushed a commit
to jdrst/helix
that referenced
this pull request
Sep 13, 2022
…ditor#3508) When changing focus, the lookup with `current!` may change the view and end up executing mode transition hooks on the newly focused view. We should use the same view and document to execute mode transition hooks so that switching away from a view triggers history save points.
herkhinah
pushed a commit
to herkhinah/helix
that referenced
this pull request
Dec 11, 2022
…ditor#3508) When changing focus, the lookup with `current!` may change the view and end up executing mode transition hooks on the newly focused view. We should use the same view and document to execute mode transition hooks so that switching away from a view triggers history save points.
pascalkuthe
added a commit
that referenced
this pull request
Jan 8, 2024
This change effectively reverts #3508 and #3633. When a view is changed we must make history commits (and ensure that the cursor is in view) for the newly focused view. Not the old view. These changes were originally introduced to fix mode switch hooks. However, the mode switch hooks have been moved elsewhere so that concern doesn't apply anymore. In particular, because modes are now editor wide and not per view and also because view switches now always reset the editor back to normal mode.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When changing the focused view with C-w for example, the w event was
being handled in the EditorView event handler as if it belonged to
the newly focused window.
Instead of handling the event for the newly focused window, we shouldreturn early. We don't want the change in focus to trigger a history
checkpoint (following block) and we don't want to execute the mode
transition hooks (the block after). With some configs this can cause
a panic, for example
since these fall into theunimplemented!in the mode transition block.Instead of handling the event in the newly focused view, we should handle
the event in the original view.