callint.c:506

callint.c:506

[Mario Lang]

Hello.

I just investigated a little emacspeak related issue
and found out that in callint.c:506, we call Fcompleting_read
instead of Fread_command.

Now I have several questions, please be patient, I'm very
new to the C side of Emacs:

1. If we call a F* function from C, will
defadvices work for this function?

I mean, if someone advises read-command, will the
advice code be called if Fread_command is called?

2. If yes, is there a special reason why we call
Fcompleting_read directly there, or could we
also call Fread_command?


-- 
CYa,
  Mario

Re: callint.c:506

[Richard Stallman]

    I just investigated a little emacspeak related issue
    and found out that in callint.c:506, we call Fcompleting_read
    instead of Fread_command.

It makes no real difference--they do the same thing.

    1. If we call a F* function from C, will
    defadvices work for this function?

No, that cannot work.  What you see in the C code are ordinary
C function calls.

Why do you want to advise read-command?

Re: callint.c:506

[Mario Lang]

Richard Stallman <rms@gnu.org> writes:

>     I just investigated a little emacspeak related issue
>     and found out that in callint.c:506, we call Fcompleting_read
>     instead of Fread_command.
>
> It makes no real difference--they do the same thing.
That is true.

>     1. If we call a F* function from C, will
>     defadvices work for this function?
>
> No, that cannot work.  What you see in the C code are ordinary
> C function calls.
I relaized that after I sent the mail :(

> Why do you want to advise read-command?
Emacspeak advices nearly every interactive function to get spoken prompts.

For example:

(defadvice read-command (around emacspeak pre act)
  "Prompt using speech as well."
  (let ((prompt (ad-get-arg 0)))
    (when prompt
      (tts-with-punctuations "all"
                             (dtk-speak prompt)))
    ad-do-it
    (tts-with-punctuations "all"
                           (dtk-speak (format "%s" ad-return-value)))
    ad-return-value))

Now see for instance global-set-key, it's interactive form is:

(interactive "KSet key globally: \nCSet key %s to command: ")

If the `C` char for instance would call read-command (not the C function,
the Lisp function), the defadvice from above would automagically
work for global-set-key.   

Emacspeak has:

(defadvice global-set-key (before emacspeak pre act)
  "Provide spoken prompts."
  (interactive
   (list
    (read-key-sequence "Globally  bind key:")
    (read-command "To command:" ))))

This uses read-command for the interactive form instead of 'C' to get the
spoken feedback from read-command's advice code.

I'd like to find a nicer way to do all this.

Ideas right now are:
1. Call the Lisp function when processing string interactive forms.
I dont know what this would mean in terms of performance, but
it would solve the above "problem".
2. Introduce a new hook (prompt-hook?) which would get called
for every minibuffer prompt displayed.

Solution 2 seems more involved, but it would make things more cleaner
imo.

comments?


-- 
CYa,
  Mario

Re: callint.c:506

[Miles Bader]

On Thu, Aug 29, 2002 at 01:24:25PM +0200, Mario Lang wrote:
> 2. Introduce a new hook (prompt-hook?) which would get called
> for every minibuffer prompt displayed.

Why not use `minibuffer-setup-hook'?

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

Re: callint.c:506

[Kim F. Storm]

Mario Lang <mlang@delysid.org> writes:

> 2. Introduce a new hook (prompt-hook?) which would get called
> for every minibuffer prompt displayed.
> 
> Solution 2 seems more involved, but it would make things more cleaner
> imo.

I'm not sure how difficult this would be (it's not trivial for sure),
but IMO it definitely seems to make a lot of sense to provide such a
hook function.

A semi-workable solution might be to add the hook to call-interactively
[which implements the (interactive ...) form] and let it pass the
callint_message to the prompt hook function [together with the arg type],

Something like this

     if (callint_message[0] && !NILP (Vinteractive_prompt_function))
        call2 (Vinteractive_prompt_function,
               build_string (callint_message),
               make_number (*tem));

added before:

      switch (*tem)
	{
	case 'a':		/* Symbol defined as a function */


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

Re: callint.c:506

[Stefan Monnier]

> Ideas right now are:
> 1. Call the Lisp function when processing string interactive forms.
> I dont know what this would mean in terms of performance, but
> it would solve the above "problem".

The performance impact is completely negligible since it's
only for interactive calls anyway.

That just reminds me that while thinking of what it would take
to move all or part of the read-eval-loop to Elisp, I thought that
we could use a `interactive-code-alist' which could hold
things like

	'((?d . (lambda (prompt) (list (point))))
	  (?r . (lambda (prompt) (list (region-beginning) (region-end))))
	  (?f . (lambda (prompt) (list (read-file-name prompt))))
	  ...)

I remember I had another application for it at some point, but I can't
think of it right now.


	Stefan

Re: callint.c:506

[Richard Stallman]

    > Why do you want to advise read-command?
    Emacspeak advices nearly every interactive function to get spoken prompts.

Do you really mean that each and every command (interactively callable
function) in Emacs has an advice in Emacspeak?  What a horribly
cumbersome method that is.

Or do you really mean something else when you say "interactive
function"?  I suspect maybe you do, because read-command is not an
interactive function (it has no `interactive' spec).

Emacspeak is important enough, and the general class of applications
it belongs to is important enough, that it would be worth while to add
features to make such a thing easy to do.

    2. Introduce a new hook (prompt-hook?) which would get called
    for every minibuffer prompt displayed.

    Solution 2 seems more involved, but it would make things more cleaner
    imo.

Is minibuffer-setup-hook sufficient to do the job?  If not, we could
add some other hook.  However, in order for us to figure out what
hooks are the best way to do this job, you have to make it clearer
what you are trying to achieve.

Re: callint.c:506

[Mario Lang]

Miles Bader <miles@gnu.org> writes:

> On Thu, Aug 29, 2002 at 01:24:25PM +0200, Mario Lang wrote:
>> 2. Introduce a new hook (prompt-hook?) which would get called
>> for every minibuffer prompt displayed.
>
> Why not use `minibuffer-setup-hook'?
Oh, thanks for pointing this out.  Now I see that Emacspeak indeed
uses minibuffer-setup-hook in some places for exactly
that.  Using `last-command', one can then even do context-dependent stuff.


-- 
CYa,
  Mario

Re: callint.c:506

[Mario Lang]

Richard Stallman <rms@gnu.org> writes:

>   > Why do you want to advise read-command?
>   Emacspeak advices nearly every interactive function to get spoken prompts.
>
> Do you really mean that each and every command (interactively callable
> function) in Emacs has an advice in Emacspeak?  What a horribly
> cumbersome method that is.
Indeed, it appears that emacspeak advises alot of interactive
commands to get spoken feedback.  I agree that the method is a bit
cumbersome but it appears there was no other way to achieve
the same result.

> Or do you really mean something else when you say "interactive
> function"?  I suspect maybe you do, because read-command is not an
> interactive function (it has no `interactive' spec).
I mean, Emacspeak advises most functions which actually do
interaction with the user.  This includes functions with
the interactive spec, and functions doing any kind of input/output.

> Emacspeak is important enough, and the general class of applications
> it belongs to is important enough, that it would be worth while to add
> features to make such a thing easy to do.
This is good to hear.

>     2. Introduce a new hook (prompt-hook?) which would get called
>     for every minibuffer prompt displayed.
>
>     Solution 2 seems more involved, but it would make things more cleaner
>     imo.
>
> Is minibuffer-setup-hook sufficient to do the job?  If not, we could
> add some other hook.

It should work if combined with `last-command'.  I see that emacspeak
does something based on `minibuffer-setup-hook' already, but
unfortunately in those cases, defadvice is still used.
I'd prefer if the use of defadvice could be reduced.

Anyway, I'll have to investigate this a bit more and will report
back if I can find anything we could do to Emacs directly to improve
the situation.

-- 
CYa,
  Mario

Re: callint.c:506

[Richard Stallman]

    Anyway, I'll have to investigate this a bit more and will report
    back if I can find anything we could do to Emacs directly to improve
    the situation.

Thank you in advance.