From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Proposed new core library: alert.el Date: Fri, 06 Nov 2015 17:52:21 +0200 Message-ID: <83mvurqg5m.fsf@gnu.org> References: <87io5g2po3.fsf@lifelogs.com> <87y4ec19gm.fsf@lifelogs.com> <83a8qrsatb.fsf@gnu.org> <87bnb716um.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1446825171 29725 80.91.229.3 (6 Nov 2015 15:52:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2015 15:52:51 +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:52:44 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 1ZujJj-0000Gu-O4 for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 16:52:43 +0100 Original-Received: from localhost ([::1]:39601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujJj-0007li-8Q for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 10:52:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujJd-0007hq-Ha for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:52:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZujJY-0007cM-5R for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:52:37 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:34534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujJX-0007b6-UB for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:52:32 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NXE00M00H64YT00@mtaout28.012.net.il> for emacs-devel@gnu.org; Fri, 06 Nov 2015 17:51:24 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXE00H1LHDOSP50@mtaout28.012.net.il> for emacs-devel@gnu.org; Fri, 06 Nov 2015 17:51:24 +0200 (IST) In-reply-to: <87bnb716um.fsf@lifelogs.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:193436 Archived-At: > From: Ted Zlatanov > Date: Fri, 06 Nov 2015 10:32:33 -0500 > > 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. If 'message' could be told to display notifications, yes. But what you say is just the design; someone should write the code to implement it. > 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. Who sets up the handler in that scenario? > 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. What should be in the metadata? > 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? That's just the infrastructure, AFAICT. The other part, i.e., what you describe in 2) above, still needs to be written, for this to be ready to use. Right?