bug#6256: 24.0.50; read-event in `repeat' command

[Drew Adams]

(Putting this back into the bug-list thread, since some of my reply (#3 below)
still pertains to #6256.)

1. > Yes, tho the only change it requires is to change the lets into setqs.

Including the let-binding of `repeat-message-function'?  I assume not.  Doing
that would change the value globally from then on.  I've left that one as a let
binding.


2. However, you say that your implementation will anyway render a let binding of
`repeat-message-function' ineffective.  Do you mean your current fix using
read-key or your future reimplementation that you have locally?

I assume you mean the latter.  I can't test that, so I can't say how annoying
the changed message behavior would be.

Not being able to effectively let bind `repeat-message-function' (anywhere)
would significantly reduce the utility of that variable.  That's kind of the
point of such a variable - code that uses it is unlikely to just treat it as a
global setting (e.g. setq).

There needs to be some simple way to prevent `repeat' from issuing its own
message for the duration (including during all repetitions).  And preferably we
would also provide a way to apply an alternative function - i.e. to do exactly
what `repeat-message' was intended to do and does currently.

It seems like your future replacement would change the notion of a repetition so
that it no longer does everything that is currently done in `repeat' (since
`repeat' is not called repetitively).  Dunno.  I realize you are still working
on it, but please try not to sacrifice too much in your quest for simplicity.


3. Your current read-key fix for `repeat' does not work in Emacs 23, whereas my
fix using read-event does work.

Yours works only for Emacs 24 - I'm not sure why (can you tell me perhaps?).
Mine works also in Emacs 22 and 23.  (Emacs 22 has no `read-key'.)  So I cannot
say I'm overjoyed with that solution.

But maybe I will be if I understand its advantages.  What was your objection to
the solution I provided using `read-event'?  You never stated it, IIRC.

I realize that you do not care much about Emacs 22 or 23, but it seems like a
fair amount of loss for little gain.  I'd like to understand the advantage of
your current fix using read-key.

(Granted, an Emacs 22/23 user would need to eval the fixed version of `repeat',
but that's not a big deal.)


4.

> If you look at the corresponding patch included below, you'll see that
> it makes it unnecessary to deal with pre/post-command-hook or with
> undo-boundary.  Actually it also handles various other details of the
> top-level loop which the current version of repeat just 
> hasn't bothered to try and reproduce (e.g. moving the cursor outside
> of images/compositions/invisible text).

Yes, it looks simpler.  (But you didn't show the definition of
`set-temporary-overlay-map'.)

> > I'm not objecting but asking to understand, especially 
> > since it breaks the way `repeat' has functioned (its
> > interface), requiring code changes for at least some
> > `repeat' callers such as mine.
> 
> Yes, that's a concern.

Consider providing some info in NEWS about how to make code compatible etc.

> I've sent my current implementation to emacs-devel in some
> other thread, but in any case it suffers from a few problems.
> 
> > BTW, what's the `t' argument for?
> 
> It means "keep this overlay map active as long as the user hits keys
> within that keymap".  A nil value means to keep it active only for the
> very next command.  You can also provide a predicate function 
> to decide when to deactivate the map.

Do you actually use such optional functionality?  How/where?