[texhax] Trying to find if a listing is continued with listings package

[Philip Taylor]

Reinhard Kotucha wrote:

> Hello Phil,

> here is the definition (see texmf-dist/source/latex/ltdefns.ltx):

So sorry, I thought you proposed \@undefined, not \@ifundefined; mea culpa.

> It's much safer if LaTeX users use LaTeX code exclusively.

Yes, I agree. In fact, I often think life would be a /very/ great deal
simpler if the TeX/LaTeX confusion that currently exists could be done
away with completely -- it does not help that lists such as TeXhax,
Usenet newsgroups such as Comp.Text.TeX and fora such as
TeX.Stackexchange allow (nay, positively encourage) discussions
concerning LaTeX.  Separate lists/newsgroups/fora (LaTeXhax,
Comp.Text.LaTeX, LaTeX.Stackexchange, etc) need to created to host such
discussions, allowing those of us who want to ask questions about TeX to
get TeX-related answers and not (as is only too often the case)
LaTeX-related answers from those who do not understand the difference.
The situation is analogous to that of the JavaScript world, where one
asks a question about JavaScript but 90% of the answers assume that
JQuery is really the Universe of Discourse.

> BTW, the fact that \csname \endcsname always sets the control 
> sequence to \relax, even if you are just testing whether it exists at
> all, is quite unfortunate.

But it is also very useful; it allows tests with side-effects in
contexts where only expansion is allowed (to test, for example, whether
something occurs in the left or right column in an output routine). And
if \csname ... \endcsname is being used in the context of a test, then
one can (should) use \ifcsname ... \fi, which adds nothing to the hash
table if the <csname> does not exist.

> It adds something to the hash table which can never be removed and 
> thus stays there forever.  This slows down table lookups and blows up
> the string pool.  When I created huge files with pgfplots I already
> had to increase the string pool.  In this case however, I believe
> that there is a bug in one of related the packages.

I think that the use of \ifcsname would have addressed this.

> Phil, we discussed this issue a few years ago and you forwarded a 
> mail from someone who explained *why* TeX cannot remove unused 
> csnames from the hash table.  Unfortunately I can't find this mail 
> anymore.  Do you remember it and can you forward it to me again?

It may have been in this thread :

	https://tug.org/pipermail/texhax/2006-September/006871.html

or perhaps this statement from the Grand Wizard himself, via BNB:

> when knuth was asked about this, a long time ago, his response was 
> that he was unable to tell whether in fact a \cs was defined 
> elesewhere, locally, and to continually be defining and undefining 
> the same thing would be wasteful and time-consuming.  i think there 
> was also some consideration of clearing things out of the middle of 
> the hash table (the same reason given for not being able to remove a 
> file name from the string pool unless it is the very last thing put 
> onto the list). i will try to look up the reference if that is 
> considered useful. also, peter may have a different opinion ... -- 
> bb

to which Denis Roegel replied :

> In TeX's errorlog, I found the following which might shed some light
>  on the topic.
> 
> Denis.
> 
> * 28 Aug 1979 ... S422\>403. Correct a serious |\gdef| bug: Control 
> sequences don't obey a last-in-first-out discipline, so \TeX\ loses 
> things from the hash table when deleting a control sequence. @259 # 
> To fix this, I either need to restrict \TeX\ (so that |\gdef| can be 
> used inside a group only for control sequences already defined on
> the outer level) or need to change the hash table algorithm. Although
> all applications of \TeX\ known to me will agree to the former 
> restriction, I've chosen the latter alternative, because it gives me
>  a chance to improve the language: Control sequences of arbitrary 
> length will now be recognized.

** Phil.