TEDIT.ABBREVS entry with LITATOM on CHARACTERNAMES failed to process

[MattHeffron]

If CADR of a TEDIT.ABBREVS entry is LITATOM that can CHARCODE.DECODE (i.e., it's on CHARACTERNAMES), use it.

Clear the TEdit prompt window of any old messages if \TEDIT.ABBREV.EXPAND finds an expansion in TEDIT.ABBREVS.

"=" is duplicated as an expansion KEY, so modified the TEDIT.ABBREVS entry:

("=" "357,121")

to

("lra" "357,121"  ; U+21C6 Leftwards Arrow Over Rightwards Arrow ("lra" is "left-right-arrow")
                )

because "=" is also the KEY in entry:

("=" NONBREAKING-HYPHEN)

which was never seen as a possibility (the above was earlier in the ALIST).
(This change exposed the issue with LITATOM as CADR of entry.)

Cleaned up some comments, typos. Added a few more TEDIT.ABBREVS entries.

(Discovered, that if the CADR of the entry is valid itself, then the CDDR of the entry is ignored and can be a comment.)

Further issue:

@rmkaplan
Three entries on TEDIT.ABBREVS depend on entries on CHARACTERNAMES that aren't present in a FULL sysout. They're added in TEDIT-SCREEN under

[DECLARE%: EVAL@COMPILE DONTCOPY
               (EXPORT etc

They only get added to CHARACTERNAMES by loading tedit-exports.all.
I tried to move them out of the above structure to the top of the TEDIT-SCREENCOMS:

((COMS
   ;; This shouldn't be under the DONTCOPY.
   ;; There's no reason for these not to be added to CHARACTERNAMES on any normal LOAD
   (ALISTS (CHARACTERNAMES SOFT-HYPHEN NONBREAKING-HYPHEN NONBREAKING-SPACE)))
 (DECLARE%: EVAL@COMPILE DONTCOPY
               (EXPORT etc

but was unable to remake the file or compile it.

[pamoroso]

On Linux Mint 22.1 Cinnamon it seems to be working fine, event for b and c that yield the warning No abbreviation to expand on master.

I'm not sure about << and >> though as the expanded text looks nearly identical to the abbreviation.

[MattHeffron]

I'm not sure about << and >> though as the expanded text looks nearly identical to the abbreviation.

@pamoroso
That may be due to the particular font. I tested with Modern 10.
The expansion doesn't look correct. It ought to be smaller and a single character glyph, not 2 characters.

[pamoroso]

With Modern 10 << and >> expand as expected along with other abbreviations that don't expand with Gacha.

[rmkaplan]

It shouldn't depend on the font--Missing Gacha should have been filled in from Terminal and then Modern when the medleyfont was created.

…

On Dec 3, 2025, at 2:14 AM, Paolo Amoroso ***@***.***> wrote: pamoroso left a comment (Interlisp/medley#2398) <#2398 (comment)> With Modern 10 << and >> expand as expected along with other abbreviations that don't expand with Gacha. abbrevs-modern.png (view on web) <https://github.com/user-attachments/assets/d90755dc-4ae9-4318-a520-d2723d47e5e8> — Reply to this email directly, view it on GitHub <#2398 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKD7LH62CHKO6EIZM3372ZZ7AVCNFSM6AAAAACNYCVBSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBWGA3TSMRZGQ>. You are receiving this because you were mentioned.