[CVS] f7, f8 bound..

[CVS] f7, f8 bound..

[D. Goel]

I checked out CVS today. 

unfortunately, the latest CVS seems to have keys f7 and f8 bounded to
kmacro commands. The keys f5--f9 are supposed to be reserved for
users. (and my .emacs relies on these conventions).

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

"D. Goel" <deego@glue.umd.edu> writes:

> I checked out CVS today. 
> 
> unfortunately, the latest CVS seems to have keys f7 and f8 bounded to
> kmacro commands. The keys f5--f9 are supposed to be reserved for
> users. (and my .emacs relies on these conventions).
> 

I can see that is a problem.  

I need to bind them to two adjacent function keys, but maybe we should
move them to f3 and f4 instead ? 

AFAICS, f3 and f4 are not bound by default.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[D. Goel]

Kim

thanks for the reply. 

> > unfortunately, the latest CVS seems to have keys f7 and f8 bounded to
> 
> I need to bind them to two adjacent function keys, but maybe we should
> move them to f3 and f4 instead ? 

That sounds good to me.  :-)

(perhaps even better, they could be bound to [f4 f4] and [f4 f5]
respectively).  This means that kmacro takes the f4- keys, while
leaving f3 for other applications.


> 
> AFAICS, f3 and f4 are not bound by default.

same here. 

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> > I checked out CVS today. 
> > 
> > unfortunately, the latest CVS seems to have keys f7 and f8 bounded to
> > kmacro commands. The keys f5--f9 are supposed to be reserved for
> > users. (and my .emacs relies on these conventions).
> > 
> 
> I can see that is a problem.  
> 
> I need to bind them to two adjacent function keys, but maybe we should
> move them to f3 and f4 instead ? 

Please don't use Fn keys.  It's very non-intuitive.
By the way, how about making C-x e e e e e e repeat like
C-x z z z z z does ?


	Stefan

Re: [CVS] f7, f8 bound..

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > I need to bind them to two adjacent function keys, but maybe we should
> > move them to f3 and f4 instead ? 
> 
> Please don't use Fn keys.  It's very non-intuitive.

Yeah [and on my happy-hacking keyboard, they're even hard to type].

I agree that `C-x e' is kind of a pain to type, but what's wrong with
`C-x (' & `C-x )', exactly?

[I'd actually prefer to have a meta-shifted key to do what `C-x e' does,
then I could just hold down the meta-key on my keyboard and repeatedly
hit the command key.]

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > > I need to bind them to two adjacent function keys, but maybe we should
> > > move them to f3 and f4 instead ? 
> > 
> > Please don't use Fn keys.  It's very non-intuitive.
> 
> Yeah [and on my happy-hacking keyboard, they're even hard to type].
> 
> I agree that `C-x e' is kind of a pain to type, but what's wrong with
> `C-x (' & `C-x )', exactly?

IMO, they are a pain to type as well!  I don't see why we should hide
an excellent feature like keyboard macros under bindings which
requires you to use a total of 8 keystrokes just the define the macro.


> 
> [I'd actually prefer to have a meta-shifted key to do what `C-x e' does,
> then I could just hold down the meta-key on my keyboard and repeatedly
> hit the command key.]

M-f4 :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > > I checked out CVS today. 
> > > 
> > > unfortunately, the latest CVS seems to have keys f7 and f8 bounded to
> > > kmacro commands. The keys f5--f9 are supposed to be reserved for
> > > users. (and my .emacs relies on these conventions).
> > > 
> > 
> > I can see that is a problem.  
> > 
> > I need to bind them to two adjacent function keys, but maybe we should
> > move them to f3 and f4 instead ? 
> 
> Please don't use Fn keys.  It's very non-intuitive.

But its so much simpler to use...  

Although I can see that there is more "sense" in the C-x (, C-x ), and
C-x e bindings, they are just way too cumbersome to type.

I.e. I have to hit 4 keys to type C-x (, type the macro, then hit 4
keys to type C-x ), and finally 3 keys to type C-x e for every call of
the macro.

This means that keyboard macros are simply not used as much as they
could be with simpler bindings.  Compare the above with: hit f3, type
the macro, hit f4, and then hit f4 for every invocation of the macro.

In any case, I haven't removed the old bindings, just *supplemented*
them with a much more efficient interfaces based on using two function
keys.

So the question is not whether to use function keys, but which ones
to use by default.  If I don't hear any objections to using f3 and f4,
I'll make the change.

> By the way, how about making C-x e e e e e e repeat like
> C-x z z z z z does ?

Try C-x C-k C-k C-k.... :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Juanma Barranquero]

On 27 Aug 2002 10:55:15 +0200, storm@cua.dk (Kim F. Storm) wrote:

> But its so much simpler to use...  

Yeah, but...

> In any case, I haven't removed the old bindings, just *supplemented*
> them with a much more efficient interfaces based on using two function
> keys.

...why not bind `kmacro-start-macro-or-insert-counter',
`kmacro-end-or-call-macro', etc. to "C-x something" and let the user
bind them to F7/F8, F3/F4 or whatever?

You can even recommend the F7/F8 interface in kmacro comments, or supply
a kmacro-set-bindings function where user-chosen keys can be passed (à
la windmove-default-keybindings), etc...


                                                           /L/e/k/t/u

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> On 27 Aug 2002 10:55:15 +0200, storm@cua.dk (Kim F. Storm) wrote:
> 
> > But its so much simpler to use...  
> 
> Yeah, but...
> 
> > In any case, I haven't removed the old bindings, just *supplemented*
> > them with a much more efficient interfaces based on using two function
> > keys.
> 
> ...why not bind `kmacro-start-macro-or-insert-counter',
> `kmacro-end-or-call-macro', etc. to "C-x something" and let the user
> bind them to F7/F8, F3/F4 or whatever?

I really don't understand why binding function keys by default is
worth making a fuzz about. 

f1, f2, and f10 are already bound, I don't see why binding f3 and f4
should upset anyone (as it obviously does).

There's nothing preventing a user (even a novice user) from changing
the default bindings, but what's wrong with providing default bindings
which makes emacs easier to use?

> 
> You can even recommend the F7/F8 interface in kmacro comments, or supply
> a kmacro-set-bindings function where user-chosen keys can be passed (à
> la windmove-default-keybindings), etc...

I did that originally, but removed it since the new C-x C-k bindings
are better than the original bindings (which included M-f7, C-f8, S-f8
etc).


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Juanma Barranquero]

On 27 Aug 2002 12:32:24 +0200, storm@cua.dk (Kim F. Storm) wrote:

> I really don't understand why binding function keys by default is
> worth making a fuzz about. 
> 
> f1, f2, and f10 are already bound, I don't see why binding f3 and f4
> should upset anyone (as it obviously does).

Obviously, the F1..Fn space is much smaller than a control-whatever
multikey binding.

Yes, I feel strongly about anything using F keys. F1 is to all effects a
"standard" for Help, but from F2 and F10 I have removed the default
bindings, that I simply don't use.

I like kmacro a lot, but if standard Emacs packages start to use the
F-space, well, there's very little and I'm sure many other packages
would benefit from using F keys (bs functions for cycling buffers, for
example). IMHO, the decision about how to manage these keys is best left
in user's hands.

> There's nothing preventing a user (even a novice user) from changing
> the default bindings, but what's wrong with providing default bindings
> which makes emacs easier to use?

Nothing, of course. But there are *lots* of things in Emacs that the
user must access through several keystrokes and that would be easier if
bound to an F-key. I certainly use list-buffers (bs-show, in fact, but
that's irrelevant) a lot more than macros, so it is much much better for
me to bind list-buffers to a single key that any macro function...
Obviously YMMV.

> I did that originally, but removed it since the new C-x C-k bindings
> are better than the original bindings (which included M-f7, C-f8, S-f8
> etc).

As all that wonderful functionality is available through C-x C-k, the
fact is that you're reserving two F-keys basically to start recording a
macro (inserting counters is useful, but secondary), to finish recording
it and to recall it. The last use I can understand, but you don't record a
macro that often. What's wrong with having a multikey binding? 

All that said, I'm not opposing in any way to using F3/F4 or F7/F8; is
not that important an issue. I'm just venting my opinion that I feel
vaguely "wrong" to steal the F-keys from the user.


                                                           /L/e/k/t/u

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> As all that wonderful functionality is available through C-x C-k, the
> fact is that you're reserving two F-keys basically to start recording a
> macro (inserting counters is useful, but secondary), to finish recording
> it and to recall it. The last use I can understand, but you don't record a
> macro that often. What's wrong with having a multikey binding? 

Nothing as such, but it makes a nice interface to have this on two
function keys next to each other.  Of course I biased, as I first
implemented and started using kmacro 10 years ago!!

Actually, back then, no function keys had default bindings (not even
F1), so I put it on F1 and F2 ... and I still have it there :-)

And since then, I use keyboard macros _A LOT_ -- because it is now so
easy to start(!), end and call them...

> 
> All that said, I'm not opposing in any way to using F3/F4 or F7/F8; is
> not that important an issue. I'm just venting my opinion that I feel
> vaguely "wrong" to steal the F-keys from the user.

Nothing's stolen from the user.  He is offered a service which he can
refuse to use.  I don't see the harm.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Juanma Barranquero]

On 27 Aug 2002 13:55:42 +0200, storm@cua.dk (Kim F. Storm) wrote:

> Nothing as such, but it makes a nice interface to have this on two
> function keys next to each other.

Yes.

> Nothing's stolen from the user.  He is offered a service which he can
> refuse to use.  I don't see the harm.

There's no harm. But I think many people refuse to change default
bindings. They don't want to be "un-standard".

I even have a boss who frowns upon me because I have a heavily
configured Emacs and his thinking is that you should use only the
standard keybindings so you aren't lost if you ever have to use anyone
else's Emacs (of course I have pretty strong arguments against this :)


                                                           /L/e/k/t/u

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> > > > I checked out CVS today. 
> > > > 
> > > > unfortunately, the latest CVS seems to have keys f7 and f8 bounded to
> > > > kmacro commands. The keys f5--f9 are supposed to be reserved for
> > > > users. (and my .emacs relies on these conventions).
> > > > 
> > > 
> > > I can see that is a problem.  
> > > 
> > > I need to bind them to two adjacent function keys, but maybe we should
> > > move them to f3 and f4 instead ? 
> > 
> > Please don't use Fn keys.  It's very non-intuitive.
> 
> But its so much simpler to use...  

The menmonic content is pretty damn close to 0, so it's very much not
simpler to use unless you use it all the time.  If you do use it
all the time, feel free to rebind them, indeed.

> Although I can see that there is more "sense" in the C-x (, C-x ), and
> C-x e bindings, they are just way too cumbersome to type.

Maybe but they're reasonably mnemonic and we have to support them
anyway because that's the way it worked in the past.

> I.e. I have to hit 4 keys to type C-x (, type the macro, then hit 4
> keys to type C-x ), and finally 3 keys to type C-x e for every call of
> the macro.

Sure.  So you bound them to some of the user-reserved function keys.
Great for you.  Don't force it down everybody's throat.

> So the question is not whether to use function keys, but which ones
> to use by default.  If I don't hear any objections to using f3 and f4,
> I'll make the change.

No, I think that using function keys for it is just wrong.

> > By the way, how about making C-x e e e e e e repeat like
> > C-x z z z z z does ?
> Try C-x C-k C-k C-k.... :-)

No, I really meant C-x e e e e e e, not some other binding
(especially not one that reminds me of killing a line).


	Stefan

Re: [CVS] f7, f8 bound..

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > I.e. I have to hit 4 keys to type C-x (, type the macro, then hit 4
> > keys to type C-x ), and finally 3 keys to type C-x e for every call of
> > the macro.
> 
> Sure.  So you bound them to some of the user-reserved function keys.
> Great for you.  Don't force it down everybody's throat.

Yeah, I think this sums it up.  Everybody has their favorite customizations,
but please think a little harder before pushing to make them the default.

Maybe some people use keyboard macros very frequently, but I think most use
them just sometimes, and reserving two keys from an extremely limited set is
too much.  As those two keys are rather hard to remember, it's likely that
this change won't help the occasional macro-user _at all_.

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > > I.e. I have to hit 4 keys to type C-x (, type the macro, then hit 4
> > > keys to type C-x ), and finally 3 keys to type C-x e for every call of
> > > the macro.
> > 
> > Sure.  So you bound them to some of the user-reserved function keys.
> > Great for you.  Don't force it down everybody's throat.
> 
> Yeah, I think this sums it up.  Everybody has their favorite customizations,
> but please think a little harder before pushing to make them the default.

I've thought quite a lot about this.

The _main point_ of the new kmacro package is that it is supposed to
make keyboard macro _much easier_ to use that the current bindings do.

Note that where the old (and still available) bindings use separate
commands for ending and calling a keyboard macro, the new bindings
merges the ending and calling onto the same key.  So kmacro just needs
two [function] keys rather than three.

> 
> Maybe some people use keyboard macros very frequently, but I think most use
> them just sometimes, and reserving two keys from an extremely limited set is
> too much.  As those two keys are rather hard to remember, it's likely that
> this change won't help the occasional macro-user _at all_.

My mission is to convert occasional macro users into frequent macro users !

A trivial example:

Let's say I need to tag a ; onto the next four lines in my buffer.

I could do this directly:

        C-e ; C-n C-e ; C-n C-e ; C-n C-e ;

That's a total of 18 key strokes counting 4 uses of Ctrl and 4 uses of
Shift as key strokes (assuming ; is on a Shifted key and you keep the
Ctrl key pressed while typing C-n C-e.)

Since this is a repeated task, I should be able to use a keyboard
macro for it...   let's try it with the old bindings:

        C-x ( C-e ; C-n C-x ) M-3 C-x e

But that's still 18 key strokes [half of which are modifier keys], so
it's definitely not worth the trouble.  No wonder keyboard macros are
not used very much...

Ok, to be fair, I (as an expert user) know that if I want to repeat
the macro immediately, I could do it with just 16 key strokes like
this:

        C-x ( C-e ; C-n M-4 C-x )

But that's still not really worth it.

With the new bindings this is quite different:

        F3 C-e ; C-n F4 F4 F4 F4

That's just 11 key strokes - of which the last 4 are on the same key -
so it more like 8 individual key strokes and a little extra tapping on
the last key.  And only three modifier keys are used.

That's why I'm strongly advocating putting the kmacro commands on
easily accessible keys (read: function keys); it really makes using
keyboard macros much more efficient for repeating _simple_ tasks.

So to Stefan and others:
I'm not trying to force things down everybody's throat.  I'm
providing a default binding which makes a _big_ difference in
usability for the average user.

If _you_ don't need it or want it ... just rebind it.  Oh yeah,
you probably already did that, so what's the fuzz all about?

++kfs

Re: [CVS] f7, f8 bound..

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Note that where the old (and still available) bindings use separate
> commands for ending and calling a keyboard macro, the new bindings
> merges the ending and calling onto the same key.  So kmacro just needs
> two [function] keys rather than three.

I think the merging of `end-kmacro-definition' and `execute-kmacro' is
clever and useful.

> With the new bindings this is quite different:
> 
>         F3 C-e ; C-n F4 F4 F4 F4
> 
> That's just 11 key strokes - of which the last 4 are on the same key -
> so it more like 8 individual key strokes and a little extra tapping on
> the last key.  And only three modifier keys are used.

I think you're obsessing way too much on `keystrokes'.  I suspect the
mental overhead of being careful to make your actions repeatable,
completely swamps the savings of two or three strokes.

[Also, for a touch-typist, it's probably _faster_ to type `C-x (' than
it is to type F3 -- and the former is clearly easier to remember!]

> I'm providing a default binding which makes a _big_ difference in
> usability for the average user.

You haven't shown that.  I'm sure you love this system, but as you said,
you've used it for 10 years, so I think you're really not a very good judge.

Your idea of an easy-to-hit combined end-execute key _is_ very good, and
probably worth adding; but surely we can come up with something better
than a function key!

Hell, why not just make `C-x e' end the macro as well as executing it,
and then use Stefan's idea of allowing the `e' to be repeated
indefinitely [or something similar]?  That would gain most of the
savings of your approach, while maintaining the existing
easy-to-remember bindings for macros.

> If _you_ don't need it or want it ... just rebind it.

We shouldn't just add every new feature that comes to mind, without
giving it a bit of debate.  Saying `well you can rebind it' is rather
lame...

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: [CVS] f7, f8 bound..

[Juanma Barranquero]

On 28 Aug 2002 17:54:40 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:

> We shouldn't just add every new feature that comes to mind, without
> giving it a bit of debate.  Saying `well you can rebind it' is rather
> lame...

In fact, if Fn/Fn+1 isn't made default for kmacro functions, I think
I'll bind them to that ASAP... but I still think they *shouldn't* be
default.

The documentation should suggest the bindings, as other packages do. A
user is not going to know how to use macros/kmacro without reading it
anyway.


                                                           /L/e/k/t/u

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Juanma Barranquero <lektu@terra.es> writes:

> On 28 Aug 2002 17:54:40 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:
> 
> > We shouldn't just add every new feature that comes to mind, without
> > giving it a bit of debate.  Saying `well you can rebind it' is rather
> > lame...
> 
> In fact, if Fn/Fn+1 isn't made default for kmacro functions, I think
> I'll bind them to that ASAP... but I still think they *shouldn't* be
> default.

I don't understand... you like the binding to function keys, but you
don't like that to be easily accessible to new users.  Why not?

To me, the function key binding issue seems more religious than practical.

> 
> The documentation should suggest the bindings, as other packages do. A
> user is not going to know how to use macros/kmacro without reading it
> anyway.

Really ?

Hm, yes.  The documentation for C-h k f3 should be improved to briefly
explain what keyboard macros are all about.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Juanma Barranquero]

On 28 Aug 2002 12:58:36 +0200, storm@cua.dk (Kim F. Storm) wrote:

> I don't understand... you like the binding to function keys, but you
> don't like that to be easily accessible to new users.  Why not?

Because I'm not convinced they need that access more than they do to
bs-cycle-next and bs-cycle-previous, for example. And the F-keys are
mostly a user convenience, to be used as he sees fit.

In my experience, most new Emacs users (of the kind that barely read the
tutorial, if anything) have trouble knowing how to switch buffers, and
having a way to rotate between them in an easy, just-one-keystroke-away
key, is good for them. They don't use many buffers anyway.

But still bs.el doesn't bind F-keys by default, it just suggests doing
so to F9/F10. Why? Because the binding is a matter of taste, and because
a user is not going to know how to use bs anyway without reading at
least a bit of documentation (and then they can copy the suggested
bindings and put F5/F6 or whatever instead of F9/F10 without problem).

Using macros seems natural to you and me, but users who don't know how
to bind a command to a key are not going to use macros either. If they
take the pain to read about them, they'll find the bit of documentation
that says how to bind them to whatever they want. Who knows, perhaps
they'll agree with you in that having kmacro in F-keys is good, but they
strongly and religiously believe the right F-keys for macros are F11/F12!
:)

> To me, the function key binding issue seems more religious than practical.

As most keybinding issues are.

> Really ?
> 
> Hm, yes.  The documentation for C-h k f3 should be improved to briefly
> explain what keyboard macros are all about.

And perhaps refer them to the relevant Info node... :)


                                                           /L/e/k/t/u

Re: [CVS] f7, f8 bound..

[Miles Bader]

I wrote:
> Hell, why not just make `C-x e' end the macro as well as executing it,
> and then use Stefan's idea of allowing the `e' to be repeated
> indefinitely [or something similar]?  That would gain most of the
> savings of your approach, while maintaining the existing
> easy-to-remember bindings for macros.

Actually, I think a better idea would be to make `C-x e' repeat if you
hit SPC afterwards, and display a message to that effect so that it's
obvious, e.g., 

  Hit SPC to repeat macro

(You could hit ^G if you want to insert a real space immediately after a
macro)

[I also think that hitting SPC should use the same repeat-count as the
original `C-x e', e.g., `C-u 20 C-x e SPC SPC' should execute the macro
60 times]

I would _love_ an interface like that -- it's definitely true that it's
currently very annoying to hit `C-x e' repeatedly.
[by contrast, the F3/F4 interface seems very blah to me; I guess I just
don't like function keys, they seem far too arbitrary]

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I wrote:
> > Hell, why not just make `C-x e' end the macro as well as executing it,
> > and then use Stefan's idea of allowing the `e' to be repeated
> > indefinitely [or something similar]?  That would gain most of the
> > savings of your approach, while maintaining the existing
> > easy-to-remember bindings for macros.
> 
> Actually, I think a better idea would be to make `C-x e' repeat if you
> hit SPC afterwards, and display a message to that effect so that it's
> obvious, e.g., 
> 
>   Hit SPC to repeat macro
> 
> (You could hit ^G if you want to insert a real space immediately after a
> macro)

Maybe it would be sensible to make this customizeable, e.g.
kmacro-call-repeat-key which defaults to `e' or ` ' or nil.

IMO, default should be nil as it is the least confusing choice.

> 
> [I also think that hitting SPC should use the same repeat-count as the
> original `C-x e', e.g., `C-u 20 C-x e SPC SPC' should execute the macro
> 60 times]

Hm, I can see what you mean, but I can easily think of cases where it
will be confusing.  But we can try it...

> 
> I would _love_ an interface like that -- it's definitely true that it's
> currently very annoying to hit `C-x e' repeatedly.

You'd love it, I think I'd dislike it very much not; not being able to
simply hit e or SPC after executing a macro seems completely broken to me.
Remember, I use macros even for trivial tasks.

In any case, I don't see any reason why I cannot add this feature for
_your_ convenience.

> [by contrast, the F3/F4 interface seems very blah to me; I guess I just
> don't like function keys, they seem far too arbitrary]

So why all the fuzz?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> > > Hell, why not just make `C-x e' end the macro as well as executing it,
> > > and then use Stefan's idea of allowing the `e' to be repeated
> > > indefinitely [or something similar]?  That would gain most of the
> > > savings of your approach, while maintaining the existing
> > > easy-to-remember bindings for macros.
> > 
> > Actually, I think a better idea would be to make `C-x e' repeat if you
> > hit SPC afterwards, and display a message to that effect so that it's
> > obvious, e.g., 
> > 
> >   Hit SPC to repeat macro
> > 
> > (You could hit ^G if you want to insert a real space immediately after a
> > macro)
> 
> Maybe it would be sensible to make this customizeable, e.g.
> kmacro-call-repeat-key which defaults to `e' or ` ' or nil.

I think repeating "the last key" is the best choice, in case the command
is bound to something else than C-x e.  Also this mimics the C-x z z z z
behavior, so there's a precedent for it.
I have a C-x e e e e e hack in my .emacs (taken from a friend of mine who
suggested the idea in the first place and that I managed to convince to
write the code rather than wait for me to do it ;-) and I find it very
convenient.

> In any case, I don't see any reason why I cannot add this feature for
> _your_ convenience.

The hack I have in my .emacs is rather non-trivial.
You can't expect a normal user to write it.  So it's very different from
the Fn question where it's trivial for the user to add a `define-key'
in his .emacs file.

> > [by contrast, the F3/F4 interface seems very blah to me; I guess I just
> > don't like function keys, they seem far too arbitrary]
> So why all the fuzz?

Because I don't want to see the interface I use (i.e. C-x (, C-x )
and C-x e) take second class status and have all the improvement go
on F3 and F4 bindings.

My experience is similar to Miles: the problem is not the time it takes
to hit C-x ( and C-x ), but the effort it takes to make your key sequence
repeatable.  I'd rather see the `edit-kbd-macro' kind of functionality
improved/supplemented with something lighter weight so I can fix my macros
"on the fly" as I see them fail (no I don't know what that would look
like, sadly).

And yes, I think it's important to have a "single-key repeat", which
is why I find C-x e e e e e so valuable (and it makes the need for
a single-key binding such as F4 unnecessary).


	Stefan

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > Maybe it would be sensible to make this customizeable, e.g.
> > kmacro-call-repeat-key which defaults to `e' or ` ' or nil.
> 
> I think repeating "the last key" is the best choice, in case the command
> is bound to something else than C-x e.  Also this mimics the C-x z z z z
> behavior, so there's a precedent for it.

I've implemented this.

New custom variables are kmacro-call-repeat-key and
kmacro-call-repeat-with-arg so both you and Miles will be happy.

In addition C-x e will now end the macro (like C-x )) if it is current
defining a macro rather than signalling an error.  And you can repeat it
immediately with `e'...

> 
> Because I don't want to see the interface I use (i.e. C-x (, C-x )
> and C-x e) take second class status and have all the improvement go
> on F3 and F4 bindings.

This is unfounded.  I think I'm pretty receptive to the requests and
ideas from users to add features that I'd never use myself.  

In the case of kmacro, you just got what you asked for :-) 

> 
> My experience is similar to Miles: the problem is not the time it takes
> to hit C-x ( and C-x ), but the effort it takes to make your key sequence
> repeatable.

For non-trivial tasks that is true.  For trivial tasks, it does make a
(huge) difference to me.  YMMV.

>  I'd rather see the `edit-kbd-macro' kind of functionality
> improved/supplemented with something lighter weight so I can fix my macros
> "on the fly" as I see them fail (no I don't know what that would look
> like, sadly).

That's a nice idea.  

Maybe something like "step through macro" with the ability:

For each key sequence, ask user for confirmation:

 SPC to accept the last action and executes the next,
 DEL to undo the last action and removes it from the macro,
 C-x ( ... C-x ) allows you to add actions in the middle of the macro, and
 RET simply accepts the rest of the macro.

WDYT?

> 
> And yes, I think it's important to have a "single-key repeat", which
> is why I find C-x e e e e e so valuable (and it makes the need for
> a single-key binding such as F4 unnecessary).

Agree to first part, disagree on second part!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > > Maybe it would be sensible to make this customizeable, e.g.
> > > kmacro-call-repeat-key which defaults to `e' or ` ' or nil.
> > 
> > I think repeating "the last key" is the best choice, in case the command
> > is bound to something else than C-x e.  Also this mimics the C-x z z z z
> > behavior, so there's a precedent for it.
> 
> I've implemented this.
> 
> New custom variables are kmacro-call-repeat-key and
> kmacro-call-repeat-with-arg so both you and Miles will be happy.
> 
> In addition C-x e will now end the macro (like C-x )) if it is current
> defining a macro rather than signalling an error.  And you can repeat it
> immediately with `e'...

Thanks.  That's just great!
Hopefully the repeating behavior (whether with C-x e e e e
or C-x e SPC SPC SPC) can be made the default, but at least now it's
easy to turn it on.

> > Because I don't want to see the interface I use (i.e. C-x (, C-x )
> > and C-x e) take second class status and have all the improvement go
> > on F3 and F4 bindings.
> 
> This is unfounded.  I think I'm pretty receptive to the requests and
> ideas from users to add features that I'd never use myself.

Yes, but you wouldn't have thought about C-x e e e e yourself because
you don't use that interface [ I fell like I'm not really
defending my argument here ;-) ]

> >  I'd rather see the `edit-kbd-macro' kind of functionality
> > improved/supplemented with something lighter weight so I can fix my macros
> > "on the fly" as I see them fail (no I don't know what that would look
> > like, sadly).
> 
> That's a nice idea.  
> 
> Maybe something like "step through macro" with the ability:
> 
> For each key sequence, ask user for confirmation:
> 
>  SPC to accept the last action and executes the next,
>  DEL to undo the last action and removes it from the macro,
>  C-x ( ... C-x ) allows you to add actions in the middle of the macro, and
>  RET simply accepts the rest of the macro.
> 
> WDYT?

As I said I had no idead what that could look like, but this suggestion
sounds pretty good.  Maybe something else than C-x ( ... C-x )
(for instance: any other binding is taken as "execute it and insert
it in the macro"), so if I see that the macro failed, I can undo it,
then step through it and when a step fails I just DEL + replacement...
That sounds great.


	Stefan

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

>  I'd rather see the `edit-kbd-macro' kind of functionality
> improved/supplemented with something lighter weight so I can fix my macros
> "on the fly" as I see them fail (no I don't know what that would look
> like, sadly).

I just added kmacro-step-edit-macro bound to C-x C-k SPC

Pls. try it out...


> .... so if I see that the macro failed, I can undo it,
> then step through it and when a step fails I just DEL + replacement...

I still see one problem with the way keyboard macros are defined
currently - if you make a mistake (and get a `ding'), the macro
is NOT saved.

I would like to change that so if an error occurs while defining a
macro, emacs will query the user whether he wants to continue adding
to the macro, end and save it, or discard it.   WDYT?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

storm@cua.dk (Kim F. Storm) writes:
   I would like to change that so if an error occurs while defining a
   macro, emacs will query the user whether he wants to continue adding
   to the macro, end and save it, or discard it.   WDYT?

YES!!!   Please do :-)

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Mon, Sep 09, 2002 at 01:02:45AM +0200, Kim F. Storm wrote:
> I would like to change that so if an error occurs while defining a
> macro, emacs will query the user whether he wants to continue adding
> to the macro, end and save it, or discard it.   WDYT?

That sounds like a good idea; unintentional errors are one of the most
annoying things about defining macros.

Some points:

  * Since the command that that caused the error will likely do the same
    thing when actually executing the macro, it seems like it would be useful
    to somehow remove the last command (which caused the error) from the
    macro.  However, I'm not sure whether this could be always be done
    without mucking things up -- for commands which always signal an error
    before causing any side-effects, it seems like it would be safe though.

  * A three-way choice seems unnecessary, since the user can easily end the
    macro himself; it would be simpler to just ask `Error occured; ignore
    last command? (y or n)' or something similar.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    I would like to change that so if an error occurs while defining a
    macro, emacs will query the user whether he wants to continue adding
    to the macro, end and save it, or discard it.   WDYT?

The question would be very annoying.  I think it should terminate and
define the macro.  If the user wants to ignore that definition, he
can.  If the user wants to add to it, he can do that too.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    The question would be very annoying.  I think it should terminate and
    define the macro.  If the user wants to ignore that definition, he
    can.  If the user wants to add to it, he can do that too.

Someone suggested that the erring command should be omitted from the
macro.  I agree, that is definitely desirable.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The question would be very annoying.  I think it should terminate and
>     define the macro.  If the user wants to ignore that definition, he
>     can.  If the user wants to add to it, he can do that too.
> 
> Someone suggested that the erring command should be omitted from the
> macro.  I agree, that is definitely desirable.

That's what it does!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I would like to change that so if an error occurs while defining a
>     macro, emacs will query the user whether he wants to continue adding
>     to the macro, end and save it, or discard it.   WDYT?
> 
> The question would be very annoying.  I think it should terminate and
> define the macro.  If the user wants to ignore that definition, he
> can.  If the user wants to add to it, he can do that too.

Ok, done.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    > The question would be very annoying.  I think it should terminate and
    > define the macro.  If the user wants to ignore that definition, he
    > can.  If the user wants to add to it, he can do that too.

    Ok, done.

Thanks.

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

       I would like to change that so if an error occurs while defining a
       macro, emacs will query the user whether he wants to continue adding
       to the macro, end and save it, or discard it.   WDYT?
   
   The question would be very annoying.  I think it should terminate and
   define the macro.  If the user wants to ignore that definition, he
   can.  If the user wants to add to it, he can do that too.
   
That is only part of the problem.  It often occurs to me that, while I'm
defining a long macro, I make a mistake in the middle of it.  

The current behaviour is discarding the work done so far, so I have to
restart from the beginning.  

The behaviour Richard proposes is to stop recording the macro (without
discarding it), so I'd have to restart with a series of undos, in order
to get rid of the modifications I did with the interrupted macro
definition, then restart with C-uC-x(, which reexecutes the macro
defined so far and then allows me to continue defining it.  Also, this
requires some thinking, because after doing the undo and the redo I must
be careful to remember where exactly I had made a mistake.

Generally speaking, the possible choices one would want are:
- aborting the definition (the current behaviour)
- ending the definition with or without the last command
- continuing the definition with or without the last command

As Miles says, however, only one question is needed:
 Error occured; ignore last command? (y or n)
without interrupting the recording of the macro.

This would leave the user the whole range of choices: they can abort
with C-g, they can continue, they can end with C-x), and they can choose
whether they want the last command included.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Francesco Potorti` <pot@gnu.org> writes:

>        I would like to change that so if an error occurs while defining a
>        macro, emacs will query the user whether he wants to continue adding
>        to the macro, end and save it, or discard it.   WDYT?
>    
>    The question would be very annoying.  I think it should terminate and
>    define the macro.  If the user wants to ignore that definition, he
>    can.  If the user wants to add to it, he can do that too.
>    
> That is only part of the problem.  It often occurs to me that, while I'm
> defining a long macro, I make a mistake in the middle of it.  
> 
> The current behaviour is discarding the work done so far, so I have to
> restart from the beginning.  
> 
> The behaviour Richard proposes is to stop recording the macro (without
> discarding it), so I'd have to restart with a series of undos, in order
> to get rid of the modifications I did with the interrupted macro
> definition, then restart with C-uC-x(, which reexecutes the macro
> defined so far and then allows me to continue defining it.  Also, this
> requires some thinking, because after doing the undo and the redo I must
> be careful to remember where exactly I had made a mistake.

You can use C-u C-u C-x ( to append to the macro without re-executing it first.

Also look at `kmacro-execute-before-command'.  If you set it to nil, you can
use C-u C-x ( to append to the previous macro without re-executing it.

You can look at the defined macro with C-x C-k C-v.

You can also experiment with the new step-edit feature on C-x C-k SPC.

> 
> Generally speaking, the possible choices one would want are:
> - aborting the definition (the current behaviour)
> - ending the definition with or without the last command
> - continuing the definition with or without the last command
> 
> As Miles says, however, only one question is needed:
>  Error occured; ignore last command? (y or n)
> without interrupting the recording of the macro.
> 
> This would leave the user the whole range of choices: they can abort
> with C-g, they can continue, they can end with C-x), and they can choose
> whether they want the last command included.

Although this would be nice, I think the current feature set is adequate.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

   > That is only part of the problem.  It often occurs to me that, while I'm
   > defining a long macro, I make a mistake in the middle of it.  
   > 
   > The current behaviour is discarding the work done so far, so I have to
   > restart from the beginning.  
   > 
   > The behaviour Richard proposes is to stop recording the macro (without
   > discarding it), so I'd have to restart with a series of undos, in order
   > to get rid of the modifications I did with the interrupted macro
   > definition, then restart with C-uC-x(, which reexecutes the macro
   > defined so far and then allows me to continue defining it.  Also, this
   > requires some thinking, because after doing the undo and the redo I must
   > be careful to remember where exactly I had made a mistake.
   
   You can use C-u C-u C-x ( to append to the macro without re-executing it first.

I suppose this is a new feature, because the current pretest does no
exhibit this behaviour (nor does it document it).  It is useful,
indeed. 
   
   Also look at `kmacro-execute-before-command'.  If you set it to nil, you can
   use C-u C-x ( to append to the previous macro without re-executing it.
   
   You can look at the defined macro with C-x C-k C-v.
   
   You can also experiment with the new step-edit feature on C-x C-k SPC.

These are all useful features, but they are not easy nor obvious to use.
You must know about them, you must learn how to use them, you must
remember them once you have learned.  I, for one, usually write some
complex macros once in a while.  It may happen that I do not write one
for some months, and then I spend some days writing many.  Non-obvious
features are forgotten in the meantime.

The suggestion Miles made (below) allows the whole range of choices at
the cost of a single question, and then only when you make an error.  It
cannot be annoying, because the fact itself of making an error somehow
breaks your thought direction.  The advantage is that it immediately
allows you to resume, without any other thinking, and it requires no
learning at all.

   > Generally speaking, the possible choices one would want are:
   > - aborting the definition (the current behaviour)
   > - ending the definition with or without the last command
   > - continuing the definition with or without the last command
   > 
   > As Miles says, however, only one question is needed:
   >  Error occured; ignore last command? (y or n)
   > without interrupting the recording of the macro.
   > 
   > This would leave the user the whole range of choices: they can abort
   > with C-g, they can continue, they can end with C-x), and they can choose
   > whether they want the last command included.

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

Miles Bader <miles@lsi.nec.co.jp> writes:
   I would _love_ an interface like that -- it's definitely true that it's
   currently very annoying to hit `C-x e' repeatedly.

When I create a macro, I always put a C-xq command in it, and end it
with M-0C-x), so it repeats indefinitely until I press SPC and stops as
soon as I press C-g.

This behaviour could be made standard for kmacro, perhaps, without the
need of putting a C-xq inside the macro just for this purpose.

   [by contrast, the F3/F4 interface seems very blah to me; I guess I just
   don't like function keys, they seem far too arbitrary]

In my opinion, F1 and F10 are well chosen.  F2 makes no sense to me.  A
precious function key wasted for a seldom used functionality.  And as
long as the other function keys are concerned, I do not think that
casually assigning them is a good idea.  Either let them free for the
user, or else carefully plan how to use them.

If we want to make life easier for newbies, for example, F2 and F3 are
traditionally used to open a file (find-file) and save it (save-buffer),
and F4 to select a block (set-mark-command).

As far as kmacro is concerned, I'd have no objections to, say S-f5 and
S-f6.

Re: [CVS] f7, f8 bound..

[Kai Großjohann]

Francesco Potorti` <pot@gnu.org> writes:

> F2 makes no sense to me.

The default binding of F2 is for two-column stuff.  I find the "2"
rather mnemonic here.

Or were you talking about something else?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

   > F2 makes no sense to me.
   The default binding of F2 is for two-column stuff.  I find the "2"
   rather mnemonic here.

Sorry, bad wording.  It does make sense indeed, only I think that this
is "casual assignement of function keys", which, as I explained in my
previous message, I believe should be avoided without a complete
planning of function key usage, or just avoided altogether.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

I agree that the feature on F2 is obscure; we chose it because the 2
in F2 is mnemonic for two-column mode, but I don't think that's really
enough to justify such a prominent place for such a rarely-used
feature.

Can anyone think of a better place to put it?

Re: [CVS] f7, f8 bound..

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I agree that the feature on F2 is obscure; we chose it because the 2
> in F2 is mnemonic for two-column mode, but I don't think that's really
> enough to justify such a prominent place for such a rarely-used
> feature.
>
> Can anyone think of a better place to put it?

The F2 bindings are also available as C-x 6 bindings, so nothing
needs to be done, I think.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    The F2 bindings are also available as C-x 6 bindings, so nothing
    needs to be done, I think.

Do people think we should remove the F2 bindings?  We could provide
commands on F2 and F3 that resemble simple text editors.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The F2 bindings are also available as C-x 6 bindings, so nothing
>     needs to be done, I think.
> 
> Do people think we should remove the F2 bindings?  We could provide
> commands on F2 and F3 that resemble simple text editors.

IMO, we better use the function keys for things which makes using
emacs easier.

I don't know what simple editors we need to look like, or whether any of
the simple editors resembles each other.  I doubt it.

As an example, M$-Word (which I would image quite a few users are
using -- like it or not) has the following bindings

F2 runs "MoveText",
F3 runs "InsertAutoText",
F4 runs "EditRedoOrRepeat",
F5 runs "EditGoTo",
etc...

Seems completely arbitraty to me...

I don't know what bindings M-$ visual studio (or whatever it's called)
or other IDEs put on the function keys.

We already provide things like crisp-mode which binds a lot of keys in
ways which resembles other editors.  That's a reasonable approach.

But it shouldn't be the default to try to mimic other (inferior :-)
editors.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Fri, Aug 30, 2002 at 04:48:41PM +0200, Kim F. Storm wrote:
> IMO, we better use the function keys for things which makes using
> emacs easier.
...
> As an example, M$-Word (which I would image quite a few users are
> using -- like it or not) has the following bindings
...
> Seems completely arbitraty to me...

Right -- I think the same can be said for almost _any_ binding, except
absurdly standardized ones like F1 (though even that's really useful for PC
users).

Personally I think it's silly to even think about having standardized
bindings for function keys; we should just leave them all for user-use
(except F1 and F10 I suppose, because they're apparently _very_ standard, and
for backward-compatibilty reasons).

Certainly, for operations you perform _very_ often, it can be convenient to
have them on a function key -- but exactly which operations those are is very
subjective.  For any operation that you only perform _somewhat_ often, on the
other hand, function keys are a positively _bad_ user interface:  they're
hard to touch-type and more importantly, they're very hard to remember.

A _much_ better idea, I think, would be to make it very simple for even
novice users to easily _bind_ the function keys to their liking; I'm not
saying it's all that hard now, but I mean, make it really, really, easy.

For instance, a mode that shows a graphical representation of the function
keys and their current bindings, and allows the user to trivially change them.
Perhaps by moving the cursor to a function key picture, and hitting SPC/RET
which would make it prompt for a another key-binding, and then copy that to
the function key; while in this special mode, it might even locally rebind
all the function keys so that you could just hit e.g. `F5 C-x C-f' to bind F5
to find-file.

What do you think about this?

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

> A _much_ better idea, I think, would be to make it very simple for even
> novice users to easily _bind_ the function keys to their liking; I'm not
> saying it's all that hard now, but I mean, make it really, really, easy.

I really like this!  Perhaps the following is good enough?

(defcustom key-bindings
  (mapcar
   (lambda (key)
     (cons key (global-key-binding (read-kbd-macro key))))
   '("<f1>" "<f2>" "<f3>" "<f4>" "<f5>" "<f6>" "<f7>" "<f8>" "<f9>"
     "<f10>" "<f11>" "<f12>" ))
  "Customization for keys."
  :type '(repeat
	  (cons :tag "Key" (string :tag "Name") function))
  :set (lambda (sym val)
	 (set-default sym val)
	 (mapc (lambda (bind)
		 (global-set-key (read-kbd-macro (car bind)) (cdr bind)))
	       val)))

(customize-option 'key-bindings)

Alex.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    (defcustom key-bindings
      (mapcar
       (lambda (key)
	 (cons key (global-key-binding (read-kbd-macro key))))
       '("<f1>" "<f2>" "<f3>" "<f4>" "<f5>" "<f6>" "<f7>" "<f8>" "<f9>"
	 "<f10>" "<f11>" "<f12>" ))

This is an interestingly simple approach.  Is there any way to adapt
it to handle more than just function keys?  Really all key bindings
should be controllable with Custom, and I am not sure this method
generalizes that far.

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     (defcustom key-bindings
>       (mapcar
>        (lambda (key)
> 	 (cons key (global-key-binding (read-kbd-macro key))))
>        '("<f1>" "<f2>" "<f3>" "<f4>" "<f5>" "<f6>" "<f7>" "<f8>" "<f9>"
> 	 "<f10>" "<f11>" "<f12>" ))
>
> This is an interestingly simple approach.  Is there any way to adapt
> it to handle more than just function keys?  Really all key bindings
> should be controllable with Custom, and I am not sure this method
> generalizes that far.

It already handles all global bindings.  Just type [ins] and add a new
binding.

The UI can obviously be enhanced, for example with a button to read a
key binding, and some way to display the doc string for the functions.
New 'key-binding' and 'command' widgets for that purpose would be
nice.  But all that can be done incrementally with full backward
compatibility, it is just fiddling with the :type parameter.  Alex'
suggestion, as is, is already useful.

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> It already handles all global bindings.  Just type [ins] and add a new
> binding.

Oops, no, it doesn't, as pressing [del] will not undo the binding.

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > It already handles all global bindings.  Just type [ins] and add a new
> > binding.
> 
> Oops, no, it doesn't, as pressing [del] will not undo the binding.

I think we really want something like

	(defcustom global-map
	  "blabla"
	  :get 'custom-keymap-to-alist
	  :set 'custom-update-keymap-from-alist)

I think it's important that the defcustom declares `global-map'
rather than some new pseudo variable.
And most likely, it'll be important to do the diff-list kind of trick
so that users can enter (and save) additions and removals rather
than editing/saving the whole keymap which will quickly lead
to undesired effects when upgrading (where the user won't ses the
new bindings).


	Stefan

Re: [CVS] f7, f8 bound..

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> And most likely, it'll be important to do the diff-list kind of trick
> so that users can enter (and save) additions and removals rather
> than editing/saving the whole keymap which will quickly lead
> to undesired effects when upgrading (where the user won't ses the
> new bindings).

Another approach could be to have Emacs look for keybindings in
global-user-map before looking in global-map.  The default value for
global-user-map would be nil (or whatever the value is for an empty
keymap).  Then the keymap can just be set directly, and the diff-list
trick is not necessary.

Btw, what is the plan about the diff-list trick?  It seems that
Customize could be augmented to implement this, or numerous places in
Emacs could be changed so that the diff-list trick is not needed: for
each foo-hook, introduce another foo-user-hook variable defaulting to
nil.  Similar for other variables which are lists, such as load-path.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> > And most likely, it'll be important to do the diff-list kind of trick
> > so that users can enter (and save) additions and removals rather
> > than editing/saving the whole keymap which will quickly lead
> > to undesired effects when upgrading (where the user won't ses the
> > new bindings).
> 
> Another approach could be to have Emacs look for keybindings in
> global-user-map before looking in global-map.

I.e. increase the code-size and thus maintenance cost while only
providing a solution for global-map but not for any other map ?
And of course all the code will not to be checked for cases where
it has to be changed to consult global-user-map as well.

> Btw, what is the plan about the diff-list trick?  It seems that
> Customize could be augmented to implement this, or numerous places in
> Emacs could be changed so that the diff-list trick is not needed: for
> each foo-hook, introduce another foo-user-hook variable defaulting to
> nil.  Similar for other variables which are lists, such as load-path.

Sounds like a lot of trouble, compared to solving the problem once
and for all in a centralized place (i.e. where it belongs:
in the customization code).  I think that Alex's diff-list trick
is *much* better.


	Stefan

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

>> Another approach could be to have Emacs look for keybindings in
>> global-user-map before looking in global-map.

Yes, that is what I envisioned.  I used "use-global-map" to simulate
this in the code I posted.

> I.e. increase the code-size and thus maintenance cost while only
> providing a solution for global-map but not for any other map ?

The same solution can be used for all other maps, have a "for
customize only" keymap used by the mode that has the "for Lisp only"
keymap as a parent.

I think such a seperation between Lisp and Customize will be both
simpler and more robust, as the two will never interfere with each
other.  It will also provide full backward compatibility.

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Tue, Sep 03, 2002 at 12:55:03PM +0200, Per Abrahamsen wrote:
> The same solution can be used for all other maps, have a "for
> customize only" keymap used by the mode that has the "for Lisp only"
> keymap as a parent.
> 
> I think such a seperation between Lisp and Customize will be both
> simpler and more robust, as the two will never interfere with each
> other.

It sounds more confusing for the user to have two variables which are `the
same but different' like that.  I think we should be trying to make customize
_more_ of a thin UI layer on top of existing mechanisms, not less.

I think Stefan's exactly right that the _right_ thing to do is something
roughly equivalent to `defcustom global-map'.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

Miles Bader <miles@gnu.org> writes:

> On Tue, Sep 03, 2002 at 12:55:03PM +0200, Per Abrahamsen wrote:
>> The same solution can be used for all other maps, have a "for
>> customize only" keymap used by the mode that has the "for Lisp only"
>> keymap as a parent.
>> 
>> I think such a seperation between Lisp and Customize will be both
>> simpler and more robust, as the two will never interfere with each
>> other.
>
> It sounds more confusing for the user to have two variables which are `the
> same but different' like that.

The user will only see one of them, in this case either "global-map"
if he is a Lisp user, or "Global Key Bindings" if he is a Customize
user. 

If he is both, he really need two different variables, as mixing them
otherwise gives problems, like if you both setq a variable in .emacs
and set it from customize.  With seperate keymaps, he really can do
both, and get a well-defined result.

The only one we risk confusing is the programmer, not the user.  The
programmer will need to understand all three, the variable for
customization, the automatically generated custom keymap, and the
normal keymap.

> I think we should be trying to make customize _more_ of a thin UI
> layer on top of existing mechanisms, not less.

That is a good idea if we believe that the difference between
the customization needs of a programmer and a non-programmer is merely
a matter of syntactic sugar.  

I am more interested in moving the other direction, and focus on
simplicity for the non-programmer, and generality for the programmer.
Emacs is _still_ not really customizable for non-programmers.

And I disagree with the Naggum "the goal of Emacs is to turn people
into Lisp programmers" line.  I don't want Emacs to turn users into
programmers, anymore than I want my car to turn me into an auto
mechanic.

> I think Stefan's exactly right that the _right_ thing to do is something
> roughly equivalent to `defcustom global-map'.

Something like 

  (defkeymap my-mode-map ...)

generating all three for major and minor modes.

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> The only one we risk confusing is the programmer, not the user.  The
> programmer will need to understand all three, the variable for
> customization, the automatically generated custom keymap, and the
> normal keymap.

Sounds like a nightmare!

> > I think we should be trying to make customize _more_ of a thin UI
> > layer on top of existing mechanisms, not less.
> 
> That is a good idea if we believe that the difference between
> the customization needs of a programmer and a non-programmer is merely
> a matter of syntactic sugar.  
> 
> I am more interested in moving the other direction, and focus on
> simplicity for the non-programmer, and generality for the programmer.
> Emacs is _still_ not really customizable for non-programmers.

I want it to be easy to use but I don't want the programmer to
have to do anything extra for it (or as little as possible).
The `defcustom' is a great example of it: to the programmer, it's
just like `defvar', to the user it offers all kinds of benefits.

I'm all in favor of `defkeymap', as long as its use is as simple
(for the programmer) as (defvar foo-mode-map ...).  If done right,
it could be even better than (defvar foo-mode-map ...) just like
`defface' is easier to use for the programmer than a set of
`make-face' and `set-face-foo' calls.


	Stefan

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Tue, Sep 03, 2002 at 03:53:28PM +0200, Per Abrahamsen wrote:
> >> I think such a seperation between Lisp and Customize will be both
> >> simpler and more robust, as the two will never interfere with each
> >> other.
> >
> > It sounds more confusing for the user to have two variables which are `the
> > same but different' like that.
> 
> The user will only see one of them, in this case either "global-map"
> if he is a Lisp user, or "Global Key Bindings" if he is a Customize
> user. 

There really isn't such a clean separation between `Lisp users' and
`Customize users'.  A few people only see the customize interface, but most
will see both variables (since they are both really just variables).
The `Lisp world' is a superset of the customize one.

In the rest of your message you seem to really _wish_ there was such a
separation, but there just isn't, and I don't think we can make one either,
without completely changing emacs (and I don't want to change emacs, I think
it's basically fine, despite some rough edges).

Since there isn't such a separation, pretending there is just confuses
people.

> That is a good idea if we believe that the difference between
> the customization needs of a programmer and a non-programmer is merely
> a matter of syntactic sugar.  

You have to work within the reality of emacs, and in emacs, users can see all
variables.  That doesn't make them `programmers'.

> > I think Stefan's exactly right that the _right_ thing to do is something
> > roughly equivalent to `defcustom global-map'.
> 
> Something like 
>   (defkeymap my-mode-map ...)
> generating all three for major and minor modes.

Well, I'd say a macro like that might be a good idea, but it shouldn't
`generate all three', it should just Do The Right Thing for _one_ keymap.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

|> The `Lisp world' is a superset of the customize one.

This isn't actually true any more.  There are already variables that do
any effect only when set through customize.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Tue, Sep 03, 2002 at 09:27:59PM +0200, Andreas Schwab wrote:
> |> The `Lisp world' is a superset of the customize one.
> 
> This isn't actually true any more.  There are already variables that do
> any effect only when set through customize.

... but they're still visible from lisp, so they still confuse people.

This is actually a good example of a mechanism established for the use of
customize which ends up `dirtying the waters' for people who use anything
more.

-miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Miles Bader]

I wrote:
> This is actually a good example of a mechanism established for the use of
> customize which ends up `dirtying the waters' for people who use anything
> more.

Actually, in retrospect, I think this was a little strong.  As far as I know
such `mode-variables' existed before customize, and all customize did was
make them `active' (and it had little choice, since it tries to be a
declarative interface).

However, making the variables active in customize leads to people thinking
that they are in lisp too.

Customize and lisp share the same namespace, so they have to play nice with
each other.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Robert J. Chassell]

   However, making the variables active in customize leads to people
   thinking that they are in lisp too.

This confuses me.  It suggests that the customize variables are not
part of lisp.  Has something changed while I was not looking?

In my past experience, customize was a front end (a `GUI') that
created lisp expressions for my .emacs file.  Customize was a part of
lisp.  It created lisp expressions that look like this (except that
customize never did such a good pretty printing job, which is a bug in
customize):

    (custom-set-faces
     ;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
     ;; Your init file should contain only one such instance.
     '(Info-title-1-face 
       ((t (:background "darkblue" :foreground "white" :overline nil 
                        :underline nil :slant normal :weight normal 
                        :height 193 :width normal))))
     '(Info-title-2-face 
       ((t (:background "darkblue" :foreground "white" 
                        :underline nil :weight bold 
                        :height 193 :family "misc-fixed"))))
    ....


    (custom-set-variables
     ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
     ;; Your init file should contain only one such instance.
     '(Info-fontify t)
     '(Info-fontify-maximum-menu-size 50000)
     '(Man-notify-method (quote bully))
     '(ange-ftp-default-user "ftp@gnu.org")
     '(baud-rate 38400)
     '(browse-url-browser-function (quote browse-url-galeon) t)
    ....


Sometimes, I edit these expressions, since it is often easier to
figure things out in them than in the various `Customize' interfaces.

As you saying that sometime recently, Emacs introduced a construction
so that these expressions no longer go into my .emacs file (or into
another file that is loaded from .emacs)?  If so, where are they?  How do
I hand edit them?

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: [CVS] f7, f8 bound..

[Alex Schroeder]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> As you saying that sometime recently, Emacs introduced a construction
> so that these expressions no longer go into my .emacs file (or into
> another file that is loaded from .emacs)?  If so, where are they?  How do
> I hand edit them?

It is not yet part of Emacs.  The concept of a diff-list is that a
list has a standard value, and all you want to do is add items or
remove items from the list.  This is important for large lists where
your changes are small in comparison -- complex lists and keymaps come
to mind.

This translates as follows.

Normal variable:

(setq l '(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15))

or use custom to save a setting to a file:

(custom-set-variables ... (l '(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)))


Diff List:

(add-to-list 'l 16)
(setq l (delete 4 l))

or use custom to save it:

(custom-set-variables ... (l '(diff-list (16) (4))))


I think this representation works pretty well for me.  You might have
problems, if you think about it as follows:

(setq l '(1 2 3 5 6 7 8 9 10 11 12 13 14 15 16))

is saved by custom as

(custom-set-variables ... (l '(diff-list (16) (4))))

If you think that custom-set-variables just represents a set of setq
statements, then you will be confused.

What is the benefit, you might ask.

Well, 1. we might save space in the file where the customizations are
saved, since we do not need to copy them there, and 2. the
customization will make sense even when the standard-value of a list
has changed.  Again, the example is Gnus.  Assume you have a list of
MIME types.  You want to remove text/html and add picture/jpeg.  If
the new Gnus adds signature/gpg as a MIME type, only the diff-list
solution will produce a value that contains the new signature/gpg
type, as well as picture/jpeg added by the user, and lacking text/html
removed by the user.

Ok, enough for today.  :)

Alex.

Re: [CVS] f7, f8 bound..

[Robert J. Chassell]

   |> The `Lisp world' is a superset of the customize one.

   This isn't actually true any more.  There are already variables that do
   any effect only when set through customize.

Hmmm.... I occasionally use Customize (mainly for faces, which I do
really not understand) and I use setq, and also, I hand edit the
expressions that Customize inserts in my .emacs file.

Please, arrange that customize and everything else work with just
*one* variable.  Not two.  Otherwise, you will make maintenance much
harder.  Thank you.

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Hmmm.... I occasionally use Customize (mainly for faces, which I do
> really not understand) and I use setq, and also, I hand edit the
> expressions that Customize inserts in my .emacs file.

With either Alex or my code, what is saved to the .emacs file will
look nothing like what you would write by hand.  You can still edit
it, though.

> Please, arrange that customize and everything else work with just
> *one* variable.  Not two.  Otherwise, you will make maintenance much
> harder.  Thank you.

I believe maintenance will be much harder with one variable that tries
to do everything, rather than two variables with clearly identified
purposes.

Example:

foo-mode.el:  Defines foo-mode-map.
foo-extra.el: Defines some new bindings for foo-mode-map.

With Alex current code, the foo-extra bindings will be removed each
time the user make any changes to his own bindings.

We could change Alex' code to remember the old user bindings, but then
the result will depend on whether the user bindings were were made
before or after foo-extra.el was loaded, and if the standard bindings
change in foo-mode.el, removing the user bindings will give you the
old binding, with the risk of weird errors.

We may be able to overcome these problems, or choose to ignore them,
but in either case I believe the end result will be much more complex
than simply having two keymaps, one for customize, and one for Lisp.

We don't need the extra non-keymap variable, Alex code use a symbol
property instead, which should work just as well.  Only customize have
an interest in that value, so there is no problem hiding it that way.

We _can_ also use a property for the customize keymap, but since that
is the map the mode need to enable (with use-local-mode), it will have
to know about it.

Re: [CVS] f7, f8 bound..

[Robert J. Chassell]

   > Please, arrange that customize and everything else work with just
   > *one* variable.  Not two.  Otherwise, you will make maintenance much
   > harder.  Thank you.

   I believe maintenance will be much harder with one variable that tries
   to do everything, rather than two variables with clearly identified
   purposes.

I wrote badly.  I meant to say, please do not create two different
systems to do the same thing.

    ... what is saved to the .emacs file will look nothing like what
    you would write by hand.  You can still edit it, though.

Please use nice `pretty printing' for expressions.  Even if they are
edited only by some people, they certainly should be easy to study.

(Incidentally, my .emacs file actually contains the statement:

  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!

which is entirely contrary to the principles of freedom: it says do
not modify, do not share!  What a bug!  If you work on this, please
fix this bug.)

   We don't need the extra non-keymap variable, Alex code use a symbol
   property instead, which should work just as well.  Only customize have
   an interest in that value, so there is no problem hiding it that way.

You confuse me:  Suppose I set something with a setq and then, either
earlier or later in my .emacs file, a customize statement sets a
symbol property that has the same effect as my setq -- this means I
have to think both about binding variables and symbol properties.
Why?

What mental model is leading you to think that two different kinds of
expression are a good idea?  Or am I misunderstanding you.

Or are you thinking that people who use Customize are too ignorant to
ever want to share or learn about Emacs?  Are you figuring that these
people should be given a low grade, not for hackers, way to set
values?  Are you thinking that hackers will never want to use
Customize, even for setting things for which they think Customize is
useful?


It makes more sense to me to write a backend to the Customize GUI that
generates a readable .emacs file that people can study, modify, and
share, if they wish.  (This reminds me of the since removed program
that converted keyboard macros into Emacs Lisp defuns, rather than as
currently, creating fset expressions.)

The goal for Customize should be to generate easy-to-understand Emacs
Lisp expressions and pretty print them nicely (to fit within a 70
character wide display, or other fill-column value, in your .emacs
file).

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: [CVS] f7, f8 bound..

[Alex Schroeder]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> You confuse me:  Suppose I set something with a setq and then, either
> earlier or later in my .emacs file, a customize statement sets a
> symbol property that has the same effect as my setq -- this means I
> have to think both about binding variables and symbol properties.
> Why?
>
> What mental model is leading you to think that two different kinds of
> expression are a good idea?  Or am I misunderstanding you.

The mental model I use is that custom and setq both change the values
of variables.  This leads to confusion if you use either more than
once -- because now order of evaluation is important.  This is true
for two setq, too.

The mental model does not say that the actual lisp expressions, must
be similar.  Often they are; sometimes they are not.  Custom is very
powerful.  When custom sets variables, it can do all kinds of funky
stuff:  The simplest example is perhaps this:

(defcustom whitespace-global-mode nil
  "Toggle global Whitespace mode.

Setting this variable directly does not take effect;
use either \\[customize] or the function `whitespace-global-mode'
\(which see)."
  :set (lambda (sym val)
	 (whitespace-global-mode (or val 0)))
  :initialize 'custom-initialize-default
  :type 'boolean
  :group 'whitespace
  :require 'whitespace)

Setting this variable via custom (such as when loading the
customizations at startup) will call the function
whitespace-global-mode.

Obviously a mental model that tries to understand custom on the basis
of setq is too limited to capture this.

My code does something else:

When you call defkeymap with a default value, the variable is set to
the default value.  Custom, however, saves only the *additions* to the
file.  This, because we don't want to save the entire global-map to
.emacs if the user adds a single keybinding, for example.

From this stance, having a variable with the standard value and
another variable with the additions for custom continues to fit the
mental model.

Hope that helps.

As to pretty printing and sharing -- that would indeed be nice, and
would not involve fancy tricks.  You could, for example, split the one
call to custom-set-variables into one call per variable.  The
simplicity of the current approach is saving:  You only need to search
for the one and only sexp that starts with custom-set-variables, and
replace it.  Finding all individual new custom-set-variable
statements, deleting them, and writing another set, opens the door to
lots of bugs.  Example (schematically):

Currently we use one sexp:

(custom-set-variables ((a 1) (b 2)))

If we explicitly allow (from a tech point of view!) the pasting and
copying, we'd have something like this:

(custom-set-variable a 1)
(custom-set-variable b 2)

But what do we do in this case:

(custom-set-variable a 1)
(when foo
  (custom-set-variable b 2))

We can easily find all the sexps and delete them.  But where do we
write the new customizations:  At the point of the first or the last
sexp we deleted?

Furthermore, assume when we save variables that -- when set -- should
enable a global minor mode.  We *could* save these commands as
required ("the Customize GUI that generates a readable .emacs file
that people can study, modify, and share, if they wish" -- perhaps
that translates to "lisp code similar to what i would write by hand").
Well, in that case we get into the kinds of problems lots of code
wizards get into:  We cannot eat the dogfood we write to files.

So discouraging people from manually fiddling with the save-file helps
us reduce the number of potential bugs.  We could now improve this
saving, or provide functions to import and export settings -- but I
for one do not care too much for it.

> Or are you thinking that people who use Customize are too ignorant
> to ever want to share or learn about Emacs?  Are you figuring that
> these people should be given a low grade, not for hackers, way to
> set values?  Are you thinking that hackers will never want to use
> Customize, even for setting things for which they think Customize is
> useful?

I do not understand the questions.  Is this sarcasm?  Sorry, English
is my third language.  Yes, sometimes custom is the right thing for
people that want to customize Emacs without learning lisp.  Sometimes
custom is the right thing for hackers that do not want to spend too
much time thinking about the complex datastructures they want to
modify (as one might see in Gnus, for example).  So all the options
you offer seem to be pretty narrow.

Personally, I do not use custom anymore at home, but I still use it
regularly at work.

Alex.

Re: [CVS] f7, f8 bound..

[Robert J. Chassell]

Thank you for the explanation.  This helps!

   When you call defkeymap with a default value, the variable is set to
   the default value.  Custom, however, saves only the *additions* ...

This is a wonderful tool, but it is named wrongly.  If I understand
you rightly, its name should be something like:

    custom-add-delete

and its documentation should say something like this (but better):

    `custom-add-delete' saves only changes; it adds or deletes values.
    In contrast to `setq', this is a destructive function, like `set'

Then as an example you might show (where ==> means, `evaluates to'):

    (setq foovar '(a . 1))
    (custom-set-variable b 2)
    foovar     ==> ((a . 1) (b . 2))

    (custom-set-variable b nil)
    foovar     ==> ((a . 1))


You say:

   ... ("the Customize GUI that generates a readable .emacs file
   that people can study, modify, and share, if they wish" -- perhaps
   that translates to "lisp code similar to what i would write by hand").

Yes, that is a way of translating it.  What I am trying to say is that
we should be able to understand the code fairly readily.

   Well, in that case we get into the kinds of problems lots of code
   wizards get into:  We cannot eat the dogfood we write to files.

This is the wrong way to think about computers or software.  After
all, many /etc/ configuration files are created or modified
automatically; but you want to be able to read and edit them, right?

Similarly, Emacs is designed to be easily modifiable, more easily
understood and worked with than most programs.  We should continue
this.

   So discouraging people from manually fiddling with the save-file helps
   us reduce the number of potential bugs.  

On the contrary, we should encourage people to try things out, to
learn.  That is the only way they will become better.

Of course, that takes good design, so that novices do not get
themselves into bad trouble.  Novices need to learn that they can
always start a plain vanilla instance of Emacs; and even more
important, they need to learn how to return to the state their already
modified Emacs was in before they changed it in ways they dislike.

The idea that that `custom-add-delete' should simply add or delete a
customization, is good design.  It means that a novice can focus on
just the change he or she wants to make, and be sure it works.

And again, I want to say that some way to remember history, or tell
people about existing history -- how to return to the state they were
in, before screwing up! -- that is important, too.

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Even if they are edited only by some people, they certainly should
> be easy to study.

No, they should not.

> (Incidentally, my .emacs file actually contains the statement:
>
>   ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
>
> which is entirely contrary to the principles of freedom: it says do
> not modify, do not share!  What a bug!  If you work on this, please
> fix this bug.)

It is hard to share, the themes code is suppsoed to be the fix for
that bug.

Your freedom is not affected, it is a warning that the code is
automatically generated, such code exists in all free software
projects.  You should not edit configure in Emacs, instead edit
configure.in.  It is plain common sense not to edit automatically
generated code, something all programmers learn sooner or later.

> You confuse me:  Suppose I set something with a setq and then, either
> earlier or later in my .emacs file, a customize statement sets a
> symbol property that has the same effect as my setq -- this means I
> have to think both about binding variables and symbol properties.

Don't do that.

> Or are you thinking that people who use Customize are too ignorant to
> ever want to share or learn about Emacs?  

No, but they should read _Introduction to Emacs Lisp_ if, and only if,
they want to learn Emacs Lisp.  They should not expect Customize to
teach them Lisp.  It is hard enough to make a customization fascility
intuitive without at the same time trying to teach the users a
programming language.

> Are you figuring that these people should be given a low grade, not
> for hackers, way to set values?

Customize should not be low grade.

> Are you thinking that hackers will never want to use
> Customize, even for setting things for which they think Customize is
> useful?

No, but they should be smart enough not to set the same variables from
both Lisp and Customize.

> It makes more sense to me to write a backend to the Customize GUI that
> generates a readable .emacs file that people can study, modify, and
> share, if they wish. 

Feel free to do that.  But be sure that you do not diminish the
front-end at the process.

> The goal for Customize should be to generate easy-to-understand Emacs
> Lisp expressions and pretty print them nicely (to fit within a 70
> character wide display, or other fill-column value, in your .emacs
> file).

Oh, that is easy.  

    (fset 'customize 'emacs-lisp-mode)

Done.

I believe the goal of customize should be to make Emacs easy to
customize for non-programmers.

Re: [CVS] f7, f8 bound..

[Robert J. Chassell]

    It is plain common sense not to edit automatically generated code,
    something all programmers learn sooner or later.

I do not understand your mental model of a person who uses Emacs.

This is code in my .emacs file.  I should be able to understand and
edit my .emacs file.  After all, I do want both to understand and to
configure Emacs to my liking.  Moreover, as I said, sometimes it is
much easier for me to edit my .emacs file than to run Customize.

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

       It is plain common sense not to edit automatically generated code,
       something all programmers learn sooner or later.
   
   I do not understand your mental model of a person who uses Emacs.

Unfortunately the above statement is true, independent of Emacs.

I have this just the beginnig of my .emacs:

(setq custom-file "~/.emacs.d/custom.el")
(load custom-file t t t)

This make custom write somewhere else nad not pollute my .emacs, and
allows me to override its settings, because its settings are loaded
first. 

I think that this should be the *default* behaviour of customise, and
that it should never touch the user's .emacs.

However, my solution is just hiding the problem you mention, I fear.

Re: [CVS] f7, f8 bound..

[D. Goel]

> I have this just the beginnig of my .emacs:
> 
> (setq custom-file "~/.emacs.d/custom.el")

Thank you!   I have been looking for a way for custom to leave my
.emacs alone for a long time :), currently, i use kludges like

alias ed 'emacs -q -l .emacs.editor' <-- but "-q" leads to other
						problems..


> I think that this should be the *default* behaviour of customise, and
> that it should never touch the user's .emacs.

I second that :) .. custom should save changes in some other file, and
simply advise the user to (load) that file in the .emacs.  

.emacs is the default file loaded by emacs, and there's no good way to
change that, except the (other problems) -q option... therefore, imho,
custom should not touch .emacs ..




DG                                 http://24.197.159.102/~deego/
--
RIAA logic applied to cars--->
http://www.bbspot.com/News/2002/08/ride_sharing.html

Re: [CVS] f7, f8 bound..

[Robert J. Chassell]

    [people who use Customize] should read _Introduction to Emacs
    Lisp_ if, and only if, they want to learn Emacs Lisp.  They should
    not expect Customize to teach them Lisp.

But I am not suggesting that Customize teach Lisp.

What I am saying is that *if* the person who is using Customize also
knows some Lisp, then it makes sense that the person should be able to
modify that code in his .emacs file, if he wants.  And he should be
able to look at the `custom-set-faces' or `custom-set-variables'
expressions and figure out how to work with them.

If he is not interested in Lisp, then he does not study or modify the
code in his .emacs file.

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    It makes more sense to me to write a backend to the Customize GUI that
    generates a readable .emacs file that people can study, modify, and
    share, if they wish.

I agree, this would be desirable.  Pretty-printing the forms
might be a good idea.

      ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!

    which is entirely contrary to the principles of freedom: it says do
    not modify, do not share!

This is meant as a warning; I'm surprised you took it as an order.
I will make that comment longer and clearer.

Re: [CVS] f7, f8 bound..

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> We could change Alex' code to remember the old user bindings, but then
> the result will depend on whether the user bindings were were made
> before or after foo-extra.el was loaded, and if the standard bindings
> change in foo-mode.el, removing the user bindings will give you the
> old binding, with the risk of weird errors.

Good point.  I am not sure how we should proceed.

Generally I feel like taking the pragmatic approach:  Let us use the
solution that fits 80% of the problems.  This will give us users, and
these will in turn contribute to hopefully fix the remaining problems.

Alex.

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> Generally I feel like taking the pragmatic approach:  Let us use the
> solution that fits 80% of the problems.  This will give us users, and
> these will in turn contribute to hopefully fix the remaining problems.

Since two keymaps 100% solution is not an option, I believe we should
just use your code as is.  We might get a 90% solution by various
hacks, but I think this would just make the rules more confusing.

With your code, the rules are simle:  If you change a keymap with
customize, all other changes are lost.  With such a simple rule, the
rest of the world can comply.  I.e. the user should put no define-key
for the map in his .emacs, and foo-extra.el should be reimplemented as
a minor mode instead.  

Re: [CVS] f7, f8 bound..

[Miles Bader]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > Generally I feel like taking the pragmatic approach:  Let us use the
> > solution that fits 80% of the problems.  This will give us users, and
> > these will in turn contribute to hopefully fix the remaining problems.
> 
> Since two keymaps 100% solution is not an option, I believe we should
> just use your code as is.  We might get a 90% solution by various
> hacks, but I think this would just make the rules more confusing.

`Two keymaps' is not a 100% solution.  There are going to the problems
no matter which solution we pick.

> With your code, the rules are simle:  If you change a keymap with
> customize, all other changes are lost.  With such a simple rule, the
> rest of the world can comply.

That's obviously a simple rule, but it's also silly and bad; if that's
what the current code does, then it's not usable.

Your two variable solution has a similar problem, BTW -- if
e.g. `custom-global-map' overrides `global-map', and someone has bound a
key via custom, and tries to re-bind it using `M-x global-set-key' --
then his new binding will be effectively ignored!

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
>> With your code, the rules are simle:  If you change a keymap with
>> customize, all other changes are lost.  With such a simple rule, the
>> rest of the world can comply.
>
> That's obviously a simple rule, but it's also silly and bad; if that's
> what the current code does, then it's not usable.

Why "not usable"?  

It seems a lot better than what we have now, which is nothing.

Well, it is not usable for the global map, too many packages write to
that, but packages writing directly to mode maps aren't that common.
For the global map, maybe we can get dispensation to use two keymaps.

> Your two variable solution has a similar problem, BTW -- if
> e.g. `custom-global-map' overrides `global-map', and someone has bound a
> key via custom, and tries to re-bind it using `M-x global-set-key' --
> then his new binding will be effectively ignored!

True, I haven't though of using non-customize functions interactively.
They would have had to be modified in order to make the two keymap
solution a 100% solution.  I believe there are very few of those
commands.  This is similar to how Stefan made the global minor mode
function customize aware.

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Fri, Sep 06, 2002 at 12:07:51PM +0200, Per Abrahamsen wrote:
> >> With your code, the rules are simle:  If you change a keymap with
> >> customize, all other changes are lost.  With such a simple rule, the
> >> rest of the world can comply.
> >
> > That's obviously a simple rule, but it's also silly and bad; if that's
> > what the current code does, then it's not usable.
> 
> Why "not usable"?  

Because it's `brittle', and makes customize incompatible with with
non-customize use, which is something we want to avoid (well, maybe you don't
want to avoid it, but I do).

The way keymaps are handled, traditionally, is via incremental modification,
not simply `setting' them, and customize should be no different.

In any case, it doesn't really seem that hard to do better -- customize
should only ever add or remove entries from keymaps, not `set the keymap,'
and it should keep track of which ones it did, and only save those when
saving.  One way to do this is just have an alist of (MAP-VAR ADDED DEL'D)
entries (where ADDED and DEL'D are lists of keys).

> Well, it is not usable for the global map, too many packages write to
> that, but packages writing directly to mode maps aren't that common.

The problem is not `packages writing to mode maps,' it's _users_.

Many people set keybindings in mode hooks and the like; sometimes they've
copied that code from other people and don't really understand it.  The
`trash everything' approach obviously messes this up.

The `incremental' approach I mention above is much kinder.

> For the global map, maybe we can get dispensation to use two keymaps.

Not if I can help it.

> > Your two variable solution has a similar problem, BTW -- if
> > e.g. `custom-global-map' overrides `global-map', and someone has bound a
> > key via custom, and tries to re-bind it using `M-x global-set-key' --
> > then his new binding will be effectively ignored!
> 
> True, I haven't though of using non-customize functions interactively.
> They would have had to be modified in order to make the two keymap
> solution a 100% solution.

Are you suggesting they modify the customize keymap too?  In other words all
commands modify _one_ keymap?  In that case you're basically using one
keymap, so why not drop the pretense, and just use one for real?

[Maybe you're suggesting that interactive and `non-interactive' (e.g. invoked
by `M-:') uses of global-set-key work differently, but I think that's
unacceptable.]

The more I think about it, the more I think the two keymap solution is
confusing, both to programmers _and_ users, and that an incremental one
keymap solution (see above) is what we should use.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

Miles Bader <miles@gnu.org> writes:

> The way keymaps are handled, traditionally, is via incremental modification,
> not simply `setting' them, and customize should be no different.

Is there a reason customize should not be different?

> In any case, it doesn't really seem that hard to do better -- customize
> should only ever add or remove entries from keymaps, not `set the keymap,'
> and it should keep track of which ones it did, and only save those when
> saving.  One way to do this is just have an alist of (MAP-VAR ADDED DEL'D)
> entries (where ADDED and DEL'D are lists of keys).

That is what Alex' code does.

What do you suggest it should do when the user remove an ADDED item?

> Many people set keybindings in mode hooks and the like; sometimes they've
> copied that code from other people and don't really understand it.  The
> `trash everything' approach obviously messes this up.

But in an obvious way.  Alex new code does so in an non-obvious way.

When you remove an ADDED item, the value last seen by customize is
restored.  What that value is depend on timing, i.e. whan any Lisp
level changes (from hooks or whatever) have been done.  Before or
after the last change?

> [Maybe you're suggesting that interactive and `non-interactive' (e.g. invoked
> by `M-:') uses of global-set-key work differently, but I think that's
> unacceptable.]

Yes.  That is what Stefan have implemented for global minor modes.

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> > Generally I feel like taking the pragmatic approach:  Let us use the
> > solution that fits 80% of the problems.  This will give us users, and
> > these will in turn contribute to hopefully fix the remaining problems.
> 
> Since two keymaps 100% solution is not an option, I believe we should
> just use your code as is.  We might get a 90% solution by various
> hacks, but I think this would just make the rules more confusing.
> 
> With your code, the rules are simle:  If you change a keymap with
> customize, all other changes are lost.

This doesn't have to be the case.  The custom info can simply
keep track of "what the user added with custom" and "what the user
removed with custom" and custom-set-variable would simply take the
current map and add/remove the corresponding entries.
So changes made outside of custom would only be clobbered if they
conflict, which I think is not too confusing and even somewhat
intuitive.
I don't think creating a whole new map is a good idea anyway
since the map might already be used somewhere and updating the
variable will not update the already active major-mode maps.


	Stefan

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Fri, Sep 06, 2002 at 01:36:13PM -0400, Stefan Monnier wrote:
> > With your code, the rules are simle:  If you change a keymap with
> > customize, all other changes are lost.
> 
> This doesn't have to be the case.  The custom info can simply keep track of
> "what the user added with custom" and "what the user removed with custom"
> and custom-set-variable would simply take the current map and add/remove
> the corresponding entries.  So changes made outside of custom would only be
> clobbered if they conflict, which I think is not too confusing and even
> somewhat intuitive.

I completely agree:  this is the way we should do it.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Fri, Sep 06, 2002 at 01:36:13PM -0400, Stefan Monnier wrote:
> > > With your code, the rules are simle:  If you change a keymap with
> > > customize, all other changes are lost.
> > 
> > This doesn't have to be the case.  The custom info can simply keep track of
> > "what the user added with custom" and "what the user removed with custom"
> > and custom-set-variable would simply take the current map and add/remove
> > the corresponding entries.  So changes made outside of custom would only be
> > clobbered if they conflict, which I think is not too confusing and even
> > somewhat intuitive.
> 
> I completely agree:  this is the way we should do it.

Me too.

But what's does it mean to delete a key binding?

Is it the same as adding a keybinding with command = nil,
effectively removing any binding of the key ?

Or should it restore a default key binding from bindings.el ?

Or is it a combination of the two -  if the current key binding
is set from custom, deleting means: remove the custom binding and
restore the default binding; otherwise, remove the default binding.

I think the last interpretation is the most flexible...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Sat, Sep 07, 2002 at 02:53:36AM +0200, Kim F. Storm wrote:
> But what's does it mean to delete a key binding?

I interepret it as `remove the binding from this map' -- in other words, if
it's global-map, you probably get an unbound error, but if it's some mode
map, it probably results in the global binding showing through (this is
important, become some modes define really annoying local bindings).

In other words an `active delete'.  In customize's saved-state in the startup
files, this would be represented by an entry saying `remove this key from
this map'.

That's distinct from the operation of restoring the default binding -- this
is something that probably would be merely a user-interface operation.  This
wouldn't be represented in the saved-state at all (other than by the asbsence
of any binding or binding-deletion for a key, thus ensuring the default gets
used).

I guess maybe your point was -- we gotta stash the default bindings somewhere
so that customize can know what to restore...

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

> I interepret it as `remove the binding from this map' -- in other words, if
> it's global-map, you probably get an unbound error, but if it's some mode
> map, it probably results in the global binding showing through (this is
> important, become some modes define really annoying local bindings).

Good point.  I will try something like that.

Alex.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    But what's does it mean to delete a key binding?

    Is it the same as adding a keybinding with command = nil,
    effectively removing any binding of the key ?

Yes.

    Or should it restore a default key binding from bindings.el ?

No, that binding is (probably) what you deleted.

    Or is it a combination of the two -  if the current key binding
    is set from custom, deleting means: remove the custom binding and
    restore the default binding; otherwise, remove the default binding.

The first is deleting a customization; the second is adding a
customization to delete a binding.  Those are completely different
operations.

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> But what's does it mean to delete a key binding?

Right now, I think we can assume it's "defined" by the definition
of global-unset-key (which indeed binds the key to nil).

> Or should it restore a default key binding from bindings.el ?

Huh?  We're talking about "any random keymap", so there's no reason
why it should have any relationship with bindings.el.
For one, the keymap might never be used directly (see vc-prefix-map
for an example which is only ever used after the C-x v prefix).

> Or is it a combination of the two -  if the current key binding
> is set from custom, deleting means: remove the custom binding and
> restore the default binding; otherwise, remove the default binding.

I think you're thinking about "what if the user drops a change?"
(either an addition or a removal).  In that case, we might indeed
want to reset the binding to what it was before custom started
to mess with the map.
That's indeed the main difficulty.  Per's solution is to either
rebuild the whole keymap each time (which requires saving its
original value somewhere) or use two maps.
The "two maps" approach is a possibility.
Basically, the idea is to keep the original map as the parent
of the actual map.  So when custom changes the map, it does:

	(let ((orig (keymap-parent map)))
	  (setq map (make-sparse-keymap))
	  (set-keymap-parent map orig)
          ...add/remove bindings...)

The problem is that any changes made to `map' rather than to its parent
are lost without regards to whether the changes were made by custom or not.


	Stefan

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Per's solution is to either
> rebuild the whole keymap each time (which requires saving its
> original value somewhere) 

That was Alex' original proposal (through code), not mine.

His latest code remembers the old value, which works well enough for
the vast majority of cases.

> The "two maps" approach is a possibility.
>
> Basically, the idea is to keep the original map as the parent
> of the actual map.  So when custom changes the map, it does:
>
> 	(let ((orig (keymap-parent map)))
> 	  (setq map (make-sparse-keymap))
> 	  (set-keymap-parent map orig)
>           ...add/remove bindings...)
>
> The problem is that any changes made to `map' rather than to its parent
> are lost without regards to whether the changes were made by custom or not.

Which is why the DOC string said "Automatically created by customize,
do not touch." (or something like that).

Miles' current idea is to build this into a rather low level
via. define-key and friends, which will allow the two keymaps to be
invisible to both the user and all applications except customize.

I believe Alex current code is se much better than the status quo that
I'd hate to see it rejected because of an even better paper solution.
Also, as far as I can see, we should be able to replace Alex code with
a "define-key" solution at any time someone implements it, with no
changes in the programmer interface.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    > But what's does it mean to delete a key binding?

    Right now, I think we can assume it's "defined" by the definition
    of global-unset-key (which indeed binds the key to nil).

    > Or should it restore a default key binding from bindings.el ?

I am afraid that the confusion I tried to clear up last weekend
is striking again.  We need to distinguish between

(1) deleting a key binding customization, and
(2) deleting a binding in a keymap.

Telling Custom that you want to do delete a global binding (if we
provide a way to do this) is actually adding a customization.
Deleting a customization is (1); it may or may not be (2).

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    > This doesn't have to be the case.  The custom info can simply keep track of
    > "what the user added with custom" and "what the user removed with custom"
    > and custom-set-variable would simply take the current map and add/remove
    > the corresponding entries.  So changes made outside of custom would only be
    > clobbered if they conflict, which I think is not too confusing and even
    > somewhat intuitive.

I agree with this.

This can be done using one keymap, or using two keymaps internally.

Re: [CVS] f7, f8 bound..

[Alex Schroeder]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> This doesn't have to be the case.  The custom info can simply
> keep track of "what the user added with custom" and "what the user
> removed with custom" and custom-set-variable would simply take the
> current map and add/remove the corresponding entries.
> So changes made outside of custom would only be clobbered if they
> conflict, which I think is not too confusing and even somewhat
> intuitive.

I think we do not have to worry about the default keybindings a user
might want to remove.  Adding key bindings should be enough.  The way
I see it, we can write code that allows the user to add bindings, and
remove them.  The only problem is that when a user does that, the old
(default) binding of a key will not reappear.  It will reappear the
next time Emacs gets started, but not during the current session.  Hm.
Unless we save the old binding somewhere.  I will try to write
something that does this.

> I don't think creating a whole new map is a good idea anyway
> since the map might already be used somewhere and updating the
> variable will not update the already active major-mode maps.

I would like that, too -- and without modifying define-key and
friends.

Alex.

Re: Customizing key bindings

[Alex Schroeder]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> This doesn't have to be the case.  The custom info can simply
> keep track of "what the user added with custom" and "what the user
> removed with custom" and custom-set-variable would simply take the
> current map and add/remove the corresponding entries.

Hm, but while we are in the same session, potential bug remain (the
ones that Per keeps talking about).

1. Load foo.el which uses defkeymap to create a keymap with binding A
   for one key.
2. Customize the keymap with binding B for the same key.  The shadowed
   binding A is saved.
3. Load foo-extra or call a hook that uses define-key to change the
   binding for the same key to C.
4. Customize the keymap.  I think it is ok to see binding C, because
   after all that is what happens to variables as well.  The problem
   is that when the user removes the binding for that key, we revert
   to binding A, instead of B.

We solved one particular problem which would have been solved with all
the other approaches as well.  When the original keybindings in the
source (defkeymap) get improved, the user benefits at all times.  So
that is not the benefit of the current solution, that is a benefit of
all solutions.

We had a solution using two variables instead of one, which was
considered a drawback.  In step 4, however, this two-variable solution
would have reverted to binding B.  This is what Per calls the 100%
solution.

I actually think that this last step to 100% is not really required,
so I am happy with the current code I posted.

Alex.

Re: Customizing key bindings

[Miles Bader]

On Sat, Sep 07, 2002 at 04:08:59PM +0200, Alex Schroeder wrote:
> Hm, but while we are in the same session, potential bug remain (the
> ones that Per keeps talking about).
> 
> 1. Load foo.el which uses defkeymap to create a keymap with binding A
>    for one key.
> 2. Customize the keymap with binding B for the same key.  The shadowed
>    binding A is saved.
> 3. Load foo-extra or call a hook that uses define-key to change the
>    binding for the same key to C.
> 4. Customize the keymap.  I think it is ok to see binding C, because
>    after all that is what happens to variables as well.  The problem
>    is that when the user removes the binding for that key, we revert
>    to binding A, instead of B.
...
> We had a solution using two variables instead of one, which was
> considered a drawback.  In step 4, however, this two-variable solution
> would have reverted to binding B.

The above situation seems rather silly (and unlikely); if `foo-extra' screws
around like that, then I don't think we should expect custom to intuit what
the right thing to do is.  If a hook overrode the binding, on the other hand,
then I think restoring to A is the _right_ thing to do (the custom command is
probably `restore to original setting').

> This is what Per calls the 100% solution.

... which is a misnomer, since it's not really `100%', just 90% with a
different 10% cut out.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Customizing key bindings

[Per Abrahamsen]

Miles Bader <miles@gnu.org> writes:

> The above situation seems rather silly (and unlikely); if `foo-extra' screws
> around like that, then I don't think we should expect custom to intuit what
> the right thing to do is. 

Such packages are common for "global-map".

> If a hook overrode the binding, on the other hand,
> then I think restoring to A is the _right_ thing to do (the custom command is
> probably `restore to original setting').

It will be timing dependent what the "remove user binding" command
will restore.

> ... which is a misnomer, since it's not really `100%', just 90% with a
> different 10% cut out.

As you pointed out, it would require a "when (interactive-p)" added to
global-(un)set-key and local-(un)set-key to be a 100% solution.

Re: Customizing key bindings

[Miles Bader]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > The above situation seems rather silly (and unlikely); if `foo-extra' screws
> > around like that, then I don't think we should expect custom to intuit what
> > the right thing to do is. 
> 
> Such packages are common for "global-map".

My first reaction was to say `true', but now that I think about it, are they?

The usual way that global bindings are established is to bind the key
ahead of time (often via ###autoload), and autoload the package when
the binding is first invoked.  In those cases, the `default binding' is
established ahead of time, so customize will find it.

One exception is e.g., gdb-mode (with its `C-x C-a' prefix bindings).

> > ... which is a misnomer, since it's not really `100%', just 90% with a
> > different 10% cut out.
> 
> As you pointed out, it would require a "when (interactive-p)" added to
> global-(un)set-key and local-(un)set-key to be a 100% solution.

The truth is that to really be 100%, you have to read the users mind,
and we (sadly) can't do that.

Non-trival differences in behavior based on (interactive-p) are
something that make me nervous.

For example, someone has a bunch of (global-set-key ...) forms in his
.emacs file, and notices some binding isn't as he wants it, so he does
`eval-region' on them.  Or he has a hook set up some bindings.  In both
cases, if they're shadowed by customize bindings, they act as if they
don't exist, no matter how many times he evaluates them.

On the other hand, the case that you cite is that when a package is
loaded, it shouldn't override a customized binding (though I expect
there are some occasions that users will think it should), and that if
the user undoes his customization, he should get the last-executed
`traditional' binding.


If I can try to restate what you said, it seems to be:

   [a] customize-bindings override traditional bindings (with
       interactive uses of `global-set-key' granted honorary customize
       status)
        
   [b] traditional (define-key, etc) bindings provide the value for
       `restore default' in customize

(and within each category, `customize' and `traditional', the most
recent definition always supersedes previous ones)


What seem better to me is this:

   [a] _user_ bindings override non-user bindings

   [b] non-user bindings provide the value for `restore default'

(with the same time-ordering within each category)

Where `user' is fuzzily defined to be `something the user did, not a package.'

So is there a definition of `user' that's easy to implement?  I'm not
sure, maybe something like `not defined while loading a file'.  That
would catch customize, M-x global-set-key, M-: (global-set-key ...),
hooks, eval-region, etc.  It would also mean that bindings established
in .emacs are `non-user' which may be good or bad, but maybe it could be
made be an exception to the loading-files test.

Note that this sort of test could be done entirely within `define-key',
and wouldn't have to distinguish between customization and other uses.

It's possible to implement this either as a nested set of keymaps (like
you use), where the decision whether to use a `user' or `default'
binding is made at key-lookup time, or to simply stash the default
bindings in a different keymap for use by customize and also put them in
the real keymap when appropriate.


Another question is `if there the implementation uses two keymaps
(either for nesting at lookup time, or just for bookkeeping purposes),
where is the second one stored?'  I really dislike your idea of having
two separate lisp variable to store them.  It oughtn't even be necessary
to know the name of a keymap to find its associated `2nd keymap',
especially when more than just customize is looking at them.

Is it possible to stash the `2nd keymap' within the primary keymap
directly?  Alternatively, there could be a global alist mapping primary
keymaps (note, _not_ variable names) to 2ndary keymaps.

-Miles

Re: Customizing key bindings

[Per Abrahamsen]

Miles Bader <miles@lsi.nec.co.jp> writes:

> The usual way that global bindings are established is to bind the key
> ahead of time (often via ###autoload), and autoload the package when
> the binding is first invoked.  In those cases, the `default binding' is
> established ahead of time, so customize will find it.

Only for bundled packages.  

> Non-trival differences in behavior based on (interactive-p) are
> something that make me nervous.

Me too, but nobody protested when Stefan added such functionality to
define-minor-mode, so I presumed it was an acceptable solution.

> If I can try to restate what you said, it seems to be:
>
>    [a] customize-bindings override traditional bindings (with
>        interactive uses of `global-set-key' granted honorary customize
>        status)
>         
>    [b] traditional (define-key, etc) bindings provide the value for
>        `restore default' in customize
>
> (and within each category, `customize' and `traditional', the most
> recent definition always supersedes previous ones)

Yes.  I find this this simple and intuitive.

> So is there a definition of `user' that's easy to implement? 

I define "user" to be someone who use the interactive fascilities for
customizing Emacs, rather than the Lisp fascilities for the same.

> I'm not sure, maybe something like `not defined while loading a
> file'.

That may be more reliable, rather than, as now, gradually making
existing commands customize aware, as people think of them.

E.g. set-variable should probably really be customize aware when
called interactively.

> That would catch customize, M-x global-set-key, M-: (global-set-key
> ...), hooks, eval-region, etc.  It would also mean that bindings
> established in .emacs are `non-user' which may be good or bad, but
> maybe it could be made be an exception to the loading-files test.

They should be "non-user", as we don't want customize to duplicate
these bindings on start-up.

> Note that this sort of test could be done entirely within `define-key',
> and wouldn't have to distinguish between customization and other uses.

Cool.

Do you want to propose the same for "setq" ;-)

> It's possible to implement this either as a nested set of keymaps (like
> you use), where the decision whether to use a `user' or `default'
> binding is made at key-lookup time, or to simply stash the default
> bindings in a different keymap for use by customize and also put them in
> the real keymap when appropriate.
>
>
> Another question is `if there the implementation uses two keymaps
> (either for nesting at lookup time, or just for bookkeeping purposes),
> where is the second one stored?'  I really dislike your idea of having
> two separate lisp variable to store them.  It oughtn't even be necessary
> to know the name of a keymap to find its associated `2nd keymap',
> especially when more than just customize is looking at them.
>
> Is it possible to stash the `2nd keymap' within the primary keymap
> directly?  Alternatively, there could be a global alist mapping primary
> keymaps (note, _not_ variable names) to 2ndary keymaps.

I probably shouldn't say this, but it will be simpler for XEmacs,
where keymaps are an opaque type.

Re: Customizing key bindings

[Miles Bader]

On Mon, Sep 09, 2002 at 02:20:33PM +0200, Per Abrahamsen wrote:
> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > The usual way that global bindings are established is to bind the key
> > ahead of time (often via ###autoload), and autoload the package when
> > the binding is first invoked.  In those cases, the `default binding' is
> > established ahead of time, so customize will find it.
> 
> Only for bundled packages.  
> 
> > Non-trival differences in behavior based on (interactive-p) are
> > something that make me nervous.
> 
> Me too, but nobody protested when Stefan added such functionality to
> define-minor-mode, so I presumed it was an acceptable solution.
> 
> > If I can try to restate what you said, it seems to be:
...
> Yes.  I find this this simple and intuitive.

Er, you omitted my additional definition, which abstracts things a bit more;
does that mean you find a problem with it?

> > So is there a definition of `user' that's easy to implement? 
> 
> I define "user" to be someone who use the interactive fascilities for
> customizing Emacs, rather than the Lisp fascilities for the same.

Unfortunately, that doesn't really match a typical emacs user; emacs users
use `lisp' facilities to define keys all the time.

I know you're coming from the point of view where customize is more
important, but please try to understand that many of us wish to at least
_try_ to make both sets of users happy.

> > I'm not sure, maybe something like `not defined while loading a
> > file'.
> 
> That may be more reliable, rather than, as now, gradually making
> existing commands customize aware, as people think of them.
> 
> E.g. set-variable should probably really be customize aware when
> called interactively.
> 
> > That would catch customize, M-x global-set-key, M-: (global-set-key
> > ...), hooks, eval-region, etc.  It would also mean that bindings
> > established in .emacs are `non-user' which may be good or bad, but
> > maybe it could be made be an exception to the loading-files test.
> 
> They should be "non-user", as we don't want customize to duplicate
> these bindings on start-up.

I'm not sure what you mean by `duplicate on start-up' -- if .emacs bindings
are marked as `user bindings' then they won't overwrite the `binding
defaults' for the keys they define; if custom then defines any of the same
bindings, it will overwrite the _user_ bindings, but not the `binding
defaults'.  So there's no `duplication', just redefinition -- just as if you
had used customize to define the same key twice.

The benefit of making .emacs bindings `user bindings' is that people can't
use `revert to default binding' to get rid of a (non-custom) .emacs binding
and go back to the binding established by the default emacs code, which many
people would find intuive I think.

> I probably shouldn't say this, but it will be simpler for XEmacs,
> where keymaps are an opaque type.

Perhaps in theory, but in practice I think that's not true -- there are so
many wierd twists in the keymap format that no one in their right mind
actually modifies them without using standard keymap functions.  As far as I
can see the only real use of the non-opaque keymaps is that it's easy to
print them out and see what's in there...

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Customizing key bindings

[Per Abrahamsen]

Miles Bader <miles@gnu.org> writes:

> Er, you omitted my additional definition, which abstracts things a bit more;
> does that mean you find a problem with it?

That definition was identical, given a suitable definition of "user".

> I know you're coming from the point of view where customize is more
> important, but please try to understand that many of us wish to at least
> _try_ to make both sets of users happy.

So do I, which is why I have tried advocating the 100% solution.

> I'm not sure what you mean by `duplicate on start-up' 

".emacs" contains:

   (setq foo 'bar)

The user say:
   M-x customize-option <ret> foo <ret>

Customize warns that the option is set "outside customize".  If he
nonetheless go ahead and saves it, it will have no effect since it
will be overwritten by the setq in the next session.

This is the whole point of differentiating between "set by customize"
and "set outside customize".  It is there to help the user from
screwing himself, either directly (by saving an option already set in
".emacs"), or indirectly (by customizing an option some other package
he loads believe it has the right to change).

> if .emacs bindings
> are marked as `user bindings' then they won't overwrite the `binding
> defaults' for the keys they define; if custom then defines any of the same
> bindings, it will overwrite the _user_ bindings, but not the `binding
> defaults'. 

The problem is not setting, but saving the binding.  If he saves the
binding, it will be set twice on upstart.  The final value will depend
on whether the "define-key" call is before or after the
"custom-set-variables" call.

> The benefit of making .emacs bindings `user bindings' is that people can't

Should that be "can"?

> use `revert to default binding' to get rid of a (non-custom) .emacs binding
> and go back to the binding established by the default emacs code, which many
> people would find intuive I think.

It might be intuitive, but frustrating when they start a new session,
and the customization they erased in the previous session magically
reappears.

>> I probably shouldn't say this, but it will be simpler for XEmacs,
>> where keymaps are an opaque type.
>
> Perhaps in theory, but in practice I think that's not true -- there are so
> many wierd twists in the keymap format that no one in their right mind
> actually modifies them without using standard keymap functions.  As far as I
> can see the only real use of the non-opaque keymaps is that it's easy to
> print them out and see what's in there...

So you can change the format of keymaps, with no fear of breaking user
code?

Re: Customizing key bindings

[Stefan Monnier]

> >> I probably shouldn't say this, but it will be simpler for XEmacs,
> >> where keymaps are an opaque type.
> >
> > Perhaps in theory, but in practice I think that's not true -- there are so
> > many wierd twists in the keymap format that no one in their right mind
> > actually modifies them without using standard keymap functions.  As far as I
> > can see the only real use of the non-opaque keymaps is that it's easy to
> > print them out and see what's in there...
> 
> So you can change the format of keymaps, with no fear of breaking user
> code?

Yes and no.  There is code out there that relies on the representation
currently used.  There's actually a fair bit of it.
But all the examples I can think of have no impact on the issue at hand.
I.e. they either "construct a whole keymap at a time" and do things
like (cons 'keymap (mapcar 'foo mylist)) or use nconc in place
of set-keymap-parent or they just parse the keymap for one reason
or another (but without modifying it).

I don't claim that there isn't any other case, but I can't remember
seeing any.  I'd actually be interested in any info about such odd
cases.


	Stefan

Re: Customizing key bindings

[Stefan Monnier]

> > Non-trival differences in behavior based on (interactive-p) are
> > something that make me nervous.
> Me too, but nobody protested when Stefan added such functionality to
> define-minor-mode, so I presumed it was an acceptable solution.

In the case of define-minor-mode, the use of interactive-p (which
I tend to dislike) only has "trivial" impact: it is used to decide
whether to output a message and whether to consider the change as
"explicitly asked by the user so custom can consider it as a
user-customization".  This last difference has no impact whatsoever
as long as you don't use custom.

So I think using interactive-p is OK as long as it's only to
record some info for customize the use later, but it's not OK if
it actually changes the behavior of the command when it is
invoked.


	Stefan

Re: Customizing key bindings

[Richard Stallman]

    In the case of define-minor-mode, the use of interactive-p (which
    I tend to dislike) only has "trivial" impact: it is used to decide
    whether to output a message and whether to consider the change as
    "explicitly asked by the user so custom can consider it as a
    user-customization".  This last difference has no impact whatsoever
    as long as you don't use custom.

I agree--for trivial purposes like this, this is legitimate.

Re: Customizing key bindings

[Richard Stallman]

    Another question is `if there the implementation uses two keymaps
    (either for nesting at lookup time, or just for bookkeeping purposes),
    where is the second one stored?'  I really dislike your idea of having
    two separate lisp variable to store them.

In my two-keymap proposal, the second one is found only as the parent
of the first.  The first is marked somehow as a customization keymap
so that define-key knows to keep moving and define in its parent.

My two-keymap proposal is #1 below.

======================================================================
Here's what I think the :set for a keymap should do.
Actually, I have two alternative ideas:

1. Create a new keymap, as above, but make its parent be
the keymap that was the value of SYM before.  Put the
symbol `custom' in the keymap to mark it as made here.

If Custom had already run and done this, strip off the
keymap it made before, and make a new one.

Change define-key so that it skips that keymap and makes the change in
the parent.

Now all changes made outside Custom will be permanent.  However, the
bindings specified with Custom will shadow those changes.  In some
cases the user might not like that, but I don't see that any
alternative is clearly better.

[In fact, it seems to me that this is more correct than any other
alternative.]

2. Instead of making a new keymap, just install the changes in the
original keymap, saving the original definitions.

More precisely, here's what :set would do:

* Reinstall all the saved original bindings

* For each key that has a Custom key binding,
save is current binding.

* Install the Custom key bindings.

This way, changes made outside Custom all take effect immediately.
If the key has no Custom binding, the change is permanent.
If the key does have a Custom binding, the change is lost when
Custom runs again, but maybe that is reasonable in this case.

Re: Customizing key bindings

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> 2. Instead of making a new keymap, just install the changes in the
> original keymap, saving the original definitions.

This is what Alex latest code does.

Re: Customizing key bindings

[Richard Stallman]

    > 2. Instead of making a new keymap, just install the changes in the
    > original keymap, saving the original definitions.

    This is what Alex latest code does.

Yes, I know.  What I am saying is that perhaps it should do #1 instead,
as a way to get better results when other packages load new keybindings
for key sequences that have been customized.

Re: Customizing key bindings

[Alex Schroeder]

My code implements #2.  The reason for choosing that approach are
trivial: I don't want to touch the C code, so changing define-key is
out of the question (for me).  Now, if #2 had been difficult to do,
then we would have returned to #1.  But #2 was rather easy to do.
This is why I see no reason to do #1 at the moment.

I realize this is not a real argument.  :)  It just seems more
pragmatic at the moment.

Alex.

Richard Stallman <rms@gnu.org> writes:

>     Another question is `if there the implementation uses two keymaps
>     (either for nesting at lookup time, or just for bookkeeping purposes),
>     where is the second one stored?'  I really dislike your idea of having
>     two separate lisp variable to store them.
>
> In my two-keymap proposal, the second one is found only as the parent
> of the first.  The first is marked somehow as a customization keymap
> so that define-key knows to keep moving and define in its parent.
>
> My two-keymap proposal is #1 below.
>
> ======================================================================
> Here's what I think the :set for a keymap should do.
> Actually, I have two alternative ideas:
>
> 1. Create a new keymap, as above, but make its parent be
> the keymap that was the value of SYM before.  Put the
> symbol `custom' in the keymap to mark it as made here.
>
> If Custom had already run and done this, strip off the
> keymap it made before, and make a new one.
>
> Change define-key so that it skips that keymap and makes the change in
> the parent.
>
> Now all changes made outside Custom will be permanent.  However, the
> bindings specified with Custom will shadow those changes.  In some
> cases the user might not like that, but I don't see that any
> alternative is clearly better.
>
> [In fact, it seems to me that this is more correct than any other
> alternative.]
>
> 2. Instead of making a new keymap, just install the changes in the
> original keymap, saving the original definitions.
>
> More precisely, here's what :set would do:
>
> * Reinstall all the saved original bindings
>
> * For each key that has a Custom key binding,
> save is current binding.
>
> * Install the Custom key bindings.
>
> This way, changes made outside Custom all take effect immediately.
> If the key has no Custom binding, the change is permanent.
> If the key does have a Custom binding, the change is lost when
> Custom runs again, but maybe that is reasonable in this case.

Re: Customizing key bindings

[Richard Stallman]

      Now, if #2 had been difficult to do,
    then we would have returned to #1.  But #2 was rather easy to do.
    This is why I see no reason to do #1 at the moment.

It seems that that #1 gives a cleaner behavior than #2.

You're arguing that it won't matter in practice.  Perhaps that is
true.

Re: Customizing key bindings

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>       Now, if #2 had been difficult to do,
>     then we would have returned to #1.  But #2 was rather easy to do.
>     This is why I see no reason to do #1 at the moment.
>
> It seems that that #1 gives a cleaner behavior than #2.
>
> You're arguing that it won't matter in practice.  Perhaps that is
> true.

We can install #2 now (since we have it), and switch to #1 (which I
agree is cleaner) if approach #2 proves to cause problems in practice.
The interface is the same as far as I can see, so it would be a clean
switch.

Re: Customizing key bindings

[Richard Stallman]

    Hm, but while we are in the same session, potential bug remain (the
    ones that Per keeps talking about).

    1. Load foo.el which uses defkeymap to create a keymap with binding A
       for one key.
    2. Customize the keymap with binding B for the same key.  The shadowed
       binding A is saved.
    3. Load foo-extra or call a hook that uses define-key to change the
       binding for the same key to C.
    4. Customize the keymap.  I think it is ok to see binding C, because
       after all that is what happens to variables as well.  The problem
       is that when the user removes the binding for that key, we revert
       to binding A, instead of B.

I think my two-keymap solution, with a modified define-key, would
handle this right.  (It would also prevent C from being visible while
the customization is in effect.)

Re: Customizing key bindings

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     3. Load foo-extra or call a hook that uses define-key to change the
>        binding for the same key to C.
>     4. Customize the keymap.  I think it is ok to see binding C, because
>        after all that is what happens to variables as well.  The problem
>        is that when the user removes the binding for that key, we revert
>        to binding A, instead of B.
> 
> I think my two-keymap solution, with a modified define-key, would
> handle this right.

Please elaborate.  What is `my two-keymap solution'?  How is it
different from Per's?

> (It would also prevent C from being visible while the customization is
> in effect.)

... which is the wrong thing in the case of a hook.

[Note that if `foo-extra' uses a `defkeymap' variant of some sort to
define C (which it probably would, if `foo' does too), then that could
be used to make custom aware of the A->B change.]

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Customizing key bindings

[Richard Stallman]

    > (It would also prevent C from being visible while the customization is
    > in effect.)

    ... which is the wrong thing in the case of a hook.

Why do you think that is wrong?  I think it is probably correct.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    I believe maintenance will be much harder with one variable that tries
    to do everything, rather than two variables with clearly identified
    purposes.

Would someone please explain concisely and clearly what these two
alternatives really mean?  In the "two variables" alternative,
what are the two variables, and what information do they record?

People have also proposed the idea of using two keymaps for each one
that we have now.  I am definitely going to reject that idea.
However, having additional variables might be ok, depending
on the details of what they are used for.

Re: [CVS] f7, f8 bound..

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> People have also proposed the idea of using two keymaps for each one
> that we have now.  I am definitely going to reject that idea.

This is my proposal.  Since you definitely is going to reject that, I
won't argue more for it.  Alex' code (with one keymap) is a big
improvement over status quo, despite my reservations.

> However, having additional variables might be ok, depending
> on the details of what they are used for.

The two variables would hold the two keymaps, so that is the same
proposal as the one you are definitely going to reject.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    The only one we risk confusing is the programmer, not the user.  The
    programmer will need to understand all three, the variable for
    customization, the automatically generated custom keymap, and the
    normal keymap.

I don't like this idea.  I think we should avoid making several
keymaps where we now have just one.  There are other ways to keep
track of which bindings were set by Custom, without complicating
either the non-programmer interface or the programmer interface.

Re: [CVS] f7, f8 bound..

[Kai Großjohann]

Miles Bader <miles@gnu.org> writes:

> It sounds more confusing for the user to have two variables which are `the
> same but different' like that.  I think we should be trying to make customize
> _more_ of a thin UI layer on top of existing mechanisms, not less.

On the one hand, it's a big task to convert all of the places where
variables are used.

On the one hand, it's easier to understand one variable than two.

On the other hand, if you have a list of items and loading a package
adds items to the list and Customize also adds items to the list, then
the time when the package is loaded influences the order of items on
the list, which might lead to subtle problems.  This would be avoided
if the Customize stuff was always searched first (because it's in an
extra variable).

IMHO, there are merits and demerits to either approach.  I'm sure it
is possible to argue for a long time which approach is the right
approach.  But one approach must be chosen, and that must be
implemented.  I think a "compromise" does not make sense in this
situation.  Therefore I propose that a decision be made on what shall
be done, and then both camps can start to work on it, knowing that at
least the second-best solution has been chosen, and the horrible
alternative has been avoided :-)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

> On the other hand, if you have a list of items and loading a package
> adds items to the list and Customize also adds items to the list, then
> the time when the package is loaded influences the order of items on
> the list, which might lead to subtle problems.  This would be avoided
> if the Customize stuff was always searched first (because it's in an
> extra variable).

Please don't forget that the user might also want to *remove* things
from the default value.


	Stefan

Re: [CVS] f7, f8 bound..

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Please don't forget that the user might also want to *remove* things
> from the default value.

Oops.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    It already handles all global bindings.  Just type [ins] and add a new
    binding.

That is not really handling all global bindings.  To handle all global
bindings properly, the custom facility for bindings needs to know
about all the existing bindings, not just a few.

I don't think this mechanism would be very convenient if it had a
list of hundreds of bindings in no particular order.

Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Here is a version that handle [DEL].

To test, evaluate the code, 

   M-x customize-option <ret> global-key-bindings <ret>

   Activate the [INS] button.

   Enter <f7> in the Key field and apropos in the Command field.

   Activate the [Set for Current Session] button

   Press <f7> to test.

   Activate the [DEL] button.

   Press <f7> to test.

Obviously the UI needs to be improved, but the basic mechanism (except
perhaps the use of use-global-map) should work.  A similar mechanism
can be used for the mode specific maps, instead of fiddling with
use-global-map, we would just change the mode to use
custom-my-mode-map directly.

(defvar custom-global-keymap (let ((map (make-sparse-keymap)))
			       (set-keymap-parent map global-map)
			       map)
  "Global keymap for use by customize.")

(defcustom global-key-bindings nil
  "Global keybindings defined through customize."
  :type '(repeat
	  (group (string :tag "Key") (function))
  :set (lambda (sym val)
	 (set-default sym val)
	 (setq custom-global-keymap (make-sparse-keymap))
	 (set-keymap-parent custom-global-keymap global-map)
	 (mapc (lambda (bind)
		 (define-key custom-global-keymap (read-kbd-macro (car bind))
		   (cadr bind)))
	       val)
	 (use-global-map custom-global-keymap)
	 val))

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> (defcustom global-key-bindings nil ...

Cool, it works (after adding a paren at the right place).  How about
this addition.  A side note: Why is the default value for function
types the string "ignore"?

Alex.

(defvar custom-global-keymap (let ((map (make-sparse-keymap)))
			       (set-keymap-parent map global-map)
			       map)
  "Global keymap for use by customize.")

(defcustom global-key-bindings nil
  "Global keybindings defined through customize.

While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  The easiest thing is probably
to hit C-q and then just type the key.  C-q will insert the correct
string representation for you.

While entering the name of a command, you can use M-TAB to comlete
the function name."
  ;; Note that we cannot use \\[quoted-key-insert] because the keymap
  ;; is not the same.
  :type '(repeat
	  (group (string :tag "Key") (function)))
  :set (lambda (sym val)
	 (set-default sym val)
	 (setq custom-global-keymap (make-sparse-keymap))
	 (set-keymap-parent custom-global-keymap global-map)
	 (mapc (lambda (bind)
		 (define-key custom-global-keymap (read-kbd-macro (car bind))
		   (cadr bind)))
	       val)
	 (use-global-map custom-global-keymap)
	 val))

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(define-key custom-global-keymap (kbd "C-q") 'quoted-key-insert)

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> How about this addition.

A big help.  I don't think C-q should be rebound globally, the user
may want to enter literal control characters in string values for
other variables.  So I made it specific to the field, end encapsulated
it into a new 'key-sequence' widget.  I also added a [Key sequence]
button, and a new 'command' widget.

> A side note: Why is the default value for function types the string
> "ignore"?

I don't know.  It is supposed to be the symbol `ignore'.  Using the
widget package directly with (widget-create 'function) works, so I
guess somehow customize convert the value twice.  Somehow, now it just
ignores the default value, and use nil.  Strange.

;;; cus-key.el -- Customize support for changing key bindings.

(require 'wid-edit)

(defvar custom-global-keymap (let ((map (make-sparse-keymap)))
			       (set-keymap-parent map global-map)
			       map)
  "Global keymap for use by Customize.

This is automatically generated from `global-key-bindings', you should 
never change this manually.  Instead, change either `global-map' from Lisp 
or `global-key-bindings' from Customize.")

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :keymap key-sequence-widget-map)

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'group
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get)

(defun key-sequence-value-create (widget)
  (let ((button (widget-create-child widget '(key-sequence-button)))
	(field (widget-create-child-value widget 
					  '(key-sequence-field
					    :format " %v")
					  (widget-get widget :value))))
    (widget-put widget :children (list field))
    (widget-put widget :buttons (list button))))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (commandp (widget-value widget))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(defcustom global-key-bindings nil
  "Global keybindings defined through customize.

While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of a command, you can use M-TAB to comlete
the function name."
  ;; Note that we cannot use \\[quoted-key-insert] because the keymap
  ;; is not the same.
  :type '(repeat
	  (group key-sequence command))
  :set (lambda (sym val)
	 (set-default sym val)
	 (setq custom-global-keymap (make-sparse-keymap))
	 (set-keymap-parent custom-global-keymap global-map)
	 (mapc (lambda (bind)
		 (define-key custom-global-keymap (read-kbd-macro (car bind))
		   (cadr bind)))
	       val)
	 (use-global-map custom-global-keymap)
	 val))

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Cool.  Thanks for writing this widget stuff.  I really should look
more into this; I am sort of "there", but do not grok it enoug to
write new real widgets.  All I do is write wizards and defcustoms.  :)

I think this looks really useful.  If we merged this with the
diff-list stuff, we could write something interesting that would look
more or less like this:

(defmacro defkeymap (symbol map doc &rest args)
  "Define SYMBOL to be a keymap with value MAP.
DOC is the keymap documentation."
  ;; It is better not to use backquote in this file,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (nconc (list 'custom-declare-keymap
	       (list 'quote symbol)
	       (list 'quote map)
	       doc)
	 args))

(defun custom-declare-keymap (symbol map doc &rest args)
  "Like `defkeymap', but SYMBOL and MAP are evaluated as normal arguments.
MAP should be an expression to evaluate to compute the default value,
not the default value itself.  The DOC string will be expanded with
some standard instructions for customization."
  ;; Keymaps are variables.  The only difference is that we know lots
  ;; of defcustom properties already.
  (setq doc (concat (get symbol 'variable-documentation)
		    "\n
While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of the command, you can use M-TAB to complete
it."))
  (apply 'custom-declare-variable symbol map doc 
	 :type '(repeat (group key-sequence command))
         :get (some diff-list stuff)
         :set (some mix of diff-list and the code you wrote)))

I will see wether I can dig out the diff-list stuff from the mailing
list archives, I must have lost it somewhere along the way...

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Alex Schroeder <alex@emacswiki.org> writes:

> I will see wether I can dig out the diff-list stuff from the mailing
> list archives, I must have lost it somewhere along the way...

Emacs Wiki to the rescue!  The stuff still exists:

http://www.emacswiki.org/cgi-bin/wiki.pl?CustomDiffList

I will try to use Per's last code and diff-list to implement a
defkeymap macro...

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Hm, I am a bit confused.  The following is for people who want to help
me fix the code.  Here is what happens:

I have a defkeymap macro now, that seems to do the right thing.  See
the test keymap at the end.  The defkeymap creates a keymap and uses
the value given as the standard-value.  When you use customize,
however, it does not use the variable value of the keymap but the
custom-keymap property, which is nil.  When you add a keybinding, the
custom-keymap property holds a binding such as (("3" buffer-menu)).
The variable-value of the keymap is now a key map that holds the
binding for 3, and inherits from the standard-value.  Cool, so far.
Everything seems to work.  It even saves the correct customization
(only the binding for 3, not the entire keymap).

Here comes the problem, now.  When you customize the variable a second
time, custom detects a mismatch.  And I cannot discover what the
problem is.  I have started playing with the get and set methods to
figure out what is going on, but as far as I can tell, (("3"
buffer-menu)) should be a legal value for customization.

Per, do you know the answer?  I am too tired right now to keep at it.
:)

Alex. 


;;; cus-key.el -- Customize support for changing key bindings.

(require 'wid-edit)

(defvar custom-global-keymap (let ((map (make-sparse-keymap)))
			       (set-keymap-parent map global-map)
			       map)
  "Global keymap for use by Customize.

This is automatically generated from `global-key-bindings', you should 
never change this manually.  Instead, change either `global-map' from Lisp 
or `global-key-bindings' from Customize.")

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :keymap key-sequence-widget-map)

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'group
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get)

(defun key-sequence-value-create (widget)
  (let ((button (widget-create-child widget '(key-sequence-button)))
	(field (widget-create-child-value widget 
					  '(key-sequence-field
					    :format " %v")
					  (widget-get widget :value))))
    (widget-put widget :children (list field))
    (widget-put widget :buttons (list button))))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (commandp (widget-value widget))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(defmacro defkeymap (symbol map doc &rest args)
  "Define SYMBOL to be a keymap with value MAP.
DOC is the keymap documentation."
  ;; It is better not to use backquote in this file,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (nconc (list 'custom-declare-keymap
	       (list 'quote symbol)
	       (list 'quote map)
	       doc)
	 args))

(defun custom-declare-keymap (symbol map doc &rest args)
  "Like `defkeymap', but SYMBOL and MAP are evaluated as normal arguments.
MAP should be an expression to evaluate to compute the default value,
not the default value itself.  The DOC string will be expanded with
some standard instructions for customization."
  ;; Keymaps are variables.  The only difference is that we know lots
  ;; of defcustom properties already.
  (setq doc (concat doc
		    "\n
While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of the command, you can use M-TAB to complete
it."))
  (apply 'custom-declare-variable symbol map doc 
	 :type '(repeat (group key-sequence command))
	 :set 'custom-set-keymap
	 :get 'custom-get-keymap
	 args))

(defun custom-set-keymap (sym bindings)
  "Update keymap SYM with BINDINGS.
This creates a new keymap based on BINDINGS, and sets the parent of
that new keymap to the standard-value of SYM.  This is set as the new
variable value of SYM.  At the same time, the additions by themselves
are stored in the custom-keymap property."
  (let ((org (eval (car (get sym 'standard-value))))
	(map (make-sparse-keymap)))
    (set-keymap-parent map org)
    ;; When defkeymap is called for the first time, BINDINGS is the
    ;; standard-value.  When customized, BINDINGS is no longer a
    ;; keymap but an alist of bindings.
    (unless (equal bindings org)
      (mapc (lambda (bind)
	      (define-key map (read-kbd-macro (car bind))
		(cadr bind)))
	    bindings)
      (put sym 'custom-keymap (list bindings)))
    (set-default sym map)))

(defun custom-get-keymap (sym)
  "Return the additions to the standard-value of keymap SYM.
These additions are stored in the custom-keymap property by
`custom-set-keymap'."
  (car (get sym 'custom-keymap)))

;; Example:

(defkeymap my-keymap
  (let ((map (make-sparse-keymap)))
    (define-key map (read-kbd-macro "<f11>") 'bbdb)
    map)
  "Keymap to demonstrate `defkeymap'.")

;; my-keymap
;; (keymapp my-keymap)
;; (custom-get-keymap 'my-keymap)
;; (put 'my-keymap 'custom-keymap nil)
;; (get 'my-keymap 'standard-value)
;; (customize-option 'my-keymap)
;; (unintern 'my-keymap)

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> Per, do you know the answer?  I am too tired right now to keep at it.

I forgot to define :match for the 'key-sequence' widget.  I have
included it below, together with a :validate for 'key-sequence-field'.
But first some other comments:

1. We are modifying symbols, not a keymaps.  Unfortunately, keymaps
are mostly used directly, as values, rather than indirectly through
symbols.  I.e.

If you do 

  (use-local-map my-keymap)

  (setq my-keymap (make-sparse-keymap))
  (define-key my-keymap [foo] 'bar)

[foo] will not be bound on the current local keymap, but on the newly
created keymap.  I believe the easiest way to solve this is by
changing Emacs to allow

  (use-local-map 'my-keymap)

rather than changing cus-key.el to work on keymaps instead of
variables.

2. You avoid the use of an extra keymap variable by instead storing
the receipe for creating the keymap in a symbol property, thus making
Stefan happy.  However, it means all changes made from Lisp is lost
whenever it is changed from customize.  I think that is a poor
trade-off, and would prefer an explicit variable for use from Lisp.

(define-widget 'key-sequence 'group
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get)

(defun key-sequence-match (widget value)
  (stringp value))

(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  :validate 'key-sequence-field-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-widget-validate (widget value)
  (let ((value (widget-apply widget :value-get)))
    (condition-case (read-kbd-macro value)
	nil
      (error widget))))

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    2. You avoid the use of an extra keymap variable by instead storing
    the receipe for creating the keymap in a symbol property, thus making
    Stefan happy.  However, it means all changes made from Lisp is lost
    whenever it is changed from customize.

Could you explain why that consequence would follow?  I don't see
any general reason why it would.  Perhaps it is the consequence
of some specific details of the proposed solution--in which case,
how about changing those details?

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     2. You avoid the use of an extra keymap variable by instead storing
>     the receipe for creating the keymap in a symbol property, thus making
>     Stefan happy.  However, it means all changes made from Lisp is lost
>     whenever it is changed from customize.
>
> Could you explain why that consequence would follow?  

Everytime customize "set" the variable, the entire keymap is recreated
from scratch.  So any changes made from outside customize is lost, as
customize does not know about them.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    Everytime customize "set" the variable, the entire keymap is recreated
    from scratch.

It is not entirely clear what "from scratch" means here.  The natural
meaning of "create the global map again from scratch" would mean to
make an empty map and load bindings.el into it, but I am sure that is
not what the code does.

Could someone please explain more precisely what data it is recreated
from?  That makes all the difference.

    With your code, the rules are simle:  If you change a keymap with
    customize, all other changes are lost.

I doubt there is a fundamental reason why all other changes should be
lost.  When someone explains to me why this happens at present,
I will look for a way to prevent it.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     Everytime customize "set" the variable, the entire keymap is recreated
>     from scratch.
>
> It is not entirely clear what "from scratch" means here.  The natural
> meaning of "create the global map again from scratch" would mean to
> make an empty map and load bindings.el into it, but I am sure that is
> not what the code does.
>
> Could someone please explain more precisely what data it is recreated
> from?  That makes all the difference.

From the custructer given as the second argument to defcustom.  That
constructor is the 'standard-value' symbol property, and used whenever
the user modify the keymap through customize.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Stefan Monnier]

> (defkeymap my-keymap
>   (let ((map (make-sparse-keymap)))
>     (define-key map (read-kbd-macro "<f11>") 'bbdb)
>     map)
>   "Keymap to demonstrate `defkeymap'.")

How about allowing a more declarative form like

  (defkeymap my-mode-map
    '(([mouse-1] . foo)
      (([mouse-2] "f" "e" "\C-m") . open-file))
    "Keymap for My mode."
    :group 'foo
    :inherit his-mode-map)


-- Stefan

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

>> (defkeymap my-keymap
>>   (let ((map (make-sparse-keymap)))
>>     (define-key map (read-kbd-macro "<f11>") 'bbdb)
>>     map)
>>   "Keymap to demonstrate `defkeymap'.")
>
> How about allowing a more declarative form like
>
>   (defkeymap my-mode-map
>     '(([mouse-1] . foo)
>       (([mouse-2] "f" "e" "\C-m") . open-file))
>     "Keymap for My mode."
>     :group 'foo
>     :inherit his-mode-map)

I'd prefer that too, it would be more in line with how the rest of
Customize (custom is a place where you are forced to declare your
stuff).  It would probably make more sense to use the read-kbd-macro
format though, as that is what the code use internally, and that is
what it saves to to .emacs.  I.e.

   (defkeymap my-mode-map
       '(("<mouse-1>" foo)
        (("<mouse-2> f e C-m". open-file))
     "Keymap for My mode."
     :group 'foo
     :inherit his-mode-map)

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

      It would probably make more sense to use the read-kbd-macro
    format though, as that is what the code use internally, and that is
    what it saves to to .emacs.

That would be inconsistent with define-key, so I don't want to do that.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>       It would probably make more sense to use the read-kbd-macro
>     format though, as that is what the code use internally, and that is
>     what it saves to to .emacs.
> 
> That would be inconsistent with define-key, so I don't want to do that.

I agree.  The natural format for the key bindings is what is accepted by
define-key.

However, (kbd "...") should be accepted too, and probably be the
default format [as it is easier to write than a string or vector] for
the format used in the Customization of the binding.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Customizing key bindings

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>> How about allowing a more declarative form like
>>
>>   (defkeymap my-mode-map
>>     '(([mouse-1] . foo)
>>       (([mouse-2] "f" "e" "\C-m") . open-file))
>>     "Keymap for My mode."
>>     :group 'foo
>>     :inherit his-mode-map)

We could always add that, later.  In the simplest case, we would use a
function that transforms the one into the other and call it from
custom-declare-keymap.

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    How about allowing a more declarative form like

      (defkeymap my-mode-map
	'(([mouse-1] . foo)
	  (([mouse-2] "f" "e" "\C-m") . open-file))
	"Keymap for My mode."
	:group 'foo
	:inherit his-mode-map)

That is a clean interface, but the crucial question is, what would it
expand into?  Would it just be a defvar for my-mode-map, or a
defcustom for my-mode-map?  Or would it produce something else?  If
so, what else?

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     How about allowing a more declarative form like
>
>       (defkeymap my-mode-map
> 	'(([mouse-1] . foo)
> 	  (([mouse-2] "f" "e" "\C-m") . open-file))
> 	"Keymap for My mode."
> 	:group 'foo
> 	:inherit his-mode-map)
>
> That is a clean interface, but the crucial question is, what would it
> expand into?  Would it just be a defvar for my-mode-map, or a
> defcustom for my-mode-map?  Or would it produce something else?  If
> so, what else?

It is just a variation of the code Alex already posted.  It creates a
variable my-mode-map whose value is a keymap with the specified
bindings, and which can be customized with customize-option.  The
variable belongs to the foo customize group, and the keymap inherits
from his-mode-map.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    It is just a variation of the code Alex already posted.  It creates a
    variable my-mode-map whose value is a keymap with the specified
    bindings, and which can be customized with customize-option.  The
    variable belongs to the foo customize group, and the keymap inherits
    from his-mode-map.

That seems good.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    I will try to use Per's last code and diff-list to implement a
    defkeymap macro...

What job do you think a defkeymap macro ought to do?

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     I will try to use Per's last code and diff-list to implement a
>     defkeymap macro...
>
> What job do you think a defkeymap macro ought to do?

Does the code we already posted answer the question?  I can elaborate,
of course, but here is the terse description:  Allow mode authors to
define keymaps that are easily customizable.  Currently keymaps are
defined using defvar.  They are not customizable.

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    Does the code we already posted answer the question?  I can elaborate,
    of course, but here is the terse description:  Allow mode authors to
    define keymaps that are easily customizable.  Currently keymaps are
    defined using defvar.  They are not customizable.

I can't find the code you already posted.  Could you show me what the
*expansion* of the macro is supposed to be?

Re: Customizing key bindings

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     Allow mode authors to define keymaps that are easily
>     customizable.  Currently keymaps are defined using defvar.  They
>     are not customizable.
>
> I can't find the code you already posted.  Could you show me what the
> *expansion* of the macro is supposed to be?

The defkeymap macro is like defcustom -- it expands into a function
call.  In this case, we call custom-declare-keymap, which in turn
calls custom-declare-variable with some extra keyword parameters to
make sure that when this variable is customized, a lot of other stuff
gets changed, too.

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Kai Großjohann]

Alex Schroeder <alex@emacswiki.org> writes:

> I will try to use Per's last code and diff-list to implement a
> defkeymap macro...

I wonder if it might be useful to try the diff-list approach on
something simpler, first?

How about checking in some changes that use it on load-path, for
example?

I looked at the description of how the diff-list feature would look
in a Customize buffer.  Nifty.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

use diff-list in Emacs

[Alex Schroeder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> How about checking in some changes that use it on load-path, for
> example?

Well, the need is not too big as people can always just use
add-to-list to do things.  Removing from load-path is usually not
required.

> I looked at the description of how the diff-list feature would look
> in a Customize buffer.  Nifty.

Yes, it is.  Perhaps we should start using it in Gnus instead of
Emacs.  It might make more sense, there.

Alex.

Re: use diff-list in Emacs

[Kai Großjohann]

Alex Schroeder <alex@emacswiki.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> How about checking in some changes that use it on load-path, for
>> example?
>
> Well, the need is not too big as people can always just use
> add-to-list to do things.  Removing from load-path is usually not
> required.

What I was trying to get at: Diff-lists are a nontrivial feature in
itself, and keymaps add more complexity.  So it might help to discuss
the simple case.  Discussing the simple case is greatly encouraged if
diff-lists are used by default in Customize (where it makes sense).

Hence I think it would be useful to start using diff-lists where it
makes sense.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: use diff-list in Emacs

[Miles Bader]

On Sat, Sep 07, 2002 at 05:52:10PM +0200, Kai Gro?johann wrote:
> What I was trying to get at: Diff-lists are a nontrivial feature in
> itself, and keymaps add more complexity.  So it might help to discuss
> the simple case.

Actually I think keymaps _are_ the simple case, in that they're unordered and
have no duplicate entries.  ... :-)

Using diff-lists for lists, on the other hand, does have the issue of
ordering (you have to know where to add new entries, and sometimes it won't
be at the beginning or end; if you record an existing entry to add after,
what if it isn't found?).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: use diff-list in Emacs

[Kai Großjohann]

Miles Bader <miles@gnu.org> writes:

> Using diff-lists for lists, on the other hand, does have the issue of
> ordering (you have to know where to add new entries, and sometimes it won't
> be at the beginning or end; if you record an existing entry to add after,
> what if it isn't found?).

Whee.  You're right.  So, what do we do?

Okay, let's start with keymaps, then.

kai

PS: I think that functionality for add-to-list and remove-from-list
    (though this function doesn't exist, I think you know what I mean)
    are sufficient as a first start.  So if there is a list of things
    to prepend to, to append to, and to remove from, the default
    value, a lot will be achieve.
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

Is there any chance you could arrange that inserting a new key
sequence into the list will get its current global binding and use
that initially as the specified binding?  That would provide the ability
to "import" any existing binding into customization.

Perhaps the way to do it is that changing the value of the key
sequence field, when the binding field is unspecified, substitutes in
the current binding of that key sequence.

Another alternative method is that display of the key sequence field
could show its current global binding in parentheses.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> Another alternative method is that display of the key sequence field
> could show its current global binding in parentheses.

I have implemented that in the code below.  Evaluate the code, and
type

        M-x customize-option <ret> global-key-bindings <ret>

to test it.

;;; cus-key.el -- Customize support for changing key bindings.

(require 'wid-edit)

(defvar custom-global-keymap (let ((map (make-sparse-keymap)))
			       (set-keymap-parent map global-map)
			       map)
  "Global keymap for use by Customize.

This is automatically generated from `global-key-bindings', you should 
never change this manually.  Instead, change either `global-map' from Lisp 
or `global-key-bindings' from Customize.")

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  :validate 'key-sequence-field-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-widget-validate (widget value)
  (let ((value (widget-apply widget :value-get)))
    (condition-case nil
	(progn 
	  (read-kbd-macro value)
	  nil)
      (error widget))))

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'default
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :format "%v"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get
  :notify 'key-sequence-notify)

(defun key-sequence-match (widget value)
  (stringp value))

(defun widget-ancestor-get (widget property)
  "Starting from WIDGET, return the value of PROPERTY.
If PROPERTY is not specified or nil in WIDGET and the :parent property is 
non-nil, call `widget-ancestor-get' recusively with the value of the :parent
property.  Otherwise, return nil."
  (cond ((widget-get widget property))
	((widget-get widget :parent)
	 (widget-ancestor-get (widget-get widget :parent) property))
	(nil)))

(defun key-sequence-describe (widget command)
  "Create a child to WIDGET that describes COMMAND.
The child widget is returned."
  (cond ((functionp command)
	 (widget-create-child-value 
	  widget '(function-item) command))
	((null command)
	 (widget-create-child-value
	  widget '(item) "Undefined"))
	((numberp command)
	 (widget-create-child-value
	  widget '(item) "Binding too long"))
	((keymapp command)
	 (widget-create-child-value
	  widget '(item) "Prefix key"))
	(t
	 (widget-create-child-value
	  widget '(item) "Dude, this is too weird"))))

(defun key-sequence-value-create (widget)
  (let ((value (widget-default-get widget))
	(map (or (widget-ancestor-get widget :keymap)
		 (current-global-map)))
	(button (widget-create-child-and-convert
		 widget '(key-sequence-button)))
	(field (widget-create-child-value
		widget '(key-sequence-field :format " %vOld binding: ")
		(widget-get widget :value))))
    (let* ((command (condition-case nil
			(lookup-key map (read-kbd-macro value))
		      (error nil)))
	   (binding (key-sequence-describe widget command)))
      (widget-put widget :children (list field))
      (widget-put widget :buttons (list binding button)))))

(defun key-sequence-notify (widget child &optional event)
  "Update the old binding, and notify parent."
  (let* ((buttons (widget-get widget :buttons))
	 (binding (car buttons))
	 (children (widget-get widget :buttons))
	 (field (car children))
	 (value (widget-value child))
	 (map (or (widget-ancestor-get widget :keymap)
		  (current-global-map)))
	 (command (condition-case nil
		      (lookup-key map (read-kbd-macro value))
		    (error nil))))
    (save-excursion
      (goto-char (widget-get binding :from))
      (widget-delete binding)
      (setcar buttons (key-sequence-describe widget command))))
  (widget-default-notify widget child event))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (commandp (widget-value widget))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(define-widget 'key-binding 'group
  "Bind a key sequence to a command."
  :value '("" ignore)
  :indent 0
  :args '(key-sequence (command :tag "New binding")))

(defcustom global-key-bindings nil
  "Global keybindings defined through customize.

While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of a command, you can use M-TAB to comlete
the function name."
  ;; Note that we cannot use \\[quoted-key-insert] because the keymap
  ;; is not the same.
  :type '(repeat key-binding)
  :set (lambda (sym val)
	 (set-default sym val)
	 (setq custom-global-keymap (make-sparse-keymap))
	 (set-keymap-parent custom-global-keymap global-map)
	 (mapc (lambda (bind)
		 (define-key custom-global-keymap (read-kbd-macro (car bind))
		   (cadr bind)))
	       val)
	 (use-global-map custom-global-keymap)
	 val))

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Stefan Monnier]

>         M-x customize-option <ret> global-key-bindings <ret>

I must say I really dislike the idea of customizing
`global-key-bindings' when I actually want to change `global-map'.


	Stefan

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Miles Bader]

On Fri, Sep 06, 2002 at 01:28:30PM -0400, Stefan Monnier wrote:
> >         M-x customize-option <ret> global-key-bindings <ret>
> 
> I must say I really dislike the idea of customizing
> `global-key-bindings' when I actually want to change `global-map'.

Agreed.  Customize should be a friendly face for the existing infrastructure,
not a distant relative...

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Miles Bader <miles@gnu.org> writes:

> On Fri, Sep 06, 2002 at 01:28:30PM -0400, Stefan Monnier wrote:
>> >         M-x customize-option <ret> global-key-bindings <ret>
>> 
>> I must say I really dislike the idea of customizing
>> `global-key-bindings' when I actually want to change `global-map'.
>
> Agreed.  Customize should be a friendly face for the existing infrastructure,
> not a distant relative...

Emacs will never be easy to customize, then.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Miles Bader]

On Sat, Sep 07, 2002 at 02:01:30PM +0200, Per Abrahamsen wrote:
> > Agreed.  Customize should be a friendly face for the existing
> > infrastructure, not a distant relative...
> 
> Emacs will never be easy to customize, then.

How do you draw _that_ conclusion?

In particular note that _all_ of the proposed mechanisms for customizing
keybindings will work pretty well for users that only use customize.  All
we're doing now is trying to make sure that things also work nicely for those
who wish to mix customize and non-customize keybindings.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Miles Bader <miles@gnu.org> writes:
>
>> On Fri, Sep 06, 2002 at 01:28:30PM -0400, Stefan Monnier wrote:
>>> >         M-x customize-option <ret> global-key-bindings <ret>
>>> 
>>> I must say I really dislike the idea of customizing
>>> `global-key-bindings' when I actually want to change `global-map'.
>>
>> Agreed.  Customize should be a friendly face for the existing infrastructure,
>> not a distant relative...
>
> Emacs will never be easy to customize, then.

Maybe I should elaborate...

The problem isn't global-key-bindings, it can easily be named
"global-map" with no loss of functionality.

The problem is the mindset that making complex applications written by
programmers for programmers easy to configure, is simply a matter of
providing a "friendly" interface to the existing configuration
mechanisms.  This mindset is shared by most traditional Unix
developers (and probably Lisp developers too, but who cares).

However, this assumes that being "easy to configure" is merely a
matter of "syntactical sugar", that is, provide a form based interface
to the old text based configuration files.  

What it really does is to force users to think like programmers, which
of course is a lot easier to the programmer than having programmers
think like users.

Note: Here I use "user" to mean the kind of end-users who would never
become programmers, or edit a configuration file directly.  I know
programmers are users too, and even can benefit a form based
customization interface, but they are not the kind of users who really
*need* such an interface,

If you want to make configuration easy to the end-users, you need to
start with their needs, and not with the old textual configuration
files.  It is one area where MS Windows and Mac programmers tend to be
better than Unix programmers.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Robert J. Chassell]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:

   The problem is the mindset that making complex applications written
   by programmers for programmers easy to configure, is simply a
   matter of providing a "friendly" interface to the existing
   configuration mechanisms.  This mindset is shared by most
   traditional Unix developers (and probably Lisp developers too, but
   who cares).

   However, this assumes that being "easy to configure" is merely a
   matter of "syntactical sugar", that is, provide a form based
   interface to the old text based configuration files.

Please explain in more detail.  I cannot infer your implications.

To me, the current customize is "syntactical sugar".  That is to say,
it creates, edits, and writes expressions to my .emacs file for two
functions, `custom-set-faces', and `custom-set-variables'.

I can edit and evaluate those function calls in my .emacs, or I can
edit and evaluate them using a `Customize' buffer.  Either way, I end
up with expression in my .emacs file.

   If you want to make configuration easy to the end-users, you need
   to start with their needs, and not with the old textual
   configuration files.

What are the implications of this?

After all, "the old textual configuration files" are not the `surface
representation' that an end-user ever sees; they are a `deep
structure' that a programmer sees, if he or she wishes.  (To the
programmer, of course, they are a `surface representation' of the
underlying bits.)

The configuration *must* be saved somehow.  Otherwise, the
customization did not `take hold'.  Why not save it in a format that a
programmer can readily edit?  (And in the case of Emacs, in a format
that the existing virtual machine can readily evaluate?)

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

What custom is and does

[Alex Schroeder]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Please explain in more detail.  I cannot infer your implications.

I guess the problem is that do not understand what your problem with
custom is.  Therefore, what Per says makes perfect sense to me but I
cannot explain it to you -- it seems that you two are talking about
two different problems.  Per wrote what he did in response to
something Miles wrote:

Miles Bader <miles@gnu.org> wrote:

> Agreed.  Customize should be a friendly face for the existing
> infrastructure, not a distant relative...

Perhaps the two of you understood two different things, there?  I
spent quite a bit of time explaining my mental model of custom, and
its relation to setq statements.  Perhaps in your question, you could
take my answer and tell me what questions this leaves unanswered, or
what implication you do not follow.

The way I saw it, I said that custom-set-variables was only remotely
connected to setq.  You can use custom-set-variables as a complex and
unreadable variant of hand-written setq statements.  I explained that
this was a very simplified mental model and that it would not be good
enough to explain more powerful features.

Per's position is that custom is a very powerful library to build a
user interface for the customization of Emacs.  He also said (more or
less) that to look at custom as just another way to write elisp into
your .emacs and to expect it to have the very same qualities
hand-written elisp such as readability, modifyability, etc. was to
constrain the powers of custom.  He seems to be saying that working on
this part of custom was worth less than working on extending custom in
new directions (such as keymaps, wizards/saints, etc.).  His point is
that custom can be used to build a customization infrastructure for
Emacs that has very little to do with the underlying lisp variables
and functions.  This is why he does not mind two variables instead of
one -- because custom can be used for greater things and by more
newbies that know nothing of lisp.  Per might argue that to use the
underlying lisp code as an argument in discussions about custom was an
indication of the lack of understand people have for the potential of
custom.

To this you responded along the lines that you consider this lack
readability, modifyability, of the saved data as a bug and it seemed
that you wanted people to work on this with rather high priorities.

Perhaps you need to explain your priorities, or perhaps you need to
restate the problem.  Or perhaps we need to have a discussion about
what custom is and does and what custom could and should be.  I have
read lots of posts by Per so I basically know where he is coming
from...  :)  I just don't know where you stand in all of this.

Alex.

Re: What custom is and does

[Miles Bader]

On Sat, Sep 07, 2002 at 07:48:39PM +0200, Alex Schroeder wrote:
> I guess the problem is that do not understand what your problem with
> custom is.  Therefore, what Per says makes perfect sense to me but I
> cannot explain it to you -- it seems that you two are talking about
> two different problems.

I think you're right -- I'm not talking about the `custom-...' stuff in
.emacs (that's fine with me).

I'm just saying that custom and `lisp' should (1) have the same basic
model of the world (though it's fine for there to be _some_ differences),
and (2) neither should screw each other up (e.g., some of the proposed
implementations for custom-keymaps complicate the lisp model for fairly
dubious reasons).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: What custom is and does

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> I have read lots of posts by Per so I basically know where he is
> coming from...  :)

You certainly do a better job explaining my position than I do...

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>
>    The problem is the mindset that making complex applications written
>    by programmers for programmers easy to configure, is simply a
>    matter of providing a "friendly" interface to the existing
>    configuration mechanisms.  This mindset is shared by most
>    traditional Unix developers (and probably Lisp developers too, but
>    who cares).
>
>    However, this assumes that being "easy to configure" is merely a
>    matter of "syntactical sugar", that is, provide a form based
>    interface to the old text based configuration files.
>
> Please explain in more detail.  I cannot infer your implications.

Suppose I'm a novice trying to set up Gnus for mail.  Customize won't
help.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Stefan Monnier]

> If you want to make configuration easy to the end-users, you need to
> start with their needs, and not with the old textual configuration
> files.  It is one area where MS Windows and Mac programmers tend to be
> better than Unix programmers.

But I (as a programmer-style user) simply hate those interfaces because
I have no way to relate them to the real underlying concepts so that
I end up forced to use the "user-friendly" interface all the time,
with all its limitations.

If that's what Emacs will turn into, then I'll switch to something
else (or will keep on using an old version or something).
After all, Emacs is AFAIK a text-editor with a strong "programmer" user
base and it doesn't make sense to alienate this user-base in order to
try and attract people whose only editing needs are for email messages.


	Stefan

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> But I (as a programmer-style user) simply hate those interfaces because
> I have no way to relate them to the real underlying concepts so that
> I end up forced to use the "user-friendly" interface all the time,
> with all its limitations.

As far as I know, nobody has proposed to get rid of the programmer
oriented, Lisp based interface for configuring Emacs.  What I suggest
is to add a user oriented interface.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    > If you want to make configuration easy to the end-users, you need to
    > start with their needs, and not with the old textual configuration
    > files.  It is one area where MS Windows and Mac programmers tend to be
    > better than Unix programmers.

    But I (as a programmer-style user) simply hate those interfaces because
    I have no way to relate them to the real underlying concepts so that
    I end up forced to use the "user-friendly" interface all the time,
    with all its limitations.

Could you move this theoretical abstract discussion off of emacs-devel?

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> (define-widget 'key-sequence-field 'string
>   "Field for entering key bindings."
>   :tag "Key sequence"
>   :error "Not a well-formed key sequence"
>   :validate 'key-sequence-field-validate
>   :keymap key-sequence-widget-map)
>
> (defun key-sequence-widget-validate (widget value)
>   (let ((value (widget-apply widget :value-get)))
>     (condition-case nil
> 	(progn 
> 	  (read-kbd-macro value)
> 	  nil)
>       (error widget))))

Per, something about this validate stuff is not right.  Even when I
rename -field-validate to -widget-validate, it does not work (wrong
number of arguments).  I just commented validation out for the the
moment, and it seems that I can test things now.

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> Per, something about this validate stuff is not right.  

No, an extra argument.  And it wasn't called.  Here is a fix:

(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  :validate 'key-sequence-field-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-field-validate (widget)
  (let ((value (widget-apply widget :value-get)))
    (condition-case nil
	(progn 
	  (read-kbd-macro value)
	  nil)
      (error widget))))

(define-widget 'key-sequence 'default
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :format "%v"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get
  :validate 'widget-children-validate
  :notify 'key-sequence-notify)

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

I think this does the right thing, now -- it modifies the keymap
directly.  It can restore bindings because it keeps a list of settings
it shadows.  Currently the documentation shown in the customize buffer
is from the global map, this still needs fixing.  See the FIXME
tags...  :)

Alex.

;;; cus-key.el -- Customize support for changing key bindings.

(require 'wid-edit)

(defvar custom-global-keymap (let ((map (make-sparse-keymap)))
			       (set-keymap-parent map global-map)
			       map)
  "Global keymap for use by Customize.

This is automatically generated from `global-key-bindings', you should 
never change this manually.  Instead, change either `global-map' from Lisp 
or `global-key-bindings' from Customize.")

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  ;; FIXME :validate 'key-sequence-widget-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-widget-validate (widget value)
  (let ((value (widget-apply widget :value-get)))
    (condition-case nil
	(progn 
	  (read-kbd-macro value)
	  nil)
      (error widget))))

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'group
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :format "%v"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get
  :notify 'key-sequence-notify)

(defun key-sequence-match (widget value)
  (stringp value))

(defun widget-ancestor-get (widget property)
  "Starting from WIDGET, return the value of PROPERTY.
If PROPERTY is not specified or nil in WIDGET and the :parent property is 
non-nil, call `widget-ancestor-get' recusively with the value of the :parent
property.  Otherwise, return nil."
  (cond ((widget-get widget property))
	((widget-get widget :parent)
	 (widget-ancestor-get (widget-get widget :parent) property))
	(nil)))

(defun key-sequence-describe (widget command)
  "Create a child to WIDGET that describes COMMAND.
The child widget is returned."
  (cond ((functionp command)
	 (widget-create-child-value 
	  widget '(function-item) command))
	((null command)
	 (widget-create-child-value
	  widget '(item) "Undefined"))
	((numberp command)
	 (widget-create-child-value
	  widget '(item) "Binding too long"))
	((keymapp command)
	 (widget-create-child-value
	  widget '(item) "Prefix key"))
	(t
	 (widget-create-child-value
	  widget '(item) "Dude, this is too weird"))))

(defun key-sequence-value-create (widget)
  (let ((value (widget-default-get widget))
	(map (or (widget-ancestor-get widget :keymap)
		 (current-global-map)));; FIXME
	(button (widget-create-child-and-convert
		 widget '(key-sequence-button)))
	(field (widget-create-child-value
		widget '(key-sequence-field :format " %vOld binding: ")
		(widget-get widget :value))))
    (let* ((command (condition-case nil
			(lookup-key map (read-kbd-macro value))
		      (error nil)))
	   (binding (key-sequence-describe widget command)))
      (widget-put widget :children (list field))
      (widget-put widget :buttons (list binding button)))))

(defun key-sequence-notify (widget child &optional event)
  "Update the old binding, and notify parent."
  (let* ((buttons (widget-get widget :buttons))
	 (binding (car buttons))
	 (children (widget-get widget :buttons))
	 (field (car children))
	 (value (widget-value child))
	 (map (or (widget-ancestor-get widget :keymap)
		  (current-global-map)));; FIXME
	 (command (condition-case nil
		      (lookup-key map (read-kbd-macro value))
		    (error nil))))
    (save-excursion
      (goto-char (widget-get binding :from))
      (widget-delete binding)
      (setcar buttons (key-sequence-describe widget command))))
  (widget-default-notify widget child event))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (commandp (widget-value widget))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(defmacro defkeymap (symbol map doc &rest args)
  "Define SYMBOL to be a keymap with value MAP.
DOC is the keymap documentation."
  ;; It is better not to use backquote in this file,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (nconc (list 'custom-declare-keymap
	       (list 'quote symbol)
	       (list 'quote map)
	       doc)
	 args))

(defun custom-declare-keymap (symbol map doc &rest args)
  "Like `defkeymap', but SYMBOL and MAP are evaluated as normal arguments.
MAP should be an expression to evaluate to compute the default value,
not the default value itself.  The DOC string will be expanded with
some standard instructions for customization."
  ;; Keymaps are variables.  The only difference is that we know lots
  ;; of defcustom properties already.
  (setq doc (concat doc
		    "\n
While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of the command, you can use M-TAB to complete
it."))
  (apply 'custom-declare-variable symbol map doc 
	 :type '(repeat (group key-sequence command))
	 :set 'custom-set-keymap
	 :get 'custom-get-keymap
	 args))

(defun custom-set-keymap (sym bindings)
  "Update keymap SYM with BINDINGS.
This also does the necessary book-keeping to save away shadowed bindings
and restoring them if necessary."
  (let ((standard-bindings (eval (car (get sym 'standard-value))))
	(old-bindings (car (get sym 'custom-bindings))))
    ;; When defkeymap is called for the first time, BINDINGS is the
    ;; standard-value.  When customized, BINDINGS is no longer a
    ;; keymap but an alist of bindings.
    (if (equal bindings standard-bindings)
	(set-default sym standard-bindings)
      ;; remove all keys no longer in bindings
      (mapc (lambda (bind)
	      (unless (assoc (car bind) bindings)
		(custom-remove-key sym (read-kbd-macro (car bind)))))
	    old-bindings)
      ;; define all keys in bindings
      (mapc (lambda (bind)
	      (custom-add-key sym (read-kbd-macro (car bind)) (cadr bind)))
	    bindings)
      ;; store the current bindings away
      (put sym 'custom-bindings (list bindings)))))

(defun custom-get-keymap (sym)
  "Return the additions to the standard-value of keymap SYM.
These additions are stored in the custom-bindings property by
`custom-set-keymap'."
  (car (get sym 'custom-bindings)))

(defun custom-add-key (sym key def)
  "Add KEY to the keymap stored in SYM with definition DEF.
The shadowed binding is stored, if none has been stored before.  The
shadowed bindings are stored in the custom-bindings-shadow property."
  (let* ((map (symbol-value sym))
	 (old-binding (lookup-key map key))
	 (shadows (get sym 'custom-bindings-shadow))
	 (shadow-binding (cdr (assoc key shadows))))
    (when (and old-binding (not shadow-binding))
      (put sym 'custom-bindings-shadow (cons (cons key old-binding) shadows)))
    (define-key map key def)))

(defun custom-remove-key (sym key)
  "Remove KEY from the keymap stored in SYM.
The shadowed binding is restored, if there is one."
  (let ((def (cdr (assoc key (get sym 'custom-bindings-shadow))))
	(map (symbol-value sym)))
    ;; when DEF is nil, this is a valid binding
    (define-key map key def)))

;; Example:

(defkeymap my-keymap
  (let ((map (make-sparse-keymap)))
    (define-key map (read-kbd-macro "<f11>") 'bbdb)
    map)
  "Keymap to demonstrate `defkeymap'.")

;; my-keymap
;; (keymapp my-keymap)
;; (apropos "my-keymap")
;; (custom-get-keymap 'my-keymap)
;; (put 'my-keymap 'custom-bindings nil)
;; (get 'my-keymap 'standard-value)
;; (customize-option 'my-keymap)
;; (unintern 'my-keymap)

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> I think this does the right thing, now -- it modifies the keymap
> directly.  It can restore bindings because it keeps a list of settings
> it shadows.  Currently the documentation shown in the customize buffer
> is from the global map, this still needs fixing.  See the FIXME
> tags...  :)

Well, this is the 90% solution, where removing a custom bindings will
work in the common case that it hasn't been changed through Lisp since
it was added.

> 	 :type '(repeat (group key-sequence command))

I think you should use the key-binding widget, as we might want to
allow key-sequence and command to talk to each other later.
E.g. implement the feature RMS suggested, that entering a key-sequence
should initialize the command field, if not already set.

Re: Customizing key bindings

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Alex Schroeder <alex@emacswiki.org> writes:
>
>> I think this does the right thing, now -- it modifies the keymap
>> directly.  It can restore bindings because it keeps a list of settings
>> it shadows.  Currently the documentation shown in the customize buffer
>> is from the global map, this still needs fixing.  See the FIXME
>> tags...  :)
>
> Well, this is the 90% solution, where removing a custom bindings will
> work in the common case that it hasn't been changed through Lisp since
> it was added.

Right.  Now we can change define-key to also do the necessary
book-keeping, updating the shadowed bindings...  Or something like
that, if somebody wants to really fix this.

>
>> 	 :type '(repeat (group key-sequence command))
>
> I think you should use the key-binding widget, as we might want to
> allow key-sequence and command to talk to each other later.
> E.g. implement the feature RMS suggested, that entering a key-sequence
> should initialize the command field, if not already set.

key-binding widget?  I must have missed that.  Will look at the old
mails.  Unfortunately I already have 17 messages in this thread marked
as important, so it gets more difficult to put it all into context,
hehe.

Alex.

Re: Customizing key bindings

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I think you should use the key-binding widget

Done.  I also removed some global-map cruft I still had in the file.

Alex.


;;; cus-key.el -- Customize support for changing key bindings.

(require 'wid-edit)

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  :validate 'key-sequence-field-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-field-validate (widget)
  (let ((value (widget-apply widget :value-get)))
    (condition-case nil
	(progn 
	  (read-kbd-macro value)
	  nil)
      (error widget))))

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'default
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :format "%v"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get
  :validate 'widget-children-validate
  :notify 'key-sequence-notify)

(defun key-sequence-match (widget value)
  (stringp value))

(defun widget-ancestor-get (widget property &optional predicate)
  "Starting from WIDGET, return the value of PROPERTY.
The value of PROPERTY will only be returned if it satisfies PREDICATE.
PREDICATE is a function accepting one parameter, the value of PROPERTY.
If PROPERTY is not specified or nil in WIDGET and the :parent property is 
non-nil, call `widget-ancestor-get' recusively with the value of the :parent
property.  Otherwise, return nil."
  (cond ((and predicate
	      (widget-get widget property)
	      (funcall predicate (widget-get widget property)))
	 (widget-get widget property))
	((and (not predicate)
	      (widget-get widget property)))
	((widget-get widget :parent)
	 (widget-ancestor-get (widget-get widget :parent) property predicate))
	(nil)))

(defun key-sequence-find-map (widget)
  "Find the map that WIDGET is supposed to customize."
  (let ((sym (widget-ancestor-get
	      widget :value
	      (lambda (sym)
		(and (symbolp sym)
		     (boundp sym)
		     (keymapp (symbol-value sym)))))))
    (if sym
	(symbol-value sym)
      (current-global-map))))

(defun key-sequence-describe (widget command)
  "Create a child to WIDGET that describes COMMAND.
The child widget is returned."
  (cond ((functionp command)
	 (widget-create-child-value 
	  widget '(function-item) command))
	((null command)
	 (widget-create-child-value
	  widget '(item) "Undefined"))
	((numberp command)
	 (widget-create-child-value
	  widget '(item) "Binding too long"))
	((keymapp command)
	 (widget-create-child-value
	  widget '(item) "Prefix key"))
	(t
	 (widget-create-child-value
	  widget '(item) "Dude, this is too weird"))))

(defun key-sequence-value-create (widget)
  (let ((value (widget-default-get widget))
	(map (key-sequence-find-map widget))
	(button (widget-create-child-and-convert
		 widget '(key-sequence-button)))
	(field (widget-create-child-value
		widget '(key-sequence-field :format " %vOld binding: ")
		(widget-get widget :value))))
    (let* ((command (condition-case nil
			(lookup-key map (read-kbd-macro value))
		      (error nil)))
	   (binding (key-sequence-describe widget command)))
      (widget-put widget :children (list field))
      (widget-put widget :buttons (list binding button)))))

(defun key-sequence-notify (widget child &optional event)
  "Update the old binding, and notify parent."
  (let* ((buttons (widget-get widget :buttons))
	 (binding (car buttons))
	 (children (widget-get widget :buttons))
	 (field (car children))
	 (value (widget-value child))
	 (map (key-sequence-find-map widget))
	 (command (condition-case nil
		      (lookup-key map (read-kbd-macro value))
		    (error nil))))
    (save-excursion
      (goto-char (widget-get binding :from))
      (widget-delete binding)
      (setcar buttons (key-sequence-describe widget command))))
  (widget-default-notify widget child event))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (commandp (widget-value widget))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(define-widget 'key-binding 'group
  "Bind a key sequence to a command."
  :value '("" ignore)
  :indent 0
  :args '(key-sequence (command :tag "New binding")))

(defmacro defkeymap (symbol map doc &rest args)
  "Define SYMBOL to be a keymap with value MAP.
DOC is the keymap documentation."
  ;; It is better not to use backquote in this file,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (nconc (list 'custom-declare-keymap
	       (list 'quote symbol)
	       (list 'quote map)
	       doc)
	 args))

(defun custom-declare-keymap (symbol map doc &rest args)
  "Like `defkeymap', but SYMBOL and MAP are evaluated as normal arguments.
MAP should be an expression to evaluate to compute the default value,
not the default value itself.  The DOC string will be expanded with
some standard instructions for customization."
  ;; Keymaps are variables.  The only difference is that we know lots
  ;; of defcustom properties already.
  (setq doc (concat doc
		    "\n
While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of the command, you can use M-TAB to complete
it."))
  (apply 'custom-declare-variable symbol map doc 
	 :type '(repeat key-binding)
	 :set 'custom-set-keymap
	 :get 'custom-get-keymap
	 args))

(defun custom-set-keymap (sym bindings)
  "Update keymap SYM with BINDINGS.
This also does the necessary book-keeping to save away shadowed bindings
and restoring them if necessary."
  (let ((standard-bindings (eval (car (get sym 'standard-value))))
	(old-bindings (car (get sym 'custom-bindings))))
    ;; When defkeymap is called for the first time, BINDINGS is the
    ;; standard-value.  When customized, BINDINGS is no longer a
    ;; keymap but an alist of bindings.
    (if (equal bindings standard-bindings)
	(set-default sym standard-bindings)
      ;; remove all keys no longer in bindings
      (mapc (lambda (bind)
	      (unless (assoc (car bind) bindings)
		(custom-remove-key sym (read-kbd-macro (car bind)))))
	    old-bindings)
      ;; define all keys in bindings
      (mapc (lambda (bind)
	      (custom-add-key sym (read-kbd-macro (car bind)) (cadr bind)))
	    bindings)
      ;; store the current bindings away
      (put sym 'custom-bindings (list bindings)))))

(defun custom-get-keymap (sym)
  "Return the additions to the standard-value of keymap SYM.
These additions are stored in the custom-bindings property by
`custom-set-keymap'."
  (car (get sym 'custom-bindings)))

(defun custom-add-key (sym key def)
  "Add KEY to the keymap stored in SYM with definition DEF.
The shadowed binding is stored, if none has been stored before.  The
shadowed bindings are stored in the custom-bindings-shadow property."
  (let* ((map (symbol-value sym))
	 (old-binding (lookup-key map key))
	 (shadows (get sym 'custom-bindings-shadow))
	 (shadow-binding (cdr (assoc key shadows))))
    (when (and old-binding (not shadow-binding))
      (put sym 'custom-bindings-shadow (cons (cons key old-binding) shadows)))
    (define-key map key def)))

(defun custom-remove-key (sym key)
  "Remove KEY from the keymap stored in SYM.
The shadowed binding is restored, if there is one."
  (let ((def (cdr (assoc key (get sym 'custom-bindings-shadow))))
	(map (symbol-value sym)))
    ;; when DEF is nil, this is a valid binding
    (define-key map key def)))

;; Example:

(defkeymap my-keymap
  (let ((map (make-sparse-keymap)))
    (define-key map (read-kbd-macro "<f11>") 'bbdb)
    map)
  "Keymap to demonstrate `defkeymap'.")

;; my-keymap
;; (keymapp my-keymap)
;; (apropos "my-keymap")
;; (custom-get-keymap 'my-keymap)
;; (put 'my-keymap 'custom-bindings nil)
;; (get 'my-keymap 'standard-value)
;; (customize-option 'my-keymap)
;; (unintern 'my-keymap)

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings

[Alex Schroeder]

Alex Schroeder <alex@emacswiki.org> writes:

> (defun key-sequence-value-create (widget)
>   (let ((value (widget-default-get widget))
> 	(map (or (widget-ancestor-get widget :keymap)
> 		 (current-global-map)));; FIXME
> 	(button (widget-create-child-and-convert
> 		 widget '(key-sequence-button)))
> 	(field (widget-create-child-value
> 		widget '(key-sequence-field :format " %vOld binding: ")
> 		(widget-get widget :value))))
>     (let* ((command (condition-case nil
> 			(lookup-key map (read-kbd-macro value))
> 		      (error nil)))
> 	   (binding (key-sequence-describe widget command)))
>       (widget-put widget :children (list field))
>       (widget-put widget :buttons (list binding button)))))

Hm, I played around with the widget-browser for the first time.  Nice
piece of work.  :)  It helped me solve a problem.  New version is
attached.  Save it, load it, then M-x customize-option my-keymap and
play around with it.  The only key that has an old binding in
my-keymap is f11.

The problem with the code above is that none of the parents has a
correct :keymap property.  What we need, here, is to either set an
appropriate property from custom-declare-keymap (how?), or to search
for something else:  We need the first parent having a :value property
that is a keymap.  What do you think?

Widget object browser.
Class: custom-variable
:documentation-shown
	t
:custom-state
	changed
:tag
	"My Keymap"
:value
	my-keymap

Here is a way to implement this.

(defun widget-ancestor-get (widget property &optional predicate)
  "Starting from WIDGET, return the value of PROPERTY.
The value of PROPERTY will only be returned if it satisfies PREDICATE.
PREDICATE is a function accepting one parameter, the value of PROPERTY.
If PROPERTY is not specified or nil in WIDGET and the :parent property is 
non-nil, call `widget-ancestor-get' recusively with the value of the :parent
property.  Otherwise, return nil."
  (cond ((and predicate
	      (widget-get widget property)
	      (funcall predicate (widget-get widget property)))
	 (widget-get widget property))
	((and (not predicate)
	      (widget-get widget property)))
	((widget-get widget :parent)
	 (widget-ancestor-get (widget-get widget :parent) property))
	(nil)))

Then we can use the following helper (assuming that
widget-ancestor-get will be used in other contexts in the future,
eventhough it is defined in cus-key.el only at the moment):

(defun key-sequence-find-map (widget)
  "Find the map that WIDGET is supposed to customize."
  (let ((sym (widget-ancestor-get
	      widget :value
	      (lambda (sym)
		(and (symbolp sym)
		     (boundp sym)
		     (keymapp (symbol-value sym)))))))
    (if sym
	(symbol-value sym)
      (current-global-map))))

I have retained the alternative (current-global-map), but I don't know
when it would ever be used...  If it ever got used, that would
indicate a bug to me.  What do you think, Per?

Alex.


;;; cus-key.el -- Customize support for changing key bindings.

(require 'wid-edit)

(defvar custom-global-keymap (let ((map (make-sparse-keymap)))
			       (set-keymap-parent map global-map)
			       map)
  "Global keymap for use by Customize.

This is automatically generated from `global-key-bindings', you should 
never change this manually.  Instead, change either `global-map' from Lisp 
or `global-key-bindings' from Customize.")

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  :validate 'key-sequence-field-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-field-validate (widget)
  (let ((value (widget-apply widget :value-get)))
    (condition-case nil
	(progn 
	  (read-kbd-macro value)
	  nil)
      (error widget))))

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'default
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :format "%v"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get
  :validate 'widget-children-validate
  :notify 'key-sequence-notify)

(defun key-sequence-match (widget value)
  (stringp value))

(defun widget-ancestor-get (widget property &optional predicate)
  "Starting from WIDGET, return the value of PROPERTY.
The value of PROPERTY will only be returned if it satisfies PREDICATE.
PREDICATE is a function accepting one parameter, the value of PROPERTY.
If PROPERTY is not specified or nil in WIDGET and the :parent property is 
non-nil, call `widget-ancestor-get' recusively with the value of the :parent
property.  Otherwise, return nil."
  (cond ((and predicate
	      (widget-get widget property)
	      (funcall predicate (widget-get widget property)))
	 (widget-get widget property))
	((and (not predicate)
	      (widget-get widget property)))
	((widget-get widget :parent)
	 (widget-ancestor-get (widget-get widget :parent) property predicate))
	(nil)))

(defun key-sequence-find-map (widget)
  "Find the map that WIDGET is supposed to customize."
  (let ((sym (widget-ancestor-get
	      widget :value
	      (lambda (sym)
		(and (symbolp sym)
		     (boundp sym)
		     (keymapp (symbol-value sym)))))))
    (if sym
	(symbol-value sym)
      (current-global-map))))

(defun key-sequence-describe (widget command)
  "Create a child to WIDGET that describes COMMAND.
The child widget is returned."
  (cond ((functionp command)
	 (widget-create-child-value 
	  widget '(function-item) command))
	((null command)
	 (widget-create-child-value
	  widget '(item) "Undefined"))
	((numberp command)
	 (widget-create-child-value
	  widget '(item) "Binding too long"))
	((keymapp command)
	 (widget-create-child-value
	  widget '(item) "Prefix key"))
	(t
	 (widget-create-child-value
	  widget '(item) "Dude, this is too weird"))))

(defun key-sequence-value-create (widget)
  (let ((value (widget-default-get widget))
	(map (key-sequence-find-map widget))
	(button (widget-create-child-and-convert
		 widget '(key-sequence-button)))
	(field (widget-create-child-value
		widget '(key-sequence-field :format " %vOld binding: ")
		(widget-get widget :value))))
    (let* ((command (condition-case nil
			(lookup-key map (read-kbd-macro value))
		      (error nil)))
	   (binding (key-sequence-describe widget command)))
      (widget-put widget :children (list field))
      (widget-put widget :buttons (list binding button)))))

(defun key-sequence-notify (widget child &optional event)
  "Update the old binding, and notify parent."
  (let* ((buttons (widget-get widget :buttons))
	 (binding (car buttons))
	 (children (widget-get widget :buttons))
	 (field (car children))
	 (value (widget-value child))
	 (map (key-sequence-find-map widget))
	 (command (condition-case nil
		      (lookup-key map (read-kbd-macro value))
		    (error nil))))
    (save-excursion
      (goto-char (widget-get binding :from))
      (widget-delete binding)
      (setcar buttons (key-sequence-describe widget command))))
  (widget-default-notify widget child event))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (commandp (widget-value widget))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(defmacro defkeymap (symbol map doc &rest args)
  "Define SYMBOL to be a keymap with value MAP.
DOC is the keymap documentation."
  ;; It is better not to use backquote in this file,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (nconc (list 'custom-declare-keymap
	       (list 'quote symbol)
	       (list 'quote map)
	       doc)
	 args))

(defun custom-declare-keymap (symbol map doc &rest args)
  "Like `defkeymap', but SYMBOL and MAP are evaluated as normal arguments.
MAP should be an expression to evaluate to compute the default value,
not the default value itself.  The DOC string will be expanded with
some standard instructions for customization."
  ;; Keymaps are variables.  The only difference is that we know lots
  ;; of defcustom properties already.
  (setq doc (concat doc
		    "\n
While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of the command, you can use M-TAB to complete
it."))
  (apply 'custom-declare-variable symbol map doc 
	 :type '(repeat (group key-sequence command))
	 :set 'custom-set-keymap
	 :get 'custom-get-keymap
	 args))

(defun custom-set-keymap (sym bindings)
  "Update keymap SYM with BINDINGS.
This also does the necessary book-keeping to save away shadowed bindings
and restoring them if necessary."
  (let ((standard-bindings (eval (car (get sym 'standard-value))))
	(old-bindings (car (get sym 'custom-bindings))))
    ;; When defkeymap is called for the first time, BINDINGS is the
    ;; standard-value.  When customized, BINDINGS is no longer a
    ;; keymap but an alist of bindings.
    (if (equal bindings standard-bindings)
	(set-default sym standard-bindings)
      ;; remove all keys no longer in bindings
      (mapc (lambda (bind)
	      (unless (assoc (car bind) bindings)
		(custom-remove-key sym (read-kbd-macro (car bind)))))
	    old-bindings)
      ;; define all keys in bindings
      (mapc (lambda (bind)
	      (custom-add-key sym (read-kbd-macro (car bind)) (cadr bind)))
	    bindings)
      ;; store the current bindings away
      (put sym 'custom-bindings (list bindings)))))

(defun custom-get-keymap (sym)
  "Return the additions to the standard-value of keymap SYM.
These additions are stored in the custom-bindings property by
`custom-set-keymap'."
  (car (get sym 'custom-bindings)))

(defun custom-add-key (sym key def)
  "Add KEY to the keymap stored in SYM with definition DEF.
The shadowed binding is stored, if none has been stored before.  The
shadowed bindings are stored in the custom-bindings-shadow property."
  (let* ((map (symbol-value sym))
	 (old-binding (lookup-key map key))
	 (shadows (get sym 'custom-bindings-shadow))
	 (shadow-binding (cdr (assoc key shadows))))
    (when (and old-binding (not shadow-binding))
      (put sym 'custom-bindings-shadow (cons (cons key old-binding) shadows)))
    (define-key map key def)))

(defun custom-remove-key (sym key)
  "Remove KEY from the keymap stored in SYM.
The shadowed binding is restored, if there is one."
  (let ((def (cdr (assoc key (get sym 'custom-bindings-shadow))))
	(map (symbol-value sym)))
    ;; when DEF is nil, this is a valid binding
    (define-key map key def)))

;; Example:

(defkeymap my-keymap
  (let ((map (make-sparse-keymap)))
    (define-key map (read-kbd-macro "<f11>") 'bbdb)
    map)
  "Keymap to demonstrate `defkeymap'.")

;; my-keymap
;; (keymapp my-keymap)
;; (apropos "my-keymap")
;; (custom-get-keymap 'my-keymap)
;; (put 'my-keymap 'custom-bindings nil)
;; (get 'my-keymap 'standard-value)
;; (customize-option 'my-keymap)
;; (unintern 'my-keymap)

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> The problem with the code above is that none of the parents has a
> correct :keymap property.  What we need, here, is to either set an
> appropriate property from custom-declare-keymap (how?), 


We probably should not use :keymap, as that already has a meaning for
the ediatble-field widget, but somthing else, like
:key-sequence-keymap.

We should also allow a symbol, then the symbol value will be used.

(defun key-sequence-value-create (widget)
  (let ((value (widget-default-get widget))
	(map (or (widget-ancestor-get widget :key-sequence-keymap)
		 (current-global-map)))
	(button (widget-create-child-and-convert
		 widget '(key-sequence-button)))
	(field (widget-create-child-value
		widget '(key-sequence-field :format " %vOld binding: ")
		(widget-get widget :value))))
    (when (symbolp map)
      (setq (map (symbol-value map))))
    (let* ((command (condition-case nil
			(lookup-key map (read-kbd-macro value))
		      (error nil)))
	   (binding (key-sequence-describe widget command)))
      (widget-put widget :children (list field))
      (widget-put widget :buttons (list binding button)))))

Then we can store it in the type:

(defun custom-declare-keymap (symbol map doc &rest args)
  ;; cut
  (apply 'custom-declare-variable symbol map doc 
	 :type `(repeat :key-sequence-keymap ,symbol key-binding)
	 :set 'custom-set-keymap
	 :get 'custom-get-keymap
	 args))


> or to search for something else: We need the first parent having a
> :value property that is a keymap.  What do you think?

I think this is close to being a layer violation.  The key-sequence
widget can be useful in many other widget applications than customize,
and looking in the :value field seem somewhat arbitrary.

If this code ever gets accepted, all the widget stuff should go to
wid-edit.el. 

> I have retained the alternative (current-global-map), but I don't know
> when it would ever be used...  If it ever got used, that would
> indicate a bug to me.  What do you think, Per?

Maybe the default should be nil, meaning to use key-binding instead of
lookup-key.  For use outside customize.

Re: Customizing key bindings

[Alex Schroeder]

I included the changes by Per for the :key-sequence-keymap property,
reverted my changes to widget-get-ancestor, etc.

I also allow nil for the command widget, atm.  Perhaps a better
solution needs to be found (a choice widget?).  The benefit of
allowing nil is that this automatically results in that key being
undefined (since the code eventually calls define-key with DEF being
nil).  I like this much better than having two lists, one with keys to
add and one with keys to remove...

While playing around with emacs-lisp-mode-map (see below), I was still
vexed a few times.  At one time, it seemed that setting customizations
for the current session did not change the keybindings for all
emacs-lisp-mode buffers.  I had to run M-x emacs-lisp-mode to achieve
that.  The next time it worked, however.  Adding bindings, deleting
them again, and defining them to nil seemed to work as well, but
suddenly I had a situation where I thought I had undone all
customizations, but my test-key still had one of the bindings I had
added before.  So I hope other people will take the example below and
spend a few minutes fooling around with it.

To test saving and loading, I proceeded as follows, with an emacs that
had no customizations set and custom-file set to "~/.custom.el".

Store the value of a keymap in a variable.
Load the code.

(setq test emacs-lisp-mode-map)
(load-file "~/elisp/cus-key.el")

Now simulate a call to defkeymap.

(defkeymap emacs-lisp-mode-map test "foo")

Customize it, add a new keybinding, save for future sessions.

(customize-option 'emacs-lisp-mode-map)

Now save the following in test.el and start emacs -q -l test.el:

(require 'lisp-mode)
(setq test emacs-lisp-mode-map)
(load-file "~/elisp/cus-key.el")
(defkeymap emacs-lisp-mode-map test "foo")
(load-file "~/.custom.el")
;; (customize-option 'emacs-lisp-mode-map)

The new emacs-lisp-mode-map should contain your new binding, and
it should be customizable.

Now switch between the Customization buffer and *scratch* to test
stuff using C-h k.

Alex.

Re: Customizing key bindings

[Alex Schroeder]

;;; cus-key.el -- Customize support for changing key bindings.

(require 'wid-edit)

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  :validate 'key-sequence-field-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-field-validate (widget)
  (let ((value (widget-apply widget :value-get)))
    (condition-case nil
	(progn 
	  (read-kbd-macro value)
	  nil)
      (error widget))))

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'default
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :format "%v"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get
  :validate 'widget-children-validate
  :notify 'key-sequence-notify)

(defun key-sequence-match (widget value)
  (stringp value))

(defun widget-ancestor-get (widget property)
  "Starting from WIDGET, return the value of PROPERTY.
If PROPERTY is not specified or nil in WIDGET and the :parent property is 
non-nil, call `widget-ancestor-get' recusively with the value of the :parent
property.  Otherwise, return nil."
  (cond ((widget-get widget property))
	((widget-get widget :parent)
	 (widget-ancestor-get (widget-get widget :parent) property))
	(nil)))

(defun key-sequence-describe (widget command)
  "Create a child to WIDGET that describes COMMAND.
The child widget is returned."
  (cond ((functionp command)
	 (widget-create-child-value 
	  widget '(function-item) command))
	((null command)
	 (widget-create-child-value
	  widget '(item) "Undefined"))
	((numberp command)
	 (widget-create-child-value
	  widget '(item) "Binding too long"))
	((keymapp command)
	 (widget-create-child-value
	  widget '(item) "Prefix key"))
	(t
	 (widget-create-child-value
	  widget '(item) "Dude, this is too weird"))))

(defun key-sequence-value-create (widget)
  (let ((value (widget-default-get widget))
	(map (or (widget-ancestor-get widget :key-sequence-keymap)
		 (current-global-map)))
	(button (widget-create-child-and-convert
		 widget '(key-sequence-button)))
	(field (widget-create-child-value
		widget '(key-sequence-field :format " %vOld binding: ")
		(widget-get widget :value))))
    (when (symbolp map)
      (setq map (symbol-value map)))
    (let* ((command (condition-case nil
			(lookup-key map (read-kbd-macro value))
		      (error nil)))
	   (binding (key-sequence-describe widget command)))
      (widget-put widget :children (list field))
      (widget-put widget :buttons (list binding button)))))

(defun key-sequence-notify (widget child &optional event)
  "Update the old binding, and notify parent."
  (let* ((buttons (widget-get widget :buttons))
	 (binding (car buttons))
	 (children (widget-get widget :buttons))
	 (field (car children))
	 (value (widget-value child))
	 (map (key-sequence-find-map widget))
	 (command (condition-case nil
		      (lookup-key map (read-kbd-macro value))
		    (error nil))))
    (save-excursion
      (goto-char (widget-get binding :from))
      (widget-delete binding)
      (setcar buttons (key-sequence-describe widget command))))
  (widget-default-notify widget child event))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (or (not (widget-value widget))
			  (commandp (widget-value widget)))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(define-widget 'key-binding 'group
  "Bind a key sequence to a command."
  :value '("" ignore)
  :indent 0
  :args '(key-sequence (command :tag "New binding")))

(defmacro defkeymap (symbol map doc &rest args)
  "Define SYMBOL to be a keymap with value MAP.
DOC is the keymap documentation."
  ;; It is better not to use backquote in this file,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (nconc (list 'custom-declare-keymap
	       (list 'quote symbol)
	       (list 'quote map)
	       doc)
	 args))

(defun custom-declare-keymap (symbol map doc &rest args)
  "Like `defkeymap', but SYMBOL and MAP are evaluated as normal arguments.
MAP should be an expression to evaluate to compute the default value,
not the default value itself.  The DOC string will be expanded with
some standard instructions for customization."
  ;; Keymaps are variables.  The only difference is that we know lots
  ;; of defcustom properties already.
  (setq doc (concat doc
		    "\n
While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of the command, you can use M-TAB to complete
it."))
  (apply 'custom-declare-variable symbol map doc 
	 :type `(repeat :key-sequence-keymap ,symbol key-binding)
	 :set 'custom-set-keymap
	 :get 'custom-get-keymap
	 args))

(defun custom-set-keymap (sym bindings)
  "Update keymap SYM with BINDINGS.
This also does the necessary book-keeping to save away shadowed bindings
and restoring them if necessary."
  (let ((standard-bindings (eval (car (get sym 'standard-value))))
	(old-bindings (car (get sym 'custom-bindings))))
    ;; When defkeymap is called for the first time, BINDINGS is the
    ;; standard-value.  When customized, BINDINGS is no longer a
    ;; keymap but an alist of bindings.  In this case, OLD-BINDINGS is
    ;; what the user customized the last time, BINDINGS is what the
    ;; user wants this time.
    (if (equal bindings standard-bindings)
	(set-default sym standard-bindings)
      (mapc (lambda (bind)
	      (unless (assoc (car bind) bindings)
		(custom-remove-key sym (read-kbd-macro (car bind)))))
	    old-bindings)
      (mapc (lambda (bind)
	      (custom-add-key sym (read-kbd-macro (car bind)) (cadr bind)))
	    bindings)
      (put sym 'custom-bindings (list bindings)))))

(defun custom-get-keymap (sym)
  "Return the additions to the standard-value of keymap SYM.
These additions are stored in the custom-bindings property by
`custom-set-keymap'."
  (car (get sym 'custom-bindings)))

(defun custom-add-key (sym key def)
  "Add KEY to the keymap stored in SYM with definition DEF.
The shadowed binding is stored, if none has been stored before.  The
shadowed bindings are stored in the custom-bindings-shadow property."
  (let* ((map (symbol-value sym))
	 (old-binding (lookup-key map key))
	 (shadows (get sym 'custom-bindings-shadow))
	 (shadow-binding (cdr (assoc key shadows))))
    (when (and old-binding (not shadow-binding))
      (put sym 'custom-bindings-shadow (cons (cons key old-binding) shadows)))
    (define-key map key def)))

(defun custom-remove-key (sym key)
  "Remove KEY from the keymap stored in SYM.
The shadowed binding is restored, if there is one."
  (let ((def (cdr (assoc key (get sym 'custom-bindings-shadow))))
	(map (symbol-value sym)))
    ;; when DEF is nil, this is a valid binding
    (define-key map key def)))

;; Example:

(defkeymap my-keymap
  (let ((map (make-sparse-keymap)))
    (define-key map (read-kbd-macro "<f11>") 'bbdb)
    map)
  "Keymap to demonstrate `defkeymap'.")

;; my-keymap
;; (keymapp my-keymap)
;; (apropos "my-keymap")
;; (custom-get-keymap 'my-keymap)
;; (put 'my-keymap 'custom-bindings nil)
;; (get 'my-keymap 'standard-value)
;; (customize-option 'my-keymap)
;; (unintern 'my-keymap)

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings

[Alex Schroeder]

Well, it turns out that my code did have some subtle bugs in it.

	* cus-key.el (key-sequence-field-validate): disallow "" as a
	keybinding.
	(key-sequence-notify): use :key-sequence-keymap, too.
	(custom-add-key): changed handling of shadow bindings so that it
	works even when the command is nil.

Note the example code at the end of the file, which I have been using
this last hour.  It works very nicely.

Things I did:  Customized f10 to a command, removed the customization,
customized f10 to a second command, customized f10 to a third command,
and checking the settings after every step.  I also customized M-TAB
(which is lisp-complete-symbol) to nil, and removed the setting
afterwards, checking after each step.

Removing the binding such that the binding from the global map
(complete-symbol) appeared, worked fine.  Removing the customization
correctly restored lisp-complete-symbol.

Saving and loading customizations (with the setup described in a
previous mail) worked as well.

All changes had immediate effect, so I assume that the few times when
I though this was not so, I had actually forgotten to add a key to the
customization.  This is why I now disallow "" keys when validating.

Except for the handling of nil, this seems "good enough" for me.  :)

Alex.

;;; cus-key.el -- Customize support for changing key bindings.

;; $Id: cus-key.el,v 1.9 2002/09/09 22:42:12 alex Exp $

(require 'wid-edit)

(defun quoted-key-insert (key)
  "Insert a string representation of the next key typed.
The string representation is a representation understood
by `read-kbd-macro'."
  (interactive "KPress a key: ")
  (insert (edmacro-format-keys key)))

(defvar key-sequence-widget-map 
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map widget-field-keymap)
    (define-key map (kbd "C-q") 'quoted-key-insert)
    map)
    "Keymap for the `key-sequence' widget.")
    
(define-widget 'key-sequence-field 'string
  "Field for entering key bindings."
  :tag "Key sequence"
  :error "Not a well-formed key sequence"
  :validate 'key-sequence-field-validate
  :keymap key-sequence-widget-map)

(defun key-sequence-field-validate (widget)
  (let ((value (widget-apply widget :value-get)))
    (condition-case nil
	(progn 
	  (when (string= value "")
	    (error widget))
	  (read-kbd-macro value)
	  nil)
      (error widget))))

(define-widget 'key-sequence-button 'push-button
  "Button for entering key bindings."
  :tag "Key sequence"
  :action 'key-sequence-button-action)

(defun key-sequence-button-action (widget &optional event)
  (let ((key (read-key-sequence "Press key sequence: ")))
    (widget-value-set (widget-get widget :parent)
		      (edmacro-format-keys key))
    (widget-setup)))

(define-widget 'key-sequence 'default
  "Widget for entering key bindings."
  :tag "Read key sequence"
  :match 'key-sequence-match
  :format "%v"
  :value ""
  :value-create 'key-sequence-value-create
  :value-delete 'widget-children-value-delete
  :value-get 'widget-choice-value-get
  :validate 'widget-children-validate
  :notify 'key-sequence-notify)

(defun key-sequence-match (widget value)
  (stringp value))

(defun widget-ancestor-get (widget property)
  "Starting from WIDGET, return the value of PROPERTY.
If PROPERTY is not specified or nil in WIDGET and the :parent property is 
non-nil, call `widget-ancestor-get' recusively with the value of the :parent
property.  Otherwise, return nil."
  (cond ((widget-get widget property))
	((widget-get widget :parent)
	 (widget-ancestor-get (widget-get widget :parent) property))
	(nil)))

(defun key-sequence-describe (widget command)
  "Create a child to WIDGET that describes COMMAND.
The child widget is returned."
  (cond ((functionp command)
	 (widget-create-child-value 
	  widget '(function-item) command))
	((null command)
	 (widget-create-child-value
	  widget '(item) "Undefined"))
	((numberp command)
	 (widget-create-child-value
	  widget '(item) "Binding too long"))
	((keymapp command)
	 (widget-create-child-value
	  widget '(item) "Prefix key"))
	(t
	 (widget-create-child-value
	  widget '(item) "Dude, this is too weird"))))

(defun key-sequence-value-create (widget)
  (let ((value (widget-default-get widget))
	(map (or (widget-ancestor-get widget :key-sequence-keymap)
		 (current-global-map)))
	(button (widget-create-child-and-convert
		 widget '(key-sequence-button)))
	(field (widget-create-child-value
		widget '(key-sequence-field :format " %vOld binding: ")
		(widget-get widget :value))))
    (when (symbolp map)
      (setq map (symbol-value map)))
    (let* ((command (condition-case nil
			(lookup-key map (read-kbd-macro value))
		      (error nil)))
	   (binding (key-sequence-describe widget command)))
      (widget-put widget :children (list field))
      (widget-put widget :buttons (list binding button)))))

(defun key-sequence-notify (widget child &optional event)
  "Update the old binding, and notify parent."
  (let* ((buttons (widget-get widget :buttons))
	 (binding (car buttons))
	 (children (widget-get widget :buttons))
	 (field (car children))
	 (value (widget-value child))
	 (map (or (widget-ancestor-get widget :key-sequence-keymap)
		  (current-global-map)))
	 (command (condition-case nil
		      (lookup-key map (read-kbd-macro value))
		    (error nil))))
    (save-excursion
      (goto-char (widget-get binding :from))
      (widget-delete binding)
      (setcar buttons (key-sequence-describe widget command))))
  (widget-default-notify widget child event))

(define-widget 'command 'function
  "An interactive Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-match 'commandp
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (or (not (widget-value widget))
			  (commandp (widget-value widget)))
		(widget-put widget :error (format "Invalid function: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(define-widget 'key-binding 'group
  "Bind a key sequence to a command."
  :value '("" ignore)
  :indent 0
  :args '(key-sequence (command :tag "New binding")))

(defmacro defkeymap (symbol map doc &rest args)
  "Define SYMBOL to be a keymap with value MAP.
DOC is the keymap documentation."
  ;; It is better not to use backquote in this file,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (nconc (list 'custom-declare-keymap
	       (list 'quote symbol)
	       (list 'quote map)
	       doc)
	 args))

(defun custom-declare-keymap (symbol map doc &rest args)
  "Like `defkeymap', but SYMBOL and MAP are evaluated as normal arguments.
MAP should be an expression to evaluate to compute the default value,
not the default value itself.  The DOC string will be expanded with
some standard instructions for customization."
  ;; Keymaps are variables.  The only difference is that we know lots
  ;; of defcustom properties already.
  (setq doc (concat doc
		    "\n
While entering the name of a key, you can either type keys yourself
just as they appear in the manual, as in C-c a.  You must use angle
brackets for function keys, as in <f7>.  You can also hit C-q and type
the key.  C-q will insert the correct string representation for you.
For longer sequences, you can also invoke the [Key sequence] button, 
and type the entire key sequence directly.

While entering the name of the command, you can use M-TAB to complete
it."))
  (apply 'custom-declare-variable symbol map doc 
	 :type `(repeat :key-sequence-keymap ,symbol key-binding)
	 :set 'custom-set-keymap
	 :get 'custom-get-keymap
	 args))

(defun custom-set-keymap (sym bindings)
  "Update keymap SYM with BINDINGS.
This also does the necessary book-keeping to save away shadowed bindings
and restoring them if necessary."
  (let ((standard-bindings (eval (car (get sym 'standard-value))))
	(old-bindings (car (get sym 'custom-bindings))))
    ;; When defkeymap is called for the first time, BINDINGS is the
    ;; standard-value.  When customized, BINDINGS is no longer a
    ;; keymap but an alist of bindings.  In this case, OLD-BINDINGS is
    ;; what the user customized the last time, BINDINGS is what the
    ;; user wants this time.
    (if (equal bindings standard-bindings)
	(set-default sym standard-bindings)
      (mapc (lambda (bind)
	      (unless (assoc (car bind) bindings)
		(custom-remove-key sym (read-kbd-macro (car bind)))))
	    old-bindings)
      (mapc (lambda (bind)
	      (custom-add-key sym (read-kbd-macro (car bind)) (cadr bind)))
	    bindings)
      (put sym 'custom-bindings (list bindings)))))

(defun custom-get-keymap (sym)
  "Return the additions to the standard-value of keymap SYM.
These additions are stored in the custom-bindings property by
`custom-set-keymap'."
  (car (get sym 'custom-bindings)))

(defun custom-add-key (sym key def)
  "Add KEY to the keymap stored in SYM with definition DEF.
The shadowed binding is stored, if none has been stored before.  The
shadowed bindings are stored in the custom-bindings-shadow property."
  (let* ((map (symbol-value sym))
	 (old-binding (lookup-key map key))
	 (shadows (get sym 'custom-bindings-shadow))
	 (shadow-binding (assoc key shadows)))
    (when (not shadow-binding)
      (put sym 'custom-bindings-shadow
	   (cons (cons key old-binding) shadows)))
    (define-key map key def)))

(defun custom-remove-key (sym key)
  "Remove KEY from the keymap stored in SYM.
The shadowed binding is restored, if there is one."
  (let ((def (cdr (assoc key (get sym 'custom-bindings-shadow))))
	(map (symbol-value sym)))
    ;; when DEF is nil, this is a valid binding
    (define-key map key def)))

;; Example:

;; (eval-buffer)
;; (setq test emacs-lisp-mode-map)
;; (defkeymap emacs-lisp-mode-map test "Elisp mode map for testing.")

;; (customize-option 'emacs-lisp-mode-map)
;; (apropos "emacs-lisp-mode-map")

(provide 'cus-key)

;;; cus-key.el ends here

Re: Customizing key bindings

[Stefan Monnier]

> (defun custom-add-key (sym key def)
>   "Add KEY to the keymap stored in SYM with definition DEF.
> The shadowed binding is stored, if none has been stored before.  The
> shadowed bindings are stored in the custom-bindings-shadow property."
>   (let* ((map (symbol-value sym))
> 	 (old-binding (lookup-key map key))

Note that

	(progn
	 (define-key map key '(menu-item "foo" a))
         (lookup-key map key)) => a

This should not be too harmful in practice, tho.


	Stefan

Re: Customizing key bindings

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> 	* cus-key.el (key-sequence-field-validate): disallow "" as a
> 	keybinding.

We may also want to disallow the creation of prefix keys, alt least
for now.  For example, Try to define "X Y" from customize.  Then
remove the binding from customize.  You will notice that "X" continues
to be a prefix key, even though "X Y" is no longer bound.

We should probably find a safe way to allow the user to create new
prefix keys, but for now, let's disallow it.

Actually, thinking about it, we _need_ to solve this, as otherwise the
user will not be able to bind e.g. "C-c x" for a mode that have no C-c
bindings already.

> Except for the handling of nil, this seems "good enough" for me.  :)

The patch below implements "Remove definition", add a check for too
long key bidnings in validate, and fix a bug with the notify function
that (did not) update the "Old binding".

*** cus-key2.el	Tue Sep 10 11:58:40 2002
--- cus-key3.el	Tue Sep 10 12:15:48 2002
***************
*** 26,39 ****
    :keymap key-sequence-widget-map)
  
  (defun key-sequence-field-validate (widget)
!   (let ((value (widget-apply widget :value-get)))
!     (condition-case nil
! 	(progn 
! 	  (when (string= value "")
! 	    (error widget))
! 	  (read-kbd-macro value)
! 	  nil)
!       (error widget))))
  
  (define-widget 'key-sequence-button 'push-button
    "Button for entering key bindings."
--- 26,64 ----
    :keymap key-sequence-widget-map)
  
  (defun key-sequence-field-validate (widget)
!   (let* ((value (widget-apply widget :value-get))
! 	 (map1 (or (widget-ancestor-get widget :key-sequence-keymap)
! 		  (current-global-map)))
! 	 (map (if (symbolp map1) (symbol-value map1) map1))
! 	 (key (condition-case nil
! 		  (read-kbd-macro value)
! 		nil))
! 	 (command (and key (lookup-key map key)))))
!   (cond ((null key)
! 	 ;; Unparsable.
! 	 widget)
! 	((string-equal key "")
! 	 ;; Empty prefix.  We can't rebind the entire keymap.
! 	 widget)
! 	((functionp command)
! 	 ;; Normal binding, OK.
! 	 nil)
! 	((null command)
! 	 ;; Unbound, OK.
! 	 nil)
! 	((numberp command)
! 	 ;; We can't allow the creation of new prefix keys, as we have
! 	 ;; no way to undo such a prefix
! 	 widget)
! 	((keymapp command)
! 	 ;; This will turn a prefix key into an ordinary binding.  A
! 	 ;; bit drastic (as many bindings can be lost), but the user
! 	 ;; asked for it.
! 	 nil)
! 	(t
! 	 ;; This is an impossible value according to the lookup-key doc
! 	 ;; string.  What to do?  Let the user deside.
! 	 nil)))
  
  (define-widget 'key-sequence-button 'push-button
    "Button for entering key bindings."
***************
*** 115,124 ****
  	 (children (widget-get widget :buttons))
  	 (field (car children))
  	 (value (widget-value child))
! 	 (map (or (widget-ancestor-get widget :key-sequence-keymap)
  		  (current-global-map)))
  	 (command (condition-case nil
! 		      (lookup-key map (read-kbd-macro value))
  		    (error nil))))
      (save-excursion
        (goto-char (widget-get binding :from))
--- 140,150 ----
  	 (children (widget-get widget :buttons))
  	 (field (car children))
  	 (value (widget-value child))
! 	 (map1 (or (widget-ancestor-get widget :key-sequence-keymap)
  		  (current-global-map)))
+ 	 (map (if (symbolp map1) (symbol-value map1) map1))
  	 (command (condition-case nil
! 		      (lookup-key map(read-kbd-macro value))
  		    (error nil))))
      (save-excursion
        (goto-char (widget-get binding :from))
***************
*** 134,152 ****
    :prompt-match 'commandp
    :match-alternatives '(commandp)
    :validate (lambda (widget)
! 	      (unless (or (not (widget-value widget))
! 			  (commandp (widget-value widget)))
  		(widget-put widget :error (format "Invalid function: %S"
  						  (widget-value widget)))
  		widget))
    :value 'ignore
    :tag "Command")
  
  (define-widget 'key-binding 'group
    "Bind a key sequence to a command."
    :value '("" ignore)
    :indent 0
!   :args '(key-sequence (command :tag "New binding")))
  
  (defmacro defkeymap (symbol map doc &rest args)
    "Define SYMBOL to be a keymap with value MAP.
--- 160,184 ----
    :prompt-match 'commandp
    :match-alternatives '(commandp)
    :validate (lambda (widget)
! 	      (unless (commandp (widget-value widget))
  		(widget-put widget :error (format "Invalid function: %S"
  						  (widget-value widget)))
  		widget))
    :value 'ignore
    :tag "Command")
  
+ (define-widget 'key-binding-value 'choice
+   "A valid key binding value for use by `define-key'.
+ This could be a command or nil."
+   :args '((const :tag "Remove definition" nil) )
+   :value 'ignore
+   :tag "New binding")
+ 
  (define-widget 'key-binding 'group
    "Bind a key sequence to a command."
    :value '("" ignore)
    :indent 0
!   :args '(key-sequence key-binding-value))
  
  (defmacro defkeymap (symbol map doc &rest args)
    "Define SYMBOL to be a keymap with value MAP.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

It looks basically good now.

    (defvar custom-global-keymap (let ((map (make-sparse-keymap)))
				   (set-keymap-parent map global-map)
				   map)

It looks like that is no longer used for anything.  Is it obsolete?

    (defmacro defkeymap (symbol map doc &rest args)
      "Define SYMBOL to be a keymap with value MAP.
    DOC is the keymap documentation."
      ;; It is better not to use backquote in this file,
      ;; because that makes a bootstrapping problem
      ;; if you need to recompile all the Lisp files using interpreted code.
      (nconc (list 'custom-declare-keymap
		   (list 'quote symbol)
		   (list 'quote map)
		   doc)
	     args))

It would be better to generate a defvar plus whatever other stuff
you need.

	  ;; remove all keys no longer in bindings
	  (mapc (lambda (bind)
		  (unless (assoc (car bind) bindings)
		    (custom-remove-key sym (read-kbd-macro (car bind)))))
		old-bindings)

I think that comment doesn't match the code.  The code removes all the
bindings in the previous list of customizations.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> It looks basically good now.
>
>     (defvar custom-global-keymap (let ((map (make-sparse-keymap)))
> 				   (set-keymap-parent map global-map)
> 				   map)
>
> It looks like that is no longer used for anything.  Is it obsolete?

Yes, totally.

>     (defmacro defkeymap (symbol map doc &rest args)
>       "Define SYMBOL to be a keymap with value MAP.
>     DOC is the keymap documentation."
>       ;; It is better not to use backquote in this file,
>       ;; because that makes a bootstrapping problem
>       ;; if you need to recompile all the Lisp files using interpreted code.
>       (nconc (list 'custom-declare-keymap
> 		   (list 'quote symbol)
> 		   (list 'quote map)
> 		   doc)
> 	     args))
>
> It would be better to generate a defvar plus whatever other stuff
> you need.

I prefer doing most of the work in functions rather than macros,
because if we change defkeymap in Emacs version X+1, then packages
compiled by the user in Emacs version X will call the new function,
and thus continue to work.  I had a lot of such problems with
easymenu.el.

It seems likely that we may want to change 'custom-declare-keymap'
after getting experience from a release, so this is a real concern.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    > It would be better to generate a defvar plus whatever other stuff
    > you need.

    I prefer doing most of the work in functions rather than macros,
    because if we change defkeymap in Emacs version X+1, then packages
    compiled by the user in Emacs version X will call the new function,
    and thus continue to work.  I had a lot of such problems with
    easymenu.el.

defvar does a number of things, and eval-defun-1 handles it specially,
so please do generate a defvar.  It is ok to do the rest with a
single function call.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     > It would be better to generate a defvar plus whatever other stuff
>     > you need.
>
>     I prefer doing most of the work in functions rather than macros,
>     because if we change defkeymap in Emacs version X+1, then packages
>     compiled by the user in Emacs version X will call the new function,
>     and thus continue to work.  I had a lot of such problems with
>     easymenu.el.
>
> defvar does a number of things, and eval-defun-1 handles it specially,
> so please do generate a defvar.  It is ok to do the rest with a
> single function call.

I don't quite understand the reason for this.  Can you explain?  And
what is the important part -- that (defkeymap ...) expand into (progn
(defvar ...) (custom-declare-keymap ...))?

Alex.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    I don't quite understand the reason for this.  Can you explain?

The reason is so that C-M-x on a defvar will reinitialize the
variable.  But it doesn't really matter--the point is that we want
to generate a defvar.

								     And
    what is the important part -- that (defkeymap ...) expand into (progn
    (defvar ...) (custom-declare-keymap ...))?

Yes, exactly.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> I don't quite understand the reason for this.  Can you explain?  And
> what is the important part -- that (defkeymap ...) expand into (progn
> (defvar ...) (custom-declare-keymap ...))?

An alternative would be to recognize defkeymap the same places defvar
and defcustom are recognized.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Richard Stallman]

    > I don't quite understand the reason for this.  Can you explain?  And
    > what is the important part -- that (defkeymap ...) expand into (progn
    > (defvar ...) (custom-declare-keymap ...))?

    An alternative would be to recognize defkeymap the same places defvar
    and defcustom are recognized.

That is a more complex and less modular solution.  It's better to make
it generate defvar.

Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..)

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     (defmacro defkeymap (symbol map doc &rest args)
>       "Define SYMBOL to be a keymap with value MAP.
>     DOC is the keymap documentation."
>       ;; It is better not to use backquote in this file,
>       ;; because that makes a bootstrapping problem
>       ;; if you need to recompile all the Lisp files using interpreted code.
>       (nconc (list 'custom-declare-keymap
> 		   (list 'quote symbol)
> 		   (list 'quote map)
> 		   doc)
> 	     args))
>
> It would be better to generate a defvar plus whatever other stuff
> you need.

Why?  The current custom code also has a macro deffoo that expands
into a call to custom-declare-foo.

> 	  ;; remove all keys no longer in bindings
> 	  (mapc (lambda (bind)
> 		  (unless (assoc (car bind) bindings)
> 		    (custom-remove-key sym (read-kbd-macro (car bind)))))
> 		old-bindings)
>
> I think that comment doesn't match the code.  The code removes all the
> bindings in the previous list of customizations.

I do not understand.  The code takes all entries in the alist
OLD-BINDINGS, and for each entry BIND, it checks wether the key (the
car of BIND) is already a member of the alist BINDINGS.  Only if it is
not, does the code do anything.  To me that translates: "remove all
keys from the map which are in old-bindings and not in bindings", and
the general idea is to undefine (call define-key with a DEF of nil)
all bindings that used to be in bindings (now called old-bindings) and
are no longer there.

Anyway, since the comment confuses, I will remove it altogether.  :)
Since I moved some of the code into custom-remove-key, it is much
easier on the eyes, anyway.

Alex.

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Sun, Sep 01, 2002 at 08:03:21AM +0200, huug wrote:
> By which standard was <f10> to do what?

It pops up the menus.

> Whatever it was, I cannot recall having encountered something even
> approaching a standard for it (nor does Notepad;)

The last time it was discussed, people came up with a list of things that use
F10; in any case, it was `enough to matter.'

> And <f1> may be standard, but Emacs doesn't adhere.  Minimally, it
> should do a C-h r, or better look up the current mode in the manual.

The only standardized thing about F1 is that it `brings up help' in some way.
The details vary widely over time and among different programs, and emacs'
method is as good as any.  As long as users know to hit it, they can follow
the prompts from there.

> Maybe change the behaviour of unbound keys from <beep> to
> (what-do-you-want-me-to-do)?

That sounds _extremely_ annoying...

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Eli Zaretskii]

On Sun, 1 Sep 2002, huug wrote:

> And <f1> may be standard, but Emacs doesn't adhere.  Minimally, it
> should do a C-h r, or better look up the current mode in the manual.

I don't see why.  F1 invokes the application-specific help command, and 
"C-h" in Emacs fits the bill IMHO.  In particular, "C-h" in special 
situations like in an isearch does a much better job than "C-h r".

Re: [CVS] f7, f8 bound..

[Pavel Janík]

   From: Eli Zaretskii <eliz@is.elta.co.il>
   Date: Sun, 1 Sep 2002 15:02:28 +0200 (IST)

Eli,

   > I don't see why.  F1 invokes the application-specific help command, and 
   > "C-h" in Emacs fits the bill IMHO.  In particular, "C-h" in special 
   > situations like in an isearch does a much better job than "C-h r".

I think that Emacs does almost the right thing with f1. The question is
whether it could do a better job. What about opening Help menu? Do you
think it could be better for users who are used to get help by f1? To tell
the truth, I do not know. I've never used f1 to get help from Emacs.
-- 
Pavel Janík

Terminate input by end-of-file or marker, not by count.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

Re: [CVS] f7, f8 bound..

[Eli Zaretskii]

> From: Pavel@Janik.cz (Pavel =?iso-8859-2?q?Jan=EDk?=)
> Date: Sun, 01 Sep 2002 15:45:19 +0200
> 
> I think that Emacs does almost the right thing with f1. The question is
> whether it could do a better job. What about opening Help menu? Do you
> think it could be better for users who are used to get help by f1?

I think there's a rule that a command that was invoked by a keyboard
key does not open the menu bar.  So what Emacs does looks consistent
to me.

Re: [CVS] f7, f8 bound..

[Eli Zaretskii]

> From: Pavel@Janik.cz (Pavel =?iso-8859-2?q?Jan=EDk?=)
> Date: Sun, 01 Sep 2002 15:45:19 +0200
> 
> I think that Emacs does almost the right thing with f1. The question is
> whether it could do a better job. What about opening Help menu? Do you
> think it could be better for users who are used to get help by f1?

I think there's a rule that a command that was invoked by a keyboard
key does not open the menu bar.  So what Emacs does looks consistent
to me.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    A _much_ better idea, I think, would be to make it very simple for even
    novice users to easily _bind_ the function keys to their liking; I'm not
    saying it's all that hard now, but I mean, make it really, really, easy.

I would really like to see someone extend Custom to handle key bindings.

    For instance, a mode that shows a graphical representation of the function
    keys and their current bindings, and allows the user to trivially change them.
    Perhaps by moving the cursor to a function key picture, and hitting SPC/RET
    which would make it prompt for a another key-binding, and then copy that to
    the function key;

That sounds nice.

     while in this special mode, it might even locally rebind
    all the function keys so that you could just hit e.g. `F5 C-x C-f' to bind F5
    to find-file.

I think that is too inconsistent and brings a risk of error.

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

RMS:
   > Do people think we should remove the F2 bindings?  We could provide
   > commands on F2 and F3 that resemble simple text editors.
Kim:   
   I don't know what simple editors we need to look like, or whether any of
   the simple editors resembles each other.  I doubt it.
   
   As an example, M$-Word (which I would image quite a few users are
   using -- like it or not) has the following bindings

Word is not a simple editor, it is a very complex wysiwyg word
processor.  I was referring to simple text editors, like those I used in
the old time of DOS systems on text consoles, and like many are still
around.

Doing a quick survey of the text editors available in Debian, I find
that some use Emacs-like bindings, some (the simplest ones) use only
single control-key commands, some use C-k prefixed commands.  Of the
others (X is X, T is text console): 

T fte:      F1 help  F2 save  F3 open                     F9 compile  F10 menu
T hexedit:  F1 save  F2 save  F3 load  F7 copy  F8 paste  F9 mark     F10 menu 
T jered:    F1 comm  F2 shell F3 quit  F4 save  F5 find F6 mark       F10 remove
T le:       F1 help  F2 save  F3 load           F5/6 mark F9 compile  F10 menu 
T mped:              F2 save  F3 open  F4 close F5 new
T ne:       F1 menu  F2 next  F3 prev  F4 select F5/6 undo/redo       F10 help
T qe:       F1 manu
T sted:     F1 help                                       F9 quit F11 load F12 save
T woody:                                                              F10 menu 
T zed:      F1 help  F2 save  F3 load           F5 zoom               F10 menu 
T zile:     F1 help  F2 save  F3 load                                 F10 menu 
X Kedit:    F1 help           F3 find next
X flimmer:  F1 help  F2 props F4 highlight
X gedit:                            F3 open  F6 find  F7 replace
X ghex:                       F3 open
X gnotepad:                   F3 open
X kate:     F1 help           F3 find next
X scite:    F1 help  F2 n.bkmk F3 find next
X the:      F1 help  F2 nextw F3 save

Apparently, then, traditional textual editors use F2 and F3 for save and
load quite consistently, while modern X-based editors use a different
convention, maybe there are Gnome and Kedit standards for this.
   
   We already provide things like crisp-mode which binds a lot of keys in
   ways which resembles other editors.  That's a reasonable approach.
   
Yes.

   But it shouldn't be the default to try to mimic other (inferior :-)
   editors.

Don't know.  Maybe we could provide a series of mappings for the
functions keys.  If we find a mapping that can be thought to be
reasonably standard for simple text editors, we could use that as the
default, and make it possible to switch to other mappings.

Re: [CVS] f7, f8 bound..

[Damien Elmes]

huug <huug.at.gmane@xs4all.nl> writes:

> On 2002-08-30, Richard Stallman <rms@gnu.org> wrote:
>>     The F2 bindings are also available as C-x 6 bindings, so nothing
>>     needs to be done, I think.
>> 
>> Do people think we should remove the F2 bindings?  We could provide
>> commands on F2 and F3 that resemble simple text editors.
>
> I'ld like that very much, thank you.  I cannot recall how often that
> binding has bitten me, but it probably runs into five figures, if not
> more.  Enough for me to almost completely forget there used to be a
> practical function bound to that key :(

I'm all for removing the F2 binding, but please don't replace F2/F3 with load
and save. Bindings that close together are a recipe for disaster.

Regards,

-- 
Damien Elmes

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    > Do people think we should remove the F2 bindings?  We could provide
    > commands on F2 and F3 that resemble simple text editors.

There seems to be disagreement about whether there is any uniformity
among widely used text editors in their use of F2 and F3.  If there
is no uniformity, it is not clear what convention we could usefully
follow in Emacs.

Re: [CVS] f7, f8 bound..

[David A. Cobb]

Richard Stallman wrote:

>    > Do people think we should remove the F2 bindings?  We could provide
>    > commands on F2 and F3 that resemble simple text editors.
>
>There seems to be disagreement about whether there is any uniformity
>among widely used text editors in their use of F2 and F3.  If there
>is no uniformity, it is not clear what convention we could usefully
>follow in Emacs.
>
Certainlly no unanimity.  In the M$ world, [F3] seems most often related 
to "Find" (Search).

How about the CUA spec/guideline/whatever-it-is?  Any help there.

>_______________________________________________
>Emacs-devel mailing list
>Emacs-devel@gnu.org
>http://mail.gnu.org/mailman/listinfo/emacs-devel
>
>  
>

-- 
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Francesco Potorti` <pot@gnu.org> writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
>    I would _love_ an interface like that -- it's definitely true that it's
>    currently very annoying to hit `C-x e' repeatedly.
> 
> When I create a macro, I always put a C-xq command in it, and end it
> with M-0C-x), so it repeats indefinitely until I press SPC and stops as
> soon as I press C-g.
> 
> This behaviour could be made standard for kmacro, perhaps, without the
> need of putting a C-xq inside the macro just for this purpose.

I think setting the new kmacro-call-repeat-key to `? ' will mostly do exactly
what you want.


> If we want to make life easier for newbies, for example, F2 and F3 are
> traditionally used to open a file (find-file) and save it (save-buffer),
> and F4 to select a block (set-mark-command).

traditionally in what environment?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

   > If we want to make life easier for newbies, for example, F2 and F3 are
   > traditionally used to open a file (find-file) and save it (save-buffer),
   > and F4 to select a block (set-mark-command).
   
   traditionally in what environment?

In simple text editors that do not have emacs-like key bindings.  It's a
usage that comes from the editors of the eighties on DOS machines.

However, I'm not advocating standard bindings like these.  I mean that,
if one wants to write a package for newbies, or configure an Emacs for
newbies, they could choose bindings such as those.  It was just an
example of a possible natural usage of those keys.

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Sun, Sep 01, 2002 at 06:58:29AM +0200, huug wrote:
> Hmm..  Maybe someone could explain why start-macro ought to have a
> different binding then end-macro?  As far as I can recall, you can't
> start a macro definition when you are recording a macro, so..

If the macro start/end-definition keys are separate from execute-macro, as
with the standard emacs bindings, then you could combine them for the reason
you say.  However, Kim's scheme puts end-definition and execute-macro on the
same key, so you can't combine that with start-definition (because then it
wouldn't know if you want to execute the macro again, or define a new macro).

In other words, you need at least two keys for macros.

> Having learnt Emacs under OS/2, <f11> means (call-last-kbd-macro) to
> me (not to mention <f2> is (switch-to-other-buffer), <f3>
> (emx-search-forward) and <f4> (emx-search-backward) ;) , so something
> like [C-f11] (start-or-end-kbd-macro), [C-u C-f11]
> (extend-last-kbd-macro) and [M-f11] (name-last-kbd-macro) would be
> more logical to me.

Those bindings are completely meaningless for the great majority of users
(just like Kim's).  This is exactly the reason why we should just avoid
making standard bindings for function keys altogether -- they're not mnemonic
at all.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Edward O'Connor]

> > Note that where the old (and still available) bindings use
> > separate commands for ending and calling a keyboard macro, the
> > new bindings merges the ending and calling onto the same key.
> > So kmacro just needs two [function] keys rather than three.
>
> I think the merging of `end-kmacro-definition' and
> `execute-kmacro' is clever and useful.

I agree, but why not go one step further, and merge macro starting
in as well? For quite a long time, I've had the following defun in
my .emacs:

(defun ted-macro-dwim (arg)
  "DWIM keyboard macro recording and executing."
  (interactive "P")
  (if defining-kbd-macro
      (end-kbd-macro arg)
    (if last-kbd-macro
        (call-last-kbd-macro arg)
      (start-kbd-macro arg))))

Try binding that to F9 or C-x e or whatever. The functionality is
trivial, and the defun less than 10 lines. I wouldn't object in
the slightest to this being included with Emacs. I find it nice to
have a binding to clear out the value of `last-kbd-macro' too.


-- 
Edward O'Connor
ted@oconnor.cx

Re: [CVS] f7, f8 bound..

[Miles Bader]

"Edward O'Connor" <ted@oconnor.cx> writes:

> I agree, but why not go one step further, and merge macro starting in
> as well?
> 
> I find it nice to have a binding to clear out the value of
> `last-kbd-macro' too.

But you _have_ to use such a `clear out' binding to define any more
macros, which means that you end up needing _two_ commands to define
all macros except the first -- so it's really no better than any other
two-command alternative...

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    Hell, why not just make `C-x e' end the macro as well as executing it,
    and then use Stefan's idea of allowing the `e' to be repeated
    indefinitely [or something similar]?

These seem like good ideas, except that I would have chosen C-x ) instead
of C-x e, for symmetry with C-x (.

    Actually, I think a better idea would be to make `C-x e' repeat if you
    hit SPC afterwards, and display a message to that effect so that it's
    obvious, e.g., 

SPC would be easier to type over and over than e.

However, one thing worries me about both ideas: both of them could be
error-prone.  You might want to type an e, or a space, for its normal
meaning, after executing the macro.

Re: [CVS] f7, f8 bound..

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Hell, why not just make `C-x e' end the macro as well as executing it,
>     and then use Stefan's idea of allowing the `e' to be repeated
>     indefinitely [or something similar]?
> 
> These seem like good ideas, except that I would have chosen C-x ) instead
> of C-x e, for symmetry with C-x (.

Yeah, I agree, but that changes the meaning of `C-x )', whereas adding
this new meaning to `C-x e' can be done in a backward-compatible way
(currently `C-x e' while defining a macro just results in an error).

I also like the mnemonic value of `C-x e' -- `execute' -- and the
concept of an `execute' command implicitly terminating the definition
phase seems more natural to me that the concept of the `end-def'
command (for which `C-x )' is highly mnemonic) executing once.

I also think that `C-x )' is still a useful command; sometimes I want to
just end the current macro definition with, without executing it (e.g.,
when I'm defining the macro in a different buffer on some fake data).

>     Actually, I think a better idea would be to make `C-x e' repeat if you
>     hit SPC afterwards, and display a message to that effect so that it's
>     obvious, e.g., 
> 
> SPC would be easier to type over and over than e.
> 
> However, one thing worries me about both ideas: both of them could be
> error-prone.  You might want to type an e, or a space, for its normal
> meaning, after executing the macro.

Very true, but I think that that's _far_ more rare than wanting to
execute the macro again (that's why I think it's important to display a
message, so it's up-front obvious that you're really in some sort of
mode), and SPC is just about the easiest to type and most widespread
repetition key there is (think of pagers such as more, query-replace,
etc).

It's kind of isearch -- sometimes you want to search for RET, and have
to think a little to do it, but most of the time the convenience of the
unusual binding wins out.

I think the _best_ thing would be a single-mnemonic-letter-with-modifier
binding, e.g. M-e (but that's obviously taken, and of course not
everyone has a real meta-key); however adding repeating behavior to an
existing command seems like a decent alternative.

Also, adding the SPC-key behavior to `C-x e' would have the benefit
that existing emacs users could immediately start using it, when they
see the message, without really learning any new commands at all.

I agree with Kim that the repetition key should probably be controlled
by a variable or something, mostly so people who don't like this
behavior can set it to nil -- but I also think that the default should
be to enable it, with a value of SPC.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    I also think that `C-x )' is still a useful command; sometimes I want to
    just end the current macro definition with, without executing it (e.g.,
    when I'm defining the macro in a different buffer on some fake data).

I think there is a misunderstanding here.  Isn't that exactly
what C-x e will now do if you are defining a macro?

Re: [CVS] f7, f8 bound..

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     I also think that `C-x )' is still a useful command; sometimes I want to
>     just end the current macro definition with, without executing it (e.g.,
>     when I'm defining the macro in a different buffer on some fake data).
> 
> I think there is a misunderstanding here.  Isn't that exactly
> what C-x e will now do if you are defining a macro?

Hmm, what I was thinking was that it would end the macro definition, and
immediately execute the macro.  I'm not sure that there's much
advantage to having it just end the macro, since it's not much easier
to type than `C-x )', and has less mnemonic value (by the same token,
there seems little point to having `C-x )' execute the macro when used
outside a macro definition).

-Miles
-- 
Run away!  Run away!

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    Hmm, what I was thinking was that it would end the macro definition, and
    immediately execute the macro.  I'm not sure that there's much
    advantage to having it just end the macro,

Simplicity is the advantage.

But what actually has been implemented?  Does C-x e just close the macro
definition, or does it execute the macro again?

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Hmm, what I was thinking was that it would end the macro definition, and
>     immediately execute the macro.  I'm not sure that there's much
>     advantage to having it just end the macro,
> 
> Simplicity is the advantage.
> 
> But what actually has been implemented?  Does C-x e just close the macro
> definition, or does it execute the macro again?

`C-x e' ends the definition; after that repeating `e' will call the macro.

E.g. in [C-x ( .... C-x e e e], the `C-x e' ends the macro and `e e' then
executes it twice.

Keeping C-x ) with the current binding (kmacro-end-macro) will have
the advantage that C-x ( .... C-x ) simply defines the macro, but it
cannot be called immediately by repeating ), 

i.e. with C-x ( ... C-x ) you can insert a `)' or `e' immediately
after defining the macro if you need to, whereas using C-x ( ... C-x e
does not allow you to insert an `e' immediately after defining the
macro.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Miles Bader]

Richard Stallman writes:
>     Hmm, what I was thinking was that it would end the macro definition, and
>     immediately execute the macro.  I'm not sure that there's much
>     advantage to having it just end the macro,
>
> Simplicity is the advantage.

Simplicity in what way?

(A) Conceptually?

   I think end-macro-definition and execute-macro are two pretty
   different operations (certainly for emacs users, and I see no reason
   that novices should be different).  I think ideally that it's much
   easier to use when different operations are on different keys (with
   exceptions for `equivalent' operations, or those with strong
   historical meaning in different context -- but this is neither of
   those cases).

   So making the same key invoke or or the other depending on the context
   actually is _less_ simple to think about.

(B) Operationally?

   Consider two cases:

    (1) Where the user wants to end the macro definition, do some other
        stuff (move around or whatever) and then execute the macro for
        the first time.

       In this case, I seen no particular advantage to having the same
       binding do one or the other operations -- the intermediate
       operations move your fingers around and remove whatever advantage
       there is to hitting the same set of keystrokes twice.

    (2) Where the user wants to immediately execute the macro after
        ending the definition.

       With a multiple keystroke binding like `C-x e' or `C-x )', this
       isn't as easy as simply hitting a single key twice (like in Kim's
       original), but in this case, there probably _is_ some advantage
       to being able to use the same binding twice -- your fingers are
       positioned appropriately, and it's less burden to think about
       what to do next.

       However, note that this is _exactly_ the case where my
       suggestion is even better.


Now consider my suggestion (have `C-x e' end any currently-being-defined
macro definition and _also_ execute the macro once) using the same criteria:

(A) Conceptually?

   Note that using my definition, both bindings (`C-x e' and `C-x )')
   retain their current simple one-binding-one-operation meanings.

   What it essentially does is _extend_ the number of places where `C-x e' 
   works, by implicitly ending any current macro definition before
   executing the macro.  It removes a case the user has to worry about
   (getting an error by forgetting to type `C-x )').

   Thus, I think you can say that it's actually simpler than the
   historical definition of `C-x e', and certainly simpler than Kim's
   replacement (end-macro-or-execute).

(B) Operationally?

   Consider two cases:

    (1) Where the user wants to end the macro definition, do some other
        stuff (move around or whatever) and then execute the macro for
        the first time.

       In this case, my binding is basically the same as the historical
       one, which is fine because the historical one is just right for
       this case; there's no reason to merge the operations.

    (2) Where the user wants to immediately execute the macro after
        ending the definition.

       Here, obviously my binding is more convenient -- you just have
       to hit `C-x e' once (instead of twice as with Kim's binding, or
       instead of two different bindings as with the historical ones).


So as far as I can see, my idea is simpler and more convenient than both
the historical bindings and Kim's replacement:  in case (A), it's
conceptually easier to think about (and explain), in case (B 1) it's no
less convenient than other bindings, and in case (B 2) it's more
convenient than the alternatives.

-Miles
-- 
Fast, small, soon; pick any 2.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

It is conceptually simple to have command A that ends a macro and
command B that executes a macro.

It is also conceptually simple to have one command that ends a macro
and executes it, and have two key bindings for that one command.

But it is rather strange to have one command that either ends the
macro or executes it, and another command that only ends it.  All else
being equal, it would be better to replace them with one command that
does both jobs.

    Now consider my suggestion (have `C-x e' end any currently-being-defined
    macro definition and _also_ execute the macro once) using the same criteria:

    (A) Conceptually?

       Note that using my definition, both bindings (`C-x e' and `C-x )')
       retain their current simple one-binding-one-operation meanings.

There is a way to look at this which makes it coherent.  It could
mean, "Execute the keyboard macro, closing it first if necessary."

That's not what it does now, though, is it?

Re: [CVS] f7, f8 bound..

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>        Note that using my definition, both bindings (`C-x e' and `C-x )')
>        retain their current simple one-binding-one-operation meanings.
> 
> There is a way to look at this which makes it coherent.  It could
> mean, "Execute the keyboard macro, closing it first if necessary."

Right, that's what I thought I said (or tried to say, anyway).

> That's not what it does now, though, is it?

No, Kim changed it to have the `a-OR-b' definition.

I think it would be better to revert that change, and simply make the
primitive `call-last-kbd-macro' silently end any macro currently being
defined before executing the macro.

-Miles
-- 
We live, as we dream -- alone....

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Richard Stallman <rms@gnu.org> writes:
> >        Note that using my definition, both bindings (`C-x e' and `C-x )')
> >        retain their current simple one-binding-one-operation meanings.
> > 
> > There is a way to look at this which makes it coherent.  It could
> > mean, "Execute the keyboard macro, closing it first if necessary."
> 
> Right, that's what I thought I said (or tried to say, anyway).
> 
> > That's not what it does now, though, is it?
> 
> No, Kim changed it to have the `a-OR-b' definition.

I'd call it a-THEN-b ...

> 
> I think it would be better to revert that change, and simply make the
> primitive `call-last-kbd-macro' silently end any macro currently being
> defined before executing the macro.

Personally, I have no preferences here.

What do others think?

Should C-x ( ...  C-x e terminate and execute the macro immediately?

If so, should it still be possible to repeat the call by just hitting
`e' or `SPC'?




-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > No, Kim changed it to have the `a-OR-b' definition.
> 
> I'd call it a-THEN-b ...

What I meant is that _each_ invocation is either `a-OR-b'.
The user has to explicitly hit it twice to get `a-THEN-b' behavior.

> > I think it would be better to revert that change, and simply make the
> > primitive `call-last-kbd-macro' silently end any macro currently being
> > defined before executing the macro.
...
> Should C-x ( ...  C-x e terminate and execute the macro immediately?
> 
> If so, should it still be possible to repeat the call by just hitting
> `e' or `SPC'?

Of course.

The thing to remember is that, using my suggested behavior,
`C-x e' really just means `execute the macro'.  The `end definition'
part is more like background housekeeping done for the user's
convenience, and I doubt most users would ever think about it; there's 
no need to distinguish it from uses of `C-x e' afterwards.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

Kim, what do you think of Miles' "close and then execute" proposal?

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Kim, what do you think of Miles' "close and then execute" proposal?

I don't think either way...  as I don't use the C-x e binding myself.
I have nothing against Miles' proposal, so if nobody else objects, I'll
change it to do just that [and keep C-x ) as is].


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    I have nothing against Miles' proposal, so if nobody else objects, I'll
    change it to do just that [and keep C-x ) as is].

Ok.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > Kim, what do you think of Miles' "close and then execute" proposal?
> 
> I don't think either way...  as I don't use the C-x e binding myself.
> I have nothing against Miles' proposal, so if nobody else objects, I'll
> change it to do just that [and keep C-x ) as is].

Since nobody objected, I have now changed it.

So, when necessary, C-x e now terminates the macro before calling it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    > However, one thing worries me about both ideas: both of them could be
    > error-prone.  You might want to type an e, or a space, for its normal
    > meaning, after executing the macro.

    Very true, but I think that that's _far_ more rare than wanting to
    execute the macro again (that's why I think it's important to display a
    message, so it's up-front obvious that you're really in some sort of
    mode), and SPC is just about the easiest to type and most widespread
    repetition key there is (think of pagers such as more, query-replace,
    etc).

Yes, but there is no surprise when SPC has its normal meaning.  When
it has some other special meaning, that causes risk of surprise.

    It's kind of isearch -- sometimes you want to search for RET, and have
    to think a little to do it, but most of the time the convenience of the
    unusual binding wins out.

Speaking of Isearch, I find that the isearch binding for M-e screws me
and I am thinking of eliminating it.  We may have too many special
Isearch commands now.  This is despite the fact that Isearch is a kind
of special mode, and people expect that some commands will behave
differently in Isearch.  "After C-x e" is not a special mode at all.

Re: [CVS] f7, f8 bound..

[Stefan Monnier]

>     Very true, but I think that that's _far_ more rare than wanting to
>     execute the macro again (that's why I think it's important to display a
>     message, so it's up-front obvious that you're really in some sort of
>     mode), and SPC is just about the easiest to type and most widespread
>     repetition key there is (think of pagers such as more, query-replace,
>     etc).
> 
> Yes, but there is no surprise when SPC has its normal meaning.  When
> it has some other special meaning, that causes risk of surprise.

How about trying it to see if people indeed suffer from it or if they're
pleasantly surprised by the new feature.

>     It's kind of isearch -- sometimes you want to search for RET, and have
>     to think a little to do it, but most of the time the convenience of the
>     unusual binding wins out.
> 
> Speaking of Isearch, I find that the isearch binding for M-e screws me
> and I am thinking of eliminating it.

I use it all the time :-(

> We may have too many special
> Isearch commands now.  This is despite the fact that Isearch is a kind
> of special mode, and people expect that some commands will behave
> differently in Isearch.  "After C-x e" is not a special mode at all.

The same argument applies to C-x z z z z z, right ?


	Stefan

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    The same argument applies to C-x z z z z z, right ?

Yes, it does.  There is a plus and a minus in each of these cases.
I don't think we should eliminate them all, but we have to be careful
how many we add.

Re: [CVS] f7, f8 bound..

[Miles Bader]

On Fri, Aug 30, 2002 at 10:35:53AM -0400, Stefan Monnier wrote:
> > Speaking of Isearch, I find that the isearch binding for M-e screws me
> > and I am thinking of eliminating it.
> 
> I use it all the time :-(

I also find isearch M-e very useful, though I only found out about it
recently (due to Stefan praising, I think :-).

If we get rid of that binding, I think it ought to be moved to some other
binding instead.

BTW, as a general matter, I find the set of bindings in isearch mode very
confusing; I sort of wish they were all on a single prefix key or
something...

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [CVS] f7, f8 bound..

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

> BTW, as a general matter, I find the set of bindings in isearch mode very
> confusing; I sort of wish they were all on a single prefix key or
> something...

I agree.  They feel very unnatural to me.  I always have to think
about eventhe simplest things such as ending isearch -- RET?  C-g?
The one leaves point, the other returns point.  But I do not want to
"Enter" -- I want to "Quit".  Oh well.  And then there is the
confusion of yanking and killing.  I sometimes kill a word, then want
to search for it.  C-s C-y will not do what I expect.  I don't like
it.

Alex.

Re: [CVS] f7, f8 bound..

[Francesco Potorti`]

Richard Stallman <rms@gnu.org> writes:
   Speaking of Isearch, I find that the isearch binding for M-e screws me
   and I am thinking of eliminating it.

Nooo!  :-)

It is among the ten most useful things recently changed in Emacs user
interface in the last year.  My opinion, obviously, but just for the
record. 

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Francesco Potorti` <pot@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>    Speaking of Isearch, I find that the isearch binding for M-e screws me
>    and I am thinking of eliminating it.
> 
> Nooo!  :-)
>
> It is among the ten most useful things recently changed in Emacs user
> interface in the last year.  My opinion, obviously, but just for the
> record. 

I completely agree that a default binding for isearch-edit-string in
isearch-mode-map is very useful.  That's why I've had C-e bound to
it for years!  I think the new default M-e is fine too.

But the isearch prompt should change to "I-search [EDIT]:" or similar
to emphasize what's going on.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 31 Aug 2002 02:33:33 +0200
> 
> But the isearch prompt should change to "I-search [EDIT]:" or similar
> to emphasize what's going on.

On systems that support that, we could change the cursor shape.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Hell, why not just make `C-x e' end the macro as well as executing it,
>     and then use Stefan's idea of allowing the `e' to be repeated
>     indefinitely [or something similar]?
> 
> These seem like good ideas, except that I would have chosen C-x ) instead
> of C-x e, for symmetry with C-x (.

I implemented Miles suggestion that C-x e end and executes the macro.
This is done by binding C-x e to kmacro-end-or-call-macro.

If you want to have the same functionality on C-x ), we can bind that
function there too.

BTW, that is exactly what I initially suggested (to you) to do, but
you explicitly requested that C-x ), and C-x e should continue to work
as they used to.

> 
>     Actually, I think a better idea would be to make `C-x e' repeat if you
>     hit SPC afterwards, and display a message to that effect so that it's
>     obvious, e.g., 
> 
> SPC would be easier to type over and over than e.

This is now a custom option kmacro-call-repeat-key.

> 
> However, one thing worries me about both ideas: both of them could be
> error-prone.  You might want to type an e, or a space, for its normal
> meaning, after executing the macro.

If you don't like this, set kmacro-call-repeat-key to nil.
Maybe it should be the default setting?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I implemented Miles suggestion that C-x e end and executes the macro.
> This is done by binding C-x e to kmacro-end-or-call-macro.

BTW, is there any reason to change the names of all these functions?

If your code is better, why not replace the old functions?

There's presumably people out there using the old names, and since the
new functions are backward-compatible, they'd be a drop-in-replacement.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: [CVS] f7, f8 bound..

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > I implemented Miles suggestion that C-x e end and executes the macro.
> > This is done by binding C-x e to kmacro-end-or-call-macro.
> 
> BTW, is there any reason to change the names of all these functions?

The old names are the built-in C functions.  I still need those for
interfacing to the actual definition and execution of keyboard macros.
Of course, I could change the names of the C functions, but then
other existing code interfacing to these functions could break.

> 
> If your code is better, why not replace the old functions?

If... ?  :-)

> 
> There's presumably people out there using the old names, and since the
> new functions are backward-compatible, they'd be a drop-in-replacement.

For non-interactive use they are not completely backwards compatible.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [CVS] f7, f8 bound..

[Richard Stallman]

    If you want to have the same functionality on C-x ), we can bind that
    function there too.

Please do that.  If both of these commands end a macro, but only
one of them executes a macro, that is quite incoherent.

    If you don't like this, set kmacro-call-repeat-key to nil.
    Maybe it should be the default setting?

I am not sure, but I think the default should be nil
to avoid surprises.

Re: [CVS] f7, f8 bound..

[Richard Stallman]

I think there is no harm in supporting F3 and F4 as well as C-x (, C-x
) and C-x e and C-x C-k, if users like F3 and F4.  We could take a poll
and ask them.