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: Request: Use message instead of message_with_string for user visible output? Date: Mon, 28 Oct 2013 18:26:50 -0700 Message-ID: References: <83wql0f1ej.fsf@gnu.org> <87ob6byfug.fsf@dpaduchikh.invalid> <526E1AAA.9060308@poczta.onet.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1383010013 8271 80.91.229.3 (29 Oct 2013 01:26:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2013 01:26:53 +0000 (UTC) To: Jarek Czekalski , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 29 02:26:57 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 1Vay5B-0007Cy-3g for ged-emacs-devel@m.gmane.org; Tue, 29 Oct 2013 02:26:57 +0100 Original-Received: from localhost ([::1]:43811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vay5A-0006NM-En for ged-emacs-devel@m.gmane.org; Mon, 28 Oct 2013 21:26:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vay56-0006NH-Eg for emacs-devel@gnu.org; Mon, 28 Oct 2013 21:26:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vay55-0005Kz-E0 for emacs-devel@gnu.org; Mon, 28 Oct 2013 21:26:52 -0400 Original-Received: from mail-qa0-x230.google.com ([2607:f8b0:400d:c00::230]:58708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vay55-0005Kt-7w for emacs-devel@gnu.org; Mon, 28 Oct 2013 21:26:51 -0400 Original-Received: by mail-qa0-f48.google.com with SMTP id k4so2593929qaq.14 for ; Mon, 28 Oct 2013 18:26:50 -0700 (PDT) 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=773FSQ0mxyL+lXljwnxW9binJI4Fa+v1sW3lg2M6f2I=; b=UYPL7/T0ZAMq5wIEu+kSA5FzFvlHAXGEPqXZqBqR0bRQzmiedPUCPCm5bZ5REBqh/V 4WHJoMwuCbEZMPs7wBqxtIdnuGQRUgr5lNs7IQCmWJRj0cnN5LaFzV/b1ZvnbI582Vot eGe3vPHJ2s6ryYNcrrwKk/51M710dwM3pkH6MSsBAu/KVv7SjrEKk07oOWH+A6h8Y/5O l+HdJ6oo371YPjMbaMrMbDoghuLPZoOLZq8HtWNxvwoxs1z1RAdF+HHrailCcEZD7XIF CAYjibLhbvyrUPYlWsLcaGAY0t72FWqM0dmp9THEuIDY3XGQjZ7uYCN6MiKr6b4pK50Y r7xQ== X-Received: by 10.49.59.70 with SMTP id x6mr20541977qeq.17.1383010010872; Mon, 28 Oct 2013 18:26:50 -0700 (PDT) Original-Received: by 10.229.171.135 with HTTP; Mon, 28 Oct 2013 18:26:50 -0700 (PDT) In-Reply-To: <526E1AAA.9060308@poczta.onet.pl> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c00::230 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:164606 Archived-At: 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 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 > > >