It’s good news that Don intends to look about the Shortcut Mapper. And I suppose, he will come back, with a top-form, from his present holidays !! Refer to the link below :

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/353#issue-91573331

Three points about that discussion :

1. Just have a look to my own solution, using a simple Excel file, at the address :

https://sourceforge.net/p/notepad-plus/discussion/331753/thread/7d642bae/#11ea

2. I’m agree with all of you, especially with Dail’s post : the actual features of the Shortcut Mapper are quite poor and out of date !

3. An IMPORTANT remark :

Very often, when someone posts about a possible N++ issue, one suggests to rename the plugins folder, in the N++ directory, in order to easily detect if that issue depends on a specific plugin or not.

Well. But this action may be very dangerous, IF you previously chose some user shortcuts for some plugins. Indeed, after the plugins folder is active again, all plugins’s user shortcuts are definitively lost !

As for me, I ALWAYS keep a copy of the shortcuts.xml file ! We must be aware of that N++ behaviour, concerning the Shortcuts.xml file !

Best regards,

guy038

I think that if NP++ exposed some suitable API’s in its plugin interface, people might use them to come up with a decent GUI interface.

If we are to use a file (which could also facilitate a GUI interface), I think this should be as simple as possible, with lines like

“GOOGLE Search” alt-f2
“Launch in Firefox” Ctrl-alt-shift-X

Everything should be case insensitive, and the order of key modifiers should not matter.

Thus in particular, users should not need to bother about the various different sorts of commands (intrenal, plugin, etc). The several different lists is part of the problem with the current system.

This means that users with all levels of ability can edit the shortcut information successfully.

This would make a great first step, and GUI’s would obviously follow.

Because of the need to retain compatibility with users’ existing shortcut , modifications, I think an acceptable solution might be to supply a command that output the current shortcut information to a file (in the above format), and another to read back such a file after the user had modified the information. This would mean that the existing XML files could continue to be used internally.

This approach would also mean that NP++ would ‘know’ the point when the information was updated and needed saving internally, and people could also save copies of their shortcut configuration if they wished.

David

My opinion is : we should remove the Graphic User Interface used to configure shortcuts. Everything should be loaded from an editable configuration file using an easy editable language (yaml as an example). It’s more flexible, it needs lees code than a GUI. Sublime text is a good example.

Christophe

Thanks Don for taking a look!!
David

Thanks for offering to look at this!

While you are working in this area, I think it would be good if a user could kick off an action from within the shortcut mapper just to be able to test it, or alternatively provide a button to link to the relevant help.

For example, I haven’t a clue what Big5 would do Some sort of font I guess), and if I wanted to find out, I would have to find a free shortcut, assign it to Big5, and then test it.

David

• Search for shortcuts by name
• Search for shortcut by shortcut key
• Show conflicting shortcuts
• List by shortcut key
• Better UI
• Several other tweaks

Sometimes it makes sense to have shortcuts for Menu, Macros, Run, Plugins and Scintilla listed separately…and sometimes it doesn’t. I tried to reassign some shortcuts, got into a hopeless snarl, and wound up having to use a mouse script to deassign all shortcuts in all five areas, just to start again with a blank slate.

The only way to change the listed order is to edit the XML file - and I can say from experience that one mistake there can lead to N++ resetting the list to default.