Info: Console Vs GUI difference?

["T.V. Raman" <tv.raman.tv@gmail.com>]

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