[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