From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Delayed warnings Date: Mon, 21 Mar 2011 15:48:54 +0100 Message-ID: References: <4D8705CA.1020300@gmx.at> <4D874FF3.9010606@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1300718996 19976 80.91.229.12 (21 Mar 2011 14:49:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2011 14:49:56 +0000 (UTC) Cc: Emacs developers To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 21 15:49:52 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q1gQZ-00079V-G0 for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2011 15:49:51 +0100 Original-Received: from localhost ([127.0.0.1]:56383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1gQY-0002Gw-Bx for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2011 10:49:50 -0400 Original-Received: from [140.186.70.92] (port=54437 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1gQN-0002FP-4Z for emacs-devel@gnu.org; Mon, 21 Mar 2011 10:49:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1gQK-0005hE-SY for emacs-devel@gnu.org; Mon, 21 Mar 2011 10:49:38 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:49461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1gQK-0005h9-Q7 for emacs-devel@gnu.org; Mon, 21 Mar 2011 10:49:36 -0400 Original-Received: by yxt33 with SMTP id 33so3067187yxt.0 for ; Mon, 21 Mar 2011 07:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=UgjsTz+698eDXCpqBoRdp8SbZbbQ3La3ytnSRHzOoyw=; b=Q0KI8C2kn1KxKvya6XJhwK8i8Inr4PZIEXn9eKIdRe/agld9IGKRsHaB54WVLm3LVE JaFQsoOJzw20ZL8graOG/WtTO2SprF875Ta/obNsrFAV4AG1YqYSKPwNtBHlx3BtJoXu DBgdirmuvtPuXYBYm1KyHuKxf2zVSDpKVI24w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=O4wUwyNMHCbjlaGt3XPB83h+a02fvpGDVfTy//rQl3uht8s+GpKskon7SixYvmO/dQ gphvmbnWajT01BOOsvD3ZJ+9d0gsVoXyfmOV1DYPcon3FAup4sz8k3uphO28+KZzXUqP CHACyconwvrYw8r6mD43comd3lTY4kQCjK3r4= Original-Received: by 10.151.27.16 with SMTP id e16mr3977699ybj.356.1300718975793; Mon, 21 Mar 2011 07:49:35 -0700 (PDT) Original-Received: by 10.147.34.11 with HTTP; Mon, 21 Mar 2011 07:48:54 -0700 (PDT) In-Reply-To: <4D874FF3.9010606@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.213.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137478 Archived-At: On Mon, Mar 21, 2011 at 14:17, martin rudalics wrote: > Fully agreed. =C2=A0But the same arguments hold for redisplay errors whic= h > currently pass through add_to_log where they are treated like messages. Of course there's a hierarchy of "errors": those that the user cannot do anything about (and should go to *Messages*), those that the user *must* attend to (and should either interrupt the user or bring Emacs to a halt), and warnings that inform the user about what he should do/know, but can be ignored. I'm mostly concerned about the third kind, specially when they happen in low-level code, because they are difficult to make (from C) both visible and, user wishing, easily ignorable. Sending them to *Messages* is not enough, unless we're going to (pop-to-buffer "*Messages*") and that's basically duplicating `display-warning' :-) > What I wanted is a mechanism that handles (and optionally ignores) all > sorts of errors/warnings which currently can't be issued prominently > because Emacs is in an inconsistent state. Which kind of design have you in mind? =C2=A0 =C2=A0 Juanma