Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>
>  > There's also the case that the application was invoked on a remote
>  > host, and its output is passed via the network (a.k.a. "Tramp").  Not
>  > sure if those 3 cases cover that.
>
> My three cases were intended to cover the "local" case, where the user
> presumably has control of the files on her system.  The case you are
> describing is covered under network streams as far as I'm concerned
> (YMMV, that's just the way I broke things down).
>
>  > > An example of (3) is David's case, with AUCTeX handling of TeX error
>  > > messages containing non-unibyte text.)  AFAIK such applications are
>  > > quite rare nowadays.
>  > 
>  > "Rare" doesn't mean unimportant to users to the degree we can ignore
>  > them.  If we do want to cater to those "rare" cases, the only way of
>  > doing that is maintain a database of programs and their behaviors.
>
> That's my main strategy, yes.  We have `file-coding-system-alist' for
> filename cases, similar features for process and network streams, and
> individual modes such as AUCTeX are developed by hackers who have
> proved themselves able to take care of themselves.

But that's not what happens.  AUCTeX uses the normal defaults.  When
those defaults prove _insufficient_ to do the trick (which happens in
sub-percentages of the total) for finding the corresponding source in a
(normally encoding-correct) buffer of characters by interpreting the
error context messages on a terminal where byte-based linebreaks may
corrupt characters, _then_ the error context message (which came in from
a terminal with an encoding, so no byte stream exists any more) are
reencoded to utf-8, the line break is removed, and the byte stream is
redecoded and matched again to the source file buffer containing
_characters_ in the same encoding as those used for decoding the
terminal.

So the point is that
a) TeX daring to produce error output on its console does not cause
beeps and interruptions
b) I have a fallback strategy for dealing with that kind of "ugh" that
is _not_ covered by the standard fallback strategies but that can be
hand-implemented _because_ there was no information loss.

The alternative would be to create an encoding utf-8-with-bad-linebreaks
and the respective coders/recoders and have that as the terminal
encoding for running TeX.

And I have no doubt that people will say that I should be forced to go
that path since it is the "correct" one.

Except that a single TeX run may very well go across several files with
_different_ encodings, so there really is no single "correct" encoding
for the terminal messages of TeX.

Which means that the current "don't mess with things you have not been
told to mess with" behavior leaves the programmer in the situation to
focus on the _actual_ problem rather than fighting Emacs' preconceptions
about what problem he is allowed to encounter.

> Nevertheless, things are much better today than in the days when Erik
> Naggum declared that "Emacs has a fatal disease, and its name is
> 'MULE'".

Erik was the highest profile programmer/user abandoning Emacs for XEmacs
in order to avoid the consequences of multibyte encodings.  I seem to
remember that he blamed the principle of multibyte encodings rather than
the early buggy MULE implementations (the earliest implementations
worked with byte offsets for buffer and string positions so there was
wagonloads of fallout, but I think he also objected to the performance
implications when closing that problem vector by making buffer and
string positions character-based).

I have no idea which Emacs variant he would be using these days if he
were still around.  It may well be XEmacs since part of his objections
against MULE (which is now pretty unavoidable in XEmacs as well
I _think_) was the manner of the top-down decision-making resulting in
its early inclusion in Emacs when it was not all-that-ready.

> I suppose it would be reasonable to distinguish between Internet
> streams, local network streams (but only if a valid certificate was
> presented, otherwise there's little reason to be confident), and local
> files or processes.  But doing that conveniently and accurately sounds
> like a painstaking task.

The only thing one case sensibly do in stacked problems like this is to
have each level deal with its own problems.  And that means that it
needs to pass on data that is not being processed at its own level.

-- 
David Kastrup