From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "T.V. Raman" Newsgroups: gmane.emacs.devel Subject: Info: Console Vs GUI difference? Date: Sun, 3 Nov 2013 07:51:05 -0800 Message-ID: References: <83eh70as37.fsf@gnu.org> <837gcrc10q.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1383493867 4921 80.91.229.3 (3 Nov 2013 15:51:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Nov 2013 15:51:07 +0000 (UTC) To: Stefan Monnier , Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 03 16:51:12 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VczxI-0005Ph-0e for ged-emacs-devel@m.gmane.org; Sun, 03 Nov 2013 16:51:12 +0100 Original-Received: from localhost ([::1]:45540 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VczxH-0004yN-Jz for ged-emacs-devel@m.gmane.org; Sun, 03 Nov 2013 10:51:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VczxE-0004yI-QM for emacs-devel@gnu.org; Sun, 03 Nov 2013 10:51:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VczxD-0006vj-W9 for emacs-devel@gnu.org; Sun, 03 Nov 2013 10:51:08 -0500 Original-Received: from mail-oa0-x229.google.com ([2607:f8b0:4003:c02::229]:55694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VczxC-0006vN-F5; Sun, 03 Nov 2013 10:51:06 -0500 Original-Received: by mail-oa0-f41.google.com with SMTP id o9so6390207oag.28 for ; Sun, 03 Nov 2013 07:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=L8VQUkfpMlNzBwCQP1IEBtrttDhXw7WSM+W+zlVeuuA=; b=miIBh/5r73E+O88vRmuSl0x4KTdok8y4umF3BNhqMReQe7Lg5cok5A3cjKdXuapLjE 0Oz/pHkX3m7/JO5dr+M0aC/nFmapzH6LxU0Y7CrJy4JNLHGLA4MypPaFlGWV9/kNVRA2 dI0d25sfTs8CKH5fuhXEFuQUsYftx4kYfocfVaMV/l2fhHgdtufb49GGoFXyQilpuxbc VMSai3k8Qmm6L3xWLAjn+MB/Lqdrk+C7xLFMhSkC7haANc/pLiEKEI6cszHUl9pTdfRd VaiKlpxoGBnzAbDSxh7vvkwdWa3ptAJyKYQsIRxK8INuViO7BV//6/TqBYsUoTuMxJFI 021w== X-Received: by 10.60.70.134 with SMTP id m6mr10561706oeu.14.1383493865519; Sun, 03 Nov 2013 07:51:05 -0800 (PST) Original-Received: by 10.182.33.229 with HTTP; Sun, 3 Nov 2013 07:51:05 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164900 Archived-At: 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 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 >