Re: Need some bug/version info
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> Ok, so it would appear that the next release announcement
David> should essentially have to contain something like:
David> Since at the current point of time no XEmacs developer
David> can be interested enough in preview-latex to even answer
David> questions, the
Why, how can you possibly conclude that?
Because my request that included the specific date and time and
comment from the XEmacs developer that could be dug out from the CVS
logs (there is not even a ChangeLog entry, unfortunately) met no
response whatsoever on an otherwise active list.
I estimated that what with the lack of any XEmacs-specific
information on a rarely manifesting bug dealt with by a non-XEmacs
developer, you would realize that it would take at least 10 days to
do the necessary research, and have a bit of patience.
If nobody acknowledges a request after two days with even a word or
comment, it would be absurd of me to assume that an answer will
magically pop up at some later point of time. It would appear obvious
that _if_ somebody was intending to do the necessary research but
considered it to take some time, he would indicate this, at the very
least to save others doing unnecessary work.
Since you are in a hurry, my answer is "I'm sorry, but I
have no
idea what you are talking about; I simply don't recall any such
report. If you would give us test cases and information about
versions and configurations of XEmacs so that we can replicate the
bug with the version in question, then we can probably get back to
you about current status, including exploring various configurations
that might be relevant and whether it has been solved or can easily
be solved in XEmacs---in about a week. If we have to do all that
research, it'll be several weeks, if it happens at all."
Ok, so it is not possible to take a look into the ChangeLog files for
XEmacs' version of dired at around the given date to check whether
this particular problem has been tackled at some point of time.
Regarding code examples and test cases: no can do. I don't think
anybody from our developers has a collection of different XEmacsen
flying around. The bug was pretty severe: complete corruption of all
image loads by :file specifier after dired has been loaded. This
would not just have affected preview-latex, but also other stuff that
was loading images by file name (probably w3). Maybe even toolbar
buttons, no idea.
At that time, workaround code for XEmacs has been added into
preview-latex (basically using :data instead of :file, unnecessarily
loading images that might not actually get displayed). This
workaround affects code that I am just now changing, and it affects
the installation procedure. We just recently had a report where the
installation under XEmacs failed completely due to the script part
intended to cater for the workaround: it appears to have suffered from
bit rot. We don't have the means to maintain the workaround in
working condition without a responsible developer. So we just have to
take the bet that maybe the workaround is no longer required after
all, and throw it out completely.
I will probably manage to give some cursory testing with a stock
XEmacs from Fedora development, which should tell us enough to tell
people "don't even try XEmacs" in case the dired bug has survived
after all (which I hope not). But even if it hasn't, we don't have a
pointer about what XEmacs version would be required to make
preview-latex work.
A thorough research on the mailing list also turns up
<URL:http://sourceforge.net/mailarchive/message.php?msg_id=2367671>
where Nick describes the problem origin after hunting it down.
We don't have any more information about this bug available. If you
say you need test cases and descriptions for reproducing it and
whatever else: I don't think we can provide any of this. However, if
the bug persists, it should be easy enough to trigger by loading any
image by way of a :file type image descriptor, after dired has already
been loaded.
You're certainly welcome to promote GNU Emacs at the expense of
XEmacs in your announcement; I've encouraged you to do that in the
past, as I see no constituency (aside from maybe poor Uwe Brauer,
who works his butt off) for preview-latex among XEmacs users.
You pointed this out for AUCTeX. And yes, we are following your
advice there. I've given up pretense equality there and stopped
censoring our developers. The recommendation for people wanting to
use AUCTeX is to use Emacs by now. It would be dishonest to pretend
equality: almost all of the recent releases turned out to have severe
problems of some kind with XEmacs. So we have taken up discrimination
in the literal meaning of the word. I don't like it one bit, but if
we don't tell people that there are differences to be expected, then
problems with a particular platform reflect on AUCTeX in general.
Alternatively, you can tell your users to do their part by making a
fuss about the bugs that bite them on XEmacs channels. But please
leave the XEmacs developers' attitude out of it; we would be quite
happy to help your XEmacs users if there were evidence that they
want it.
If the reason for not giving better news to XEmacs users is that
requests on the XEmacs developer list tend to go unanswered for me, I
don't see why I should try to make a secret of that. That is not
bringing anybody's "attitude" into play, as I don't indulge in
speculation about the reasons.
If I try hiding this,
a) users will fault us for unfairly discriminating against XEmacs.
It's not like I don't provide a perfect target for that.
b) users will continue not to give evidence to XEmacs developers that
they'd appreciate any help from XEmacs developers for preview-latex
and/or AUCTeX under XEmacs.
If, as you state, there is no evidence that XEmacs users for our
packages would be interested in any attempt of cooperation with XEmacs
developers, what I happen to write into our docs/release notes should
not impact you in any manner: it won't be perused by XEmacs users,
anyhow.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum