Macro processor tries too hard without curly braces

Question

Given this MWE;

\documentclass[12pt]{report}
\usepackage{fontspec}
\def\ee{=e=e}
\begin{document}
    sh\ee{n}g ur k=asn
\end{document}

Is there a way to eliminate the curly braces that prevent the macro processor from becoming confused and looking for another macro name? Similar to the way that \=a does not consume the following s. I have just now noticed that the \ee will consume the following space for reasons I do not have sufficient LaTeX-Fu to correct other than with a pair of closed braces {}.

@CarLaTex Am I correct in thinking that there is no ability to move questions to the correct place? — hsmyers, Mar 26 '24 at 18:36
Is the problem that you don't want to type {n} and instead would prefer to type just n? That is the exact reason why the following space is consumed, it allows you to type \ee n and that will give the same output as \ee{n}. — Marijn, Mar 26 '24 at 22:32
@Marijn Exactly! I have many of these double-letter additions, and the slight annoyance adds up. Besides, it would be nice to add this ability to my macro writing. — hsmyers, Mar 26 '24 at 22:47
Take a look at these two earlier questions: Space after LaTeX commands and Acceptable use cases for xspace; When will it fail? — barbara beeton, Mar 26 '24 at 23:12
@barbarabeeton, these solve the mystery of the macro that ate a space! Thanks for the pointer… — hsmyers, Mar 26 '24 at 23:37
@barbarabeeton, well I don't need the empty braces anymore, so that part is solved. But the larger problem of having to enclose a letter that follows such a macro with braces still remains. — hsmyers, Mar 27 '24 at 00:07
I haven't tested this, but ending the definition with empty braces would mean that the last \=e is "blocked": \def\ee{\=e\=e{}}. By the way, since you're using LaTeX and not plain, you'll be better off in the long run to use \newcommand instead of \def; if a command name already exists, \newcommand will check, and complain if it does; \def will happily overwrite it, and may surprise you later. — barbara beeton, Mar 27 '24 at 00:55
@hsmyers I have to admit I still don't fully understand what exactly the problem is. Do you want to be able to type \een with the result of running \ee and then printing n? This would be rather different from how programming languages normally work, it would be quite difficult to implement and it could introduce confusion (what if you have defined both \ee and \een, which one should be taken?). Or is this not what you mean and you want something else? If so, what is the input syntax you want to use and what is the output that you expect from that? — Marijn, Mar 27 '24 at 06:58
@Marijn, what you have deduced is correct. I inquired, knowing it might be impossible and impractical. This is used frequently in phonetic spelling and is not subject to extension by adding a letter; the chance that someone else might have exists, but it seems a bit of a stretch to me. — hsmyers, Mar 27 '24 at 14:16
Why not just typing ēē? With my keyboard its “option-a e”. — egreg, Mar 27 '24 at 16:09
@egreg, what OS and what keyboard? I'm Windows with a nice but non-programable keyboard (i.e., non-gamers.) — hsmyers, Mar 27 '24 at 16:20
@hsmyers I'm pretty sure there are dead keys also on Windows, but I can't test as Windows machines refuse to work when I'm in front of them (not only I, actually). The keyboard I use is the standard internetional keyboard on a Mac. — egreg, Mar 27 '24 at 16:28
@egreg Well, if I translate "option" to control, then control a selects all of the text in the file, so problems abound. Be nice, though! — hsmyers, Mar 27 '24 at 16:35

Marijn · Accepted Answer · 2024-03-27T21:06:18.693

3

It is possible with LuaLaTeX. You can add a callback that post-processes each line to replace instances of \ee by \ee , i.e., add a space. gsub is a global replacement, so all occurrences in a line will be replaced. You can add other macros with additional gsub lines.

\documentclass[12pt]{report}
\usepackage{luacode}
\def\ee{=e=e}
\def\oo{=o=o}
\begin{luacode}
    function addspace(line)
        line = string.gsub(line, "\ee", "\ee ")
        line = string.gsub(line, "\oo", "\oo ")
        return line
    end
    luatexbase.add_to_callback("process_input_buffer", addspace, "easytyping")
\end{luacode}
\begin{document}
    sh\eeng ur k=asn \oong \eeng
\end{document}

But I would recommend just typing sh\ee ng ur k\=asn \oo ng \ee ng yourself, it is very easy to get used to and it would save the trouble of doing the postprocessing.

edited Mar 27 '24 at 21:06

answered Mar 27 '24 at 14:28

Marijn

37,699

So remove the \xspace in the macro and use the eating space in my favor? This from a macro version you've not seen. – hsmyers Mar 27 '24 at 15:39
There are two more macros. Does Lua have a case construct? Likewise, there are cases where the following character is a closing brace—which might be handled by the existing sub? – hsmyers Mar 27 '24 at 15:46
I've determined that this works well for the edge cases. All that I need is to add the else if statements, which, at a guess, would require knowing which macro I was looking at? – hsmyers Mar 27 '24 at 15:57
Of course one mustn't have the macros \eel or \eek, unless many more cases have to be added. – egreg Mar 27 '24 at 16:09
@egreg, Chuckle—seems unlikely in text involving Scottish Gaelic! – hsmyers Mar 27 '24 at 16:17
Another problem occurs to me: there is possibly more than one occurrence of these macros on a given line. – hsmyers Mar 27 '24 at 16:39
I'm going with your suggestion just use a space to separate as needed. In the edge case where they end with 'real' space, I'll just use a '~.' – hsmyers Mar 27 '24 at 17:29
@hsmyers I made two extensions to cover multiple macros and multiple occurrences of a single macro, just as a proof of principle. – Marijn Mar 27 '24 at 20:58

Macro processor tries too hard without curly braces

1 Answers1