all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Keymap initialization (was: [Emacs-diffs] master 7a2038d: Create a toggle between block and line comments in CC Mode)
       [not found] ` <20170615210440.2D57C206CD@vcs0.savannah.gnu.org>
@ 2017-06-25 21:29   ` Stefan Monnier
  2017-06-26 16:39     ` Alan Mackenzie
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2017-06-25 21:29 UTC (permalink / raw)
  To: emacs-devel; +Cc: Alan Mackenzie

>     Create a toggle between block and line comments in CC Mode.
[...]
>     (c-mode-map, c++-mode-map, objc-mode-map, java-mode-map, idl-mode-map)
>     (pike-mode-map, awk-mode-map): Make entries in these key maps each time
>     the mode is loaded rather than just once per Emacs session.

This seems completely unrelated.

>  (defvar pike-mode-map
>    (let ((map (c-make-inherited-keymap)))
> -    ;; Additional bindings.
> -    (define-key map "\C-c\C-e" 'c-macro-expand)
>      map)
>    "Keymap used in pike-mode buffers.")
> +;; Additional bindings.
> +(define-key pike-mode-map "\C-c\C-e" 'c-macro-expand)

This is anti-idiomatic: Emacs's own code has been making the
opposite change over the years in most/all bundled packages.

There are many ways to skin this cat; the two alternatives above have
both advantages and disadvantages, so I think we should agree on one and
stick to it.  Consistency is not Emacs's forte and is not something that
I consider indispensable, but I really don't see why CC-mode's keymaps
need to behave differently from all other major modes.


        Stefan



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Keymap initialization (was: [Emacs-diffs] master 7a2038d: Create a toggle between block and line comments in CC Mode)
  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
  0 siblings, 1 reply; 8+ messages in thread
From: Alan Mackenzie @ 2017-06-26 16:39 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Hello, Stefan.

On Sun, Jun 25, 2017 at 17:29:56 -0400, Stefan Monnier wrote:
> >     Create a toggle between block and line comments in CC Mode.
> [...]
> >     (c-mode-map, c++-mode-map, objc-mode-map, java-mode-map, idl-mode-map)
> >     (pike-mode-map, awk-mode-map): Make entries in these key maps each time
> >     the mode is loaded rather than just once per Emacs session.

> This seems completely unrelated.

As the commit message (the bit you snipped) said.

> >  (defvar pike-mode-map
> >    (let ((map (c-make-inherited-keymap)))
> > -    ;; Additional bindings.
> > -    (define-key map "\C-c\C-e" 'c-macro-expand)
> >      map)
> >    "Keymap used in pike-mode buffers.")
> > +;; Additional bindings.
> > +(define-key pike-mode-map "\C-c\C-e" 'c-macro-expand)

> This is anti-idiomatic: Emacs's own code has been making the
> opposite change over the years in most/all bundled packages.

I got sick and tired of having to do M-: (makunbound 'foo-map) before
loading files with changed keymaps.  As a developer yourself, you should
welcome such changes.

> There are many ways to skin this cat; the two alternatives above have
> both advantages and disadvantages, so I think we should agree on one and
> stick to it.  Consistency is not Emacs's forte and is not something that
> I consider indispensable, but I really don't see why CC-mode's keymaps
> need to behave differently from all other major modes.

They don't.  You press a pertinent key combination and the key maps take
you to the matching command.  Precisely how these keymaps are
constructed and loaded is of lesser importance.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Keymap initialization
  2017-06-26 16:39     ` Alan Mackenzie
@ 2017-06-26 17:41       ` Stefan Monnier
  2017-06-26 18:08         ` Alan Mackenzie
  2017-06-26 20:08         ` Clément Pit-Claudel
  0 siblings, 2 replies; 8+ messages in thread
From: Stefan Monnier @ 2017-06-26 17:41 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

>> This is anti-idiomatic: Emacs's own code has been making the
>> opposite change over the years in most/all bundled packages.
> I got sick and tired of having to do M-: (makunbound 'foo-map) before
> loading files with changed keymaps.  As a developer yourself, you should
> welcome such changes.

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.

>> I consider indispensable, but I really don't see why CC-mode's keymaps
>> need to behave differently from all other major modes.
> They don't.

Obviously they do, which is why you made the change.

> Precisely how these keymaps are constructed and loaded is of
> lesser importance.

It seems important enough for you to change from the idiomatic form to
a non-idiomatic one.

But yes, I do think it's of lesser importance, which is why I think it's
more important that the downsides (e.g. the need to C-M-x or (makunbound
'foo-map), or the need to re-run your .emacs after reloading cc-mode.el,
...) be standardized.

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.


        Stefan



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Keymap initialization
  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 20:08         ` Clément Pit-Claudel
  1 sibling, 1 reply; 8+ messages in thread
From: Alan Mackenzie @ 2017-06-26 18:08 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Hello, Stefan.

On Mon, Jun 26, 2017 at 13:41:50 -0400, Stefan Monnier wrote:
> >> This is anti-idiomatic: Emacs's own code has been making the
> >> opposite change over the years in most/all bundled packages.
> > I got sick and tired of having to do M-: (makunbound 'foo-map) before
> > loading files with changed keymaps.  As a developer yourself, you should
> > welcome such changes.

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

> >> I consider indispensable, but I really don't see why CC-mode's keymaps
> >> need to behave differently from all other major modes.
> > They don't.

> Obviously they do, which is why you made the change.

> > Precisely how these keymaps are constructed and loaded is of
> > lesser importance.

> It seems important enough for you to change from the idiomatic form to
> a non-idiomatic one.

<sigh>.  It's of near zero importance to the Emacs team, it's of quite
some importance to the hacker who's currently changing the key maps.

> But yes, I do think it's of lesser importance, which is why I think it's
> more important that the downsides (e.g. the need to C-M-x or (makunbound
> 'foo-map), or the need to re-run your .emacs after reloading cc-mode.el,
> ...) be standardized.

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

> 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.  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.
People should feel free to try out various ways of doing things.  Only
this way can new ideas come forth, leading to a gradual improvement in
Emacs when these ideas spread.

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.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Keymap initialization
  2017-06-26 17:41       ` Keymap initialization Stefan Monnier
  2017-06-26 18:08         ` Alan Mackenzie
@ 2017-06-26 20:08         ` Clément Pit-Claudel
  1 sibling, 0 replies; 8+ messages in thread
From: Clément Pit-Claudel @ 2017-06-26 20:08 UTC (permalink / raw)
  To: emacs-devel

On 2017-06-26 13:41, Stefan Monnier wrote:
> Or write a new M-x reload-file which causes all
> the defvars to be re-evaluated.

That would be really nice. I use M-< F3 C-M-f C-M-x F4 C-- F4 more often than I feel comfortable admitting.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Keymap initialization
  2017-06-26 18:08         ` Alan Mackenzie
@ 2017-06-26 20:27           ` Stefan Monnier
  2017-06-26 21:13             ` Alan Mackenzie
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2017-06-26 20:27 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Keymap initialization
  2017-06-26 20:27           ` Stefan Monnier
@ 2017-06-26 21:13             ` Alan Mackenzie
  2017-06-27  2:34               ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Alan Mackenzie @ 2017-06-26 21:13 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Keymap initialization
  2017-06-26 21:13             ` Alan Mackenzie
@ 2017-06-27  2:34               ` Stefan Monnier
  0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2017-06-27  2:34 UTC (permalink / raw)
  To: emacs-devel

> Only CC Mode developers are likely to be reloading the file.

But every maintainer has that same need for its own files, so it'd be
better to solve this for others as well.

> It can actually be written and maintained.  CC Mode probably rates
> amongst the top few packages in terms of difficulty, and that difficulty

Actually, your keymap setup looks pretty straightforward.  Definitely not more
complex than most other packages.

And now that I look more closely, I see that the bindings in those maps
have basically stayed unchanged for the last 20 years or so, so the need
to update the map when you reload the file can't have bitten you that
many times (if ever).

The only keymap that's seen changes (e.g. the recent addition of
c-toggle-comment-style) is apparently c-mode-base-map, and for some
reason you haven't applied that same change to it, so reloading
cc-mode.el won't update the only map which might need updating.

Obviously, I'm missing something.

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

Implementing something like M-x reload-file OTOH would give the same
kind of benefit without needing to patch any file.

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

Yes, it can be hard work.

> Some of the things you seem to want in CC Mode would complexify it.

We just don't have the same definition of complexity.

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

CC-mode has been a thorn in the side while I was maintaining Emacs
because it always does everything differently.  I find it very important
to try and solve this problem.


        Stefan




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-06-27  2:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [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
2017-06-27  2:34               ` Stefan Monnier
2017-06-26 20:08         ` Clément Pit-Claudel

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.