Add error check for creating a MENU with empty ITEMS.

[MattHeffron]

This addresses issue #2306.

There might be cases where a MENU is constructed incrementally, starting with an empty ITEMS list. This change will break that situation!

(My first thought was to default the ITEMS to (LIST "*** Empty MENU!! ***"). That felt like a hack solution.)

[pamoroso]

When building Medley on Linux Mint 22.1 Cinnamon I get this error:

INTERLISP-ERROR
In ERROR:
MENU ITEMS list is empty

paolo@lispmachine:~/medley/medley$ ./scripts/loadup-all.sh -apps
>>>>> START loadup-init
"/home/paolo/bin/lde" "/home/paolo/medley/medley/internal/loadups/starter.sysout" -id "loadup_init_1" -title "Medley::loadup_init_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/loadups/build/loadup-init.init"
REM.CM FILE: ""
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_init_1.virtualmem"
+++++ SUCCESS +++++
[...]
+++++ SUCCESS +++++
..... files created .....
-rw-rw-r-- 1 paolo paolo 10030 Oct  2 10:59 /home/paolo/medley/medley/loadups/build/full.dribble
-rw-rw-r-- 1 paolo paolo 10889728 Oct  2 10:59 /home/paolo/medley/medley/loadups/build/full.sysout
<<<<< END loadup-full-from-lisp

>>>>> START loadup-apps-from-full
"/home/paolo/bin/lde" "/home/paolo/medley/medley/loadups/build/full.sysout" -id "loadup_apps_from_full_1" -title "Medley::loadup_apps_from_full_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/greetfiles/NOGREET"
REM.CM FILE: "/home/paolo/medley/medley/loadups/build/loadup-apps-from-full.cm"
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_apps_from_full_1.virtualmem"

This is the directory loadups/build: build.zip

[masinter]

building incrementally and starting with a invalid structure until built is a common usage pattern and should be accomodated.
(create MENU) should return. It MIGHT be better to avoid the divide-by-zero error, BUT I don't think that makes anything more stable or fixes any problems with backward compatibility or portability. The manual doesn't say what (MENU (craete MENU)) does, but it doesn't say what (MENU (create MENU ITEMS _
'JUNK)) does either.

[MattHeffron]

Closing this PR as the strategy is wrong.

[rmkaplan]

My concern is that a divide-by-zero from deep in the menu code does not help a user figure out what's wrong. An error with a meaningful message that happens later, when the menu is actuallly displayed would be OK. But it might be harder to trap those situations.

…

On Oct 2, 2025, at 11:11 AM, Matt Heffron ***@***.***> wrote: MattHeffron left a comment (Interlisp/medley#2307) <#2307 (comment)> Closing this PR as the strategy is wrong. — Reply to this email directly, view it on GitHub <#2307 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOGUXKNZATNEAE3TSL3VVTGTAVCNFSM6AAAAACICKJCMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNRSGQYTCOJVHA>. You are receiving this because your review was requested.

[MattHeffron]

An error with a meaningful message that happens later, when the menu is actually displayed would be OK.

That was going to be my next approach.
It could check for an empty ITEMS list on the call to (MENU ...), but how should it assert the error? Calling (ERROR m1 m2) ?
Attached menus also should check. It's easy when attaching, but what about if the ITEMS list has been modified?
Does modifying the ITEMS of an attached menu even work (without detaching, modifying, then re-attaching)?