unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: Keymap initialization
Date: Mon, 26 Jun 2017 21:13:33 +0000	[thread overview]
Message-ID: <20170626211333.GF2471@acm> (raw)
In-Reply-To: <jwvinji7c3h.fsf-monnier+emacsdiffs@gnu.org>

Hello, Stefan.

On Mon, Jun 26, 2017 at 16:27:04 -0400, Stefan Monnier wrote:
> 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.

Only CC Mode developers are likely to be reloading the file.  It would
be nice to be able to remove the old bindings, but that's hardly as
important as getting the new ones loaded.

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

It can actually be written and maintained.  CC Mode probably rates
amongst the top few packages in terms of difficulty, and that difficulty
is mainly due to the topic of the mode (particularly the more recent
versions of C++), though unfortunate maintenance choices over the
decades have certainly contributed to it.  Constraining it to "standard"
ways of working would make it too complicated to be maintained.

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

Such patches are beyond my capacity to make, certainly if I want to
carry on with CC Mode, too.

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

There are a few improvements I've tried to make in the Emacs core, only
to get knocked back.  I'm more wary about spending time there, now.  I
also value KISS.  Some of the things you seem to want in CC Mode would
complexify it.

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

Given how little difficulty either approach will cause in practice,
there seems to be little to speak for a rigid common approach.  We have,
perhaps, both been wasting time over the past few hours discussing it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2017-06-26 21:13 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
2017-06-26 21:13             ` Alan Mackenzie [this message]
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=20170626211333.GF2471@acm \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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).