I was ambushed by the 63-character limit for plugin menu item names
-
See my comment in this GH issue for more context.
TL;DR: I tried to make a menu item that was too long, sometimes it caused Notepad++ to fail to start with no message or anything, and sometimes it just caused the offending menu item to appear mangled. I think Notepad++ does a pretty good job most of the time of trying to let the user know why it’s about to crash, so I was a bit frustrated that I had to do so much poking around to figure out the origin of the issue.
I feel pretty strongly that something should be done to communicate this limitation more clearly in the user manual or maybe via a message at Notepad++ startup, but I’m not sure what. What do others think? And don’t worry, I won’t be too offended if you think the correct solution is for me to git gud ;)
-
maybe via a message at Notepad++ startup
I don’t think that would be a useful message. It’s not the users who care, it’s the Plugin authors who need to take note.
communicate this limitation more clearly in the user manual
I think such a note would be pretty “jarring” , since there aren’t any other such low-level hints in the manual. I’m not 100% opposed, mind you, but before adding a “gotchas” section, I think your comment in the issue is worth thinking about:
and since it’s in the Notepad++ codebase there’s nothing I can do (other than request that it be changed, which likely wouldn’t work)
Given that the
menuItemSize
doesn’t affect anything except the size of the Plugins’ menu entries inTCHAR _itemName[menuItemSize]
, and the equivalent for built-in context menus isgeneric_string _itemName
, which doesn’t have length restrictions, I think it’s worth trying to ask Don to allow for an increase (“Notepad++ menu entries don’t have a length restriction, but Plugin menu entries do” seems a solid argument, to me).As an aside: Personally, I dislike long menu entry names, and they can usually be rephrased to shorten it. For example, even in your English from that discussion, “Choose schemas to automatically validate &filename patterns” could be shortened to “Choose &filename-validation schemas”, which is 40% shorter… though still on the long side of what I like in menu entries. “Verb” or “Verb Object” make the best menu entries, using hierarchy to give context. So your four schema-related entries could be put under
Schema >
, with&Validate JSON
,Edit &filename patterns
,Generate from JSON
, andGenerate random valid JSON
. (But yes, I know that Notepad++ punishes plugins for putting any actions in sub-menus by not allowing shortcut editing. That’s another thing that should be changed in Notepad++, but I find it less likely to be fixed than menu-entry length.) -
@PeterJones said in I was ambushed by the 63-character limit for plugin menu item names:
Given that the menuItemSize doesn’t affect anything except the size of the Plugins’ menu entries in TCHAR _itemName[menuItemSize], and the equivalent for built-in context menus is generic_string _itemName , which doesn’t have length restrictions, I think it’s worth trying to ask Don to allow for an increase (“Notepad++ menu entries don’t have a length restriction, but Plugin menu entries do” seems a solid argument, to me).
Changing that would break existing plugins. It’s hard-coded into the C interface.
@Mark-Olson
I’m coming a bit off the top of my head here, but I see no way Notepad++ could offer a message, since the length limit is hard-coded into the interface structure. If you’re supplying more than 63 characters, you have, by definition, broken the interface.If you hard-coded a character string of more than 63 characters into a C/C++ program using that structure (as I use it here), you’d get a compile time error.
As I understand it, plugins that choose to be translatable must supply their own translation mechanism; Notepad++ doesn’t do anything about that. I believe it must be the translation process in your plugin that is copying a string without checking the acceptable target length first.