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

Thanks, here's the bug.

I'll get the patch into Gerritt shortly.


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.



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.


eclipse-dev mailing list
To unsubscribe from this list, visit
eclipse-dev mailing list
To unsubscribe from this list, visit

Back to the top