1:53 p.m.
>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
Hello David,
Directed to both XEmacs and AUCTeX developer lists.
It has become clear in the last few years that the efforts of
AUCTeX developers to support XEmacs are basically a waste of time.
According to the XEmacs developer lists, there is no noticeable
interest in an uptodate AUCTeX distribution.
Well, first of all I have to apologize for not having been able to
submit the desired patch in due time. However thanks to Mats Lidell we
have an almost working solution (save a patch which should be applied to
XEmacs.rules). It is however not clear right now, whether this patch
will be accepted or another solution should be found. In any case I will
submit that patch tomorrow, (my workload has been high in the past
months) and hopefully within a couple of days we will have a working
solution. Once that is settled further synchronization should be easy
(given that the Installation process will not be changed again).
I all the time have benefit from your generous support of XEmacs and
appreciate that a lot. It is true there was no real Xemacs hacker (save
Nick for a time) actively contribution code to auctex. The best I could
offer myself would be testing, some contributions to style files but
unfortunately not more.
Am I overlooking something?
So given that we will have a working solution soon I would like to ask
you, not to stop the support you have given so far to XEmacs.
Thank you very much
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:05 p.m.
New subject: [AUCTeX-devel] Re: Upstream support of XEmacs in AUCTeX
Uwe Brauer <oub(a)mat.ucm.es> writes:
>>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
Hello David,
> Directed to both XEmacs and AUCTeX developer lists.
> It has become clear in the last few years that the efforts of
> AUCTeX developers to support XEmacs are basically a waste of time.
Well, first of all I have to apologize for not having been able to
submit the desired patch in due time. However thanks to Mats Lidell we
have an almost working solution (save a patch which should be applied to
XEmacs.rules). It is however not clear right now, whether this patch
will be accepted or another solution should be found. In any case I will
submit that patch tomorrow, (my workload has been high in the past
months) and hopefully within a couple of days we will have a working
solution. Once that is settled further synchronization should be easy
(given that the Installation process will not be changed again).
> Am I overlooking something?
So given that we will have a working solution soon I would like to ask
you, not to stop the support you have given so far to XEmacs.
Unless I misunderstand, the patch that is going to be checked into the
XEmacs package system does not make any use of the build infrastructure
for XEmacs that the AUCTeX upstream has created, but rather tries to
incrementally change the previously existing package framework (which is
the main reason that the workload for you has been quite difficult if I
understand correctly).
So I don't see that upstream dropping all support for building XEmacs
packages should affect your work. Unless I misunderstand the situation,
our XEmacs package support never has been used in the XEmacs package
system, anyway.
Am I overlooking something?
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:25 a.m.
New subject: Upstream support of XEmacs in AUCTeX
Unless I misunderstand, the patch that is going to be checked into
the
XEmacs package system does not make any use of the build infrastructure
for XEmacs that the AUCTeX upstream has created, but rather tries to
incrementally change the previously existing package framework (which is
the main reason that the workload for you has been quite difficult if I
understand correctly).
This is correct.
So I don't see that upstream dropping all support for building
XEmacs
packages should affect your work. Unless I misunderstand the situation,
our XEmacs package support never has been used in the XEmacs package
system, anyway.
Am I overlooking something?
Well it seems that I misunderstood your announcement. On one hand I
appreciate all your efforts of even providing a xemacs pkg and I can
perfectly understand that you are frustrated that it did not make it way
into the official xemacs pkg system.
Unfortunately Xemacs does not support 3rd party pkg the same way
debian dpkg or RH rpm does. I raised that subject form time to time but
it seems to be a very hard problem and I myself have not enough lisp
knowledge of even dreaming to provide such a functionality.
So in short if you decide to drop this sort of support that is perfectly
understandable (though sad), and you are right it should be our turn to
provide such a pkg.
However you also write in your mail
David> I would thus suggest that we discontinue maintenance of the
David> XEmacs-related parts of AUCTeX. It has been a resource hog,
David> and only a few selected XEmacs users, those that will use our
David> tarball rather than an offical XEmacs package, will ever be
David> able to make use of it, anyway.
David> I would also suggest that we stop investing time to figure out
David> how to make AUCTeX features work on XEmacs. There is little
David> point, for example, for supporting non-MULE builds. There is
David> also little point in bending over backwards in designing
David> operation and interfaces for areas of large incompatibilities,
David> like syntax highlighting and display engine features (images,
David> folding, and so on).
That sounds to me that you are going to drop support of Xemacs
all together and again it seems for the lack of active coders.
It seems to me that there are two possiblites:
- you add some new functionality but that code will not work in
xemacs
- you add code that may break the usability of auctex for xemacs
all together.
It is the second possibility which worries me a lot but all I can offer
would be some testing (may be a person with knowledge and interest is
reading this and would like to play a more active role in the Xemacs
part of auctex). I hope that for the moment you are not really
considering to break the usability of auctex for Xemacs users.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11 a.m.
New subject: [AUCTeX-devel] Re: Upstream support of XEmacs in AUCTeX
Uwe Brauer <oub(a)mat.ucm.es> writes:
> So I don't see that upstream dropping all support for
building
> XEmacs packages should affect your work. Unless I misunderstand
> the situation, our XEmacs package support never has been used in
> the XEmacs package system, anyway.
> Am I overlooking something?
Well it seems that I misunderstood your announcement. On one hand I
appreciate all your efforts of even providing a xemacs pkg and I can
perfectly understand that you are frustrated that it did not make it
way into the official xemacs pkg system. Unfortunately Xemacs does
not support 3rd party pkg the same way debian dpkg or RH rpm does. I
raised that subject form time to time but it seems to be a very hard
problem and I myself have not enough lisp knowledge of even dreaming
to provide such a functionality.
Basically it seems like a waste of time to recreate the AUCTeX build
process when one can just let the build process run and check the
results in. In that manner, supporting AUCTeX is not a bit more
complicated than supporting any Lisp-only package.
But it looks like people are intent on doing it the hard way. Of course
this has the advantage that we don't need to take XEmacs into account
anymore and can remove the respective code.
However you also write in your mail
David> I would thus suggest that we discontinue maintenance of the
David> XEmacs-related parts of AUCTeX. It has been a resource hog,
David> and only a few selected XEmacs users, those that will use
David> our tarball rather than an offical XEmacs package, will ever
David> be able to make use of it, anyway.
David> I would also suggest that we stop investing time to figure
David> out how to make AUCTeX features work on XEmacs. There is
David> little point, for example, for supporting non-MULE builds.
David> There is also little point in bending over backwards in
David> designing operation and interfaces for areas of large
David> incompatibilities, like syntax highlighting and display
David> engine features (images, folding, and so on).
That sounds to me that you are going to drop support of Xemacs all
together and again it seems for the lack of active coders.
For the lack of dedicated coders. Any work supporting XEmacs at the
moment detracts resources from supporting AUCTeX on Emacs. And even
though with Emacs we have an active, supportive, responsive and thriving
developer community and a solid code base, making AUCTeX keep pace with
what it could and should do is hard.
It seems to me that there are two possiblites:
- you add some new functionality but that code will not work in
xemacs
- you add code that may break the usability of auctex for xemacs
all together.
It is the second possibility which worries me a lot but all I can
offer would be some testing (may be a person with knowledge and
interest is reading this and would like to play a more active role in
the Xemacs part of auctex). I hope that for the moment you are not
really considering to break the usability of auctex for Xemacs users.
We don't want features that are in a state of stasis or bit rot mainly
because of the complexity from XEmacs compatibility. The LaTeX toolbar
is in that state, and that's mostly my fault because I asked its author
for it. The multibyte and error parsing support for preview-latex is
close. The compatibility stuff for font lock code is complicating
things, and still font lock does not work satisfactorily: XEmacs is
unusable on large files and much less accurate.
I am considering dropping Emacs 21 compatibility soon because the Emacs
22 provisions are just a better environment for development. XEmacs has
not even left the Emacs 20.4 (or so) era consistently.
XEmacs compatibility is crippling AUCTeX development for all of its
users. And the XEmacs user base is just too small to warrant that. If
those that actually use XEmacs are not willing or able to get the stuff
to run on XEmacs, because XEmacs is too different or broken or most
likely because nobody really cares enough, then that's just that.
I'd rather have AUCTeX go forward Emacs-only than not at all.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:28 p.m.
New subject: Upstream support of XEmacs in AUCTeX
On Mon, 7 Jul 2008, Uwe Brauer wrote:
>>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
[...]
> Am I overlooking something?
So given that we will have a working solution soon I would like to ask
you, not to stop the support you have given so far to XEmacs.
Thank you very much
Uwe Brauer
I second that.
Thanks a lot for all your work.
Itay
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5764
days inactive
5765
days old
4 comments
3 participants
participants (3)
-
David Kastrup -
Itay Furman -
Uwe Brauer