On Wed, Aug 30, 2017 at 11:02:19PM -0400 I heard the voice of Steve Litt, and lo! it spake thus: > > Although the Enter key works beautifully on a leaf level item, > executing the associated command, on an item that calls a submenu > the Enter key acts like Escape: It exits the menu. > > To me this is unexpected behavior. Most menus that use Enter to > invoke a choice invoke that choice whether it's a choice to run a > command or a choice to display a submenu. Either this is a bug in > ctwm or there's a logic I'm just not seeing.
Probably some of both. For further investigation of the why, I'd note the change in that block in 3.3; prior to that the conditional was simpler and only went into that block for the Workspaces menu. So it seems like it may at least be in the "unexpected side effect" bug bucket; 'd have to do a little more investigation of just what/why that change was intended to affect to say for sure. I wouldn't expect to have a chance to look much at it myself soon, but that should give anybody who does a starting point. > At this point I can't call my workaround a solution, because I don't > know the original intent of testing for "Return" at that point, so > my workaround might have unintended side effects. Well, from the looks of the 3.2 code, it was to make the Workspaces magic menu (i.e., 'f.menu "TwmWorkspaces"') do its thing. The Workspaces menu doesn't create real entries with real usable functions; x-ref MakeWorkspacesMenu() and despair. I don't offhand know why; it may be purely hysterical raisins and we could do better nowadays (or could even do better then, and it was just implementation accident). Though even then it did its magic only for Return, even though Right would also wind up doing the "invoke-y" thing on entries, which (without too much thought, mind) sounds at least bug-adjacent too. > I'm not sure what side effect that would be, because none of this > code is executed unless the item->func is F_MENU, which I assume > means "we're in a menu." Not exactly, if you mean "we're pressing the key while scrolling through a menu"; that's already the case since we're in the "if(ActiveMenu != NULL)" block of the KeyPress handler. It means "the entry we're trying to invoke is a 'f.menu' call". Apart from the "top-level", where a mouse click or keypress calls up a menu the first time, f.menu never gets executed like a normal function. It winds up being pulled up by magic in that keypress handler where you're looking, or by having the mouse pointer move into the right third of the entry in the menu code where it internally hijiacks the event loop. So there's plenty of magic hiding in there to fuel nightmares... -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
