Request: Use message instead of message_with_string for user visible output?

Request: Use message instead of message_with_string for user visible output?

[T.V. Raman]

Hi,

Emacspeak produces all its spoken feedback via advice --- so in
general, output that gets done purely through the C layer ends up
by-passing the advice layer.

Except in cases where efficiency is the reason for the choice,
could we switch to using message -- instead of
message_with_string to produce output in the echo area that is
 to be seen by the user?

As a place where I'd appreciate a fix, see keyboard.c:

When you press  a key that is currently undefined, the code in
that module uses message_with_string to output a visible "%s is
undefined" message.
-- 

--

Re: Request: Use message instead of message_with_string for user visible output?

[Eli Zaretskii]

> Date: Sat, 26 Oct 2013 09:11:41 -0700
> From: "T.V. Raman" <tv.raman.tv@gmail.com>
> 
> Emacspeak produces all its spoken feedback via advice --- so in
> general, output that gets done purely through the C layer ends up
> by-passing the advice layer.

We could have special hooks to support Emacspeak and its likes,
without moving everything to Lisp.

Advice IMO is a kludgey way to get features which are missing in the
infrastructure; if large and important (to some) packages such as
Emacspeak need features that are missing, it is better to add such
features than to rely on kludges forever.

Request: Use message instead of message_with_string for user visible output?

[T.V. Raman]

Am happy to see you add features for emacspeak:-)

Some useful hooks to add:

1. A hook that is called when information is echoed to the
message area --- it might get chatty if it always talked.

2. A pre-insert hook on self-insert-command -- right now I cant
tell from the emacspeak end when   self-insert-command bales out
because the current context is read-only.


-- 

-- 


On 10/26/13, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 26 Oct 2013 09:11:41 -0700
>> From: "T.V. Raman" <tv.raman.tv@gmail.com>
>>
>> Emacspeak produces all its spoken feedback via advice --- so in
>> general, output that gets done purely through the C layer ends up
>> by-passing the advice layer.
>
> We could have special hooks to support Emacspeak and its likes,
> without moving everything to Lisp.
>
> Advice IMO is a kludgey way to get features which are missing in the
> infrastructure; if large and important (to some) packages such as
> Emacspeak need features that are missing, it is better to add such
> features than to rely on kludges forever.
>

Re: Request: Use message instead of message_with_string for user visible output?

[Dmitri Paduchikh]

T.V. Raman wrote:

> Some useful hooks to add:

[...]

> 2. A pre-insert hook on self-insert-command -- right now I cant tell
> from the emacspeak end when self-insert-command bales out because
> the current context is read-only.

Just for the record, I have proposed on the Emacspeak list to use
command-error-function for speaking read-only errors. It seems to work
well with self-insert-command and other such cases.

For speaking undefined keys there is a solution using a little trickery
from ring-bell-function:

(defun my-speak-echo-area ()
  (let ((msg (current-message)))
    (if (> (length msg) 0)
	(dtk-speak msg))))

(setq ring-bell-function
      (lambda ()
	(dtk-stop)
	(emacspeak-auditory-icon 'warn-user)
	(if (eq this-command nil)
	    (run-with-idle-timer 0 nil 'my-speak-echo-area))))

Of course, it would be nice if some uniform solution existed.

-- 
With best regards
Dmitri Paduchikh

Request: Use message instead of message_with_string for user visible output?

[T.V. Raman]

I've advised self-insert-command to produce auditory output for
read-only cases.

Note that once upon a time (see emacspeak code base)  emacspeak
actually replaced self-insert-command with its own
implementation.  In newer versions, I dont do that  any more
because I can use  the relevant post hook; however, that also
lost us the auditory feedback when the buffer is read-only or
when the text has read-only property set.  My personal preference
would be to not  to muck with command-error-function -- I played
with it a bit last week -- it feels like too heavy a hammer, and
at the end of the day might also produce too much output.

Note that emacs packages are in general not well-disciplined with
when they call error vs signal -- and often use error or signal
to provide user-feedback e.g. emacs itself when you hit
end-of-buffer -- or the VM  mail reader when you hit end-of-folder.

-- 
Best Regards,
--raman


On 10/26/13, Dmitri Paduchikh <dpaduchikh@gmail.com> wrote:
> T.V. Raman wrote:
>
>> Some useful hooks to add:
>
> [...]
>
>> 2. A pre-insert hook on self-insert-command -- right now I cant tell
>> from the emacspeak end when self-insert-command bales out because
>> the current context is read-only.
>
> Just for the record, I have proposed on the Emacspeak list to use
> command-error-function for speaking read-only errors. It seems to work
> well with self-insert-command and other such cases.
>
> For speaking undefined keys there is a solution using a little trickery
> from ring-bell-function:
>
> (defun my-speak-echo-area ()
>   (let ((msg (current-message)))
>     (if (> (length msg) 0)
> 	(dtk-speak msg))))
>
> (setq ring-bell-function
>       (lambda ()
> 	(dtk-stop)
> 	(emacspeak-auditory-icon 'warn-user)
> 	(if (eq this-command nil)
> 	    (run-with-idle-timer 0 nil 'my-speak-echo-area))))
>
> Of course, it would be nice if some uniform solution existed.
>
> --
> With best regards
> Dmitri Paduchikh
>

Re: Request: Use message instead of message_with_string for user visible output?

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

Emacspeak is important, so I think we should add whatever hooks you
would find most convenient.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Request: Use message instead of message_with_string for user visible output?

[Jarek Czekalski]

W dniu 2013-10-27 23:07, T.V. Raman pisze:
> My personal preference
> would be to not  to muck with command-error-function -- I played
> with it a bit last week -- it feels like too heavy a hammer, and
> at the end of the day might also produce too much output.

Raman, in this thread [1] we are given green light to improve 
command-error-function. Could you provide an example of the operation, 
that would be handled badly by command-error-function? For me it seems 
to be the best solution. For example it delivers "read only" message 
properly.

Further, if "key undefined" was also populated as an error-message, it 
would not require special handling by Emacspeak. This is all a song of 
the future (Emacs 25), but why not having a good plan?

By now you could start using command-error-function as if it was our 
private variable, later it would be made better accessible for packages 
and then we would adjust to new standards.

Jarek

[1] 
http://emacs.1067599.n5.nabble.com/command-error-function-default-handler-tp300931.html

Re: Request: Use message instead of message_with_string for user visible output?

[Johan Bockgård]

Jarek Czekalski <jarekczek@poczta.onet.pl> writes:

> By now you could start using command-error-function as if it was our
> private variable, later it would be made better accessible for
> packages and then we would adjust to new standards.

Actually I'm surprised that you aren't using command-error-function
already, since it was added specifically for the sake of Emacspeak.

Request: Use message instead of message_with_string for user visible output?

[T.V. Raman]

Yes,

I haven't used it  yet for a couple of reasons --
I wanted to support older emacsuns as long as possible;  also,
having experimented with it, I find having to place a lot of
logic inside that function a bit unpleasant.
-- 

-- 


On 10/28/13, Johan Bockgård <bojohan@gnu.org> wrote:
> Jarek Czekalski <jarekczek@poczta.onet.pl> writes:
>
>> By now you could start using command-error-function as if it was our
>> private variable, later it would be made better accessible for
>> packages and then we would adjust to new standards.
>
> Actually I'm surprised that you aren't using command-error-function
> already, since it was added specifically for the sake of Emacspeak.
>
>

Request: Use message instead of message_with_string for user visible output?

[T.V. Raman]

Personally I believe implementing all of this logic inside
command-error-function would become fragile over time.

My personal preference would be for emacs to call through to the
lisp layer except in cases where it's running out of memory or
otherwise crashing badly --- this would significantly simplify
the emacspeak implementation.

I consider command-error-function a  solution of last resort --
not the first option.
-- 

-- 


On 10/28/13, Jarek Czekalski <jarekczek@poczta.onet.pl> wrote:
>
> W dniu 2013-10-27 23:07, T.V. Raman pisze:
>> My personal preference
>> would be to not  to muck with command-error-function -- I played
>> with it a bit last week -- it feels like too heavy a hammer, and
>> at the end of the day might also produce too much output.
>
> Raman, in this thread [1] we are given green light to improve
> command-error-function. Could you provide an example of the operation,
> that would be handled badly by command-error-function? For me it seems
> to be the best solution. For example it delivers "read only" message
> properly.
>
> Further, if "key undefined" was also populated as an error-message, it
> would not require special handling by Emacspeak. This is all a song of
> the future (Emacs 25), but why not having a good plan?
>
> By now you could start using command-error-function as if it was our
> private variable, later it would be made better accessible for packages
> and then we would adjust to new standards.
>
> Jarek
>
> [1]
> http://emacs.1067599.n5.nabble.com/command-error-function-default-handler-tp300931.html
>
>
>

RE: Request: Use message instead of message_with_string for user visible output?

[Drew Adams]

> Emacspeak produces all its spoken feedback via advice --- so in
> general, output that gets done purely through the C layer ends up
> by-passing the advice layer.

While you cannot advise C functions in general, you should at least
be able to advise special forms (builtins).

That you cannot currently advise special forms is a bug, and
specifically a regression.  Even the latest doc maintains that
you can, even though this has been broken since Emacs 22.

See bug #15666:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15666

Re: Request: Use message instead of message_with_string for user visible output?

[Stefan Monnier]

> Except in cases where efficiency is the reason for the choice,
> could we switch to using message -- instead of
> message_with_string to produce output in the echo area that is
>  to be seen by the user?

I doubt there is a place where we call message_with_string for
efficiency reasons: the added cost of going through Ffuncall of Qmessage
is negligible compared to the cost of doing the actual display of
the message.

But there might be cases where we need it for correctness reasons,
because the context is such that we can't run arbitrary Elisp code.


        Stefan

Request: Use message instead of message_with_string for user visible output?

[T.V. Raman]

Thanks Stefan,

Could you please update keyboard.c to call message instead of
message_with_string when the user presses a key that is
undefined?

I understand that opinions re advice is  mixed with some
considering it a kluge, but  kluge or not, it's stood Emacspeak
in good stead and helped create a solution that has made me and
others very productive over the last 18 years:-)

-- 
Best Regards,
--raman


On 10/26/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Except in cases where efficiency is the reason for the choice,
>> could we switch to using message -- instead of
>> message_with_string to produce output in the echo area that is
>>  to be seen by the user?
>
> I doubt there is a place where we call message_with_string for
> efficiency reasons: the added cost of going through Ffuncall of Qmessage
> is negligible compared to the cost of doing the actual display of
> the message.
>
> But there might be cases where we need it for correctness reasons,
> because the context is such that we can't run arbitrary Elisp code.
>
>
>         Stefan
>

Re: Request: Use message instead of message_with_string for user visible output?

[Stefan Monnier]

> Could you please update keyboard.c to call message instead of
> message_with_string when the user presses a key that is
> undefined?

I've changed the code to call `undefined' which then uses `message'.

> I understand that opinions re advice is mixed with some
> considering it a kluge, but kluge or not, it's stood Emacspeak
> in good stead and helped create a solution that has made me and
> others very productive over the last 18 years:-)

Advice is great, indeed.  But w generally try to take existing advices
as indication that we should add hooks and/or refactor code so that
those pieces of advice aren't needed any more.

But don't worry: emacspeak is not the only package that's been relying
on advice for many years.  `unquify' is another one that even comes
bundled with Emacs.


        Stefan

Request: Use message instead of message_with_string for user visible output?

[T.V. Raman]

Thanks for making the change Stefan!

Where advice has helped Emacspeak is  in producing extremely
context-specific feedback --- which is why except in very focused
cases   -- e.g., self-insert-command, hooks  dont work as well
---  the nightmare scenario is writing a large bunch of
case
analysis  statements within a hook function to produce cont-specific feedback.
-- 

-- 


On 10/29/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Could you please update keyboard.c to call message instead of
>> message_with_string when the user presses a key that is
>> undefined?
>
> I've changed the code to call `undefined' which then uses `message'.
>
>> I understand that opinions re advice is mixed with some
>> considering it a kluge, but kluge or not, it's stood Emacspeak
>> in good stead and helped create a solution that has made me and
>> others very productive over the last 18 years:-)
>
> Advice is great, indeed.  But w generally try to take existing advices
> as indication that we should add hooks and/or refactor code so that
> those pieces of advice aren't needed any more.
>
> But don't worry: emacspeak is not the only package that's been relying
> on advice for many years.  `unquify' is another one that even comes
> bundled with Emacs.
>
>
>         Stefan
>