You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I select a line from the zero position, then in the editSelections method, the selection range includes that line, even if the selection is not actually visible in the UI. Is that the way it's meant to be?
Details
issue.mov
As I see from Xcode, during line up/down actions, the selected lines understand their scope and automatically add/remove additional indents. Can you please show me where to look to implement similar logic? 🙏🏿
I think you're right to keep the newline character, but it sounds like there might be something going funky with finding the lines being selected to move.
And I noticed a few problems:
If I select a line from the zero position, then in the editSelections method, the selection range includes that line, even if the selection is not actually visible in the UI. Is that the way it's meant to be?
What are you using to determine what lines are selected? The editSelections method just passes along any text selections active in the TextView, so that makes me think there's maybe something going on with whatever method is being used to find lines in the selected range.
As I see from Xcode, during line up/down actions, the selected lines understand their scope and automatically add/remove additional indents. Can you please show me where to look to implement similar logic? 🙏🏿
Right now we don't have any architecture for determining 'correct' indent levels. I may be building that out right now while developing the line folding gutter and I know tree-sitter has that capability, but we haven't had a need for it just yet.
Okay looking into that method you're right it's not returning what you'd expect. Technically the selection contains the second line (line 27 in your screenshot), but that method shouldn't be returning both those lines. That's actually causing another bug with the indent lines functionality with the same issue you found. I'll have a patch ready in a moment for that method that should make it function as expected.
Looks fantastic! One detail. Should it modify your selection? Or should it move the lines, leaving your selection alone? We should follow Xcodes lead on this one. It looks like this works as expected.
Submit a PR when ready!
@austincondiff Hi! I opened 2 PRs #333 and CodeEditApp/CodeEdit#2058 to migrate logic to the menu. But I notice an issue in the current solution. As you can see, I'm relying on EditorInstance.RangeTranslator to use the lines movement API. But if I switch tabs, the TextViewCoordinator.destroy method is called after TextViewCoordinator.prepareCoordinator, as a result, I can't reach the text view controller API (textViewController is nil). Is it expected behavior? Also, it breaks the linesInRange API
@Bogdan-Belogurov you're right, that's not expected behavior. The coordinator should be setup again after switching back to the old tab. I'll investigate today
Activity
[-]✨ Move lines up and down[/-][+]✨ Move selected lines up and down[/+]Bogdan-Belogurov commentedon May 22, 2025
@austincondiff Hello! Do you mind if I take this?
0xWDG commentedon May 22, 2025
I have assigned you :)
Bogdan-Belogurov commentedon May 24, 2025
@0xWDG
Hello!
I've made the first prototype
Details
normal.mov
And I noticed a few problems:
editSelectionsmethod, the selection range includes that line, even if the selection is not actually visible in the UI. Is that the way it's meant to be?Details
issue.mov
austincondiff commentedon May 24, 2025
First of all, great work so far! Maybe if the selection ends with a newline character, we exclude it. Would that work?
Bogdan-Belogurov commentedon May 26, 2025
@austincondiff

Thanks! I'm not sure about the newline character because it allows you to draw the whole line in the UI, am I right?
From my perspective, it would be better to handle this case in the
getHighlightedLines->textLineForOffsetmethod. What do you think?thecoolwinter commentedon May 27, 2025
I think you're right to keep the newline character, but it sounds like there might be something going funky with finding the lines being selected to move.
What are you using to determine what lines are selected? The
editSelectionsmethod just passes along any text selections active in the TextView, so that makes me think there's maybe something going on with whatever method is being used to find lines in the selected range.Right now we don't have any architecture for determining 'correct' indent levels. I may be building that out right now while developing the line folding gutter and I know
tree-sitterhas that capability, but we haven't had a need for it just yet.Bogdan-Belogurov commentedon May 28, 2025
@thecoolwinter Hello!
I use
getHighlightedLinesmethod to determine what lines are selectedHere I've selected starting at line 27 of the zero position

getHighlightedLines output:

thecoolwinter commentedon May 30, 2025
Okay looking into that method you're right it's not returning what you'd expect. Technically the selection contains the second line (line 27 in your screenshot), but that method shouldn't be returning both those lines. That's actually causing another bug with the indent lines functionality with the same issue you found. I'll have a patch ready in a moment for that method that should make it function as expected.
1 remaining item
Bogdan-Belogurov commentedon May 31, 2025
@thecoolwinter Now it works perfectly. Thanks!
Spoiler
Screen.Recording.2025-05-31.at.12.25.01.mov
austincondiff commentedon May 31, 2025
Looks fantastic!
One detail. Should it modify your selection? Or should it move the lines, leaving your selection alone? We should follow Xcodes lead on this one.It looks like this works as expected.Submit a PR when ready!
Bogdan-Belogurov commentedon Jun 1, 2025
@thecoolwinter Hi! I made a PR. Could you add reviewers, please 🙏🏿
Add the ability to move selected lines up and down (#327)
thecoolwinter commentedon Jun 2, 2025
Closed with #327, thanks @Bogdan-Belogurov 🎉
Bogdan-Belogurov commentedon Jun 3, 2025
@thecoolwinter Hi! Do you need an Editor->Structure menu like in Xcode?
austincondiff commentedon Jun 3, 2025
@Bogdan-Belogurov do you mean this?
Bogdan-Belogurov commentedon Jun 3, 2025
@austincondiff I meant this editor menu
Spoiler
austincondiff commentedon Jun 3, 2025
Oh right, yes, that would be great!
Bogdan-Belogurov commentedon Jun 8, 2025
@austincondiff Hi! I opened 2 PRs #333 and CodeEditApp/CodeEdit#2058 to migrate logic to the menu. But I notice an issue in the current solution. As you can see, I'm relying on
EditorInstance.RangeTranslatorto use the lines movement API. But if I switch tabs, theTextViewCoordinator.destroymethod is called afterTextViewCoordinator.prepareCoordinator, as a result, I can't reach the text view controller API (textViewController isnil). Is it expected behavior? Also, it breaks thelinesInRangeAPIDetails
Screen.Recording.2025-06-08.at.09.41.52.mov
thecoolwinter commentedon Jun 18, 2025
@Bogdan-Belogurov you're right, that's not expected behavior. The coordinator should be setup again after switching back to the old tab. I'll investigate today
thecoolwinter commentedon Jun 26, 2025
@Bogdan-Belogurov got a fix in for the coordinator lifecycle bug, I'll lyk when it's in a tagged release so we can update the related CodeEdit PR.