unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Keymap initialization
Date: Mon, 26 Jun 2017 16:27:04 -0400	[thread overview]
Message-ID: <jwvinji7c3h.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <20170626180807.GC2471@acm> (Alan Mackenzie's message of "Mon, 26 Jun 2017 18:08:07 +0000")

>> C-M-x on the (defvar foo-map ...) takes care of it as well.  Or using
>> `defconst` instead of `defvar` would do the trick also (although that's
>> also less idiomatic).  Or write a new M-x reload-file which causes all
>> the defvars to be re-evaluated.
> Workarounds, every one.

Like your solution.  As I said, they all have advantages and disadvantages.

E.g. your solution will override some ~/.emacs changes to the cc-mode
map when reloading the file.  And it will fail to remove old bindings
when you change your code (e.g. when you move a binding from one key to
another or when you remove a binding altogether).  It has various other
additional failure modes.

> Why do you think things should be standardised?  (Not a rhetorical
> question)

It's important for the core Emacs maintainers so they can fix things
without having to decypher all the idiosyncrasies of all packages.

It's important for the end user who uses various major modes (which I'd
expect to be a large fraction of Emacs users) and will benefit from
fewer surprises due to gratuitous subtle differences between the
different major modes.

Also, standardization is generally a necessary first step before being
able to consolidate.  Consolidation in turn means that all major modes
will get more features out of the box with less work on the coder's part.

What benefit do you see in CC-mode being non-standard?

>> IOW, rather than make CC-mode yet-a-bit-more different from the rest of
>> Emacs, I wish you would try to find a way to solve your problem globally.
>> If this annoyance affects you, there's a good chance it affects many
>> other developers, so finding a general solution would be a lot better.
> That seems to presume that the way things are already done in Emacs is
> at or near some optimum, and deviating from that way is therefore
> sub-optimal.

Actually, if you read carefully, nowhere did I say that the current
idiomatic way is in itself better.  I'm OK with changing the standard to
fix problems with it.  What I object to is having a single package
(e.g. CC-mode) stray from the currently followed standard for reasons
unrelated to the specificities of this package.

IOW I would object less strenuously to a patch which applies the same
change to all of Emacs's major modes.

> I don't think there's any evidence for this.  I see some "standard"
> ways of doing things in Emacs which I don't think are good.

I often see that as well.  My reaction is to try and change that in
a way which works for everyone.
Your reaction instead seems to be "oh screw them, I'll do it my way".

> Setting key map entries at load time could be a general solution to that
> particular annoyance.  People, having seen it in CC Mode, will be able
> to adapt it for their own modes, should they see fit.

That could be an OK argument in theory, but this approach has been used
for many years in many packages and did not prove superior (nor
significantly worse, indeed).


        Stefan



  reply	other threads:[~2017-06-26 20:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170615210438.18512.16715@vcs0.savannah.gnu.org>
     [not found] ` <20170615210440.2D57C206CD@vcs0.savannah.gnu.org>
2017-06-25 21:29   ` Keymap initialization (was: [Emacs-diffs] master 7a2038d: Create a toggle between block and line comments in CC Mode) Stefan Monnier
2017-06-26 16:39     ` Alan Mackenzie
2017-06-26 17:41       ` Keymap initialization Stefan Monnier
2017-06-26 18:08         ` Alan Mackenzie
2017-06-26 20:27           ` Stefan Monnier [this message]
2017-06-26 21:13             ` Alan Mackenzie
2017-06-27  2:34               ` Stefan Monnier
2017-06-26 20:08         ` Clément Pit-Claudel

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=jwvinji7c3h.fsf-monnier+emacsdiffs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acm@muc.de \
    --cc=emacs-devel@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).