[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AUCTeX-devel] Re: [AUCTeX-diffs] Changes to auctex/ChangeLog

From: David Kastrup
Subject: [AUCTeX-devel] Re: [AUCTeX-diffs] Changes to auctex/ChangeLog
Date: Mon, 23 Jan 2006 22:16:25 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Masayuki Ataka <address@hidden> writes:

> From: David Kastrup <address@hidden>
> Subject: Re: [AUCTeX-diffs] Changes to auctex/ChangeLog
> Date: Sun, 22 Jan 2006 21:08:28 +0100
>> Masayuki Ataka <address@hidden> writes:
>> > Index: auctex/ChangeLog
>> > diff -u auctex/ChangeLog:5.1280 auctex/ChangeLog:5.1281
>> > --- auctex/ChangeLog:5.1280        Sun Jan 22 13:25:44 2006
>> > +++ auctex/ChangeLog       Sun Jan 22 15:02:52 2006
>> > @@ -1,3 +1,19 @@
>> > +2006-01-22  Ikumi Keita <address@hidden>
>> > +
>> > +  * tex.el (TeX-command-list): Removed TeX-run-dviout because dviout
>> > +  here is only work with Emacs on MS-DOS.
>> Uh, I can't remember a discussion about that change, 
> First of all, I apologize that I removed codes of run-dviout
> without discussions.
>> Is there a good reason for removing the run-dviout functionality,
>> given that such platforms are definitely in use?
> I put the patch for run-dviout at the end of this mail for your
> help.
> The function TeX-run-dviout is for MS-DOS and PC-9801.

Uh, no.  It _special-cases_ those two operating systems, but I don't
see anything that would prevent this function from running, for
example, with dviout for Windows.  _Exactly_ because the cases for
MS-DOS and PC-9801 are specially checked and treated.

> PC-9801 aka. pc98 is a Japanese PC, which is not IBM PC so that
> Windows 98 does not work on it.  Now, no PC98 is on sale.
> Anybody uses Emacs21 on MS-DOS system?

Eli Zaretskii is one of the most active Emacs developers and
frequently reports issues with Emacs 22 development on MSDOS on the
Emacs developer list.

> If so, I will revert my change.

Since AUCTeX also contains a lot of other MSDOS support (like
synchronous sentinels), it does not make sense removing parts of it
without good reason.  If they are _known_ to be broken and nobody can
maintain them, that would be reasonable.

But even then, such a change should be proposed on the list and not
just done behind people's back.

Is there a particular technical reason that makes removing this
desirable?  If so, we can discuss it.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]