.info files

.info files

[Alfred M. Szmidt]

It would be nice if .info files opened up in Info-mode automatically.
E.g. something like,

(add-to-list 'auto-mode-alist
	     '("\\.info\\'" . (lambda () (interactive)
				(let ((file-name (buffer-file-name)))
				  (kill-buffer (current-buffer))
				  (info file-name)))))

Re: .info files

[Stefan Monnier]

> It would be nice if .info files opened up in Info-mode automatically.
> E.g. something like,

> (add-to-list 'auto-mode-alist
> 	     '("\\.info\\'" . (lambda () (interactive)
> 				(let ((file-name (buffer-file-name)))
> 				  (kill-buffer (current-buffer))
> 				  (info file-name)))))

Agreed.  I wrote Info-on-current-buffer a long time ago to try and
address this need, but it's clearly not good enough.
Your code above is (sadly) not quite good enough either since its use of
kill-buffer+info will likely introduce misbehaviors in various cases.


        Stefan

Re: .info files

[Alfred M. Szmidt]

   > It would be nice if .info files opened up in Info-mode automatically.
   > E.g. something like,

   > (add-to-list 'auto-mode-alist
   > 	     '("\\.info\\'" . (lambda () (interactive)
   > 				(let ((file-name (buffer-file-name)))
   > 				  (kill-buffer (current-buffer))
   > 				  (info file-name)))))

   Agreed.  I wrote Info-on-current-buffer a long time ago to try and
   address this need, but it's clearly not good enough.
   Your code above is (sadly) not quite good enough either since its use of
   kill-buffer+info will likely introduce misbehaviors in various cases.

True that, what about the following:

(add-to-list 'auto-mode-alist
	     '("\\.info\\'" . (lambda () (interactive)
				(require 'info)
				(info-setup (buffer-file-name) (current-buffer)))))

Re: .info files

[Stefan Monnier]

> True that, what about the following:
> (add-to-list 'auto-mode-alist
> 	     '("\\.info\\'" . (lambda () (interactive)
> 				(require 'info)
> 				(info-setup (buffer-file-name) (current-buffer)))))

Looks better, indeed.  Still sounds a bit risky since it throws away the
current content of the buffer, so it probably won't work right in things
like archive-members.


        Stefan


PS: Reminds me that I don't like the way our Info files (and some other
project's as well) don't have a .info extension.
PPS: And of course, the question remains of what to do when visiting
foo-N.info.

Re: .info files

[Alfred M. Szmidt]

   > True that, what about the following:
   > (add-to-list 'auto-mode-alist
   > 	     '("\\.info\\'" . (lambda () (interactive)
   > 				(require 'info)
   > 				(info-setup (buffer-file-name) (current-buffer)))))

   Looks better, indeed.  Still sounds a bit risky since it throws away the
   current content of the buffer, so it probably won't work right in things
   like archive-members.

It doesn't. :-) I'll look at what Info-on-current-buffer does and frob
that.

   PS: Reminds me that I don't like the way our Info files (and some
   other project's as well) don't have a .info extension.

Please, yes, please!

   PPS: And of course, the question remains of what to do when visiting
   foo-N.info.

When makeinfo splits files, it will name them foo.info-N (not
foo-N.info), so that case isn't one to worry about.

But that raises the question of files that contain no nodes,
specifically no Top node, i.e. output from:

\input texinfo  @c -*-texinfo-*-
@setfilename hello-info-world.info
@settitle Hello info world
@bye

I use this for articles, since it kills alot of the boiler plate.
Though makeinfo should probobly warn/fail if there is no Top node.

Re: .info files

[Eli Zaretskii]

> Date: Thu, 12 Apr 2012 17:58:53 -0400
> From: ams@gnu.org (Alfred M. Szmidt)
> Cc: emacs-devel@gnu.org
> 
> But that raises the question of files that contain no nodes,
> specifically no Top node, i.e. output from:
> 
> \input texinfo  @c -*-texinfo-*-
> @setfilename hello-info-world.info
> @settitle Hello info world
> @bye

The only reasonable thing in such files is to show the entire file.

> Though makeinfo should probobly warn/fail if there is no Top node.

Why should it?  Users should be free to do that if they want to.

Re: .info files

[Glenn Morris]

Stefan Monnier wrote:

> PS: Reminds me that I don't like the way our Info files (and some other
> project's as well) don't have a .info extension.

I can implement this. Unless there is some annoying MS-DOS 8+3
limitation at play...?

Re: .info files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 13 Apr 2012 15:19:36 -0400
> 
> Stefan Monnier wrote:
> 
> > PS: Reminds me that I don't like the way our Info files (and some other
> > project's as well) don't have a .info extension.
> 
> I can implement this. Unless there is some annoying MS-DOS 8+3
> limitation at play...?

When you implement it, we'll see ;-)

Re: .info files

[Glenn Morris]

Eli Zaretskii wrote:

> When you implement it, we'll see ;-)

Contents of my info/ directory:

COPYING
ada-mode.info
auth.info
autotype.info
calc.info
calc.info-1
calc.info-2
calc.info-3
calc.info-4
calc.info-5
calc.info-6
ccmode.info
ccmode.info-1
ccmode.info-2
cl.info
dbus.info
dir
dired-x.info
ebrowse.info
ede.info
ediff.info
edt.info
efaq.info
eieio.info
eintr.info
eintr.info-1
eintr.info-2
eintr.info-3
elisp.info
elisp.info-1
elisp.info-10
elisp.info-11
elisp.info-2
elisp.info-3
elisp.info-4
elisp.info-5
elisp.info-6
elisp.info-7
elisp.info-8
elisp.info-9
emacs-gnutls.info
emacs-mime.info
emacs.info
emacs.info-1
emacs.info-2
emacs.info-3
emacs.info-4
emacs.info-5
emacs.info-6
emacs.info-7
emacs.info-8
epa.info
erc.info
ert.info
eshell.info
eudc.info
flymake.info
forms.info
gnus.info
gnus.info-1
gnus.info-2
gnus.info-3
gnus.info-4
gnus.info-5
idlwave.info
info.info
mairix-el.info
message.info
mh-e.info
mh-e.info-1
mh-e.info-2
newsticker.info
nxml-mode.info
org.info
org.info-1
org.info-2
org.info-3
pcl-cvs.info
pgg.info
rcirc.info
reftex.info
remember.info
sasl.info
sc.info
semantic.info
ses.info
sieve.info
smtpmail.info
speedbar.info
tramp.info
url.info
vip.info
viper.info
widget.info
woman.info

Re: .info files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 13 Apr 2012 17:19:19 -0400
> 
> Eli Zaretskii wrote:
> 
> > When you implement it, we'll see ;-)
> 
> Contents of my info/ directory:
> 
> COPYING
> ada-mode.info
> auth.info
> ...

Thank you for sharing ;-)  I must be missing something, because I
don't see how this list is relevant to the 8+3 issue.  That's why I
said that I'd like to see the implementation in order to figure out
whether something special is needed for MS-DOS.

In case it helps, you may find dos-8+3-filename useful.  Or not.

TIA

Re: .info files

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Thank you for sharing ;-)  I must be missing something, because I
> don't see how this list is relevant to the 8+3 issue.  That's why I
> said that I'd like to see the implementation in order to figure out
> whether something special is needed for MS-DOS.

Won't these filenames fail on DOS?

calc.info
calc.info-1
calc.info-2
etc.

Re: .info files

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 14 Apr 2012 16:04:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thank you for sharing ;-)  I must be missing something, because I
> > don't see how this list is relevant to the 8+3 issue.  That's why I
> > said that I'd like to see the implementation in order to figure out
> > whether something special is needed for MS-DOS.
> 
> Won't these filenames fail on DOS?
> 
> calc.info
> calc.info-1
> calc.info-2

"Fail" in what way?  Can you be more specific about the problems you
envision, especially in the context of visiting Info files with
commands such as "C-x C-f" or similar?

Btw, these files don't exist in the Emacs's info/ directory.  I see
there 'calc', 'calc-1', 'calc-2' etc. instead, both in the DOS build,
the Windows build, and the GNU/Linux build.

I have no idea why Glenn has them with these extensions; e.g.,
doc/misc/calc.texi clearly says

  @setfilename ../../info/calc

Re: .info files

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Won't these filenames fail on DOS?
>> 
>> calc.info
>> calc.info-1
>> calc.info-2
>
> "Fail" in what way?  Can you be more specific about the problems you
> envision, especially in the context of visiting Info files with
> commands such as "C-x C-f" or similar?
>
> Btw, these files don't exist in the Emacs's info/ directory.

Fail in the sense that 8+3 filenames can't have more than 3 characters
in the +3 part of the filename.  So they can't be part of the Emacs
tarball if we want to preserve 8+3 compatibility.

I think you missed out on a couple of messages.  What we're discussing
is adding a .info extension to the info files in Emacs (which apparently
means .info-N extensions for multi-part info files).

Re: .info files

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 14 Apr 2012 18:14:45 +0800
> 
> Fail in the sense that 8+3 filenames can't have more than 3 characters
> in the +3 part of the filename.  So they can't be part of the Emacs
> tarball if we want to preserve 8+3 compatibility.

That's right.

> I think you missed out on a couple of messages.

I definitely did, sorry.

> What we're discussing is adding a .info extension to the info files
> in Emacs (which apparently means .info-N extensions for multi-part
> info files).

Doing so is indeed incompatible with MS-DOS.

But wasn't this discussion about visiting Info files in Info mode
automatically?  If so, instead of renaming file to .info*, I think
it's much better and more robust to detect the telltale first line,
viz.:

  This is FOO, produced by makeinfo version X.Y.Z from BAR

That's because nothing forces Info files to have the .info extension.
In fact, the Texinfo package itself distributes Info files 'texinfo',
'texinfo-1', etc.

Re: .info files

[Glenn Morris]

Eli Zaretskii wrote:

> I have no idea why Glenn has them with these extensions; e.g.,
> doc/misc/calc.texi clearly says
>
>   @setfilename ../../info/calc

Because I already implemented the feature we are talking about, which
involves changing those lines (amongst other things). I'm showing you
waht the consequences will be if I commit it.

Re: .info files

[Glenn Morris]

Eli Zaretskii wrote:

>> What we're discussing is adding a .info extension to the info files
>> in Emacs (which apparently means .info-N extensions for multi-part
>> info files).
>
> Doing so is indeed incompatible with MS-DOS.

Yay.

I was going to say that I could add an INFO_EXT=.info to the Makefiles,
which MS-DOS could edit to empty, but since the info files are prebuilt
in the release tarfile, that doesn't help, unless you make a separate
MS-DOS tarfile.

IIUC, a general solution was suggested for this

http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01182.html

> But wasn't this discussion about visiting Info files in Info mode
> automatically? 

Not just about that. For aesthetic reasons, it's nice for an info file
to have an .info extension (IMO). Obviously it's not super important.

Re: .info files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sat, 14 Apr 2012 13:56:22 -0400
> Cc: Chong Yidong <cyd@gnu.org>, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> > I have no idea why Glenn has them with these extensions; e.g.,
> > doc/misc/calc.texi clearly says
> >
> >   @setfilename ../../info/calc
> 
> Because I already implemented the feature we are talking about, which
> involves changing those lines (amongst other things). I'm showing you
> waht the consequences will be if I commit it.

Sorry I was so stupid.

Re: .info files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Chong Yidong <cyd@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 14 Apr 2012 14:01:27 -0400
> 
> IIUC, a general solution was suggested for this
> 
> http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01182.html

I don't want to do that.  I hoped the idea was dead.

> > But wasn't this discussion about visiting Info files in Info mode
> > automatically? 
> 
> Not just about that.

Well, for visiting Info files, I think recognizing the preamble is a
more robust way.

> For aesthetic reasons, it's nice for an info file to have an .info
> extension (IMO).

We could use "makeinfo --no-split" for all the Info manuals (we do
that for some now), and then the .info extension wouldn't be a problem
for MS-DOS.

Re: .info files

[Glenn Morris]

Eli Zaretskii wrote:

> We could use "makeinfo --no-split" for all the Info manuals (we do
> that for some now), and then the .info extension wouldn't be a problem
> for MS-DOS.

To me, it would make sense to ask when 24.1 is released if anyone is
still making serious use of it on MS-DOS, and if so to let emacs-devel
know. config.bat could even print such a question.

Though, this was done 4 years ago.
http://lists.gnu.org/archive/html/info-gnu-emacs/2007-11/msg00000.html

I don't know how many replied.


It's an impressive technical achievement to make a modern Emacs work on
MS-DOS, but if literally no-one is using it, it would be nice if the
consequences for the rest of us could be minimized. The one that crops
up most often is file names. Obviously it is not the end of the world,
but it is an annoyance not to be able to name things as one would want.
If Paul's idea for removing that issue works, I think you would hear
fewer gripes about MS-DOS.

Re: .info files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: cyd@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 16 Apr 2012 13:44:50 -0400
> 
> Eli Zaretskii wrote:
> 
> > We could use "makeinfo --no-split" for all the Info manuals (we do
> > that for some now), and then the .info extension wouldn't be a problem
> > for MS-DOS.
> 
> To me, it would make sense to ask when 24.1 is released if anyone is
> still making serious use of it on MS-DOS, and if so to let emacs-devel
> know. config.bat could even print such a question.
> 
> Though, this was done 4 years ago.
> http://lists.gnu.org/archive/html/info-gnu-emacs/2007-11/msg00000.html
> 
> I don't know how many replied.

You could just check the comp.os.msdos.djgpp newsgroup (actually, the
signal-to-spam ratio would be lower if you used its mailing list
gateway, djgpp@delorie.com).  I can tell you that just a week ago
someone told me that Emacs 23.4 would not build for him (because some
change back-ported from the trunk broke one of DOS-specific files).
See http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/2012/04/08/18:37:56
and also http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/2012/04/08/18:21:55.

> It's an impressive technical achievement to make a modern Emacs work on
> MS-DOS, but if literally no-one is using it, it would be nice if the
> consequences for the rest of us could be minimized. The one that crops
> up most often is file names. Obviously it is not the end of the world,
> but it is an annoyance not to be able to name things as one would want.

I proposed a solution that should work for everyone.  Why not consider
it?

> If Paul's idea for removing that issue works

It doesn't, not for me.  If worse comes to worst, I'd prefer to ignore
the file-name conflicts altogether, than to use that idea.

> I think you would hear fewer gripes about MS-DOS.

I seriously doubt that.

Re: .info files

[Glenn Morris]

Eli Zaretskii wrote:

> You could just check the comp.os.msdos.djgpp newsgroup (actually, the
> signal-to-spam ratio would be lower if you used its mailing list
> gateway, djgpp@delorie.com).

I knew there some list like that, but I forgot where.

>  I can tell you that just a week ago someone told me that Emacs 23.4
> would not build for him (because some change back-ported from the
> trunk broke one of DOS-specific files). See

Sure. Does this prove he needs it, or is he just building it for fun, to
see if it works? Does one potential user justify keeping a port around?
Anyone using MS-DOS is pretty obviously not using recent software. Do
they really need Emacs 24.2? (But this is all old ground.)

> I proposed a solution that should work for everyone.  Why not consider it?

Not splitting the info files; seems fine to me (I don't know why we
should change makeinfo's default behavior for the sake of MS-DOS
though). This would give a 3MB elisp info file. I tried it and noticed
no performance issue. The gcc.info file on my system is not split and is
about 2MB (uncompressed).

>> I think you would hear fewer gripes about MS-DOS.
>
> I seriously doubt that.

You'd hear fewer from me. The file name issue is the only one that
bothers me. I don't care about "#ifdef msdos".

Re: .info files

[Glenn Morris]

> >  I can tell you that just a week ago someone told me that Emacs 23.4
> > would not build for him (because some change back-ported from the
> > trunk broke one of DOS-specific files). See
> 
> Sure. Does this prove he needs it, or is he just building it for fun,

Not the best example for you to pick. :)

http://groups.google.com/group/comp.os.msdos.djgpp/msg/f2859656f94ebe20

  It is OK with me. It was not my intention to build an emacs port, I
  only wanted to test binutils 2.22 using large source code packages.

Re: .info files

[Nix]

On 12 Apr 2012, Alfred M. Szmidt stated:

>    PS: Reminds me that I don't like the way our Info files (and some
>    other project's as well) don't have a .info extension.
>
> Please, yes, please!

Strongly seconded. I've been carrying round a patch to use and install
them with .info extensions for the last year (ever since I switched from
XEmacs, which does use a .info extension).

-- 
NULL && (void)

Re: .info files

[Alfred M. Szmidt]

   > But that raises the question of files that contain no nodes,
   > specifically no Top node, i.e. output from:
   > 
   > \input texinfo  @c -*-texinfo-*-
   > @setfilename hello-info-world.info
   > @settitle Hello info world
   > @bye

   The only reasonable thing in such files is to show the entire file.

Which it does, with an error though..

   > Though makeinfo should probobly warn/fail if there is no Top node.

   Why should it?  Users should be free to do that if they want to.

It is useful for various reasons to have at least a Top node.

Re: .info files

[Glenn Morris]

Since a few people asked for it, I implemented this (.info extension).
I felt ok about using no-split, since Karl B said 9 years ago on a
Texinfo mailing list that perhaps it should even be the default:

http://lists.gnu.org/archive/html/bug-texinfo/2003-04/msg00014.html


I still suggest that the 24.1 release announcement would be a good time
to take try and take stock of how many people are making real of Emacs
on MS-DOS (and probably the older Unix variants too).

Re: .info files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 04 May 2012 02:53:50 -0400
> 
> I still suggest that the 24.1 release announcement would be a good time
> to take try and take stock of how many people are making real of Emacs
> on MS-DOS

And I still don't understand why this should bother anyone except
myself.

Re: .info files

[Paul Eggert]

On 05/04/2012 02:32 AM, Eli Zaretskii wrote:
> I still don't understand why this should bother anyone except
> myself.

Not two hours ago I was impeded in Emacs development by
the MS-DOS support.  The problem in this case was that
MS-DOS 8.3 file name limits do not allow two different files named
"gnulib-common.m4" and "gnulib-comp.m4", and this causes a
wrinkle in our mainstream build procedures.  In merging
some of my old patches this wrinkle caused a build to fail,
which took some time to figure out.

That's just one example, of course, but there are others.
The point is that the hassle of supporting MS-DOS does
impede other Emacs developers, and this cost needs to be
weighed against the benefit of supporting MS-DOS.

I agree with Glenn that the 24.1 release announcement
would be a good time to take stock of the need to support
Emacs on older platforms.

Re: .info files

[Eli Zaretskii]

> Date: Fri, 04 May 2012 12:16:00 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Glenn Morris <rgm@gnu.org>, emacs-devel@gnu.org
> 
> On 05/04/2012 02:32 AM, Eli Zaretskii wrote:
> > I still don't understand why this should bother anyone except
> > myself.
> 
> Not two hours ago I was impeded in Emacs development by
> the MS-DOS support.  The problem in this case was that
> MS-DOS 8.3 file name limits do not allow two different files named
> "gnulib-common.m4" and "gnulib-comp.m4", and this causes a
> wrinkle in our mainstream build procedures.  In merging
> some of my old patches this wrinkle caused a build to fail,
> which took some time to figure out.

In developing and maintaining code, we meet such problems and solve
them every day.  The fact that this one was caused by MS-DOS is just a
coincidence.

Re: .info files

[Paul Eggert]

On 05/04/2012 01:49 PM, Eli Zaretskii wrote:
> In developing and maintaining code, we meet such problems and solve
> them every day.  The fact that this one was caused by MS-DOS is just a
> coincidence.

Yes, it was a coincidence that I happened to run into an MS-DOS-related
build problem a few minutes before seeing your email.  But it is not a
coincidence that MS-DOS support comes at a cost.

Supporting MS-DOS is like supporting K&R C compilers, in that
it's a minor hassle during development that benefits a small number
of users, and we have to estimate whether the benefits are worth the cost.
With K&R C we decided the benefits are not worth the cost, and perhaps
a similar decision is appropriate for MS-DOS.

It's not just MS-DOS.  I agree with Glenn that it would
also be useful to poll about obsolete Unix variants whose support
clutter Emacs's code.  This is a normal part of our release process.

The Emacs 23.1 release announcement in 2009, for example, said that
we plan to remove support for old GNU/Linux systems based on libc
version 5, which last shipped around 1998 -- i.e., GNU systems that
were more than a decade old.  The last version of MS-DOS, if memory
serves, was the one that came with Windows ME in 2000, which suggests
that it's an appropriate time to consider decommissioning its support
as well.

Re: .info files

[Juanma Barranquero]

On Fri, May 4, 2012 at 11:33 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> Supporting MS-DOS is like supporting K&R C compilers, in that
> it's a minor hassle during development that benefits a small number
> of users, and we have to estimate whether the benefits are worth the cost.

You yourself say that it is a minor hassle, and estimating the number
of users is difficult. Certainly DOS clones seem still alive.

    Juanma

Re: .info files

[Stefan Monnier]

> were more than a decade old.  The last version of MS-DOS, if memory
> serves, was the one that came with Windows ME in 2000, which suggests
> that it's an appropriate time to consider decommissioning its support
> as well.

I believe there's a misunderstanding, here: the "MS-DOS" support of
Emacs is really about running Emacs in FreeDOS, IIUC.


        Stefan

Re: .info files

[Eli Zaretskii]

> Date: Fri, 04 May 2012 14:33:00 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rgm@gnu.org, emacs-devel@gnu.org
> 
> On 05/04/2012 01:49 PM, Eli Zaretskii wrote:
> > In developing and maintaining code, we meet such problems and solve
> > them every day.  The fact that this one was caused by MS-DOS is just a
> > coincidence.
> 
> Yes, it was a coincidence that I happened to run into an MS-DOS-related
> build problem a few minutes before seeing your email.  But it is not a
> coincidence that MS-DOS support comes at a cost.

The cost is negligible, even for me.  For others, it's less than
negligible.  It is being blown out of proportions for reasons that
have nothing to do with maintenance.

> Supporting MS-DOS is like supporting K&R C compilers, in that
> it's a minor hassle during development that benefits a small number
> of users, and we have to estimate whether the benefits are worth the cost.

You are conveniently forgetting that keeping the MS-DOS port is of
some benefit for Emacs.  The benefits might be minor, but they are not
negligible.  The tty color remapping, something without which using
colors on a tty in pre-release versions of v21 was a painful
experience, came from the MS-DOS port; inventing something like that
from scratch could have taken many months if not years.  Likewise the
mouse highlight on a tty.  Even for the issue that started this
thread, the MS-DOS port was the trigger that moved Emacs manuals to
what the Texinfo maintainer considers to be TRT, namely avoiding
splitting the manuals; and I was the one who suggested that as a
solution.

Finally, these days I'm slowly working on adding true menus to the tty
Emacs; the ideas, design, and most of the code for that will be lifted
from msdos.c.

I think these minor benefits more than outweigh the minor "hassles",
but that's me.

> With K&R C we decided the benefits are not worth the cost, and perhaps
> a similar decision is appropriate for MS-DOS.

Since almost all of the costs are mine, the decision should be mine.
Currently, I decided that I will support the MS-DOS port for as long
as I have time and energy to work on Emacs.  Keep badgering me about
this, and you will eventually succeed to break my spirit, and will
lose me for Emacs development for good, because I don't enjoy being
part of a group whose select members feel like kicking me in the butt
once in a while.

Re: .info files

[Juanma Barranquero]

On Sat, May 5, 2012 at 9:05 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Keep badgering me about
> this, and you will eventually succeed to break my spirit, and will
> lose me for Emacs development for good

That'd be a sad, sad day.

    Juanma

Re: .info files

[Glenn Morris]

Eli Zaretskii wrote:

> It is being blown out of proportions for reasons that have nothing to
> do with maintenance.

Speaking for myself, you are attributing motives to me that I do not have.

> Currently, I decided that I will support the MS-DOS port for as long
> as I have time and energy to work on Emacs.

Fine, now I understand the situation, so I don't need to bring it up
again. For you to be involved in Emacs, the MS-DOS port should stay
around, and how much usage it gets is not a factor. I think it's a
bargain price for your labour! :)


I still don't see what the big deal is with trying to establish how many
people are using Emacs on these less common platforms. Note that I did
not say "and then let's remove the ones that aren't used much". I just
think it would be interesting data to have, and the release of a new
major version seems like a good time to take stock.

For example, I have no idea why "Ultrix" (last release 1995?) gets a
mention on the Emacs homepage.

Re: .info files

[Paul Eggert]

On 05/04/2012 05:30 PM, Stefan Monnier wrote:
> I believe there's a misunderstanding, here: the "MS-DOS" support of
> Emacs is really about running Emacs in FreeDOS, IIUC.

My impression is otherwise, i.e., that the MS-DOS support of
Emacs is intended to run on true MS-DOS.  For example, the
Emacs source code and documentation mentions MS-DOS hundreds
of times, but it never once mentions FreeDOS.

I'd be surprised if the intent is to support FreeDOS as
opposed to MS-DOS, but if that's the case, this should be
stated more clearly in the release notes and/or the user
documentation, to help avoid future confusion in this area.

Re: .info files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Sat, 05 May 2012 16:14:20 -0400
> 
> Eli Zaretskii wrote:
> 
> > It is being blown out of proportions for reasons that have nothing to
> > do with maintenance.
> 
> Speaking for myself, you are attributing motives to me that I do not have.

I didn't attributing them to you.  Sorry if that wasn't clear.

> I still don't see what the big deal is with trying to establish how many
> people are using Emacs on these less common platforms.

I have no good way of doing that, except what I told earlier already.
And I don't think it's worth my time investing more effort, unless we
are doing it for other platforms as well.  E.g., how about the NS
port?

Re: .info files

[Eli Zaretskii]

> Date: Sat, 05 May 2012 18:24:26 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 05/04/2012 05:30 PM, Stefan Monnier wrote:
> > I believe there's a misunderstanding, here: the "MS-DOS" support of
> > Emacs is really about running Emacs in FreeDOS, IIUC.
> 
> My impression is otherwise, i.e., that the MS-DOS support of
> Emacs is intended to run on true MS-DOS.

The DOS port supports true MS-DOS and all compatible environments.
That includes FreeDOS, MS-Windows up to and including XP, and DOSEmu
on GNU/Linux.  Judging by email I get about the DOS port of Emacs,
there are users of it on all these platforms.

> For example, the Emacs source code and documentation mentions MS-DOS
> hundreds of times, but it never once mentions FreeDOS.

I don't think a GNU project should include too much detail about
DOS-compatible environments.  Anyone who uses them already knows that
anyway.

Re: .info files

[Paul Eggert]

On 05/05/2012 12:05 AM, Eli Zaretskii wrote:
> The cost is negligible, even for me.  For others, it's less than
> negligible.

No, the issue cost me some real time recently, and it's done so at
other times in the not-too-distant past.

> Keep badgering me about this, and you will eventually succeed to break
> my spirit, and will lose me for Emacs development for good, because
> I don't enjoy being part of a group whose select members feel like
> kicking me in the butt once in a while.

Nothing in my emails can reasonably be described as "badgering" or
"kicking".  On the contrary, I agree with Glenn and Juanma that
you are a valuable resource for Emacs development, and for that
reason I withdraw my suggestion to poll users about MS-DOS usage.

To try to avoid future kerfuffles like this, I'll look at
reworking the 8+3-related build-procedure code that cost me time
on Friday, so that it's less likely to do so in the future.

Re: .info files

[Eli Zaretskii]

> Date: Mon, 07 May 2012 23:28:29 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rgm@gnu.org, emacs-devel@gnu.org
> 
> On 05/05/2012 12:05 AM, Eli Zaretskii wrote:
> > The cost is negligible, even for me.  For others, it's less than
> > negligible.
> 
> No, the issue cost me some real time recently, and it's done so at
> other times in the not-too-distant past.

negligible != zero

> > Keep badgering me about this, and you will eventually succeed to break
> > my spirit, and will lose me for Emacs development for good, because
> > I don't enjoy being part of a group whose select members feel like
> > kicking me in the butt once in a while.
> 
> Nothing in my emails can reasonably be described as "badgering" or
> "kicking".

The feeling is obviously very personal and subjective.

> On the contrary, I agree with Glenn and Juanma that
> you are a valuable resource for Emacs development

Thanks.

> To try to avoid future kerfuffles like this, I'll look at
> reworking the 8+3-related build-procedure code that cost me time
> on Friday, so that it's less likely to do so in the future.

Thank you.