unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <sds@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: button-buffer-map should inherit from special-mode-map
Date: Thu, 21 Feb 2013 11:26:36 -0800	[thread overview]
Message-ID: <8FD33424BFE2446D8072FC1798D0021B@us.oracle.com> (raw)
In-Reply-To: <87mwuxse47.fsf@gnu.org>

> > 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.




  reply	other threads:[~2013-02-21 19:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21 17:04 button-buffer-map should inherit from special-mode-map Sam Steingold
2013-02-21 18:29 ` Drew Adams
2013-02-21 18:42   ` Sam Steingold
2013-02-21 19:26     ` Drew Adams [this message]
2013-02-21 19:57       ` Sam Steingold
2013-02-21 21:13         ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8FD33424BFE2446D8072FC1798D0021B@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=sds@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).