I was ambushed by the 63-character limit for plugin menu item names

[Mark Olson]

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 ;)

[PeterJones]

@Mark-Olson ,

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 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).

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, and Generate 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.)

[Coises]

@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.