Re: [lsp4e-dev] Command handler dispatch: undo not working following upg

[Ahmed Hussain <ahmed@xxxxxxxxxx>]

Ah - I think before we may have been implementing/subclassing BasicTextEditorActionContributor and this might be the missing link for routing requests.

D’Oh.

Ahmed


> On 14 Aug 2024, at 15:12, Ahmed Hussain <ahmed@xxxxxxxxxx> wrote:
> 
> Hi all,
> 
> Apologies if this isn’t the right place to ask, but just on the off-chance an Eclipse guru out there might know where best to dig…
> 
> Recently upgraded to using the very latest lsp4e directly, whereas before we used to shade our own copy with our own plugin & extension point namespace. Finally got to the point where we can consume unmodified production lsp4e directly - hurray! We’ve also switched to using tm4e.
> 
> Following the recent upgrade to production lsp4e, we’ve had a seriously inconvenient bug where undo stops working properly. 
> 
> Scenario:
> 
> 1. Open an editor for our file type - undo works fine.
> 2. Open a second editor for another file of the same type - undo works fine, but stops working in the first editor.
> 3. If both editors are dirty and the first editor is active, then undo causes the *second* editor to undo.
> 
> Basically, the behaviour is exactly what you’d expect if the editor on construction set up an undo handler and registered it in a way that overwrote/supplanted the handler for the previous editor, rather than registering an additional handler and making it active (or not) depending on the editor class instance, rather than the editor class.
> 
> We are using our own subclass of ExtensionBasedTextEditor - I know you’re supposed to use extension points and configuration to customise it rather than subclassing, but the subclass is trivial and only overrides initialiseKeyBindingScopes(). This is to set up our own context so that we can have key bindings scoped to the editor type - there are some unfortunate clashes in default eclipse and this is the easiest way to override them.
> 
> So that could be a smoking gun, except that we were using an editor subclass quite happily before, and before we switched to tm4e it was doing way more stuff. If I sacrifice the key binding stuff and just wire in the generic editor directly instead of this nearly-trivial subclass it all works quite happily.
> 
> Can anyone shed any light on how the command/handler framework routes commands so that it figures out whether a handler should be active based on the active editor? It’s a bit hairy to debug… It’s almost as if there’s some logic that goes
> 
> If (this is the generic editor or the generic editor context) {
>  dispatch_based_on_individual_editor_instance();
> } else {
> dispatch_based_on_type_alone();
> }
> 
> Almost as if there were some logic that was looking for a very specific class name/editor id and taking the wrong branch because it didn’t recognise the subtype. But again - can’t understand how this wouldn’t have been an issue before.
> 
> Many thanks,
> 
> Ahmed
>