button-buffer-map should inherit from special-mode-map

button-buffer-map should inherit from special-mode-map

[Sam Steingold]

IMO, button-buffer-map should inherit from special-mode-map because
whenever it is used, the map which inherits from it is immediately
subject to suppress-keymap.
If button-buffer-map inherits from special-mode-map, then this is done
automatically, and, additionally, some useful bindings are inherited.

I will commit a patch to this effect unless someone objects.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://ffii.org http://jihadwatch.org
http://dhimmi.com http://iris.org.il http://www.PetitionOnline.com/tap12009/
Only the mediocre are always at their best.

RE: button-buffer-map should inherit from special-mode-map

[Drew Adams]

> IMO, button-buffer-map should inherit from special-mode-map because
> whenever it is used, the map which inherits from it is immediately
> subject to suppress-keymap.  If button-buffer-map inherits from
> special-mode-map, then this is done automatically, and,
> additionally, some useful bindings are inherited.
> 
> I will commit a patch to this effect unless someone objects.

I'm no expert on this, but that does not sound right to me.

Different libraries use `button-mode-map' differently.  E.g. `apropos-mode-map'
is a _copy_ of `button-mode-map' and it has `special-mode-map' as its parent.
And `help-mode-map' has as its parent a keymap composed from `button-buffer-map'
and `special-mode-map'.

It seems to me that if some particular map needs the characteristics of both
`button-buffer-map' and `special-mode-map' then it should explicitly adopt them
both, e.g. as `help-mode-map' does.

Why assume that the characteristics of `special-mode-map' (e.g. keys) are
appropriate for all uses of `button-buffer-map'?  What's really gained by this
additional coupling?

IMO, there has been too liberal a use of `special-mode-map' recently, which has
sometimes required later backing out some such coupled behavior (e.g. keys).

In general, this alone should be a red flag (watch out!): "and additionally,
some useful bindings are inherited".

One person's or one library's handy convenience is another's obstacle that must
be overcome.  What if those "useful bindings" are not appropriate for your mode
that inherits from `button-buffer-map'?

Why not keep these maps separate, and let code couple/compose them explicitly
when appropriate?

Re: button-buffer-map should inherit from special-mode-map

[Sam Steingold]

> * Drew Adams <qerj.nqnzf@benpyr.pbz> [2013-02-21 10:29:49 -0800]:
>
>> IMO, button-buffer-map should inherit from special-mode-map because
>> whenever it is used, the map which inherits from it is immediately
>> subject to suppress-keymap.  If button-buffer-map inherits from
>> special-mode-map, then this is done automatically, and,
>> additionally, some useful bindings are inherited.
>> 
>> I will commit a patch to this effect unless someone objects.
>
> Why assume that the characteristics of `special-mode-map' (e.g. keys)
> are appropriate for all uses of `button-buffer-map'?

Because special-mode-map is supposed to be appropriate for any
non-self-insert buffer, and button-buffer-map is only used in such
buffers, so, whenever a map inherits from button-buffer-map but not
special-mode-map, it can be assumed to be an oversight.

> Different libraries use `button-mode-map' differently.  E.g. `apropos-mode-map'
> is a _copy_ of `button-mode-map' and it has `special-mode-map' as its parent.
> And `help-mode-map' has as its parent a keymap composed from `button-buffer-map'
> and `special-mode-map'.

These look like workarounds for the bug of button-buffer-map not
inheriting from special-mode-map.

> What's really gained by this additional coupling?

Simplicity and clarity of code and intent.


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://jihadwatch.org http://truepeace.org
http://www.memritv.org http://camera.org http://thereligionofpeace.com
Why use Windows, when there are Doors?

RE: button-buffer-map should inherit from special-mode-map

[Drew Adams]

> > Why assume that the characteristics of `special-mode-map' 
> > (e.g. keys) are appropriate for all uses of `button-buffer-map'?
> 
> Because special-mode-map is supposed to be appropriate for any
> non-self-insert buffer,

Where does it say so?  In any case, I take issue with such a claim.

It is doubtful that there is ANY given set of key bindings or ANY particular
predefined behavior that is appropriate for ALL non-self-insert buffers.
(Except the empty set of keys and empty behavior.)

`special-mode-map' certainly does not fill that bill.

> and button-buffer-map is only used in such buffers,

What buffers - non-self-insert buffers?  Are you claiming also that b-b-map is
appropriate for ALL buffers where keys are not self-inserting?  That too I
disagree with.

`button-buffer-map' is defined only as a

   "Keymap useful for buffers containing buttons."

There is nothing in that straightforward definition that implies that every
buffer that has buttons must be non-self-insert.  Whether buttons make sense for
a given buffer is not dependent on whether the buffer allows some keys to
self-insert.

> so, whenever a map inherits from button-buffer-map but not
> special-mode-map, it can be assumed to be an oversight.

Your logic is sound: N => S and B => N, therefore B => S:

1. Assume: non-self-insert buffer implies s-m-map is appropriate.

2. Assume: b-b-map implies non-self-insert buffer.

3. Therefore, any map that inherits from b-b-m should also inherit from s-m-map.

The logic is fine.  What I reject are the assertions, #1 and #2.

> > What's really gained by this additional coupling?
> 
> Simplicity and clarity of code and intent.

The intent of `button-buffer-map' is clear, and that stated intention does not
jibe with the interpretation you want to give it.  Sorry.

`button-buffer-map' is a keymap for buffers where buttons are appropriate.
Nothing more, nothing less.  Up to the person who uses b-b-map to decide whether
buttons are appropriate in any given context.

`button-buffer-map' does not imply `special-mode-map'.  And it does not imply
that the buffer does not allow any self-insertion.

Re: button-buffer-map should inherit from special-mode-map

[Sam Steingold]

> * Drew Adams <qerj.nqnzf@benpyr.pbz> [2013-02-21 11:26:36 -0800]:
>
> Your logic is sound: N => S and B => N, therefore B => S:
>
> 1. Assume: non-self-insert buffer implies s-m-map is appropriate.
>
> 2. Assume: b-b-map implies non-self-insert buffer.
>
> 3. Therefore, any map that inherits from b-b-m should also inherit from s-m-map.
>
> The logic is fine.  What I reject are the assertions, #1 and #2.

The vehemence of your objection is stunning.
I am no longer arguing in favor of my proposal, but out of curiosity:

1. can you give an example of a non-self-insert buffer where any of the
special-mode-map bindings are not appropriate?

2. can you give an example of a button-buffer-map usage in a self-insert
buffer?

PS. my practical rationale was that I bound a key in special-mode-map
and was surprised that the binding was not present in *Buffer List*.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://dhimmi.com http://memri.org http://ffii.org
http://pmw.org.il http://thereligionofpeace.com http://jihadwatch.org
Our business is run on trust.  We trust you will pay in advance.

RE: button-buffer-map should inherit from special-mode-map

[Drew Adams]

> The vehemence of your objection is stunning.

What vehemence?  Another unwarranted assumption.

I just disagree with the assumptions you made and the proposal based on them.  I
am not vehement about that disagreement.  And I mean nothing personal by my
disagreement.  You explicitly solicited objections (good), and I objected.

And the first thing I said was that I am no expert on this, which is the case.
AFAICT, there is no necessary reason for such a change, and not even any good
reason for it.  And there is every reason to keep independent things uncoupled.

But I am open to being convinced otherwise.  And I'm only one voice.

> I am no longer arguing in favor of my proposal,

Why not?  Don't stop just because it met one objection.

> but out of curiosity:
> 
> 1. can you give an example of a non-self-insert buffer where 
> any of the special-mode-map bindings are not appropriate?

Don't have to.  Can you show that no such buffer can exist?

But yes - Dired.  Perhaps you recall this thread that you started?
http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00015.html
See also: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12311.

Some keys in s-m-map, past, current, or future, might not necessarily be
appropriate for some particular non-self-insert buffer.

In the case of that thread, the argument was over whether `z' was appropriate.
It is irrelevant to the current discussion whether it is still part of s-m-map
or whether Dired uses s-m-map.

Dired mode (not Wdired) has a non-self-insert buffer, and s-m-map is not
appropriate for it (see the second URL above).

The point is that there is no necessary dependence of non-self-insert buffers
upon s-m-map.

In this case, BTW, the doc string is no help.  The s-m-map doc string just punts
to "special mode", and that just punts nowhere (not good).

A user needs to consult (elisp) `Basic Major Modes' to find out anything of
substance about what a "special mode" is.

It is a mode whose buffer text is "produced specially by Emacs, rather than
directly from a file".  That's pretty broad.  The explanation adds that the
buffer is set by `special-mode' to read-only (which is different from
non-self-insertion, BTW).

Whether all read-only or (your question) all non-self-insertion buffers must or
should also be special could be debated.

I would argue no.  For one thing, the criterion of being "produced specially by
Emacs, rather than directly from a file" is important.  But though necessary,
neither criterion is sufficient to _require_ special mode.  You can use special
mode for such a buffer, but nothing requires you to.

> 2. can you give an example of a button-buffer-map usage in a 
> self-insert buffer?

Ditto.

Things should not be coupled unless they need to be.  Occam.

Stating this is not an expression of vehemence.

> PS. my practical rationale was that I bound a key in special-mode-map
> and was surprised that the binding was not present in *Buffer List*.

That's easily remedied, no?