From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Questions about the `completing-read-function' interface Date: Fri, 17 Apr 2015 14:04:13 -0400 Message-ID: References: <87lhhrxeg2.fsf@gmail.com> <87oammn75z.fsf@gmail.com> <87bnimn4pp.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429293873 6345 80.91.229.3 (17 Apr 2015 18:04:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2015 18:04:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 17 20:04:24 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 1YjAcq-0001Hw-Ip for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 20:04:24 +0200 Original-Received: from localhost ([::1]:42937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjAcp-00009d-W3 for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 14:04:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjAcm-00009W-M8 for emacs-devel@gnu.org; Fri, 17 Apr 2015 14:04:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjAcj-0006tH-Hy for emacs-devel@gnu.org; Fri, 17 Apr 2015 14:04:20 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:54037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjAcj-0006t0-DK for emacs-devel@gnu.org; Fri, 17 Apr 2015 14:04:17 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3HI4DUR028788; Fri, 17 Apr 2015 14:04:13 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6AEA81FB6; Fri, 17 Apr 2015 14:04:13 -0400 (EDT) In-Reply-To: <87bnimn4pp.fsf@gmail.com> (Oleh Krehel's message of "Fri, 17 Apr 2015 17:40:18 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5279=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5279> : inlines <2748> : streams <1424086> : uri <1909281> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:185533 Archived-At: >> M-x ivy-mode RET >> M-x helm-mode RET >> M-x ivy-mode RET >> >> You should now have helm-mode active and working properly, yet with your >> current code, helm-mode will be "enabled by inactive". If you use >> add/remove-function this case will be handled correctly. > I meant to give an example of how `add-function' helps here. That's exactly what the example does, AFAIK. > Also, with your sequence of commands, starting from nothing, we have > ivy-mode set to "t" and having the `completing-read-function' No, the idea of this example is that after the second line ivy-mode is still t but completing-read-function is now set to use the helm version. After the 3rd line, with `setq' completing-read-function would be reset to the default value, whereas with remove-function completing-read-function would still continue using the helm version. > I've also seen this type of code: ido-vertical-mode stores the variable > `ido-decorations' of ido-mode and modifies it. When you turn off > ido-vertical-mode, it restores `ido-decorations'. But what if other > code has changed `ido-decorations' in the meantime, while > ido-vertical-mode is still on? Any way you put it, the result is > incorrect. Unless there's a robust system behind it all that manages the > `ido-decorations' variable. That's exactly what add-function aims to solve. Stefan