From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: Questions about the `completing-read-function' interface Date: Fri, 17 Apr 2015 17:40:18 +0200 Message-ID: <87bnimn4pp.fsf@gmail.com> References: <87lhhrxeg2.fsf@gmail.com> <87oammn75z.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429285614 21753 80.91.229.3 (17 Apr 2015 15:46:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2015 15:46:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 17 17:46:42 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 1Yj8TJ-0001Mm-3n for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 17:46:25 +0200 Original-Received: from localhost ([::1]:42177 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj8TI-0002mx-K6 for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 11:46:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj8So-0002BZ-0N for emacs-devel@gnu.org; Fri, 17 Apr 2015 11:45:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yj8Sj-0001ZL-01 for emacs-devel@gnu.org; Fri, 17 Apr 2015 11:45:53 -0400 Original-Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:35182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj8Si-0001ZF-Ll for emacs-devel@gnu.org; Fri, 17 Apr 2015 11:45:48 -0400 Original-Received: by wgyo15 with SMTP id o15so117566115wgy.2 for ; Fri, 17 Apr 2015 08:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=pi4WNZETSK2yFwN8aeR1fBg7kJ2czXLf0sTVP198zA8=; b=Hwtl8tQR4KlfHQAFwg1lxrhRPbODG2qpcTtbsukjpMK2/WB4r04wWd9v6PKBXqHUBu qLbpbzjjgIBJUZLG0JZhduJmdfisD7oV/1D7KvG3WY4AR+Q+HJEUk642tlwkvSvCLIJf oEe/F0j6PMwLYi2hcJYV0PbnOadECA6kNpCi+bRI/86/2N2yFcnCZUCAUmimNylWDbn+ TF1QbvzAse8vQ6duHP83X3CVwT+9mRCPj2TpBL1aJmdpaYn8IHm0j58ohWKfZjkv4Zcv fmkpZ0J3jgqb79odBvv7vArva5Cj71ofoY94S8y+PH0wJQvN42/205uiAwCnPkJWYJzj w3Kg== X-Received: by 10.194.200.194 with SMTP id ju2mr4776633wjc.61.1429285547952; Fri, 17 Apr 2015 08:45:47 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by mx.google.com with ESMTPSA id ch2sm3149642wib.18.2015.04.17.08.45.47 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Apr 2015 08:45:47 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 17 Apr 2015 11:31:48 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::22b 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:185531 Archived-At: Stefan Monnier writes: >>> So far we haven't tried to enforce this and if require-match is not set, >>> then I don't think we should require it. >> I agree for the case of >> (memq require-match '(nil confirm confirm-after-completion)) >> What about the other cases? > > If require is t I think it'd be OK for the completing-read function to > ignore any DEF argument which is not in COLLECTION. > > For the same reason, M-p should arguably skip history members which > aren't in COLLECTION (or which are rejected by PRED). > > But there are some issues: even if DEF (or history elements) would be > rejected by require-match when you hit RET, it might still be a useful > string to get via M-n (which the user then completes before hitting RET). > >> 1. all minor modes subscribe with `set-completing-read-function' >> 2. user calls M-x mode-1. mode-1 is active and subscribes. >> 3. user calls M-x mode-2. Emacs sends a message to mode-1 to shut >> down. mode-2 is active and subscribes. >> 4. and so on. > > But this extra complexity only "solves" the very narrow problem you're > facing, while introducing non-trivial issues: what about minor modes > that override completing-read-function but which only apply to some > cases? There can be several such minor modes active at the same time > without conflict. > >> There's no way to end up in a worse state than is now. > > Well yes, there is: increase code complexity for little benefit is > a worse state. It's not that much more complex. Currently, we have this behavior for major modes. When one is activated, Emacs deactivates the second one. We could get the same feature for themes, or company-mode/auto-complete, there are plenty of use cases. >>> I agree that there are potential for actual problems if the >>> completing-read-function is not properly reverted when the modes are >>> disabled. For that reason I recommend you use `add-function' and >>> `remove-function' rather than `setq'. >> I don't understand. Can you give an example? > > 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. Also, with your sequence of commands, starting from nothing, we have ivy-mode set to "t" and having the `completing-read-function' resource, while `helm-mode' is also "t" and may think that it has the resource, but it doesn't. 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. Oleh