unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* temp_echo_area_glyphs and Emacspeak
@ 2002-09-05 13:35 Mario Lang
  2002-09-06  4:01 ` Richard Stallman
  2002-09-06 17:15 ` Stefan Monnier
  0 siblings, 2 replies; 7+ messages in thread
From: Mario Lang @ 2002-09-05 13:35 UTC (permalink / raw)


One of the outstanding problems for Emacspeak
is that the [sole completion] and alike messages
don't get spoken at all.

I now found out why: temp_echo_area_glyphs is called
for all those messages, and there is no obvious
way to get this information.

Would it be a problem to introduce a new hook
which gets called with the STRING everytime temp_echo_area_glyphs is
called from C?

How should such a hook be named?  echo-area-hook?

Or is there a better way to get this kind
of information programmatically from Lisp?

-- 
CYa,
  Mario

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

* Re: temp_echo_area_glyphs and Emacspeak
  2002-09-05 13:35 temp_echo_area_glyphs and Emacspeak Mario Lang
@ 2002-09-06  4:01 ` Richard Stallman
  2002-09-06 13:24   ` Mario Lang
  2002-09-06 17:15 ` Stefan Monnier
  1 sibling, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2002-09-06  4:01 UTC (permalink / raw)
  Cc: emacs-devel

    Would it be a problem to introduce a new hook
    which gets called with the STRING everytime temp_echo_area_glyphs is
    called from C?

Ok.  Could you write it?

    How should such a hook be named?  echo-area-hook?

That name implies something more general--it gives people the wrong
idea.  How about temp-echo-area-message-hook?

How does Emacspeak find out about ordinary calls to `message'?

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

* Re: temp_echo_area_glyphs and Emacspeak
  2002-09-06  4:01 ` Richard Stallman
@ 2002-09-06 13:24   ` Mario Lang
  2002-09-07  3:17     ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Mario Lang @ 2002-09-06 13:24 UTC (permalink / raw)


Richard Stallman <rms@gnu.org> writes:

>     Would it be a problem to introduce a new hook
>     which gets called with the STRING everytime temp_echo_area_glyphs is
>     called from C?
>
> Ok.  Could you write it?
I did that now.  It's my first C-level modification of Emacs,
so I'd like to receive comments.  I tested it using
a simple lambda on the hook, and it appears to work fine.

(question: What does the Q prefix mean? V means var, but Q?)

(the patch is below)
If it is OK that way, could someone please apply it?

>     How should such a hook be named?  echo-area-hook?
>
> That name implies something more general--it gives people the wrong
> idea.  How about temp-echo-area-message-hook?
OK, I named it that way.

> How does Emacspeak find out about ordinary calls to `message'?
It uses defadvice.

(defadvice message (around emacspeak pre act)
  ...)

Indeed, it would be nice if we also had a message-hook.


ChangeLog:

2002-09-06  Mario Lang  <mlang@debian.org>

         * minibuf.c: New hook temp-echo-area-message-hook.
         (Qtemp_echo_area_message_hook, Vtemp_echo_area_message_hook)
         (temp_echo_area_glyphs): Call it.
         
 

Index: minibuf.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/minibuf.c,v
retrieving revision 1.249
diff -u -r1.249 minibuf.c
--- minibuf.c	13 Aug 2002 22:52:05 -0000	1.249
+++ minibuf.c	6 Sep 2002 12:37:06 -0000
@@ -102,6 +102,8 @@
 Lisp_Object Qminibuffer_setup_hook, Vminibuffer_setup_hook;
 Lisp_Object Qminibuffer_exit_hook, Vminibuffer_exit_hook;
 
+Lisp_Object Qtemp_echo_area_message_hook, Vtemp_echo_area_message_hook;
+
 /* Function to call to read a buffer name.  */
 Lisp_Object Vread_buffer_function;
 
@@ -2389,11 +2391,17 @@
   int opoint = PT;
   int opoint_byte = PT_BYTE;
   Lisp_Object oinhibit;
+  Lisp_Object args[2];
+
+  args[0] = Qtemp_echo_area_message_hook;
+  args[1] = build_string(m);
+ 
   oinhibit = Vinhibit_quit;
 
   /* Clear out any old echo-area message to make way for our new thing.  */
   message (0);
 
+  Frun_hook_with_args (2, args);
   SET_PT_BOTH (osize, osize_byte);
   insert_string (m);
   SET_PT_BOTH (opoint, opoint_byte);
@@ -2476,6 +2484,9 @@
   Qminibuffer_exit_hook = intern ("minibuffer-exit-hook");
   staticpro (&Qminibuffer_exit_hook);
 
+  Qtemp_echo_area_message_hook = intern ("temp-echo-area-message-hook");
+  staticpro (&Qtemp_echo_area_message_hook);
+
   Qhistory_length = intern ("history-length");
   staticpro (&Qhistory_length);
 
@@ -2496,6 +2507,11 @@
   DEFVAR_LISP ("minibuffer-exit-hook", &Vminibuffer_exit_hook,
 	       doc: /* Normal hook run just after exit from minibuffer.  */);
   Vminibuffer_exit_hook = Qnil;
+
+  DEFVAR_LISP ("temp-echo-area-message-hook", &Vtemp_echo_area_message_hook,
+	       doc: /* Normal hook run with temp-echo-area-message
+as argument. */);
+  Vtemp_echo_area_message_hook = Qnil;
 
   DEFVAR_LISP ("history-length", &Vhistory_length,
 	       doc: /* *Maximum length for history lists before truncation takes place.


-- 
CYa,
  Mario

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

* Re: temp_echo_area_glyphs and Emacspeak
  2002-09-05 13:35 temp_echo_area_glyphs and Emacspeak Mario Lang
  2002-09-06  4:01 ` Richard Stallman
@ 2002-09-06 17:15 ` Stefan Monnier
  1 sibling, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2002-09-06 17:15 UTC (permalink / raw)
  Cc: emacs-devel

> One of the outstanding problems for Emacspeak
> is that the [sole completion] and alike messages
> don't get spoken at all.
> 
> I now found out why: temp_echo_area_glyphs is called
> for all those messages, and there is no obvious
> way to get this information.
> 
> Would it be a problem to introduce a new hook
> which gets called with the STRING everytime temp_echo_area_glyphs is
> called from C?
> 
> How should such a hook be named?  echo-area-hook?
> 
> Or is there a better way to get this kind
> of information programmatically from Lisp?

Use partial-completion-mode (or whichever other package that completiely
redefines the completion functions in elisp).
There, you'll find an elisp implementation of temp_echo_area_glyphs
that you can advise just fine.


	Stefan

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

* Re: temp_echo_area_glyphs and Emacspeak
  2002-09-06 13:24   ` Mario Lang
@ 2002-09-07  3:17     ` Richard Stallman
  2002-09-07 13:11       ` Mario Lang
  0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2002-09-07  3:17 UTC (permalink / raw)
  Cc: emacs-devel

The code you wrote looks correct, but this part is not needed:

    +  DEFVAR_LISP ("temp-echo-area-message-hook", &Vtemp_echo_area_message_hook,
    +	       doc: /* Normal hook run with temp-echo-area-message
    +as argument. */);
    +  Vtemp_echo_area_message_hook = Qnil;

Vtemp_echo_area_message_hook is not needed at all,
because the real implementation does not use it.
Just defvar it in Lisp.

    > How does Emacspeak find out about ordinary calls to `message'?
    It uses defadvice.

That won't work reliably--calls from within the C code won't be
caught.  A message-hook would work more reliably.  Would you like to
write that?

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

* Re: temp_echo_area_glyphs and Emacspeak
  2002-09-07  3:17     ` Richard Stallman
@ 2002-09-07 13:11       ` Mario Lang
  2002-09-09  0:22         ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Mario Lang @ 2002-09-07 13:11 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman <rms@gnu.org> writes:

> The code you wrote looks correct, but this part is not needed:
>
>     +  DEFVAR_LISP ("temp-echo-area-message-hook", &Vtemp_echo_area_message_hook,
>     +	       doc: /* Normal hook run with temp-echo-area-message
>     +as argument. */);
>     +  Vtemp_echo_area_message_hook = Qnil;
>
> Vtemp_echo_area_message_hook is not needed at all,
> because the real implementation does not use it.
> Just defvar it in Lisp.
OK, I'll do this at the beginning of next wekk.

Just one question: Where should the lisp defvar go?  I didn't
find any suitable .el file in lisp/ at first glance.

>     > How does Emacspeak find out about ordinary calls to `message'?
>     It uses defadvice.
>
> That won't work reliably--calls from within the C code won't be
> caught.  A message-hook would work more reliably.  Would you like to
> write that?

Yes, will do.  I looked at the code, and I'm a bit confused
where to call such a  message-hook actually.
At first glance, I'd say in message3 in xdisp.c, but there is also message2
and the various no_log and dolog variants.

Also, should I define message-hook also in Lisp, and if yes, where?

-- 
Thanks,
  Mario

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

* Re: temp_echo_area_glyphs and Emacspeak
  2002-09-07 13:11       ` Mario Lang
@ 2002-09-09  0:22         ` Richard Stallman
  0 siblings, 0 replies; 7+ messages in thread
From: Richard Stallman @ 2002-09-09  0:22 UTC (permalink / raw)
  Cc: emacs-devel

    Just one question: Where should the lisp defvar go?  I didn't
    find any suitable .el file in lisp/ at first glance.

subr.el will do.

    Yes, will do.  I looked at the code, and I'm a bit confused
    where to call such a  message-hook actually.
    At first glance, I'd say in message3 in xdisp.c, but there is also message2
    and the various no_log and dolog variants.

Some of these call each other.  Find the one or two places that the
others call, and change those.

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

end of thread, other threads:[~2002-09-09  0:22 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-05 13:35 temp_echo_area_glyphs and Emacspeak Mario Lang
2002-09-06  4:01 ` Richard Stallman
2002-09-06 13:24   ` Mario Lang
2002-09-07  3:17     ` Richard Stallman
2002-09-07 13:11       ` Mario Lang
2002-09-09  0:22         ` Richard Stallman
2002-09-06 17:15 ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).