Info: Console Vs GUI difference?

Info: Console Vs GUI difference?

[T.V. Raman]

As noted on previous threads -- Emacspeak relies heavily on
advice.

I've observed something strange over the last few years that I've
been too lazy to fix, but started digging  into recently - it's
an interesting problem and may point to a curious underlying bug
-- here goes.

Basically, Info running under X  appears to be making  calls to
signal  after *every user command* -- the signal is also clearly
caught and handled at a fairly low-level because you ordinarily
never see it.

Here is a simple way to cause it to happen -- though it might not
be as easy to observe without Emacspeak active.

At an emacs frame running at the Linux console, hit C-h i to open
info (after ensuring that any previous info buffers are killed)
--  then hit either 'p' or 'u' or 'n' to trigger a user-error --
Emacs reports that  there is no where to go -- and all is well.
Kill this buffer.

Now, switch to an emacs frame in a graphical environment under X,
and repeat the experiment.

Once Emacs has triggered the user error in Info as before, what
I'm observing that when in the info buffer (and only in the info
buffer) something in Emacs appears to be calling signal under the
covers -- and the  signal is trapped and suppressed
**after**after every user action.

Looking through info.el hasn't shed any light ---
-- 

--

Re: Info: Console Vs GUI difference?

[Stefan Monnier]

> Once Emacs has triggered the user error in Info as before, what
> I'm observing that when in the info buffer (and only in the info
> buffer) something in Emacs appears to be calling signal under the
> covers -- and the  signal is trapped and suppressed
> **after**after every user action.

I can't reproduce it here.  At least (setq debug-on-signal t) doesn't
show me any signal thrown.  Which signal is thrown?  Does (setq
debug-on-signal t) catch it?  If so, what does the backtrace say?


        Stefan

Re: Info: Console Vs GUI difference?

[Jarek Czekalski]

W dniu 2013-10-30 10:27, T.V. Raman pisze:
> something in Emacs appears to be calling signal under the
> covers -- and the  signal is trapped and suppressed
> **after**after every user action.

But why do you call it a problem or an error? Since the signals are 
caught, everything is alright. That's what I think and said so in bug 
report 15670 [1]. And that's the reason why the bug was closed as "not a 
bug".

And this "something" is also described in the bug report, in backtrace. 
It is redisplay. Redisplays do not occur on terminals.

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15670

Jarek

Info: Console Vs GUI difference?

[T.V. Raman]

This is related but different/ more subtle.  I suspect something
like tooltip mode or something else that is only active in the
GUI  is raising a signal after *every* user command --- once an
error has been raised in info.
-- 

-- 


On 10/30/13, Jarek Czekalski <jarekczek@poczta.onet.pl> wrote:
>
> W dniu 2013-10-30 10:27, T.V. Raman pisze:
>> something in Emacs appears to be calling signal under the
>> covers -- and the  signal is trapped and suppressed
>> **after**after every user action.
>
> But why do you call it a problem or an error? Since the signals are
> caught, everything is alright. That's what I think and said so in bug
> report 15670 [1]. And that's the reason why the bug was closed as "not a
> bug".
>
> And this "something" is also described in the bug report, in backtrace.
> It is redisplay. Redisplays do not occur on terminals.
>
> [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15670
>
> Jarek
>
>
>

Info: Console Vs GUI difference?

[T.V. Raman]

Debug on signal t doesn't catch this which is why it's proving a
bear to debug.
-- 

-- 


On 10/30/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Once Emacs has triggered the user error in Info as before, what
>> I'm observing that when in the info buffer (and only in the info
>> buffer) something in Emacs appears to be calling signal under the
>> covers -- and the  signal is trapped and suppressed
>> **after**after every user action.
>
> I can't reproduce it here.  At least (setq debug-on-signal t) doesn't
> show me any signal thrown.  Which signal is thrown?  Does (setq
> debug-on-signal t) catch it?  If so, what does the backtrace say?
>
>
>         Stefan
>

Re: Info: Console Vs GUI difference?

[Stefan Monnier]

> Debug on signal t doesn't catch this which is why it's proving a
> bear to debug.

But you can call `backtrace' from a `signal' advice to see the context.
It's probably code in the menu-bar entries trying to decide if an entry
should be active or not.


        Stefan

Info: Console Vs GUI difference?

[T.V. Raman]

I didn't know of that :-) will try this shortly  -- and report
back.

And speaking of aditional emacs hooks that would help emacspeak:

1. A hook that I can use to catch read-only    errors for  typing
commands  -- a hook here would be a clean solution because
independent of context, I mostly want to speak the same thing

2. Less need to advice error/ and hopefully never to advice
signal --
This one is harder because many emacs packages use signal and
error to signal conditions that should be communicated to the
average user.
-- 

-- 


On 10/30/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Debug on signal t doesn't catch this which is why it's proving a
>> bear to debug.
>
> But you can call `backtrace' from a `signal' advice to see the context.
> It's probably code in the menu-bar entries trying to decide if an entry
> should be active or not.
>
>
>         Stefan
>

Re: Info: Console Vs GUI difference?

[Stefan Monnier]

> And speaking of aditional emacs hooks that would help emacspeak:

> 1. A hook that I can use to catch read-only    errors for  typing
> commands  -- a hook here would be a clean solution because
> independent of context, I mostly want to speak the same thing

> 2. Less need to advice error/ and hopefully never to advice signal --
> This one is harder because many emacs packages use signal and
> error to signal conditions that should be communicated to the
> average user.

It seems from where I stand that both should be covered by
command-error-function.  So, maybe you should explain in more detail
which part of command-error-function doesn't suit your need.


        Stefan

Re: Info: Console Vs GUI difference?

[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.

    But why do you call it a problem or an error? Since the signals are 
    caught, everything is alright. That's what I think and said so in bug 
    report 15670 [1]. And that's the reason why the bug was closed as "not a 
    bug".

It may not cause incorrect functioning, but it sounds like a cause
of slowdown.  Unless there is a reason why redisplay is supposed
to raise a signal, this is making Emacs slower than it needs to be,
and investigating the cause might be useful.

    And this "something" is also described in the bug report, in backtrace. 
    It is redisplay. Redisplays do not occur on terminals.

Redisplay does occur on terminals.  Redisplay means showing the
contents of buffers.

-- 
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.

Info: Console Vs GUI difference?

[T.V. Raman]

Hi Stefan:

At this point for the error/signal/user-error feedback -- i
believe command-error-funciton should meet my needs except for
backward compatibility -- some help in knowing how to use it
correctly would help.

Re your suggestion re calling backtrace within the advice, tried
that -- and though I'm hearing the spurious feedback under X  in
Info -- but not at the terminal -- the backtrace is not
invoked. This leads me to suspect a subtle bug in advice itself
-- Here are the advice fragments I have for error, user-error and
signal.

(defcustom emacspeak-speak-errors t
  "Specifies if error messages are cued."
  :type 'boolean
  :group 'emacspeak-speak)

(defadvice error (before emacspeak pre act comp)
  "Speak the error message.
 Also produces an auditory icon if possible."
  (when emacspeak-speak-errors
    (let ((emacspeak-speak-signals nil)
          (emacspeak-speak-errors nil)
          (dtk-stop-immediately  nil))
      (emacspeak-auditory-icon 'warn-user)
      (tts-with-punctuations 'all
                             (dtk-speak
                              (apply #'format (ad-get-arg 0)(ad-get-args 1))))))
  t)

(defadvice user-error (before emacspeak pre act comp)
  "Speak the error message."
  (when emacspeak-speak-errors
    (let ((emacspeak-speak-signals nil)
          (emacspeak-speak-errors nil)
          (dtk-stop-immediately  nil))
      (tts-with-punctuations 'all
                             (dtk-speak
                              (apply #'format (ad-get-arg 0)(ad-get-args 1))))))
  t)



;;;###autoload
(defcustom emacspeak-speak-signals t
  "Specifies if signalled   messages are cued."
  :type 'boolean
  :group 'emacspeak-speak)

(defadvice signal (before emacspeak pre act compile)
  "Speak the signalled  message."
  (when emacspeak-speak-signals
    (let ((msg (first (ad-get-arg 1))))
      (when (and msg (> (length msg) 0))
        (tts-with-punctuations 'all (dtk-speak msg))))))

-- 

-- 


On 10/31/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> And speaking of aditional emacs hooks that would help emacspeak:
>
>> 1. A hook that I can use to catch read-only    errors for  typing
>> commands  -- a hook here would be a clean solution because
>> independent of context, I mostly want to speak the same thing
>
>> 2. Less need to advice error/ and hopefully never to advice signal --
>> This one is harder because many emacs packages use signal and
>> error to signal conditions that should be communicated to the
>> average user.
>
> It seems from where I stand that both should be covered by
> command-error-function.  So, maybe you should explain in more detail
> which part of command-error-function doesn't suit your need.
>
>
>         Stefan
>

Re: Info: Console Vs GUI difference?

[Stefan Monnier]

> -- Here are the advice fragments I have for error, user-error and
> signal.

Can you show the code you used to try and get the backtrace?

> (defadvice signal (before emacspeak pre act compile)
>   "Speak the signalled  message."
>   (when emacspeak-speak-signals
>     (let ((msg (first (ad-get-arg 1))))
>       (when (and msg (> (length msg) 0))
>         (tts-with-punctuations 'all (dtk-speak msg))))))

I'd only use this advice (and throw away the error and user-error
signals), and extend it to check (ad-get-arg 0) for equality with
`error' or `user-error'.


        Stefan

Info: Console Vs GUI difference?

[T.V. Raman]

I just added (backtrace) at the top of the advice form.

-- 
Best Regards,
--raman


On 10/31/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> -- Here are the advice fragments I have for error, user-error and
>> signal.
>
> Can you show the code you used to try and get the backtrace?
>
>> (defadvice signal (before emacspeak pre act compile)
>>   "Speak the signalled  message."
>>   (when emacspeak-speak-signals
>>     (let ((msg (first (ad-get-arg 1))))
>>       (when (and msg (> (length msg) 0))
>>         (tts-with-punctuations 'all (dtk-speak msg))))))
>
> I'd only use this advice (and throw away the error and user-error
> signals), and extend it to check (ad-get-arg 0) for equality with
> `error' or `user-error'.
>
>
>         Stefan
>

Re: Info: Console Vs GUI difference?

[Eli Zaretskii]

> Date: Thu, 31 Oct 2013 16:23:17 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>     But why do you call it a problem or an error? Since the signals are 
>     caught, everything is alright. That's what I think and said so in bug 
>     report 15670 [1]. And that's the reason why the bug was closed as "not a 
>     bug".
> 
> It may not cause incorrect functioning, but it sounds like a cause
> of slowdown.  Unless there is a reason why redisplay is supposed
> to raise a signal, this is making Emacs slower than it needs to be,
> and investigating the cause might be useful.

The cause is clear.  Redisplay does not raise a signal, it just
evaluates conditions of a menu bar item, to be able to display the
"Next" item as disabled when there's no "next" node.  The Lisp code
that is invoked by redisplay to do that throws an error that is
supposed to be caught by that Lisp code.  However, Emacsspeak advises
the Lisp function Info-extract-pointer, which is involved in this
evaluation, with the result that the thrown error becomes visible.
See the Lisp backtrace here:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15670#5

and the Lisp code involved here:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15670#14

So the bottom line here is that the reason for the problem was a
bad/suboptimal advice used by Emacsspeak to advise the Info functions
in question.

Re: Info: Console Vs GUI difference?

[Stefan Monnier]

> I just added (backtrace) at the top of the advice form.

Check the docstring of `backtrace' ;-)

It doesn't display the backtrace, it just prints it somewhere.
Typically, you make it print into some temp buffer which you can consult
manually later on.


        Stefan

Info: Console Vs GUI difference?

[T.V. Raman]

Found the backtrace:-)

I  see that redisplay is triggering the bug -- but only under X.

Once user-error has been triggered once in info, then the signal
is raised after * every user command * -- see output below from
the Messages buffer.
backtrace()
  emacspeak-speak-error-message(user-error "Node has no Up")
  ad-Advice-signal(#<subr signal> user-error ("Node has no Up"))
  apply(ad-Advice-signal #<subr signal> (user-error ("Node has no Up")))
  signal(user-error ("Node has no Up"))
  user-error("Node has no %s" "Up")
  #[(name &optional errorname) "Ä\x18Šebˆ`\x19ÅyˆÆ
ÇÈ Q	Ä#ƒ\x1d\0ÉÅ!‚.\0\vÄ=?….\0ÊËÌ\v†,\0
!\"+‡" [case-fold-search bound name errorname t 1 re-search-backward
":" Info-following-node-name-re match-string-no-properties user-error
"Node has no %s" capitalize] 4
("/usr/local/share/emacs/24.3.50/lisp/info.elc" . 56390)]("up" nil)
  ad-Advice-Info-extract-pointer(#[(name &optional errorname) "Ä\x18Šebˆ`\x19ÅyˆÆ
ÇÈ Q	Ä#ƒ\x1d\0ÉÅ!‚.\0\vÄ=?….\0ÊËÌ\v†,\0
!\"+‡" [case-fold-search bound name errorname t 1 re-search-backward
":" Info-following-node-name-re match-string-no-properties user-error
"Node has no %s" capitalize] 4
("/usr/local/share/emacs/24.3.50/lisp/info.elc" . 56390)] "up")
  apply(ad-Advice-Info-extract-pointer #[(name &optional errorname)
"Ä\x18Šebˆ`\x19ÅyˆÆ
ÇÈ Q	Ä#ƒ\x1d\0ÉÅ!‚.\0\vÄ=?….\0ÊËÌ\v†,\0
!\"+‡" [case-fold-search bound name errorname t 1 re-search-backward
":" Info-following-node-name-re match-string-no-properties user-error
"Node has no %s" capitalize] 4
("/usr/local/share/emacs/24.3.50/lisp/info.elc" . 56390)] "up")
  Info-extract-pointer("up")
  Info-up()
  call-interactively(Info-up nil nil)
  command-execute(Info-up)

On 11/1/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I just added (backtrace) at the top of the advice form.
>
> Check the docstring of `backtrace' ;-)
>
> It doesn't display the backtrace, it just prints it somewhere.
> Typically, you make it print into some temp buffer which you can consult
> manually later on.
>
>
>         Stefan
>

Info: Console Vs GUI difference?

[T.V. Raman]

Eli,
The advice on Info-extract-pointer you refer to was probably
introduced by me to track this problem down.  Emacspeak used to
advice that function in the Emacs 21 timeframe as well from
memory -- but to the best of my knowledge, it hasn't depended on
advising Info-extract-pointer --


On 11/1/13, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 31 Oct 2013 16:23:17 -0400
>> From: Richard Stallman <rms@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>>     But why do you call it a problem or an error? Since the signals are
>>     caught, everything is alright. That's what I think and said so in bug
>>
>>     report 15670 [1]. And that's the reason why the bug was closed as "not
>> a
>>     bug".
>>
>> It may not cause incorrect functioning, but it sounds like a cause
>> of slowdown.  Unless there is a reason why redisplay is supposed
>> to raise a signal, this is making Emacs slower than it needs to be,
>> and investigating the cause might be useful.
>
> The cause is clear.  Redisplay does not raise a signal, it just
> evaluates conditions of a menu bar item, to be able to display the
> "Next" item as disabled when there's no "next" node.  The Lisp code
> that is invoked by redisplay to do that throws an error that is
> supposed to be caught by that Lisp code.  However, Emacsspeak advises
> the Lisp function Info-extract-pointer, which is involved in this
> evaluation, with the result that the thrown error becomes visible.
> See the Lisp backtrace here:
>
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15670#5
>
> and the Lisp code involved here:
>
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15670#14
>
> So the bottom line here is that the reason for the problem was a
> bad/suboptimal advice used by Emacsspeak to advise the Info functions
> in question.
>
>

Re: Info: Console Vs GUI difference?

[Eli Zaretskii]

> Date: Fri, 1 Nov 2013 09:55:44 -0700
> From: "T.V. Raman" <tv.raman.tv@gmail.com>
> 
> Found the backtrace:-)
> 
> I  see that redisplay is triggering the bug -- but only under X.
> 
> Once user-error has been triggered once in info, then the signal
> is raised after * every user command * -- see output below from
> the Messages buffer.
> backtrace()
>   emacspeak-speak-error-message(user-error "Node has no Up")
>   ad-Advice-signal(#<subr signal> user-error ("Node has no Up"))
>   apply(ad-Advice-signal #<subr signal> (user-error ("Node has no Up")))
>   signal(user-error ("Node has no Up"))
>   user-error("Node has no %s" "Up")

That's your problem, right there: why does the function that advises
'signal' calls emacspeak-speak-error-message in this case?  It
shouldn't, because this signal is supposed to be caught by whoever
called Info-up.  Your advice simply disrupted the designed flow of
control.

Info: Console Vs GUI difference?

[T.V. Raman]

With all due respect, I believe you're  wrong here -- that's not
the problem.  And it works correctly at the console.  When
running under X, the signal once raised, gets raised repeatedly
after every user command, and the backtrace shows that it's
coming from redisplay.

I coded up the emacspeak handler in a function that I then called
from the advice for clarity -- not sure how you conclude that
that is the cause of the problem ---

On 11/1/13, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 1 Nov 2013 09:55:44 -0700
>> From: "T.V. Raman" <tv.raman.tv@gmail.com>
>>
>> Found the backtrace:-)
>>
>> I  see that redisplay is triggering the bug -- but only under X.
>>
>> Once user-error has been triggered once in info, then the signal
>> is raised after * every user command * -- see output below from
>> the Messages buffer.
>> backtrace()
>>   emacspeak-speak-error-message(user-error "Node has no Up")
>>   ad-Advice-signal(#<subr signal> user-error ("Node has no Up"))
>>   apply(ad-Advice-signal #<subr signal> (user-error ("Node has no Up")))
>>   signal(user-error ("Node has no Up"))
>>   user-error("Node has no %s" "Up")
>
> That's your problem, right there: why does the function that advises
> 'signal' calls emacspeak-speak-error-message in this case?  It
> shouldn't, because this signal is supposed to be caught by whoever
> called Info-up.  Your advice simply disrupted the designed flow of
> control.
>

Re: Info: Console Vs GUI difference?

[Eli Zaretskii]

> Date: Fri, 1 Nov 2013 13:24:47 -0700
> From: "T.V. Raman" <tv.raman.tv@gmail.com>
> 
> With all due respect, I believe you're  wrong here -- that's not
> the problem.  And it works correctly at the console.  When
> running under X, the signal once raised, gets raised repeatedly
> after every user command, and the backtrace shows that it's
> coming from redisplay.

It comes from redisplay because redisplay recomputes the menu and
tool-bar items.  As the tool bar is not displayed in a TTY session,
you don't get signals then.

The root cause is still that 'signal' is being advised in a way that
exposes it to the user.

Info: Console Vs GUI difference?

[T.V. Raman]

I understand better now.  But I cannot but advice it because
there are many parts of emacs -- and emacs packages -- that
already use signal to display useful information to the user.
Yes, that is clearly incorrect, but that  is what packages are
doing, so I have no option but to speak them. I'd be happy to
hear about an alternative -- note that I suspect
command-error-function might run into the same issue -- perhaps
differently.


-- 

-- 


On 11/1/13, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 1 Nov 2013 13:24:47 -0700
>> From: "T.V. Raman" <tv.raman.tv@gmail.com>
>>
>> With all due respect, I believe you're  wrong here -- that's not
>> the problem.  And it works correctly at the console.  When
>> running under X, the signal once raised, gets raised repeatedly
>> after every user command, and the backtrace shows that it's
>> coming from redisplay.
>
> It comes from redisplay because redisplay recomputes the menu and
> tool-bar items.  As the tool bar is not displayed in a TTY session,
> you don't get signals then.
>
> The root cause is still that 'signal' is being advised in a way that
> exposes it to the user.
>

Info: Console Vs GUI difference?

[T.V. Raman]

For now I've worked around the problem by disabling tool-bar-mode
--  --- tool-bar-mode is something I dont personally care about
as a non-mouse-waving human -- however I would still say that
tool-bar-mode is probably doing more work than it should - in the
way it's getting called through redisplay.

Disabling the tool-bar in emacspeak likely affects low-vision
users, so this would be good to fix.

-- 
Best Regards,
--raman


On 11/1/13, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 1 Nov 2013 13:24:47 -0700
>> From: "T.V. Raman" <tv.raman.tv@gmail.com>
>>
>> With all due respect, I believe you're  wrong here -- that's not
>> the problem.  And it works correctly at the console.  When
>> running under X, the signal once raised, gets raised repeatedly
>> after every user command, and the backtrace shows that it's
>> coming from redisplay.
>
> It comes from redisplay because redisplay recomputes the menu and
> tool-bar items.  As the tool bar is not displayed in a TTY session,
> you don't get signals then.
>
> The root cause is still that 'signal' is being advised in a way that
> exposes it to the user.
>

Re: Info: Console Vs GUI difference?

[Stefan Monnier]

> hear about an alternative -- note that I suspect
> command-error-function might run into the same issue --

I don't think so: command-error-function will be called if and only if
the normal (non-emacspeak) code would display a message, whereas
advising `signal' leads to the problems you see, where some signals are
"normal occurrences" that don't lead to any user-visible message because
they get caught and handled by a `condition-case'.


        Stefan

Re: Info: Console Vs GUI difference?

[Eli Zaretskii]

> Date: Fri, 1 Nov 2013 17:17:41 -0700
> From: "T.V. Raman" <tv.raman.tv@gmail.com>
> 
> I understand better now.  But I cannot but advice it because
> there are many parts of emacs -- and emacs packages -- that
> already use signal to display useful information to the user.

I didn't say you shouldn't advise it.  I just said that there's no bug
in Emacs in this case: it works as intended.

> Yes, that is clearly incorrect, but that  is what packages are
> doing, so I have no option but to speak them. I'd be happy to
> hear about an alternative -- note that I suspect
> command-error-function might run into the same issue -- perhaps
> differently.

The short-term alternative is to avoid speaking this particular
signal, by somehow detecting it.

The long-term alternative is to gradually abandon the advice methods
and switch to using special hooks that Emacs will provide for this
type of software.  Please consider presenting a list of hooks you'd
like to have for Emacsspeak, and file a feature request bug report
with that list.  Emacs ought to have good support for Emacsspeak that
does not require use of advice, IMO.

Re: Info: Console Vs GUI difference?

[Jarek Czekalski]

W dniu 11/02/2013 02:39 AM, T.V. Raman pisze:
> Disabling the tool-bar in emacspeak likely affects low-vision
> users, so this would be good to fix.

Raman,

Emacspeak package was the reason I switched to Emacs. I use both visual 
Emacs functions and Emacspeak auditory feedback. Every loss in Emacs 
functionality is a big disadvantage for me. Please explain in what way 
you expect to fix this, so that we have Emacspeak without loosing any 
functionality of Emacs.

And please also explain what problems an Emacspeak user experiences 
without switching off the toolbar.

My vision is that Emacspeak be the best option for disabled programmers 
among all text editors. This Emacspeak should not be worse than Emacs.

Jarek

Info: Console Vs GUI difference?

[T.V. Raman]

Hi Stefan,

My last attempt at using command-error-function -- appended below
-- only produces a "back to top level"  message in all instances.

Once I can get this working, I'll make the advice on signal
conditional on older emacsuns --
(defun emacspeak-error-handler  (data  context  calling-function)
  "Emacspeak custom error handling function."
               (dtk-speak
     (format "%s %s"
             (or context "")
             (or
              (get (car data) 'error-message)
              ""))))

(declaim (special command-error-function))
                                            (add-function :before
command-error-function 'emacspeak-error-handler)

-- 

-- 


On 10/31/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> And speaking of aditional emacs hooks that would help emacspeak:
>
>> 1. A hook that I can use to catch read-only    errors for  typing
>> commands  -- a hook here would be a clean solution because
>> independent of context, I mostly want to speak the same thing
>
>> 2. Less need to advice error/ and hopefully never to advice signal --
>> This one is harder because many emacs packages use signal and
>> error to signal conditions that should be communicated to the
>> average user.
>
> It seems from where I stand that both should be covered by
> command-error-function.  So, maybe you should explain in more detail
> which part of command-error-function doesn't suit your need.
>
>
>         Stefan
>

Re: Info: Console Vs GUI difference?

[Jarek Czekalski]

W dniu 11/02/2013 04:35 PM, T.V. Raman pisze:
> My last attempt at using command-error-function -- appended below
> -- only produces a "back to top level"  message in all instances.
>

It means an error in the handler code. It manifests through this 
unrelated message.

Jarek

Re: Info: Console Vs GUI difference?

[Dmitri Paduchikh]

Raman, how about this code?

(defun emacspeak-error-handler (err context func)
  (let ((err-msg (concat context (error-message-string err)))
        (emacspeak-speak-messages nil)
        (dtk-stop-immediately nil))
    (dtk-stop)
    (message "%s"
             (concat err-msg
                     (if func (concat " (" (symbol-name func) ")") "")))
    (ding)
    (dtk-speak err-msg)))

Also note that add-function is not available in Emacs 24.3.

-- 
With best regards
Dmitri Paduchikh

T.V. Raman wrote:

> Hi Stefan,

> My last attempt at using command-error-function -- appended below
> -- only produces a "back to top level"  message in all instances.

> Once I can get this working, I'll make the advice on signal
> conditional on older emacsuns --
> (defun emacspeak-error-handler  (data  context  calling-function)
>   "Emacspeak custom error handling function."
>                (dtk-speak
>      (format "%s %s"
>              (or context "")
>              (or
>               (get (car data) 'error-message)
>               ""))))

> (declaim (special command-error-function))
>                                             (add-function :before
> command-error-function 'emacspeak-error-handler)

Info: Console Vs GUI difference?

[T.V. Raman]

Has the same problem as the code I showed -- this outputs  a set
of messages, including "back to top level"  for every case, -- so
if you install the code, (as with my previous example code), you
hear "back to top level"  even when you hit C-g.

-- 
Best Regards,
--raman


On 11/2/13, Dmitri Paduchikh <dpaduchikh@gmail.com> wrote:
> Raman, how about this code?
>
> (defun emacspeak-error-handler (err context func)
>   (let ((err-msg (concat context (error-message-string err)))
>         (emacspeak-speak-messages nil)
>         (dtk-stop-immediately nil))
>     (dtk-stop)
>     (message "%s"
>              (concat err-msg
>                      (if func (concat " (" (symbol-name func) ")") "")))
>     (ding)
>     (dtk-speak err-msg)))
>
> Also note that add-function is not available in Emacs 24.3.
>
> --
> With best regards
> Dmitri Paduchikh
>
> T.V. Raman wrote:
>
>> Hi Stefan,
>
>> My last attempt at using command-error-function -- appended below
>> -- only produces a "back to top level"  message in all instances.
>
>> Once I can get this working, I'll make the advice on signal
>> conditional on older emacsuns --
>> (defun emacspeak-error-handler  (data  context  calling-function)
>>   "Emacspeak custom error handling function."
>>                (dtk-speak
>>      (format "%s %s"
>>              (or context "")
>>              (or
>>               (get (car data) 'error-message)
>>               ""))))
>
>> (declaim (special command-error-function))
>>                                             (add-function :before
>> command-error-function 'emacspeak-error-handler)
>
>

Info: Console Vs GUI difference?

[T.V. Raman]

Hi Stefan --

Traced down command-error-function a bit further -- and here is
what I see:

If you add your own hook to command-error-function, Emacs appears
to mysteriously call normal-top-level after calling your custom
error handler -- At least that is what I see if I stick a
backtrace call inside an advice fragment to message.

The present show-stopper for using command-error-function in
emacspeak is that that "back to top level"  message  is echoed to
the echo area -- I can silence that message from emacspeak, but
it still shows in the echo area visually.

Here is what I have for the handler:
(defun emacspeak-error-handler  (data  context  calling-function)
  "Emacspeak custom error handling function."
  (tts-with-punctuations
   'all
   (dtk-speak
    (format "%s %s"
            (error-message-string data)
            (or context " ")))))

-- 
Best Regards,
--raman


On 11/1/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> hear about an alternative -- note that I suspect
>> command-error-function might run into the same issue --
>
> I don't think so: command-error-function will be called if and only if
> the normal (non-emacspeak) code would display a message, whereas
> advising `signal' leads to the problems you see, where some signals are
> "normal occurrences" that don't lead to any user-visible message because
> they get caught and handled by a `condition-case'.
>
>
>         Stefan
>

Re: Info: Console Vs GUI difference?

[Jarek Czekalski]

W dniu 11/03/2013 04:51 PM, T.V. Raman pisze:
> Here is what I have for the handler:
> (defun emacspeak-error-handler  (data  context  calling-function)
>    "Emacspeak custom error handling function."
>    (tts-with-punctuations
>     'all
>     (dtk-speak
>      (format "%s %s"
>              (error-message-string data)
>              (or context " ")))))
>

I installed this very handler with command:

(setq command-error-function 'emacspeak-error-handler)

It seems to work perfectly. Speaks "end-of-buffer", "arithmetic error", 
"buffer is read only". Echo area is all the time empty. Before 
installing the handler errors are accompanied with bell. Later there is 
no bell. Tested with Emacspeak r8509, the newest at the moment of 
writing this post.

Jarek

Info: Console Vs GUI difference?

[T.V. Raman]

It doesn't work with the recommended means of using add-function
-- so perhaps there is a bug in nadvice

-- 
Best Regards,
--raman


On 11/3/13, Jarek Czekalski <jarekczek@poczta.onet.pl> wrote:
> W dniu 11/03/2013 04:51 PM, T.V. Raman pisze:
>> Here is what I have for the handler:
>> (defun emacspeak-error-handler  (data  context  calling-function)
>>    "Emacspeak custom error handling function."
>>    (tts-with-punctuations
>>     'all
>>     (dtk-speak
>>      (format "%s %s"
>>              (error-message-string data)
>>              (or context " ")))))
>>
>
> I installed this very handler with command:
>
> (setq command-error-function 'emacspeak-error-handler)
>
> It seems to work perfectly. Speaks "end-of-buffer", "arithmetic error",
> "buffer is read only". Echo area is all the time empty. Before
> installing the handler errors are accompanied with bell. Later there is
> no bell. Tested with Emacspeak r8509, the newest at the moment of
> writing this post.
>
> Jarek
>
>

Re: Info: Console Vs GUI difference?

[Stefan Monnier]

> It doesn't work with the recommended means of using add-function

No, that will be the recommend way once command-error-function does not
default to being nil any more.  But as long as it's nil, add-function
can't be used with it.


        Stefan

Re: Info: Console Vs GUI difference?

[Dmitri Paduchikh]

T.V. Raman wrote:

> It doesn't work with the recommended means of using add-function
> -- so perhaps there is a bug in nadvice

If I understood right, add-function cannot be applied to variables
having nil values. The initial value must be a function. Though I did
not check the development version of Emacs.

-- 
With best regards
Dmitri Paduchikh

Info: Console Vs GUI difference?

[T.V. Raman]

Thanks to all who helped -- from Emacspeak's point of view, I
consider this issue closed -- setq on command-error-function
works --  and emacspeak is now able to output the feedback it
needs to without advising signal in emacsuns where
command-error-function is available.
-- 

-- 


On 11/3/13, Dmitri Paduchikh <dpaduchikh@gmail.com> wrote:
> T.V. Raman wrote:
>
>> It doesn't work with the recommended means of using add-function
>> -- so perhaps there is a bug in nadvice
>
> If I understood right, add-function cannot be applied to variables
> having nil values. The initial value must be a function. Though I did
> not check the development version of Emacs.
>
> --
> With best regards
> Dmitri Paduchikh
>