From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Proposed new core library: alert.el Date: Fri, 06 Nov 2015 10:32:33 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87bnb716um.fsf@lifelogs.com> References: <87io5g2po3.fsf@lifelogs.com> <87y4ec19gm.fsf@lifelogs.com> <83a8qrsatb.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446824000 9392 80.91.229.3 (6 Nov 2015 15:33:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2015 15:33:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 06 16:33:12 2015 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 1Zuj0n-0008BI-VJ for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 16:33:10 +0100 Original-Received: from localhost ([::1]:39438 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zuj0n-0002IL-Dv for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 10:33:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zuj0T-0002AC-Ia for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:32:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zuj0Q-0001GL-5j for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:32:49 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:53786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zuj0P-0001FZ-Vp for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:32:46 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Zuj0M-0007ju-AI for emacs-devel@gnu.org; Fri, 06 Nov 2015 16:32:42 +0100 Original-Received: from 98.229.60.157 ([98.229.60.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2015 16:32:42 +0100 Original-Received: from tzz by 98.229.60.157 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2015 16:32:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 98.229.60.157 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:0TJ2wBQSROMCjpe49WVnL2mCRws= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:193429 Archived-At: On Fri, 06 Nov 2015 12:04:48 +0200 Eli Zaretskii wrote: EZ> I think it would make sense to provide an intermediate EZ> platform-independent layer for displaying alerts Yes, this is simply a `message' call. I think the only thing missing is metadata and I would draw inspiration from syslog: level, facility, and tags. Then the *handler* should decide what to do with the message based on the metadata. I'm not sure how to provide the metadata, and it should be ignored by the default (current) message handler. Maybe it could be string properties applied to the first parameter? I *need* to know this before writing code. So before I jump to implementation, this is the design I'm considering: 1) make a new `message-handler' buffer-local variable, default to nil, customizable 1.1) maybe buffer local is not necessary? I'm not sure what's best. 2) users and packages can override `message-handler' as needed: (setq message-handler 'alert-message-handler) 3) in the C code, `editfns.c:Fmessage' will check for `message-handler' and if it exists, simply call it with all the parameters and exit 4) the handlers do not have to preserve the `message' specific behavior, as shown in its docstring, e.g. printing to STDERR in batch mode or clearing an existing message when passed nil. Once that piece is done, alert.el can be adjusted as needed; the metadata passing is the major piece missing. Sounds good? On Thu, 05 Nov 2015 17:47:18 -0800 raman wrote: r> You could do this seamlessly by attaching an around advice to message r> and having that call alert We could, but won't :) Ted