Hi,
I just added a new signal for plugins: "populate-edit-menu". The intended use is to modify or extend the editing menu (right-click popup menu) before it is shown. The current word under the cursor, the cursor position and a reference to the current document is passed to the signal handler. So plugins have many information to perform some actions. Usage example: I added this signal for the spellcheck plugin where a "Spellcheck" menu item is added to the edit menu when the cursor is above a misspelled word to provide a sub menu with suggestions.
The more important thing is while adding the new code, I noticed the function editor_find_current_word() wasn't Unicde-safe, this means when the cursor is above a word containing Unicode characters (i.e. any non-Ascii characters) the resulting string is wrong. For Goto tag definition/declaration this isn't a big problem as these are mainly plain Ascii. But it is also used e.g. for the Find dialogs when the current word below the cursor is used as search word. This badly fails with the old code. So, I tried to fix it by explicitly allowing non-Ascii characters which seems to work (SVN r2732). I'm still not very happy with the current code. It allows also any punctuation characters defined in Unicode. This is probably only a small issue at least I don't think such are used widely. A possible clean solution could be to read g_unichar's when searching the word boundaries and check each g_unichar against the passed wordchars and with e.g. g_unichar_isalnum(). But this still needs to be implemented. If anyone feels to do it, patches are welcome :).
Regards, Enrico
On Sat, 28 Jun 2008 17:58:38 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
I just added a new signal for plugins: "populate-edit-menu". The intended use is to modify or extend the editing menu (right-click popup menu) before it is shown.
I think this should be called "show-editor-menu" or "update-editor-menu", as although the spellcheck plugin uses it to populate a sub-menu, the top-level editor menu should not be populated during this signal call. So it should be used to update existing editor_menu items. (And using 'editor' instead of 'edit' seems to avoid confusion with the File->Edit menu).
Also I think menu items should not be hidden, but just set insensitive, so the user can see what options are available even when they can't be activated.
Regards, Nick
On Tue, 1 Jul 2008 12:25:56 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 28 Jun 2008 17:58:38 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
I just added a new signal for plugins: "populate-edit-menu". The intended use is to modify or extend the editing menu (right-click popup menu) before it is shown.
I think this should be called "show-editor-menu" or "update-editor-menu", as although the spellcheck plugin uses it to populate a sub-menu, the top-level editor menu should not be populated during this signal call. So it should be used to update existing editor_menu items. (And using 'editor' instead of 'edit' seems to avoid confusion with the File->Edit menu).
Ok, I don't mind changing the name, I was completely unsure about the naming and chose "populate" as this is often used but actually to really populate a menu instead of updating as in our case. I'll change this tomorrow.
Also I think menu items should not be hidden, but just set insensitive, so the user can see what options are available even when they can't be activated.
In general yes, in case of the spell check menu item, I choosed the current way to make it behave like gtkspell. gtkspell does hide the Spell Check menu item if there is nothing to correct. Again, generally I'd fully agree but in this case I think it's better to have the look and feel from gtkspell.
Regards, Enrico