bug#10385: e binding in info-mode

bug#10385: e binding in info-mode

[Karl Berry]

In info-mode, I suggest that e would be more usefully bound to
end-of-buffer (following the binding for b) than Info-edit, which, in
today's world, is unlikely to ever do anything but return "Editing Info
nodes is not enabled".  And Info-edit is not even mentioned in info.texi
(rightfully so, IMHO).

FWIW, the standalone info reader has always bound e to end-of-buffer.

Just an idea.  Life goes on, regardless :).

k

bug#10385: e binding in info-mode

[Glenn Morris]

Version: 24.0.93

Karl Berry wrote:

> In info-mode, I suggest that e would be more usefully bound to
> end-of-buffer (following the binding for b) than Info-edit

Sounds good to me. Done.

RE: bug#10385: e binding in info-mode

[Drew Adams]

> Karl Berry wrote:
> 
> > In info-mode, I suggest that e would be more usefully bound to
> > end-of-buffer (following the binding for b) than Info-edit ...
> > Just an idea.
> 
> Sounds good to me. Done.

That is not the way to make key-binding decisions for Emacs.

It should be proposed on emacs-devel, open for possible discussion.  And then
the Emacs maintainers should decide.

That said, I personally have no objection to our changing the binding of `e' to
`end-of-buffer'.  But, like you AFAIK, I do not decide alone.

Consider too that `Info-edit' has been bound to `e' for decades - just as long
as `b' has been bound to `beginning-of-buffer'.

Clearly that choice of bindings was not simply an oversight or accident.  Those
who decided this originally surely thought about it - `e' corresponding to `b'
is an obvious thing to consider.

And yet they decided the way they did.  Anyone can make mistakes, and minds can
change with addtional reflection and experience, but let's give the original
authors of this some credit at least. 

It should not be up to one person responding to a bug report/enhancement request
to change such a binding willy nilly because it "sounds good" to him.

Think how many key binding and other enhancement proposals are languishing in
the `wishlist' bin.  This one should get in line there with the others.  Or else
it should be brought up in emacs-devel for discussion.

The proposal to emacs-devel would be posed as related questions:

1. Should `e' be bound to `end-of-buffer' instead of `Info-edit' in Info?

2. If so, what, if anything, should `Info-edit' be bound to?

And if user-visible changes _are_ decided on then they should be mentioned in
NEWS.

Re: bug#10385: e binding in info-mode

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 6 Jan 2012 07:54:16 -0800
> Cc: emacs-devel@gnu.org
> 
> Consider too that `Info-edit' has been bound to `e' for decades - just as long
> as `b' has been bound to `beginning-of-buffer'.
> 
> Clearly that choice of bindings was not simply an oversight or accident.  Those
> who decided this originally surely thought about it - `e' corresponding to `b'
> is an obvious thing to consider.

AFAIK, that binding and its command go back to when there was no
makeinfo to produce Info from the Texinfo sources, and Info files were
created by hand.  That time is long gone.

That said, I agree that the change should have been preceded by an
attempt to see at least whether there are any objections.

> And if user-visible changes _are_ decided on then they should be mentioned in
> NEWS.

I agree.  There is such a NEWS entry about this particular change.

Re: bug#10385: e binding in info-mode

[Richard Stallman]

I thought that e would be a useful command
back when I supposed info files would be written by hand.
But we don't do that, so e is not useful and maybe only causes trouble.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: bug#10385: e binding in info-mode

[Juri Linkov]

> I thought that e would be a useful command
> back when I supposed info files would be written by hand.
> But we don't do that, so e is not useful and maybe only causes trouble.

There is more trouble when this obsolete feature is announced
in the customization group `info' via its customizable variable
`Info-enable-edit'.  It would be better to hide it from the
Customization interface by changing `defcustom' to `defvar':

=== modified file 'lisp/info.el'
--- lisp/info.el	2011-12-05 09:52:02 +0000
+++ lisp/info.el	2012-01-07 20:27:15 +0000
@@ -61,14 +61,12 @@
   :group 'info
   :version "24.1")
 
-(defcustom Info-enable-edit nil
-  "Non-nil means the \\<Info-mode-map>\\[Info-edit] command in Info can edit the current node.
+(defvar Info-enable-edit nil
+  "Non-nil means the `Info-edit' command in Info can edit the current node.
 This is convenient if you want to write Info files by hand.
 However, we recommend that you not do this.
 It is better to write a Texinfo file and generate the Info file from that,
-because that gives you a printed manual as well."
-  :type 'boolean
-  :group 'info)
+because that gives you a printed manual as well.")
 
 (defvar Info-enable-active-nodes nil
   "Non-nil allows Info to execute Lisp code associated with nodes.

RE: bug#10385: e binding in info-mode

[Drew Adams]

> > I thought that e would be a useful command
> > back when I supposed info files would be written by hand.
> > But we don't do that, so e is not useful and maybe only 
> > causes trouble.
> 
> There is more trouble when this obsolete feature

Since when is it obsolete?

> is announced in the customization group `info' via its
> customizable variable `Info-enable-edit'.  It would be
> better to hide it from the Customization interface by
> changing `defcustom' to `defvar':

Why?  What if someone wants to create a small Info file and doesn't want to
bother with texinfo or doesn't have the conversion/make tools handy?

Why does it hurt for this to be a defcustom?  Just leave the default value as
nil.

What's more, this is an entirely different question from the one raised by this
thread, which is about the `e' binding.

It should be enough that the binding of `e' is changed to `end-of-buffer' and
the option value remains nil by default.

Re: bug#10385: e binding in info-mode

[Juri Linkov]

>> There is more trouble when this obsolete feature
>
> Since when is it obsolete?

Since its inception.  Info-edit was never documented in info.texi.
(And perhaps references to `Info-edit-map' should be removed from elisp.texi)

> Why does it hurt for this to be a defcustom?

Think about a novice looking at the available options
in the Customization group `info'.  It would be a disservice
to teach them that editing Info nodes is a good idea.

RE: bug#10385: e binding in info-mode

[Drew Adams]

> >> There is more trouble when this obsolete feature
> >
> > Since when is it obsolete?
> 
> Since its inception.  Info-edit was never documented in info.texi.
> (And perhaps references to `Info-edit-map' should be removed 
> from elisp.texi)

That a feature is not documented everywhere, or is poor or misguided, does not
mean that it is obsolete.

It is certainly not the case that a command that has been bound to a key
(especially for decades) can be said to be undocumented or invisible/unknown to
users.  Let alone considered obsolete.

Think how many commands and key bindings are not documented in any manual.  They
are certainly not all - or even any of them - "obsolete" since their inception.
Emacs documentation is not limited to manuals, and user awareness of features is
not even limited to any form of documentation.  We provide source code, and that
is the foundation of user communication.

Typically, for a feature or a product to be considered obsolete (officially), it
must first be officially deprecated.  And typically there is a period of time
between deprecation and obsolescence - typically a relatively major release or
more.

Typically, an obsolete feature is no longer supported, and a deprecated feature
is still supported.

For example, it might be decided to announce the deprecation of this option in
24.1, and then make it obsolete in 24.2 (since Emacs point releases are
relatively major).

Given such a decision, it would change from a defcustom to a defvar, or even be
eliminated altogether, in 24.2, depending on what was intended wrt desupport (as
an option or even as a variable).

> > Why does it hurt for this to be a defcustom?
> 
> Think about a novice looking at the available options
> in the Customization group `info'.  It would be a disservice
> to teach them that editing Info nodes is a good idea.

The existence of a user option is not the same thing as suggesting that changing
its value is necessarily a good idea.  We have lots of user options that it
might not be a good idea for a novice, in particular, to customize.  We provide
plenty of rope for users to hang themselves, often even using only Customize.

Re: bug#10385: e binding in info-mode

[Juri Linkov]

> For example, it might be decided to announce the deprecation of this option in
> 24.1, and then make it obsolete in 24.2 (since Emacs point releases are
> relatively major).

The Info-edit feature is already deprecated in 23.1.  And paradoxically,
the person who deprecated this feature is you, Drew.

When your Info-breadcrumbs code was added to info.el, it broke Info-edit
because the added breadcrumbs line is saved to Info files after editing.
But nobody complained about this breakage since nobody uses it ;-)

RE: bug#10385: e binding in info-mode

[Drew Adams]

> > For example, it might be decided to announce the 
> > deprecation of this option in 24.1, and then make it
> > obsolete in 24.2 (since Emacs point releases are
> > relatively major).
> 
> The Info-edit feature is already deprecated in 23.1.
> And paradoxically, the person who deprecated this
> feature is you, Drew.
> 
> When your Info-breadcrumbs code was added to info.el, it 
> broke Info-edit because the added breadcrumbs line is
> saved to Info files after editing.  But nobody complained
> about this breakage since nobody uses it ;-)

You're still missing the point, Juri.  What I said about obsolescence wrt
official announcement holds for deprecation as well.  Something is neither made
obsolete nor deprecated just because it is broken or no one uses it.

There are thousands of things in Emacs that one might find no one uses, and
plenty of things that are broken (we do have a non-negligible list of
outstanding bugs).  Neither means that such things are deprecated.

Typically, deprecation involves an official announcement.  It constitutes a
heads-up to users so that they can think about moving away from it.  It is fair
warning that in an upcoming release the feature might be (or will be, depending
on the deprecation notice) made obsolete, e.g., desupported.

I find nothing in the Emacs 23.1, or 23.2, or 23.3 NEWS about `Info-edit', in
particular, no deprecation notice.  Unless such a notice appeared somewhere else
that I haven't found, `Info-edit' was not deprecated in 23.1, even if 23.1
happened to break it (whether by breadcrumbs or some other way).

The fact that this feature might have been broken (whenever), and the fact that
perhaps no one used it (whenever), have nothing to do with the non-fact that it
was deprecated (whenever).

Re: bug#10385: e binding in info-mode

[Juri Linkov]

> I find nothing in the Emacs 23.1, or 23.2, or 23.3 NEWS about `Info-edit', in
> particular, no deprecation notice.  Unless such a notice appeared somewhere else
> that I haven't found, `Info-edit' was not deprecated in 23.1, even if 23.1
> happened to break it (whether by breadcrumbs or some other way).

There are two ways to make a feature legally obsolete: `de jure' and `de facto'.

De facto it's already obsolete since 23.1, and now you propose to declare this fact
de jure.  I agree that we could do this now by adding a deprecation notice.

RE: bug#10385: e binding in info-mode

[Drew Adams]

> > I find nothing in the Emacs 23.1, or 23.2, or 23.3 NEWS 
> > about `Info-edit', in particular, no deprecation notice.
> > Unless such a notice appeared somewhere else
> > that I haven't found, `Info-edit' was not deprecated in 
> > 23.1, even if 23.1 happened to break it (whether by
> > breadcrumbs or some other way).
> 
> There are two ways to make a feature legally obsolete: `de 
> jure' and `de facto'.
> 
> De facto it's already obsolete since 23.1,

Nope; it's not.  Just because a bug exists does not mean that something is
obsolete, de jure, de facto, or de lusion.

And the particular bug you point to is apparently an incompatibility between two
features (breadcrumbs and `Info-edit').  That could be fixed any number of ways,
none of which need amount to the abandonment of either feature.

> and now you propose to declare this fact de jure.

Again, you are putting words in my mouth.  I proposed nothing of the kind.

> I agree that we could do this now by adding a 
> deprecation notice.

You agree with yourself. ;-)

Wrt breadcrumbs, you yourself pointed to several problems other than the one you
would now use as a reason to deprecate `Info-edit' (bugs #1447, #5809, #5998).

By your logic and using your terms, breadcrumbs have been obsolete, de facto,
from their inception.  The saving of inserted text, as you have pointed out,
breaks more than `Info-edit', so it certainly should not by itself be an
argument for making the latter obsolete.

You already proposed disabling breadcrumbs (for 23.2) because of such problems.
And you proposed multiple different solutions for those bugs, including changes
to the display engine, redesigning header lines, and designing "a new window
infrastructure that supports window groups" - fixes of varying complexity.

And I offered a patch that uses the mode line for breadcrumbs as an alternative,
with none of the problems of breadcrumbs in the body text or header.  (No one
tried, or commented on, the patch I sent.)
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5809#140

And in my own code I offer users that alternative (breadcrumbs in header/text or
in mode line, or both), with a quick toggle for mode-line display.
http://www.emacswiki.org/emacs/download/info%2b.el

Pointing to bugs for Info breadcrumbs as a reason why `Info-edit' has supposedly
been obsolete de jure since Emacs 23.1 is a little much, especially since those
same bugs cause problems beyond `Info-edit'.  It is a red herring de facto, in
facto.

Re: bug#10385: e binding in info-mode

[Richard Stallman]

Maybe just delete Info-edit.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: bug#10385: e binding in info-mode

[Richard Stallman]

    Why?  What if someone wants to create a small Info file and doesn't want to
    bother with texinfo or doesn't have the conversion/make tools handy?

It is really preferable to write in Texinfo.  I don't see a reason why we
should want to encourage people to write Info files directly.

Have you encountered anyone who really wanted to do so?

  Use free telephony http://directory.fsf.org/category/tel/

Re: bug#10385: e binding in info-mode

[Richard Stallman]

I have considered Info-edit obsolete ever since we had Texinfo.

Info has existed since 1976 or so, in the original Emacs.  At that
time, Info files were written by hand, and everyone could edit system
files on ITS.  Thus, Info-edit was useful there.

When I implemented info in GNU Emacs, I wrote Info-edit there too.
Then I implemented Texinfo to format the Emacs manual.  This made
Info-edit useless when Texinfo is in use -- which ought to be always.
Meanwhile, ordinary users can't edit the installed Info files anyway.
So Info-edit is basically useless.
-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

RE: bug#10385: e binding in info-mode

[Drew Adams]

>     Why?  What if someone wants to create a small Info file 
>     and doesn't want to bother with texinfo or doesn't have the
>     conversion/make tools handy?
> 
> It is really preferable to write in Texinfo.

I wouldn't argue with that.  I'm sure you are right.

> I don't see a reason why we should want to encourage people
> to write Info files directly.

Mere existence of the command `Info-edit' is hardly encouragement.  Have you
noticed a problem with users being too encouraged to write Info files by hand
over the last 30 years?

And during that time they have even had a simple, advertised key binding for
`Info-edit', which binding is being removed now anyway.

> Have you encountered anyone who really wanted to do so?

Nope.  But if I had to edit an Info node (which has not been the case so far)
and I did not have texinfo, makeinfo, etc. on my laptop (which is the case), I
wouldn't hesitate to do it.

And note that the Info manual has a section, `Expert Info' (with 5 subsections),
that describes "how to write an Info file by hand" and how to "install it
manually".  That suggests at least as much encouragement to write Info files by
hand as does the mere existence of command `Info-edit'.

The manual does not at all say or suggest that writing Info files by hand is
useless.  What it says, in fact, is "_in most cases_, writing a Texinfo file is
better, since you can use it to make a printed manual or produce other formats,
such as HTML and DocBook, as well as for generating Info files".

"In most cases" is a far cry from always.  And surely if it were truly useless
to write Info files by hand we would not devote 6 nodes of the Info manual to
explaining in detail how to do it (?).

Granted, `Info-edit' is not the same as all that is discussed in the manual
under the topic of writing an Info file by hand.  But your question was about
writing an Info file by hand, and here is a far greater encouragement than
`Info-edit'.

AFAICT, we seem to be saying in the Info manual that there is a use case for
hand editing, even if we say that in most cases Texinfo is more useful.  Both
the Info manual and the lack of installed `makeinfo' for at least some users on
some systems (non-development laptops? phones? tablets?) argue that hand editing
is not useless.

RE: bug#10385: e binding in info-mode

[Drew Adams]

> I have considered Info-edit obsolete ever since we had Texinfo.

If you don't tell the users that something is deprecated/obsolete, then such
interior consideration doesn't mean much.

It makes sense to let users know what to expect in terms of support etc.  And
that is pretty typical.

> Info has existed since 1976 or so, in the original Emacs.  At that
> time, Info files were written by hand, and everyone could edit system
> files on ITS.  Thus, Info-edit was useful there.
> 
> When I implemented info in GNU Emacs, I wrote Info-edit there too.
> Then I implemented Texinfo to format the Emacs manual.  This made
> Info-edit useless when Texinfo is in use -- which ought to be always.

Dunno why it "ought" to be.  But I won't argue the point.  (But see my other
reply.)

> Meanwhile, ordinary users can't edit the installed Info files anyway.

Why not?  What prevents them?

> So Info-edit is basically useless.

So you could have deprecated it, uh, let's see, about 30 years ago, and you've
known that for that time.  Apparently there has been no hurry. ;-)

Might as well deprecate it now and desupport it in Emacs 24.2 (or 29.3), I
guess.

Re: bug#10385: e binding in info-mode

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <juri@jurta.org>, <eliz@gnu.org>, <emacs-devel@gnu.org>
> Date: Sat, 7 Jan 2012 23:03:15 -0800
> 
> > Meanwhile, ordinary users can't edit the installed Info files anyway.
> 
> Why not?  What prevents them?

Access rights.  On a typical Unix or GNU system, Info manuals are
installed by the user root (= Administrator for Windows), and are not
writable by others.

Re: bug#10385: e binding in info-mode

[Stefan Monnier]

>> I thought that e would be a useful command
>> back when I supposed info files would be written by hand.
>> But we don't do that, so e is not useful and maybe only causes trouble.
> There is more trouble when this obsolete feature is announced
> in the customization group `info' via its customizable variable
> `Info-enable-edit'.  It would be better to hide it from the
> Customization interface by changing `defcustom' to `defvar':

We can mark Info-edit (and related vars) obsolete, indeed.
Tho, there's really no hurry to do it, so it can wait 24.2.


        Stefan

Re: bug#10385: e binding in info-mode

[Richard Stallman]

    > I have considered Info-edit obsolete ever since we had Texinfo.

    If you don't tell the users that something is deprecated/obsolete, then such
    interior consideration doesn't mean much.

We are not bureaucrats, we are developing software to be useful for
users and to give them freedom.  We follow certain practical practices
because they are generally helpful, but they are not imposed by gods.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

RE: bug#10385: e binding in info-mode

[Drew Adams]

>  > I have considered Info-edit obsolete ever since we had Texinfo.
> 
> If you don't tell the users that something is 
> deprecated/obsolete, then such interior consideration
> doesn't mean much.
> 
> We are not bureaucrats, we are developing software to be useful for
> users and to give them freedom.  We follow certain practical practices
> because they are generally helpful, but they are not imposed by gods.

I doubt anyone disagrees with that.  Just how is it relevant here?

The idea is to help Emacs users, including those writing Lisp code, by giving
them a heads-up wrt Emacs Dev support/intentions.  That, I presume, is the idea
behind functions such as `make-obsolete(-variable)': to inform users about
things that are considered obsolete.

Your thinking for 30 years that something is obsolete, and keeping the thought
to yourself, does not help users know that Emacs Development considers it so.

Have you considered for the same 30 years, since introducing Texinfo, that the
section of the `Info' manual that tells users how to write Info nodes by hand is
also obsolete?  If so, would it be bureaucratic to update that manual to reflect
your judgment, assuming the Emacs maintainers felt the same?

One need not be a bureaucrat or believe in gods to think that such communication
can be helpful to users.  Should we stop publishing NEWS because we are not
bureaucrats?

Re: bug#10385: e binding in info-mode

[Richard Stallman]

    > We are not bureaucrats, we are developing software to be useful for
    > users and to give them freedom.  We follow certain practical practices
    > because they are generally helpful, but they are not imposed by gods.

    I doubt anyone disagrees with that.  Just how is it relevant here?

You are askig for certain procedures to be followed rigidly.  We use
those procedures to smooth out the problems caused by removing a feature
that people really use.
If it looks like Info-edit is rarely or never used, we don't need to
follow them rigidly for Info-edit.

We are not manufacturing medicines here.  Even if we make an error, the worst
that happens is inconvenience.  A small chance of a small inconvenience
is not significant.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/