AndroidIDEOfficial
[Feature]: Backward/Forward history for going back and forth between locations in the editor
Feature description
I have mentioned this in other posts and this is the feature request.
In this feature, we are keeping history of locations of the view port and cursor. This would minimize the need for scrolling around too much in search for places of interest. It could also be the base for other related features to be implemented in the future.
The feature has some characteristics bellow:
-Every time the user taps at a position, the cursor moves there, and the positions of the cursor and view port is recorded if they are different from those of the previous point in history.
-The device's back key is used for taking us back to the previous point in history. (I guess the normal back function could be asigned to holding of the back key or something.)
-Going forward (and also backward?) is asigned to UI buttons.
This feature seems more useful for an IDE than for a general text editor. I guess @itsaky would need @Rosemoe to implement the framework in the editor library first before the feature could be integrated into AndroidIDE.
What version of AndroidIDE you're using?
v2.5.2 (debug builds)
Duplicate issues
- [X] This issue has not been reported yet.
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Every time the user taps at a position, the cursor moves there, and the positions of the cursor and view port is recorded if they are different from those of the previous point in history.
Maybe not on "every" tap, but only if the difference between lines (and probably columns) of previous location is significant. If we do record every other location, it would create a huge history and increase the memory usage.
The device's back key is used for taking us back to the previous point in history. (I guess the normal back function could be assigned to holding of the back key or something.)
In my opinion, this is not a good idea. The back button should be used for screen/window/overlay navigations only. Also, if we do add buttons for backward/forward locations in the UI, where do you think we should show them? Those buttons should be easily accessible, right? Options menu doesn't seem to be a very good choice. We could map those actions to key bindings, but not everyone uses a physical keyboard (or Hacker's keyboard). Any suggestions on this?
This feature seems more useful for an IDE than for a general text editor. I guess @itsaky would need @Rosemoe to implement the framework in the editor library first before the feature could be integrated into AndroidIDE.
This should indeed be implemented in the IDE. The user should be able to navigate between all the open files, not just the current one.
Maybe not on "every" tap, but only if the difference between lines (and probably columns) of previous location is significant.
Good point. Initially, I was thinking that if the tapped position were outside of the previous view port, we would record a new history point. Then I thought we might miss an important history point somehow that way. So, for the sake of simplicity I just said "every".
If we do record every other location, it would create a huge history and increase the memory usage.
The history probably shouldn't even need to be too long. We could have maybe 20 (30?) and discard the oldest as the newest comes.
In my opinion, this is not a good idea. The back button should be used for screen/window/overlay navigations only.
I have tried the back button for this exact purpose on another IDE before. It felt quite comfortable to use to be honest. I'm not sure how dependent AndroidIDE's UI is of the back button, but if we trigger backward only if the editor is active and use double-back or hold-back for exiting the IDE, do you think that would work? Please consider having that option as a preference at least.
Also, if we do add buttons for backward/forward locations in the UI, where do you think we should show them? Those buttons should be easily accessible, right? Options menu doesn't seem to be a very good choice. We could map those actions to key bindings, but not everyone uses a physical keyboard (or Hacker's keyboard). Any suggestions on this?
I see a nice spot for them at the last two (screen space, not including the hidden keys) keys on the right side of the quick symbols bar. If we could somehow reserve the last two key spots and make them static (not scrollable). This region is at the right thumb's comfortable reach and might work out well enough. The only thing is we always need to bring up the keyboard in order to use it, which isn't too desirable.
Do you think we could add another "tools bar" which would sit right on top of the bottom status bar, and would contain only these two new buttons on the right side? We would only show this bar when the keyboard is not visible.
More ideas should come to mind on improvements when we could see this in action on the next release.
I have tried the back button for this exact purpose on another IDE before. It felt quite comfortable to use to be honest. I'm not sure how dependent AndroidIDE's UI is of the back button, but if we trigger backward only if the editor is active and use double-back or hold-back for exiting the IDE, do you think that would work? Please consider having that option as a preference at least.
With the "double press back button to close project/exit", wouldn't navigating through the cursor history be affected? I mean, if single back press is for navigating and double back press is for closing the project, we'll have to wait for a few time (at least a second) before we could determine the number of times the user pressed the back button.
We could probably go with the "press and hold back button" thing, but I have no idea if the system dispatches any events for this.
I see a nice spot for them at the last two (screen space, not including the hidden keys) keys on the right side of the quick symbols bar. If we could somehow reserve the last two key spots and make them static (not scrollable). This region is at the right thumb's comfortable reach and might work out well enough. The only thing is we always need to bring up the keyboard in order to use it, which isn't too desirable.
Sounds good. We could go with this approach.
Do you think we could add another "tools bar" which would sit right on top of the bottom status bar, and would contain only these two new buttons on the right side? We would only show this bar when the keyboard is not visible.
I don't know. I'm not so sure about this.
More ideas should come to mind on improvements when we could see this in action on the next release.
Probably not in the next release, but after that.
The history probably shouldn't even need to be too long. We could have maybe 20 (30?) and discard the oldest as the newest comes.
On second thought, I think we could even go big on this since it's different from undo/redo where there could be a huge amount of data depending on the size of the copied text. For backward/forward, they're just some coordinates and probably file locations. I think we should go for 50 or even 100.