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: Thu, 28 Apr 2011 02:59:56 +0200 Message-ID: References: <4D8705CA.1020300@gmx.at> <4D874FF3.9010606@gmx.at> <4D8793B1.2040701@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 1303952450 12815 80.91.229.12 (28 Apr 2011 01:00:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Apr 2011 01:00:50 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 28 03:00:43 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QFFb0-0006o3-S3 for ged-emacs-devel@m.gmane.org; Thu, 28 Apr 2011 03:00:43 +0200 Original-Received: from localhost ([::1]:34837 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFFb0-0001g0-B2 for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2011 21:00:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFFax-0001fj-Iv for emacs-devel@gnu.org; Wed, 27 Apr 2011 21:00:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFFaw-0006OS-Ad for emacs-devel@gnu.org; Wed, 27 Apr 2011 21:00:39 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:43499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFFaw-0006ON-64 for emacs-devel@gnu.org; Wed, 27 Apr 2011 21:00:38 -0400 Original-Received: by gyd8 with SMTP id 8so979575gyd.0 for ; Wed, 27 Apr 2011 18:00:37 -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=zKK2KeYKeoxRjSRuBwQBUTMHY7WJxK5GDvUUbxdGpuQ=; b=YsvxORRtLrfNiA0gCEq9YGf3FQ5d0rIeeCyVzdmjhrw6ThU9vV6FXtgZgg+Vs8Pioy Pu1+t4Mc7QkVN5o4mGmqPyuqkyurE+YEN22V06JW5nv06/Ed9pDaZF6uyg7GYrqAA9ao VOCSqYaTctTT5Rm+Q3glgLba4JIwrUIDL++jM= 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=xFNMiGvdIl+uJyHHx8vY+gurYMtQY1+QvDp904iPNL4/YUkrkitMjTYerONZr1nCFB NseYXrXtE+OxUrEL9I1NISczdRFoHFgZzGUZEg20sZdgctjv65ycSWziu2gOl7WPdeW/ BrVHofpfSA8OGHcjmSdUKjHdTTRsNmXEHwwzU= Original-Received: by 10.236.193.100 with SMTP id j64mr3742055yhn.294.1303952437110; Wed, 27 Apr 2011 18:00:37 -0700 (PDT) Original-Received: by 10.147.182.5 with HTTP; Wed, 27 Apr 2011 17:59:56 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.160.169 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:138865 Archived-At: On Thu, Apr 28, 2011 at 02:40, Stefan Monnier wr= ote: > I'm thinking about messages which would be displayed once > after almost every command (because redisplay will bump into the same > error after each command). OK, but that makes the logic a bit more complex because the squashing is carried from one run of `delayed-warnings-function' to the next. How do you propose to detect that? By scanning the *Warnings* buffer? (Though, to be fair, redisplay warnings could use their own buffer *Redisplay Warnings*...) > This can't be applied generally to all > messages (it would be incorrect to silence the 2nd/3rd occurrences of > a message if the message is really linked to the particular command > executed which happens to be the same several times) Even so, perhaps some strategy like the current message consolidation ("such&such [10 times]") could be used. > so the squashable > messages would need to be flagged. In my design, the contents of `delayed-warnings-list' are arglists for `display-warning': (TYPE MESSAGE [LEVEL [BUFER-NAME]]). So simple ways to flag them would be: - Use TYPE =3D redisplay for all redisplay warnings, and make `display-delayed-warnings' know about it, or - Add a variable `delayed-warnings-squashable-types', a list of TYPEs that can be squashed, or - As suggested above, send the redisplay warnings to their own buffer via the BUFFER-NAME arg. =C2=A0 =C2=A0 Juanma