Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Sharing a new feature: make previous edit location a stack
I'm sorry I missed the comment on the bug Ari. I was not in the cc. Please put it in Gerrit. It does not have to be perfect yet. The sooner we can look at it the better.

On Sat, Jul 18, 2020 at 4:34 PM Ari Kast <arikast@xxxxxxxxx> wrote:
OK I got it resolved -- M2 (shift key) in particular doesn't work here.  I changed to M3 (alt/opt) and mapping works fine now.  Will get this patch submitted shortly.

On Fri, Jul 17, 2020 at 3:22 PM Ari Kast <arikast@xxxxxxxxx> wrote:
I have a patch for https://bugs.eclipse.org/bugs/show_bug.cgi?id=72773 working well locally, but am having difficulty mapping it to a keyboard command.

The "backward" navigation thru edit history works fine as I'm using the existing mapping (ctrl-q), but the "forwards" navigation thru edit history is where I have trouble.  I wanted to setup a new mapping for this (ctrl-shift-q) but am having difficulty on that.

Here's what I did:

1. open this file eclipse.platform.text/org.eclipse.ui.workbench.texteditor/plugin.xml and copy all lines with "LastEdit" and make new ones with "NextEdit"

2. similar copy/tweak to these files:
org.eclipse.ui.workbench.texteditor/src/org/eclipse/ui/internal/texteditor/EditorMessages.java
org.eclipse.ui.workbench.texteditor/src/org/eclipse/ui/internal/texteditor/EditorMessages.properties
org.eclipse.ui.workbench.texteditor/src/org/eclipse/ui/internal/texteditor/TextEditorPlugin.java
org.eclipse.ui.workbench.texteditor/src/org/eclipse/ui/texteditor/ITextEditorActionDefinitionIds.java
org.eclipse.ui.workbench.texteditor/src/org/eclipse/ui/texteditor/GotoNextEditPositionAction.java
org.eclipse.ui.editors/plugin.properties

3. make a new class GotoNextEditPositionAction based on the existing GotoLastEditPositionAction class

The result: I now have a new menu item under Navigation called "Next Edit Location" which works when I click it.  But the keyboard shortcut still doesn't work, even though when I open up preferences > General > Keys I see that the mapping is indeed there.

Any advice on what setup steps I may have missed?  Should I perhaps submit the patch as-is for easier collaboration on this last step?

Thanks
Ari

On Sat, Jul 4, 2020 at 6:33 PM Ari Kast <arikast@xxxxxxxxx> wrote:
Thanks, here's the bug.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=564931

I'll get the patch into Gerritt shortly.

Ari

On Sat, Jul 4, 2020 at 1:27 PM Wim Jongman <wim.jongman@xxxxxxxxx> wrote:
Hey Ari,

That sounds great. Thank you.

Yes please file a bug against platform ui and describe what you want to do. The contents of your email is great.

Then you can already create a Gerrit change and push your feature.

The link below has instructions on how to setup Gerrit for platform development.



Cheers,

Wim





On Sat, Jul 4, 2020, 4:59 PM Ari Kast <arikast@xxxxxxxxx> wrote:
Hi all

I'm creating a feature that I've always wished for: that more than one "last edit location" gets stored so that edit location history functions more like browser history, letting you go back or forward at will.

I have it working well locally and wanted to share it.  A few questions:

1. Should I first create a bug or feature request in bugzilla and describe in detail how this feature works?

2. Currently I have it so that ctrl q always takes you to most recent edit, identical to existing functionality, but then continuing to hold ctrl and hitting q again iterates thru prior locations with each additional tap of the q key.  I'd like to also create a new mapping of shift-ctrl-q to go forward again, but I'm not sure where default keystroke mappings are handled -- could someone advise?

3. I've written unit tests for the core history stack's functionality in an abstract way, is that sufficient or should I also create more contextual tests with a real document?  (If so are there some recommended tests I might emulate?)

4. I added some @since tags to make the compiler happy, but I'm not sure I used the correct version, should I just submit as is and someone will correct it?  Also it says the major version should be incremented in MANIFEST.MF, should I do that?

5. I'd love feedback from someone who knows the codebase better who could maybe advise whether my approach is in keeping with the overall architecture -- perhaps there's a better way to do it, or maybe there are cases to consider that I'm not aware of.  If so I'm happy to revise.

Thanks
Ari

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev

Back to the top