godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.22k stars 21.22k forks source link

Script editor back button doesn't work as advertised (regression) #97031

Open starblinky opened 2 months ago

starblinky commented 2 months ago

Tested versions

v4.3.stable.official [77dcf97d8] Reproducible. v4.2 works as expected.

System information

v4.3.stable.official [77dcf97d8] Reproducible.Compatibility Apple M1 Max Sonoma 14.6.1 (23G93)

Issue description

Screenshot 2024-09-14 at 10 43 32 PM

It no longer "goes back to previous edited document" as advertised when you hover over the button.

Clicking the back button in the script editor will now go back to every single line that has been selected, even if it wasn't edited, and even if it is all in the same script!

I assume this is a bug.

But if it was intentional, please revert back. This issue removes the convenience of quickly navigating back to the previous script with 1 click. Now you might have to press the back button any number of times (dozens? in worse case) just to go back to the previous script.

Steps to reproduce

Have 2 scripts. Make sure the scripts are somewhat long. (You can use any text and just comment it out)

Screenshot 2024-09-14 at 10 54 16 PM

Step 1: Open script 1 then open script 2. Step 2: Click on several different lines in the text editor. Step 3: Then press the back button.

It SHOULD go back to script 1. But actually it will go to every line you selected in step 2

Edit: Also I added a second bug with my 2nd comment - which is clearly a bug.

Minimal reproduction project (MRP)

Use any empty project.

tetrapod00 commented 2 months ago

Personally I much prefer the 4.3 behavior of navigating forward and back location by location rather than file by file, with alt+left and alt+right as the default keybinds. It matches vscode.

So a solution here might be two different actions, History Previous (current behavior) and History Previous File (4.2 behavior). They can be bound to alt+left and alt+shift+left by default. And of course the matching History Forward and History Next File. Add a setting to change what the GUI buttons do between the two behaviors.

I personally don't much care what the GUI button does, so long as the History Previous action is available and can be bound to alt+left.

I believe this was changed in https://github.com/godotengine/godot/pull/63515. Might be worth looking back at the PR and linked proposals to see how unanimous this was, and if it's worth it to add settings to disable it.

starblinky commented 2 months ago

I do agree that links should work this way, as mentioned here: #82293

But for general use, it's unpredictable what it's going to do when I press it. Will it jump to a new line? or will it change to a new script. I don't think that is good functionality. For me, the back button is how I navigate between scripts. I use it constantly and using it now causes issues.

I agree there could be 2 functions, History Previous should be a keybind and History Next File as the default button behaviour.

Also there is another bug with this, where the history is not recorded when you have the script editor open and you click on a new scene tab (which opens the scenes main script)

Screenshot 2024-09-15 at 12 42 30 AM

In the history, it doesn't know you changed to a new script.

So for example if you follow this instructions:

Step 1: Open script 1 Step 2: Open script 2 Step 3: Click on new scene tab where parent script is script 3

Clicking the back button here will send you to script 1, instead of back to script 2.

tetrapod00 commented 2 months ago

Huh. The top bar of the script editor is actually one of the few places in the editor that has free horizontal space. So if there are two back and forward actions, a course and a fine one, there is room for a button for each. It's probably the wrong solution just because it's busy and doesn't match most other programs, though.

the history is not recorded when you have the script editor open and you click on a new scene tab

This should maybe be a separate issue so the bug can be tracked separately from the more subjective discussion?

CreatedBySeb commented 2 months ago

For History previous file and History next file, would an alternative be to offer MRU switching as an option?

There is currently Next Script (Shift+Command+Period on macOS) and Previous Script (Shift+Command+Comma on macOS) to navigate in visible order. There could be an option (or even better alternative keybindings like in VSCode) to swap this to most-recently-used order instead, which sounds like what you want. This could also be extended to Control+Shift+Tab and Control+Tab for the Next/Previous Scene (potentially as two different settings though). Alt+Left and Alt+Right could then be kept for the history navigation, and the button tooltips can be updated to match their current behaviour.

An alternative would be to put the new history behaviour behind an option, but I think having the above and allowing you to rebind it to Alt+Left and Alt+Right if you want is probably better, because it makes all the actions available to you and then lets you decide where to put them.

Edit: VSCode calls these shortcuts "Open Most Recently Used Editor( in Group)" and "Open Least Recently Used Editor( in Group)", similar naming would probably work decently here: "Open Most/Least Recently Used Script/Scene".

peterhoglund commented 1 month ago

I suggest the default behavior should be to go back or forward in the recently shown script history. It is very intuitive and is what you would expect for these kinds of buttons. If we want a more granular back behavior we can put it on Shift+click. This could take you to the previously edited row or whatever would make sense for a more granular navigation behavior.

peterhoglund commented 1 month ago

Also there is another bug with this, where the history is not recorded when you have the script editor open and you click on a new scene tab (which opens the scenes main script)

There is also a third bug causing confusion where the history won't register a script change if I don't make any changes to that script. So, in Script A I jump to line 10, then line 20, and line 30. I press back and will go to line 20. If I now go to Script B and press back I will jump to line 10 in Script A. The script change isn't registered in the history. The expected behavior would be to go from Script B back to line 20 and then to line 10.

peterhoglund commented 1 month ago

I found another bug (or perhaps this is the intended behavior, it is very confusing either way): In Script A I jump to line 10, then line 20, then line 30, and then to another script. I go about my business, jumping between scripts and editing them. At some point, I am in Script X and Ctrl+click a function name which will make me jump to its definition in Script A. If I click back I will jump to line 30 in Script A, then line 20 then line 10, and then back to Script X. Expected behavior would be to go back to Script X after jumping to the function definition in Script A.

brevven commented 1 month ago

I think there is another usability issue lurking here. Right now there is no way to reliably jump between two scripts you are editing in tandem. You can have exactly one script open at a time. In 4.2, the way to edit two (or a few) scripts at once was to go back and forth through history. That functionality has effectively been removed due to the behavior explained above in the thread.

Incidentally, a different change (https://github.com/godotengine/godot/pull/88660) from 4.2 to 4.3 also made it more difficult to switch between scripts by name (it is much more finicky to do rapid VSCode/ctrlp.vim-style entry to swap between scripts), meaning yet another fallback for editing multiple scripts at once doesn't work well right now.

I think updating to support both "coarse" (file by file) and "fine" (line by line) history is probably a fine fix at the moment, since the 4.2 behavior was mostly sufficient.

However, I think the broader issue is allowing multiple scripts to be edited at once (whether both are on screen at once, or via tabs that actually switch which script you're looking at, or some other method entirely).