-
Notifications
You must be signed in to change notification settings - Fork 93
feat: Find in Editor #295
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
feat: Find in Editor #295
Conversation
…ches and clear button. When text field loses focus, emphasis layers are removed. Styled example app.
…hen looping find results or submitting when there is no result. Commented emphasize logic back in.
…ne number text color.
- If the users cursor is in view, the highlighted item will be next to the cursor - If the users cursor is out of view, we'll highlight the closed item to the visibe area
…match cycle logic from EmphasisManager to FindViewController. Using EmphasisManager in bracket pair matching instead of custom implementation reducing duplicated code. Implemented flash find matches when clicking the next and previous buttons when the editor is in focus. `bracketPairHighlight` becomes `bracketPairEmphasis`. Fixed various find issues and cleaned up implementation.
…dings didnt work while find panel was in focus preventing it from being dismissed.
Found one more bug that I'm working on in CodeEdit, I'm finding that the find panel is being removed from the view hierarchy (but not stopping being drawn) sometimes when clicking out of the find panel, and only when a previous tab had the find panel opened. I'm investigating and will report back. As well as the failing tests. |
Fixed the aforementioned bug, ended up strongly referencing |
As I'm fixing the tests, I've realized that the emphasis manager is not correctly drawing the non-flash emphases. I'm going to go fix that and link the PR here. |
Okay I have a few updates:
Screen.Recording.2025-04-07.at.12.11.10.PM.movI'm going to open the PR for these changes, and I'm tempted to just merge the change so it functions correctly and come back around to fix the text layer bug. |
### Description - Fixes an emphasis manager bug where it could leak layers without removing their `CALayer`s when replacing flash emphases with other emphases. - Updates the emphasis drawing code to correctly draw underlines. - Updates the `roundedPathForRange` to correctly handle emphases that span multiple line fragments. While fixing the last point, I discovered that the emphasis manager doesn't correctly draw the text on emphases that span multiple line fragments. This makes sense, as right now it's just using a CATextLayer that has no knowledge of line breaks. In the future, that text layer should be replaced by a custom layer that draws the text using knowledge of existing line fragments positions. However, I think the issues this PR fixes are too important to wait until that can be done. Also note that that change will be critical to drag and drop, so it will absolutely be done and I have a branch somewhere with some of that work already completed. ### Related Issues * CodeEditApp/CodeEditSourceEditor#295 ### Checklist - [x] I read and understood the [contributing guide](https://github.com/CodeEditApp/CodeEdit/blob/main/CONTRIBUTING.md) as well as the [code of conduct](https://github.com/CodeEditApp/CodeEdit/blob/main/CODE_OF_CONDUCT.md) - [x] The issues this PR addresses are related to each other - [x] My changes generate no new warnings - [x] My code builds and runs on my machine - [x] My changes are all related to the related issue above - [x] I documented my code ### Screenshots Screen recording showing the text layer bug mentioned above, as well as the fixed multi-fragment drawing, and the fixed leak. Prior to this, when switching from flash to any other emphasis type, there was a good chance one of the new emphases would be kept. This was due to the emphasis manager assuming that the emphasis being flashed was kept around after the animation delay. This has been fixed in this PR. https://github.com/user-attachments/assets/a29048e4-ab81-4376-abe0-e0499e448ea8
Alright this should be ready to go, I fixed a myriad of issues that only appeared when using multiple tabs, or the odd way we handle safe area in CodeEdit. Specifically this patch now:
|
Is the |
It's not using enum cases, it's using static variables but enums can't be initialized, so there can't be any confusion by trying to 'create' one. So it's still using strings to identify groups. I don't think an enum is the right decision here for the reason you mentioned. |
It is extendable, but it's not |
…xes (#2020) ### Description Updates CodeEditSourceEditor. Includes: - Find in Editor feature. - Improved undo grouping. - Improved word detection when selecting words. - Improved overscroll behavior. - Added mouse drag selection modes. ### Related Issues * CodeEditApp/CodeEditTextView#1 * CodeEditApp/CodeEditSourceEditor#295 ### Checklist - [x] I read and understood the [contributing guide](https://github.com/CodeEditApp/CodeEdit/blob/main/CONTRIBUTING.md) as well as the [code of conduct](https://github.com/CodeEditApp/CodeEdit/blob/main/CODE_OF_CONDUCT.md) - [x] The issues this PR addresses are related to each other - [x] My changes generate no new warnings - [x] My code builds and runs on my machine - [x] My changes are all related to the related issue above - [x] I documented my code
### Description @austincondiff has been building out the 'replace' functionality and realized the way we had structured the panel, controller, target, and model was extremely overcomplicating things. This PR is an attempt to fix that Changes: - Moves all 'business logic' into the `FindPanelViewModel` observable object. This includes clarified methods like `find`, `replace`, and `moveToNextMatch/moveToPreviousMatch`. All state has been moved to this object as well, out of a combination of both the SwiftUI view and the find view controller. - Removes the `FindPanelDelegate` type entirely. All that type was doing was passing method calls from the find panel to it's controller. Since all that logic is now in the shared view model, the controller & view can just call the necessary methods on the model. - Simplifies the `FindViewController` to only handle view/model setup and layout. - Changes the focus state variable to an enum instead of two `Bool`s. This fixes an issue where there was a moment of nothing being focused when switching between the find and replace text fields. - Removes the unnecessary `NSHostingView -> NSView -> SwiftUI View` structure, replacing it with an `NSHostingView` subclass `FindPanelHostingView` that hosts a `FindPanelView`. - Clarifies some view naming to reflect what each type does. - `FindPanel` -> `FindPanelHostingView` - `FindPanelView` search fields moved to: - `FindSearchField` - `ReplaceSearchField` ### Related Issues * #295 ### Checklist <!--- Add things that are not yet implemented above --> - [x] I read and understood the [contributing guide](https://github.com/CodeEditApp/CodeEdit/blob/main/CONTRIBUTING.md) as well as the [code of conduct](https://github.com/CodeEditApp/CodeEdit/blob/main/CODE_OF_CONDUCT.md) - [x] The issues this PR addresses are related to each other - [x] My changes generate no new warnings - [x] My code builds and runs on my machine - [x] My changes are all related to the related issue above - [x] I documented my code ### Screenshots <!--- REQUIRED: if issue is UI related --> <!--- IMPORTANT: Fill out all required fields. Otherwise we might close this PR temporarily -->
Important
We need to merge CodeEditApp/CodeEditTextView#78 before merging this PR.Description
This PR introduces the initial implementation of the “Find in Editor” feature for the source editor. Users can now search for text within the currently open file using ⌘ F. All matching results are visually emphasized, and users can navigate between matches using next/previous controls.
What’s Included
Related Issues
Checklist
Screenshots