From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrew Schwartzmeyer Newsgroups: gmane.emacs.devel Subject: Should (icomplete-mode) explicitly disable fido-mode? Date: Thu, 4 Jun 2020 10:49:05 -0700 Message-ID: <7ADEE954-6074-4C8E-9EB7-7BF93F6F46BD@schwartzmeyer.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0126F65D-9A1D-447C-9AEA-1B9BCF169925" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="68264"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 04 19:51:44 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jgu1o-000Hfe-9r for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jun 2020 19:51:44 +0200 Original-Received: from localhost ([::1]:46032 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgu1n-0001tM-BQ for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jun 2020 13:51:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33750) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgtzP-0007Eg-SE for emacs-devel@gnu.org; Thu, 04 Jun 2020 13:49:15 -0400 Original-Received: from mout01.posteo.de ([185.67.36.141]:49714) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgtzO-0007pM-Lk for emacs-devel@gnu.org; Thu, 04 Jun 2020 13:49:15 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id ED5D2160062 for ; Thu, 4 Jun 2020 19:49:09 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49dCvS4Gcbz6tmT; Thu, 4 Jun 2020 19:49:08 +0200 (CEST) X-Mailer: Apple Mail (2.3608.80.23.2.2) Received-SPF: pass client-ip=185.67.36.141; envelope-from=andrew@schwartzmeyer.com; helo=mout01.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 13:49:10 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251856 Archived-At: --Apple-Mail=_0126F65D-9A1D-447C-9AEA-1B9BCF169925 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jo=C3=A3o, I was wondering if this bit of code in icomplete-mode needs to be = changed: (when icomplete-mode (fido-mode -1)... Running (icomplete-mode) explicitly disables fido-mode, whereas running = (fido-mode) makes it appear that icomplete-mode is enabled (sets it to t = and runs its setup, without actually running the function = icomplete-mode). This causes third party packages which wrap icomplete-mode to easily = break fido-mode, like in this issue: = https://github.com/oantolin/icomplete-vertical/pull/13 = icomplete-vertical calls (icomplete-mode), I think expecting it to be = idempotent (not have any effect if icomplete-mode is already enabled), = but in fact, since fido-mode is currently enabled this explicitly = disables it and switches to the base icomplete-mode, as the mode = functions icomplete-mode and fido-mode act like toggles of each other. Should (icomplete-mode t) perhaps do nothing if fido-mode is already = enabled? I=E2=80=99m not sure. Obviously the package can workaround it = (given my patch), but I think it=E2=80=99s unexpected to have to avoid = calling (icomplete-mode) if the icomplete-mode var is already t. What do = you think? Thanks, Andy= --Apple-Mail=_0126F65D-9A1D-447C-9AEA-1B9BCF169925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jo=C3=A3o,

I was = wondering if this bit of code in icomplete-mode needs to be = changed:

  (when icomplete-mode
  =   (fido-mode -1)...

Running (icomplete-mode) explicitly = disables fido-mode, whereas running (fido-mode) makes it appear that = icomplete-mode is enabled (sets it to t and runs its setup, without = actually running the function icomplete-mode).

This causes third party packages which = wrap icomplete-mode to easily break fido-mode, like in this issue: https://github.com/oantolin/icomplete-vertical/pull/13

icomplete-vertical = calls (icomplete-mode), I think expecting it to be idempotent (not have = any effect if icomplete-mode is already enabled), but in fact, since = fido-mode is currently enabled this explicitly disables it and switches = to the base icomplete-mode, as the mode functions icomplete-mode and = fido-mode act like toggles of each other.

Should (icomplete-mode t) perhaps do nothing if fido-mode is already enabled? I=E2=80=99m = not sure. Obviously the package can workaround it (given my patch), but = I think it=E2=80=99s unexpected to have to avoid calling = (icomplete-mode) if the icomplete-mode var is already t. What do you = think?

Thanks,

Andy
= --Apple-Mail=_0126F65D-9A1D-447C-9AEA-1B9BCF169925--