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: Sat, 07 Nov 2015 08:20:32 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87egg2x7xb.fsf@lifelogs.com> References: Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1446902463 7845 80.91.229.3 (7 Nov 2015 13:21:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Nov 2015 13:21:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 07 14:20:51 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 1Zv3QI-0002NW-Pp for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 14:20:50 +0100 Original-Received: from localhost ([::1]:43807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv3QI-0008Ty-3t for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 08:20:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv3QC-0008Tt-Gn for emacs-devel@gnu.org; Sat, 07 Nov 2015 08:20:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv3Q9-0008Bk-3r for emacs-devel@gnu.org; Sat, 07 Nov 2015 08:20:44 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:51185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv3Q8-0008BX-RN for emacs-devel@gnu.org; Sat, 07 Nov 2015 08:20:41 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Zv3Q7-0002CP-1D for emacs-devel@gnu.org; Sat, 07 Nov 2015 14:20:39 +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 ; Sat, 07 Nov 2015 14:20:39 +0100 Original-Received: from tzz by 98.229.60.157 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Nov 2015 14:20:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 93 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:v2t3Uhq1CZAJtRP90fdeNIXTPgc= 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:193520 Archived-At: On Fri, 06 Nov 2015 16:38:04 -0500 Richard Stallman wrote: RS> We have a rather general feature for displaying warnings: RS> the function `display-warning'. Could it serve this purpose? RS> Could it be extended to serve this purpose? Maybe. I honestly wasn't aware of it. I'm not sure why John didn't use that interface, probably he didn't know about it either. It's really not very popular among module authors. RS> In principle, it would be nice to have just one such mechanism RS> rather than two. Well, we currently have the `message' interface (format string + format parameters) and the `display-warning' interface. I agree it would be nice to merge them, perhaps by using properties on the format string. See beow for my concrete proposal. On Fri, 06 Nov 2015 16:20:03 -0500 John Wiegley wrote: JW> At this point I think we have three proposals, so if we still don't have JW> consensus by the weekend, let's use the new Emacs Wiki Proposals index to JW> summarize the alternatives for people to review. Sure. I'll try to get to consensus. I really don't have a "favorite" proposal as you'll see below. On Sat, 7 Nov 2015 18:40:18 +0800 Elias Mårtenson wrote: EM> On 6 Nov 2015 11:33 p.m., "Ted Zlatanov" wrote: >> 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. EM> How about using CL-style keyword parameters? EM> Like: (message "hello" :source x :priority y) That is not compatible with the current `message' interface, but is exactly what alert.el uses. OTOH `display-warning' uses positional parameters for severity etc. So we have three possible interfaces. I propose to flatten them all into `message' using a string with properties as I mentioned earlier. The default `message' handler in Emacs will unpack the properties appropriately for `display-warning' and use the standard Fmessage() if there are no properties. An alternative `message' handler like the plausible one from alert.el would unpack the properties into a plist and pass them to alert.el. So we'd have: 1) default message handler, most common case: (message "simple string") -> Fmessage() 2) default message handler, with properties: (message "string-with-properties") -> (display-warning ...) 3) alert.el message handler, most common case: (message "simple string") -> `alert' or Fmessage() depending on alert.el rules 4) alert.el message handler, with properties (message "string-with-properties") -> (alert ...) Does all of that make sense? Ultimately my goal is to have a single sensible interface, not to bikeshed this to death. On Fri, 6 Nov 2015 19:03:00 +0000 Artur Malabarba wrote: AM> Maybe we're miscommunicating. I don't propose to change the current AM> behavior in any way. In fact, the outcome of my proposal should be AM> identical to yours. I'm just saying "instead of having the current AM> behavior correspond to a nil value of the variable, have it correspond AM> to a proper function value". ... AM> I am replacing the value of the variable AM> font-lock-fontify-region-function, with a function that calls the AM> original value and then calls my function. I couldn't do that if its AM> default value were nil. (sorry for bringing things back to the main thread but I don't want several replies) OK, I'm convinced. But now the problem is that `display-warning' is a third interface to messages and warnings. So if you agree with my call interface above, then yes, the message handler should be a variable as you suggested. Ted