Re: Need some bug/version info

Ralf Angeli <[email protected]> writes:

> * Stephen J. Turnbull (2005-02-02) writes:
>
>>>>>>> "Ralf" == Ralf Angeli <[email protected]> writes:
>>
>>     Ralf> As we are about to release AUCTeX 11.55, we are in need of a
>>     Ralf> workaround for 21.4.16.
>>
>> (when (and (featurep 'xemacs)
>>             (emacs-version>= 21 4 16)
>>             (not (emacs-version>= 21 4 17)))
>>   (error 'invalid-state "XEmacs 21.4.16 (and only that release) has a
>> fatal bug in the regexp code that AUCTeX triggers in several places.
>> Upgrade to 21.4.17."))
>>
>> in some appropriate place in the auctex load sequence is what I
>> would suggest; even if AUCTeX works around it, other applications
>> could trigger it.
>
> That's pretty consequent.  Besides people building current stable
> versions of XEmacs directly from xemacs.org, it would currently lock
> out everybody facilitating a distribution with a frequently updated
> package/port system, like Debian/sid, Fedora Core Devel, Mandrake
> Cooker or the BSDs.  And then we can only hope that none of the bigger
> distributions will ship XEmacs 21.4.16 with their next stable
> releases.

Actually, shy regexps are by now used rather widely in Lisp packages
(for example, preview-latex).  XEmacs' version of regexp-opt _also_
produces shy regexps, and it is used all across the XEmacs code base
and external packages, even those that don't explicitly use shy
regexps themselves.

As far as I can see, the main symptom would be random core dumps.  I
don't think that people will assign the blame to AUCTeX for core
dumps.

So basically this is major XEmacs problem affecting its operation all
across the board, and it does not make sense for AUCTeX to deal in an
isolated manner with it.  This is a matter of XEmacs release and
quality management.  The release should be pulled and people
prominently given notice.  If package authors in general are asked to
include code like the above, then we will probably follow suit.

But you would be doing a disservice to your users by pretending this
matter is even close to being dealt with responsibly if AUCTeX refuses
to load.

So my take on this matter is that we will _not_ change our code in the
above way _unless_ there is an _official_ call of the XEmacs
development team to _all_ package developers to do this.  Such a call
would probably only make sense in connection with a _general_ warning
about that XEmacs release (which is supposed to be in the stable
series).

Unless the XEmacs developers declare this step necessary for _all_
package developers in order to control the spread of this
fundamentally buggy release, I don't think we should muddy our own
code base, but instead just mention this problem in the release notes,
and maybe as package conflicts.

It is also a possibility that our installation procedure check for
working shy regexps (after all, this is not the first time they have
created havoc within XEmacs, as can be witnessed from the
preview-latex change log entries from Nix).

But the proper place for such checks would really be in regression
tests for XEmacs, not in the installation procedures of AUCTeX.

> Unless somebody has a better idea I will insert a code stanza
> similar to the one proposed by Stephen into tex-site.el and add a
> prominent note to the release notes that people who are using XEmacs
> 21.4.16 should stay away from AUCTeX 11.55 or upgrade to 21.4.17 as
> soon as it is available.

People who are using 21.4.16 will be hosed also without using AUCTeX.
Shy regexps are an integral part of XEmacs via regexp-opt.

It does not make sense to make AUCTeX the poster child for telling
this to people.  My opinion is to mention this prominently in the
release notes as long as it is to be feared that this XEmacs version
is around.  And how long this is to be feared very much depends on how
the XEmacs developers will choose to deal with the problem.  If it is
their opinion that an occasional core dump in normal operation is no
reason to warn people off a release in a prominent manner, then it is
_us_ that is going to get blamed when some stock XEmacs/AUCTeX
combination gets made available and refuses to work.

This XEmacs version must not get put on _any_ software distribution
intended to be stable since XEmacs' operation as a whole is affected,
and it is beyond the power of the AUCTeX developers to tell
distributors "don't use 21.4.16", except possibly by package
conflicts.  And if a distributor finds AUCTeX conflicting with XEmacs,
he will in case of doubt throw out AUCTeX, obviously.  We can't
reasonably substitute for XEmacs quality management in this instance.

> Stephen, thanks for your input.

Seconded.

> I adapted the Reply-To to limit further discussion of this issue to
> the AUCTeX list as this will probably not be of high relevance for
> the XEmacs community.  Feel free to ignore this if you think
> otherwise.

I did.  I consider this of high relevance to the XEmacs community, and
I would appreciate it if the auc-tex list were kept informed in case
the XEmacs developers decide to take any measures for deprecating
21.4.16 outside of this particular thread.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum