From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: message-function (was: Proposed new core library: alert.el) Date: Fri, 6 Nov 2015 19:03:00 +0000 Message-ID: References: <87io5g2po3.fsf@lifelogs.com> <87y4ec19gm.fsf@lifelogs.com> <83a8qrsatb.fsf@gnu.org> <87bnb716um.fsf@lifelogs.com> <83mvurqg5m.fsf@gnu.org> <87twozyu8l.fsf@lifelogs.com> <87d1vnyp5y.fsf_-_@lifelogs.com> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1446836608 27068 80.91.229.3 (6 Nov 2015 19:03:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2015 19:03:28 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 06 20:03:26 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 1ZumID-0006PG-7y for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 20:03:21 +0100 Original-Received: from localhost ([::1]:40588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZumIC-0004GH-HO for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 14:03:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZumHy-0004Fu-Db for emacs-devel@gnu.org; Fri, 06 Nov 2015 14:03:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZumHu-0005S6-6n for emacs-devel@gnu.org; Fri, 06 Nov 2015 14:03:06 -0500 Original-Received: from mail-lf0-x22d.google.com ([2a00:1450:4010:c07::22d]:34190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZumHt-0005S2-VU for emacs-devel@gnu.org; Fri, 06 Nov 2015 14:03:02 -0500 Original-Received: by lfgh9 with SMTP id h9so76141549lfg.1 for ; Fri, 06 Nov 2015 11:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=LBAtZv6doTkabfsZ6euQBjc1J71mVyJbQiWQGe7cCrM=; b=GkSzxqneAwqrs6k2n9lrvsS3ZM1TT43KxSmfbGIcnRmUbyiG4FpB1sl5dqtrxt5Qbt LIrXNcSfsbf89abnYuF+87LhUhuGccDFt83z1cOizLXj6lA8OsOlU9Ud4cGwd3vWb1ln CI8gBAkco5h2F5sWWC1hEe2URw7EGztKlmFK/2g4ye70i1YE0TZJvAU7eeQXTsDbrRoB UOansVVIvbnmVl+iiUtp1epyQv8a7QSxzOYx/qdrhb8IUOEQP2pOAUekU6OPkyMo6bnu Tm5mrptC7W49/sHE63TIJHcQOmbunUeDx7Lnurw9nZjKZ0WFV9iz86r2x+JLruAg6iZR qZuw== X-Received: by 10.25.141.77 with SMTP id p74mr4677996lfd.17.1446836580991; Fri, 06 Nov 2015 11:03:00 -0800 (PST) Original-Received: by 10.112.63.70 with HTTP; Fri, 6 Nov 2015 11:03:00 -0800 (PST) In-Reply-To: <87d1vnyp5y.fsf_-_@lifelogs.com> X-Google-Sender-Auth: TAlomvCE8GTUCPqXuZIRqTLyITU X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c07::22d 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:193462 Archived-At: 2015-11-06 18:10 GMT+00:00 Ted Zlatanov : > > OK, it will be `message-function'. Thanks. > AM> 2. The variable's default value should be a function (which implements > AM> the default behaviour), not nil. > > Well, your point (2) is not exactly what I think is best. Your proposal > requires a new `message-function-standard' name for the internal > Fmessage(), and changes the current `message' completely. Well, this makes it sound more complicated than it is. :-) I'm just saying to rename the current `message' function, and redefine `message' to simply call `(apply message-function args)' (of course, this could be in C). > By contrast, my proposal has `message' calling Fmessage() (the current > behavior) and then, iff `message-function' is set, doing something > different. So it preserves the current behavior exactly. I think that's > an important consideration for changing a very fundamental Emacs function. Maybe we're miscommunicating. I don't propose to change the current behavior in any way. In fact, the outcome of my proposal should be identical to yours. I'm just saying "instead of having the current behavior correspond to a nil value of the variable, have it correspond to a proper function value". > AM> Allowing a nil value is just going to make it harder for > AM> users/packages to use the `add-function' mechanisms on this variable. > AM> For instance, see the variable `font-lock-fontify-region-function'. > AM> Its name ends in `-function', and its default value is > AM> #'font-lock-default-fontify-region. That's the convention we should > AM> follow with these variables. > > If the user wants to `add-function' on `message', they should > `add-function' on `message'. I don't see why they care that > `message-function' is nil or something else. But maybe I'm missing > something here. I've been away from Emacs development for a bit. You're probably thinking of advice-add. You don't call `add-function' on a function, you call it on a variable that holds a function. Add-function is a proper (and very useful) macro for changing the value of a variable that holds a function. For instance, if I do: (add-function :after font-lock-fontify-region-function (lambda (&rest _) (message "Fontification done!"))) I am replacing the value of the variable font-lock-fontify-region-function, with a function that calls the original value and then calls my function. I couldn't do that if its default value were nil. For a more practical example, say I don't want font-lock to fontify a certain region of the buffer (this is something we do in cider.el). I can just do: (add-function :filter-args font-lock-fontify-region-function #'some-function) where some-function is a function that takes a list of arguments and returns another list of arguments. This way, many different minor modes can edit the same -function variable without having to override it and so without getting all over each other. You can also easily remove yourself from a -function variable by just using `remove-function'. It's really a very powerful and useful interface. Have a quick look at the docstring for add-function and you'll see all the many options.