From unknown Wed Jun 18 23:05:46 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#42101 <42101@debbugs.gnu.org> To: bug#42101 <42101@debbugs.gnu.org> Subject: Status: icomplete-fido-ret doesn't always use minibuffer-default when input is empty Reply-To: bug#42101 <42101@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:05:46 +0000 retitle 42101 icomplete-fido-ret doesn't always use minibuffer-default when= input is empty reassign 42101 emacs submitter 42101 Andrew Schwartzmeyer severity 42101 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 28 01:59:52 2020 Received: (at submit) by debbugs.gnu.org; 28 Jun 2020 05:59:53 +0000 Received: from localhost ([127.0.0.1]:45019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpQM4-0004I4-NR for submit@debbugs.gnu.org; Sun, 28 Jun 2020 01:59:52 -0400 Received: from lists.gnu.org ([209.51.188.17]:42758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpQM1-0004Hq-Sw for submit@debbugs.gnu.org; Sun, 28 Jun 2020 01:59:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60086) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpQM1-0006sg-KX for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2020 01:59:49 -0400 Received: from mout02.posteo.de ([185.67.36.142]:52509) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpQLz-0002RV-PA for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2020 01:59:49 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id E0D042400FC for ; Sun, 28 Jun 2020 07:59:43 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49vg1p6y4hz9rxM for ; Sun, 28 Jun 2020 07:59:42 +0200 (CEST) From: Andrew Schwartzmeyer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: icomplete-fido-ret doesn't always use minibuffer-default when input is empty Message-Id: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> Date: Sat, 27 Jun 2020 22:59:40 -0700 To: bug-gnu-emacs@gnu.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Received-SPF: pass client-ip=185.67.36.142; envelope-from=andrew@schwartzmeyer.com; helo=mout02.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/28 01:59:44 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi, Funny bug, haven=E2=80=99t figured out the cause. It may be hard to = repro. If you have some amount of minibuffer history, you can cause = icomplete-fido-ret to not accept the minibuffer-default. An example is = having history such that 'C-h v' when point is on = =E2=80=98completion-styles=E2=80=99 causes =E2=80=98completion-styles-alis= t=E2=80=99 to be the first history element. Since the minibuffer-default = shows =E2=80=98completion-styles=E2=80=99 (being that it=E2=80=99s under = point, and I=E2=80=99ve not entered any text into the minibuffer), I=E2=80= =99d expect RET to choose =E2=80=98completion-styles=E2=80=99, but = instead it choses =E2=80=98completion-styles-alist=E2=80=99 (the head of = the presented candidates, =E2=80=98completion-styles=E2=80=99 is instead = the second candidate). This repros in fido-mode, but not icomplete-mode. I took a look at the = relevant functions called on RET for these modes but am having trouble = finding the issue. I think the root cause is that if minibuffer-default matches a candidate = exactly, that candidate should always become the first history element, = but this isn=E2=80=99t happening. I=E2=80=99m not sure why; I played = around with different completion-styles but that had no effect. = Regardless, if there is no input but there is minibuffer-default, = various code in icomplete.el suggests that = 'minibuffer-complete-and-exit=E2=80=99 should just be called, I don=E2=80=99= t know why it=E2=80=99s not happening. Any ideas? Thanks, Andy= From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 28 11:49:53 2020 Received: (at 42101) by debbugs.gnu.org; 28 Jun 2020 15:49:53 +0000 Received: from localhost ([127.0.0.1]:46801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpZZ1-0004MI-GM for submit@debbugs.gnu.org; Sun, 28 Jun 2020 11:49:53 -0400 Received: from mout01.posteo.de ([185.67.36.65]:45170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpQw4-0005Fn-Qj for 42101@debbugs.gnu.org; Sun, 28 Jun 2020 02:37:06 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 3A355160060 for <42101@debbugs.gnu.org>; Sun, 28 Jun 2020 08:36:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1593326219; bh=Cc+tTLQyUSuohqJAZu6rGdnU3YWRZfEyHFHPcCYmATA=; h=From:Subject:Date:To:From; b=GuuoTiswspEQFrHRHN3oZ+VtcHRrcciJQJaicPGBv5RgeyEH0iAAfQNLNNrZIm1UI 81ROZTg4l7NwdqW7XOVT9ZhqjXvt5jk7ETJFWOgKMrlgfu0mYYJpTOJ3bEwxZRmrm5 o2cY2cAAY2VK4OTbzhWdP0Dq/vsR5JYXtaM5VnIYYxO1OMIHshdHQGX4rIVQTEvDOM 0v8QYRDcRQYEZoJpp4fYkPIWOGayD4K6WLVAxMAI/IgGltEcRDhzYoDi/Nt33yLHaQ 44/ttWsUgK8KVyTzamEklBOU6Rwn26IUw8JVN0rALc3lJJmbITuSSmLFa0C6YzPY/7 iQymuG/fYjKdg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49vgrn3cnYz6tmJ for <42101@debbugs.gnu.org>; Sun, 28 Jun 2020 08:36:57 +0200 (CEST) From: Andy Schwartzmeyer Content-Type: multipart/alternative; boundary="Apple-Mail=_63D8D700-A63D-436B-BB74-D88066811735" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: re: bug#42101 Message-Id: <67E6FFAA-233E-4A72-A947-93E358B91D4E@posteo.net> Date: Sat, 27 Jun 2020 23:36:53 -0700 To: 42101@debbugs.gnu.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42101 X-Mailman-Approved-At: Sun, 28 Jun 2020 11:49:50 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --Apple-Mail=_63D8D700-A63D-436B-BB74-D88066811735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay, with some message style debugging I think I narrowed it down: (defun icomplete-force-complete-and-exit () "Complete the minibuffer with the longest possible match and exit. Use the first of the matches if there are any displayed, and use the default otherwise." (interactive) ;; This function is tricky. The mandate is to "force", meaning we ;; should take the first possible valid completion for the input. ;; However, if there is no input and we can prove that that ;; coincides with the default, it is much faster to just call ;; `minibuffer-complete-and-exit'. Otherwise, we have to call ;; `minibuffer-force-complete-and-exit', which needs the full ;; completion set and is potentially slow and blocking. Do the ;; latter if: (if (or ;; there's some input, meaning the default in off the table by ;; definition; OR (> (icomplete--field-end) (icomplete--field-beg)) ;; there's no input, but there's also no minibuffer default ;; (and the user really wants to see completions on no input, ;; meaning he expects a "force" to be at least attempted); OR (and (not minibuffer-default) icomplete-show-matches-on-no-input) ;; there's no input but the full completion set has been ;; calculated, This causes the first cached completion to ;; be taken (i.e. the one that the user sees highlighted) completion-all-sorted-completions) (progn (message (if completion-all-sorted-completions (message = "completions t") (message "completions nil"))) (message (if minibuffer-default "default t" "default nil")) (message "FORCING") (minibuffer-force-complete-and-exit)) ;; Otherwise take the faster route... (minibuffer-complete-and-exit))) With fido-mode, the final test in the or clause, namely = 'completion-all-sorted-completions=E2=80=99, is t, whereas in = icomplete-mode it is nil. This is causing the first cached completion to = be taken (i.e. the =E2=80=98completion-styles-alist=E2=80=99 which = probably shouldn=E2=80=99t be the first completion anyway). Moreover, it = means that this function=E2=80=99s existence is being overriden: it=E2=80=99= s never shortcutting to 'minibuffer-complete-and-exit=E2=80=99 for = fido-mode users. Now to find out two more things: 1. Why is the completion list not bubbling minibuffer-default to the = top? (I=E2=80=99m using helpful-variable, but this also happens with = describe-variable, and I=E2=80=99ve noticed it with other functions that = will use a default from point.) 2. Why is 'completion-all-sorted-completions=E2=80=99 always t when = using fido-mode? At least for #1: In this bit of code the minibuffer-default is compared with equal and = with string-prefix-p: (defun icomplete--sorted-completions () (or completion-all-sorted-completions (cl-loop with beg =3D (icomplete--field-beg) with end =3D (icomplete--field-end) with all =3D (completion-all-sorted-completions beg end) for fn in (cond ((and minibuffer-default (stringp minibuffer-default) ; bug#38992 (=3D (icomplete--field-end) = (icomplete--field-beg))) ;; When we have a non-nil string default and ;; no input whatsoever: we want to make sure ;; that default is bubbled to the top so that ;; `icomplete-force-complete-and-exit' will ;; select it (do that even if the match ;; doesn't match the completion perfectly. `(,(lambda (comp) (equal minibuffer-default comp)) ,(lambda (comp) (string-prefix-p minibuffer-default comp)))) ((and fido-mode (not minibuffer-default) (eq (icomplete--category) 'file)) ;; `fido-mode' has some extra file-sorting ;; semantics even if there isn't a default, ;; which is to bubble "./" to the top if it ;; exists. This makes M-x dired RET RET go to ;; the directory of current file, which is ;; what vanilla Emacs and `ido-mode' both do. `(,(lambda (comp) (string=3D "./" comp))))) thereis (cl-loop for l on all while (consp (cdr l)) for comp =3D (cadr l) when (funcall fn comp) do (setf (cdr l) (cddr l)) and return (completion--cache-all-sorted-completions beg end (cons = comp all))) finally return all))) I=E2=80=99m not sure how to get it to do so, but when there are = candidates satisfying both =E2=80=98equals=E2=80=99 and = =E2=80=98string-prefix-p=E2=80=99, we need to get this to prefer the = former over the latter. Cheers, Andy= --Apple-Mail=_63D8D700-A63D-436B-BB74-D88066811735 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay, with some message style debugging I think I narrowed it = down:

(defun = icomplete-force-complete-and-exit ()
  = "Complete the minibuffer with the longest possible match and = exit.
Use the first of the matches if there are any = displayed, and use
the default = otherwise."
  (interactive)
  ;; This function is tricky.  The mandate is to = "force", meaning we
  ;; should take the first = possible valid completion for the input.
  ;; = However, if there is no input and we can prove that that
  ;; coincides with the default, it is much faster to = just call
  ;; `minibuffer-complete-and-exit'. =  Otherwise, we have to call
  ;; = `minibuffer-force-complete-and-exit', which needs the full
  ;; completion set and is potentially slow and = blocking.  Do the
  ;; latter = if:
  (if (or
  =      ;; there's some input, meaning the default in off = the table by
       ;; = definition; OR
       (> = (icomplete--field-end) (icomplete--field-beg))
 =      ;; there's no input, but there's also no minibuffer = default
       ;; (and the user = really wants to see completions on no input,
  =      ;; meaning he expects a "force" to be at least = attempted); OR
       (and (not = minibuffer-default)
        =     icomplete-show-matches-on-no-input)
       ;; there's no input but the full = completion set has been
      =  ;; calculated, This causes the first cached completion = to
       ;; be taken (i.e. the = one that the user sees highlighted)
    =    completion-all-sorted-completions)
      (progn
  =       (message (if completion-all-sorted-completions = (message "completions t") (message "completions nil")))
        (message (if minibuffer-default = "default t" "default nil"))
      =   (message "FORCING")
      =   (minibuffer-force-complete-and-exit))
  =   ;; Otherwise take the faster route...
  =   (minibuffer-complete-and-exit)))

With fido-mode, the final test in the or clause, = namely 'completion-all-sorted-completions=E2=80=99, is t, whereas in = icomplete-mode it is nil. This is causing the first cached completion to = be taken (i.e. the =E2=80=98completion-styles-alist=E2=80=99 which = probably shouldn=E2=80=99t be the first completion anyway). Moreover, it = means that this function=E2=80=99s existence is being overriden: it=E2=80=99= s never shortcutting to 'minibuffer-complete-and-exit=E2=80= =99 for fido-mode users.

Now to find out two more = things:

1. Why is = the completion list not bubbling minibuffer-default to the top? (I=E2=80=99= m using helpful-variable, but this also happens with describe-variable, = and I=E2=80=99ve noticed it with other functions that will use a default = from point.)
2. Why is = 'completion-all-sorted-completions=E2=80=99 always t when using = fido-mode?

At least = for #1:

In this bit = of code the minibuffer-default is compared with equal and with = string-prefix-p:

(defun = icomplete--sorted-completions ()
 (or = completion-all-sorted-completions
     (cl-loop
      with beg =3D = (icomplete--field-beg)
      with end =3D = (icomplete--field-end)
      with all =3D = (completion-all-sorted-completions beg end)
      for fn in (cond ((and = minibuffer-default
          &nb= sp;            = ;     (stringp minibuffer-default) ; = bug#38992
          &nb= sp;            = ;     (=3D (icomplete--field-end) = (icomplete--field-beg)))
          &nb= sp;            = ;;; When we have a non-nil string default and
          &nb= sp;            = ;;; no input whatsoever: we want to make sure
          &nb= sp;            = ;;; that default is bubbled to the top so that
          &nb= sp;            = ;;; `icomplete-force-complete-and-exit' will
          &nb= sp;            = ;;; select it (do that even if the match
          &nb= sp;            = ;;; doesn't match the completion perfectly.
          &nb= sp;            = ;`(,(lambda (comp)
          &nb= sp;            = ;     (equal minibuffer-default comp))
          &nb= sp;            = ;  ,(lambda (comp)
          &nb= sp;            = ;     (string-prefix-p minibuffer-default = comp))))
          &nb= sp;           ((and= fido-mode
          &nb= sp;            = ;     (not minibuffer-default)
          &nb= sp;            = ;     (eq (icomplete--category) 'file))
          &nb= sp;            = ;;; `fido-mode' has some extra file-sorting
          &nb= sp;            = ;;; semantics even if there isn't a default,
          &nb= sp;            = ;;; which is to bubble "./" to the top if it
          &nb= sp;            = ;;; exists.  This makes M-x dired RET RET go to
          &nb= sp;            = ;;; the directory of current file, which is
          &nb= sp;            = ;;; what vanilla Emacs and `ido-mode' both do.
          &nb= sp;            = ;`(,(lambda (comp)
          &nb= sp;            = ;     (string=3D "./" comp)))))
      thereis (cl-loop
          &nb= sp;    for l on all
          &nb= sp;    while (consp (cdr l))
          &nb= sp;    for comp =3D (cadr l)
          &nb= sp;    when (funcall fn comp)
          &nb= sp;    do (setf (cdr l) (cddr l))
          &nb= sp;    and return
          &nb= sp;    (completion--cache-all-sorted-completions beg = end (cons comp all)))
      finally return all)))

I=E2=80=99m not sure how to get it to do so, = but when there are candidates satisfying both =E2=80=98equals=E2=80=99 = and =E2=80=98string-prefix-p=E2=80=99, we need to get this to prefer the = former over the latter.
Cheers,
Andy
= --Apple-Mail=_63D8D700-A63D-436B-BB74-D88066811735-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 28 21:48:39 2020 Received: (at 42101) by debbugs.gnu.org; 29 Jun 2020 01:48:39 +0000 Received: from localhost ([127.0.0.1]:47295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpiuU-0001GV-TO for submit@debbugs.gnu.org; Sun, 28 Jun 2020 21:48:39 -0400 Received: from mout02.posteo.de ([185.67.36.142]:40077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpiuR-0001GC-NX for 42101@debbugs.gnu.org; Sun, 28 Jun 2020 21:48:37 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id D71192400FB for <42101@debbugs.gnu.org>; Mon, 29 Jun 2020 03:48:28 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49w9PR63XVz9rxD; Mon, 29 Jun 2020 03:48:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty) From: Andrew Schwartzmeyer In-Reply-To: Date: Sun, 28 Jun 2020 18:48:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> To: 42101@debbugs.gnu.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42101 Cc: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Jo=C3=A3o, here=E2=80=99s that CC to get into the bug report. I=E2=80=99= m sorry I don=E2=80=99t know how debbugs works! I had to actually = disable my email provider=E2=80=99s TLS sending guarantee to send this = email=E2=80=A6maybe one day we=E2=80=99ll see GNU Emacs on GitHub or = something :) Thanks, Andy > On Jun 27, 2020, at 11:00 PM, GNU bug Tracking System = wrote: >=20 > Thank you for filing a new bug report with debbugs.gnu.org. >=20 > This is an automatically generated reply to let you know your message > has been received. >=20 > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. >=20 > Your message has been sent to the package maintainer(s): > bug-gnu-emacs@gnu.org >=20 > If you wish to submit further information on this problem, please > send it to 42101@debbugs.gnu.org. >=20 > Please do not send mail to help-debbugs@gnu.org unless you wish > to report a problem with the Bug-tracking system. >=20 > --=20 > 42101: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D42101 > GNU Bug Tracking System > Contact help-debbugs@gnu.org with problems From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 29 09:52:46 2020 Received: (at 42101) by debbugs.gnu.org; 29 Jun 2020 13:52:46 +0000 Received: from localhost ([127.0.0.1]:48275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpuDG-0004OY-Ej for submit@debbugs.gnu.org; Mon, 29 Jun 2020 09:52:46 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:32892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpuDC-0004OH-Qz for 42101@debbugs.gnu.org; Mon, 29 Jun 2020 09:52:44 -0400 Received: by mail-wr1-f53.google.com with SMTP id f18so8581504wrs.0 for <42101@debbugs.gnu.org>; Mon, 29 Jun 2020 06:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=PO/zs38zIu9p9w3LWbMrqRPhtqXxzthwZ00FKzSa62k=; b=CK/1BmxDbkmIC3/WO16Y1ChuHEdLKBj8JVHR7MHbk16QFVRqOwcogEFzBK2xleQ2le DJi7VjTmxN/sxdkFnLx5Wd8g4AkRgBRHCpoF+Ws84DG1IpBNTG9suwdfes9Hn0b6AdZS 48zalzGf9rid58escQh63NTvOTruh1WDbtOMxlpH7FoUUZKEROqdTGHbB3RMRvblS7/E zrpOftedtpxjUGHbv6/2nhVVRXzPGBVQoY2FDaQxi4oHikz7hLeHWJ9oRdYRShLsrueC sc4gdBO+SBP+kYpGJYMNvhLOd2U1bypoUGv24CMmjp/12wYKJKAJVChWTDJMcvkVvrLl Noow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=PO/zs38zIu9p9w3LWbMrqRPhtqXxzthwZ00FKzSa62k=; b=RiSq4tNR0PVCat8kQsB3Ei3VH1Fa1nklKuDFzhwo8Qt8CfuvHHe4HHz5etbWwsow/5 HRi7ZsfoyhLKZ/G0lJFCUuxQI+Yn/mqWc12xzRc1JpcI7Dt0YgHI9wIWzKnSVPuyd9be T4Fojt6BI2RpA/u2Ll3/ZIFxKOBN12j0M+3wRsfMhppLACBWEySkQ1szMaDzwb4J7Wa/ 3e2wmNaRfdzuVXsi1NZgKOHpejby1un1CDELKRkL4oyw9gCT8kIjcom8+qpySIMtP5gf r++I4cOVXzMJiyVdzX+Zlnb6wt2rdsda9+mjuraZC7HygdmqtnEB7HWI7JHEVLXb+xAq odYg== X-Gm-Message-State: AOAM531unbip3U6avZ0H1kAxVs9LDTRVPU9j+mo9xsZVmyj3vvhQ9d1b zvaYQYc3XM0x6qgIVf0xHBXc1rcS X-Google-Smtp-Source: ABdhPJz4ZHojEIBV/VdAl/nKDGm+xcsMteuxwzVjyd+qoKPIs9BtRW9xHGpVQgGn0RFogB1/Q4xIvQ== X-Received: by 2002:a5d:4611:: with SMTP id t17mr16268091wrq.243.1593438756548; Mon, 29 Jun 2020 06:52:36 -0700 (PDT) Received: from krug (89-180-150-59.net.novis.pt. [89.180.150.59]) by smtp.gmail.com with ESMTPSA id c206sm31020693wmf.36.2020.06.29.06.52.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 06:52:35 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Andrew Schwartzmeyer Subject: Re: bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty) References: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> Date: Mon, 29 Jun 2020 14:52:34 +0100 In-Reply-To: (Andrew Schwartzmeyer's message of "Sun, 28 Jun 2020 18:48:25 -0700") Message-ID: <87366easil.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42101 Cc: 42101@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrew Schwartzmeyer writes: > Hi Jo=C3=A3o, here=E2=80=99s that CC to get into the bug report. I=E2=80= =99m sorry I don=E2=80=99t > know how debbugs works! I had to actually disable my email provider=E2=80= =99s > TLS sending guarantee to send this email=E2=80=A6 This is very odd. it should be as simple as sending an email message to to 42101@debbugs.gnu.org, in this case. No idea if that violate any "TLS sending guarantees". > maybe one day we=E2=80=99ll see GNU Emacs on GitHub or something :) I lean towards the "or something". As to the actual bug, I'll try to look at it soon. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 29 10:00:27 2020 Received: (at 42101) by debbugs.gnu.org; 29 Jun 2020 14:00:27 +0000 Received: from localhost ([127.0.0.1]:49016 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpuKh-0004pI-7w for submit@debbugs.gnu.org; Mon, 29 Jun 2020 10:00:27 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:54048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpuKe-0004p0-HO for 42101@debbugs.gnu.org; Mon, 29 Jun 2020 10:00:25 -0400 Received: by mail-wm1-f53.google.com with SMTP id j18so15495713wmi.3 for <42101@debbugs.gnu.org>; Mon, 29 Jun 2020 07:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=6LEywURMkVY+rVK+R5m0rTtOfVcj0UNxLFcHBw6yD1M=; b=EwAWbqRUx/F74/aBeSYhYNhjbEnQ+yJC21PBiQY41v9A8aRbmP0KGGKuBtIZFnsza6 UjXmxj7yYkQRz2rcFoWotjxZEuVaF1kan6ScvL1egNRBWogKN1ETgeq/ucNfbriUgW9m fFkKIMHR4rqHL6UtIqshUX44+LahxWsiW2LKm+FQEQtYO398hRvxzq0ilb5WSkc2XBsI B2sy3tKI4g+aJADjagRsgd3IhKNsaLUMrLGgMZdmuuOGZIH3aO/TveGI1dVrLqRjj8UL BnfoPyZ0scwKEjYBiv6XZu7aUSoNdyCip0C6evU3XcIBJIB3hn5DRiNOpFW9mKksZNGZ kdig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6LEywURMkVY+rVK+R5m0rTtOfVcj0UNxLFcHBw6yD1M=; b=AJEZ3V7XRAqPrbsg1XEOoMQr5JaxTBmewMvNajioW6E1mIaXbxuTDBWpMDXjBrt+K5 g3As1O3yZWYyHGC65tym5KYAVt8Hh7EX4vrzDjIXLX/oSJggc31ipoMRnEHP3nr9hDJD MEUfcglHEbhZYR+YewyS+0UfeYIwmpySjazg3zuE2GpHm7cBXfYnDlQvc/TWY2jwrb2/ O0/eX/ItmEOmD86I7zto1ZQAi1dyJtdQZjXY2zjga5CVykUX8jwhRFG+8Al7f49b8ST1 7+ZTPY906fDcye4BV5UqRYbQ4oxJ3W5M63Wv3ERNf+XHXm7vw79maSuEcrC/hLI88qng uQ7g== X-Gm-Message-State: AOAM533SIeGfc+PKGcwDt2xN9KzvRsBaQVn4nFp20ecamQAQdlRR9XgC efqZoyEn6aEsAH5jcuVzZ04i6wB7 X-Google-Smtp-Source: ABdhPJxcKOKbO3trADOoeFom8fMZN2NcVBgV5J+RwQQXShzAD0ThPBkukC5TDYKCo7fLVqo3zSJGAg== X-Received: by 2002:a1c:4185:: with SMTP id o127mr16602397wma.8.1593439218218; Mon, 29 Jun 2020 07:00:18 -0700 (PDT) Received: from krug (89-180-150-59.net.novis.pt. [89.180.150.59]) by smtp.gmail.com with ESMTPSA id x18sm37704729wrq.13.2020.06.29.07.00.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 07:00:17 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Andrew Schwartzmeyer Subject: Re: bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty References: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> Date: Mon, 29 Jun 2020 15:00:16 +0100 In-Reply-To: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> (Andrew Schwartzmeyer's message of "Sat, 27 Jun 2020 22:59:40 -0700") Message-ID: <87v9ja9dlb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42101 Cc: 42101@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrew Schwartzmeyer writes: > Hi, > > Funny bug, haven=E2=80=99t figured out the cause. It may be hard to repro. > > If you have some amount of minibuffer history, you can cause > icomplete-fido-ret to not accept the minibuffer-default. An example is > having history such that 'C-h v' when point is on =E2=80=98completion-sty= les=E2=80=99 > causes =E2=80=98completion-styles-alist=E2=80=99 to be the first history > element. Since the minibuffer-default shows =E2=80=98completion-styles=E2= =80=99 (being > that it=E2=80=99s under point, and I=E2=80=99ve not entered any text into= the > minibuffer), I=E2=80=99d expect RET to choose =E2=80=98completion-styles= =E2=80=99, but instead > it choses =E2=80=98completion-styles-alist=E2=80=99 (the head of the pres= ented > candidates, =E2=80=98completion-styles=E2=80=99 is instead the second can= didate). > > This repros in fido-mode, but not icomplete-mode. I took a look at the > relevant functions called on RET for these modes but am having trouble > finding the issue. I can't reproduce this. I think the first step is for you to try to identify which sequence of actions as performed from an Emacs session started with -Q lead to the problem. For the record, I tried Emacs -Q (master of around two weeks ago) C-h v completion-styles RET C-h v completion-styles-alist RET type "completion-styles" in *scratch* buffer. With cursor on word. C-h v RET (quickly, before the completions appear) C-h v RET (slowly, letting the completions appear) Both approaches lead to the variable `completion-styles` being described. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 29 21:41:55 2020 Received: (at 42101) by debbugs.gnu.org; 30 Jun 2020 01:41:55 +0000 Received: from localhost ([127.0.0.1]:49881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jq5HX-00078f-CE for submit@debbugs.gnu.org; Mon, 29 Jun 2020 21:41:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jq5HU-00078S-5q for 42101@debbugs.gnu.org; Mon, 29 Jun 2020 21:41:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41970) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jq5HO-0000kF-PF; Mon, 29 Jun 2020 21:41:46 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jq5HN-0006L1-SL; Mon, 29 Jun 2020 21:41:46 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: =?iso-8859-1?Q?Jo=C3=A3o_T=C3=A1vora?= In-Reply-To: <87366easil.fsf@gmail.com> (message from =?iso-8859-1?Q?Jo=C3?= =?iso-8859-1?Q?=A3o_T=C3=A1vora?= on Mon, 29 Jun 2020 14:52:34 +0100) Subject: Re: bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty) References: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> <87366easil.fsf@gmail.com> Message-Id: Date: Mon, 29 Jun 2020 21:41:45 -0400 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 42101 Cc: andrew@schwartzmeyer.com, 42101@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > maybe one day we’ll see GNU Emacs on GitHub or something :) > I lean towards the "or something". Here's why it can't be Github: https://www.gnu.org/software/repo-criteria-evaluation.html. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 04 01:22:54 2020 Received: (at 42101) by debbugs.gnu.org; 4 Jul 2020 05:22:54 +0000 Received: from localhost ([127.0.0.1]:57971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jradZ-0005uE-RO for submit@debbugs.gnu.org; Sat, 04 Jul 2020 01:22:54 -0400 Received: from mout01.posteo.de ([185.67.36.141]:59707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jradW-0005ts-Qv for 42101@debbugs.gnu.org; Sat, 04 Jul 2020 01:22:52 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id DA1F116005F for <42101@debbugs.gnu.org>; Sat, 4 Jul 2020 07:22:44 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49zKwM2Yndz9rxR; Sat, 4 Jul 2020 07:22:43 +0200 (CEST) From: Andrew Schwartzmeyer Message-Id: <8497A4AC-93AA-4489-AA87-3BA375049092@schwartzmeyer.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0166380F-5849-444E-9F8D-7787DA0506FA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty Date: Fri, 3 Jul 2020 22:22:41 -0700 In-Reply-To: <87v9ja9dlb.fsf@gmail.com> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> <87v9ja9dlb.fsf@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42101 Cc: 42101@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --Apple-Mail=_0166380F-5849-444E-9F8D-7787DA0506FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m sorry so Jo=C3=A3o, I had sent you a repro last week, but it = again didn=E2=80=99t go through. It appears I have to leave TLS-sending guarantees disabled because the = debbugs mail server is insecurely configured (for others who may be = reading but offering no useful input, this is a security issue that does = not exist with GitHub or other similar software). Perhaps we should move = to emacs-devel which at least accepts email sent over TLS. Anyway, I can repro this in emacs -Q with: (defun fido-mode+ () (setq-local completion-styles '(basic))) (add-hook 'icomplete-minibuffer-setup-hook #'fido-mode+) (fido-mode) Basically (heh) this happens if the =E2=80=9Cbasic=E2=80=9D = completion-style is used (or =E2=80=9Cpartial-completion=E2=80=9D or = =E2=80=9Csubstring=E2=80=9D or any combination including one of those = styles). It only doesn=E2=80=99t repro if =E2=80=9Cflex=E2=80=9D is used by = itself (the default for fido-mode, but should be able to be overridden). This also repros with icomplete-mode if = =E2=80=9Cicomplete-show-matches-on-no-input=E2=80=9D is t, as in: (defun fido-mode+ () (setq-local completion-styles '(basic) icomplete-show-matches-on-no-input t)) (add-hook 'icomplete-minibuffer-setup-hook #'fido-mode+) (icomplete-mode) Which explains why it=E2=80=99s readily apparent in fido-mode, where = that=E2=80=99s set to t already. Unfortunately, I still have no clue how = to fix it. I would appreciate your help! Being able to use the default = styles in addition to flex makes the fido-mode experience smoother, = because they return defaults for no input much faster, I find them to be = more predictable, and it=E2=80=99s when they fail that flex tends to = shine most. Thanks, Andy > On Jun 29, 2020, at 7:00 AM, Jo=C3=A3o T=C3=A1vora = wrote: >=20 > Andrew Schwartzmeyer > writes: >=20 >> Hi, >>=20 >> Funny bug, haven=E2=80=99t figured out the cause. It may be hard to = repro. >>=20 >> If you have some amount of minibuffer history, you can cause >> icomplete-fido-ret to not accept the minibuffer-default. An example = is >> having history such that 'C-h v' when point is on = =E2=80=98completion-styles=E2=80=99 >> causes =E2=80=98completion-styles-alist=E2=80=99 to be the first = history >> element. Since the minibuffer-default shows =E2=80=98completion-styles=E2= =80=99 (being >> that it=E2=80=99s under point, and I=E2=80=99ve not entered any text = into the >> minibuffer), I=E2=80=99d expect RET to choose = =E2=80=98completion-styles=E2=80=99, but instead >> it choses =E2=80=98completion-styles-alist=E2=80=99 (the head of the = presented >> candidates, =E2=80=98completion-styles=E2=80=99 is instead the second = candidate). >>=20 >> This repros in fido-mode, but not icomplete-mode. I took a look at = the >> relevant functions called on RET for these modes but am having = trouble >> finding the issue. >=20 > I can't reproduce this. I think the first step is for you to try to > identify which sequence of actions as performed from an Emacs > session started with -Q lead to the problem. For the record, I tried >=20 > Emacs -Q (master of around two weeks ago) >=20 > C-h v completion-styles RET > C-h v completion-styles-alist RET >=20 > type "completion-styles" in *scratch* buffer. With cursor on word. >=20 > C-h v RET (quickly, before the completions appear) > C-h v RET (slowly, letting the completions appear) >=20 > Both approaches lead to the variable `completion-styles` being > described. >=20 > Jo=C3=A3o --Apple-Mail=_0166380F-5849-444E-9F8D-7787DA0506FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99m sorry so Jo=C3=A3o, I had sent you a repro last = week, but it again didn=E2=80=99t go through.

It appears I have to leave TLS-sending = guarantees disabled because the debbugs mail server is insecurely = configured (for others who may be reading but offering no useful input, = this is a security issue that does not exist with GitHub or other = similar software). Perhaps we should move to emacs-devel which at least = accepts email sent over TLS.

Anyway, I can repro this in emacs -Q = with:

(defun = fido-mode+ ()
  (setq-local completion-styles = '(basic)))
(add-hook = 'icomplete-minibuffer-setup-hook #'fido-mode+)
(fido-mode)

Basically (heh) this happens if the =E2=80=9Cbasic=E2=80=9D = completion-style is used (or =E2=80=9Cpartial-completion=E2=80=9D or = =E2=80=9Csubstring=E2=80=9D or any combination including one of those = styles).

It = only doesn=E2=80=99t repro if =E2=80=9Cflex=E2=80=9D is used by itself = (the default for fido-mode, but should be able to be = overridden).

This also repros with icomplete-mode if = =E2=80=9Cicomplete-show-matches-on-no-input=E2=80=9D is t, as = in:

(defun fido-mode+ ()
  (setq-local = completion-styles '(basic)
      =         icomplete-show-matches-on-no-input = t))
(add-hook 'icomplete-minibuffer-setup-hook = #'fido-mode+)
(icomplete-mode)

Which explains why = it=E2=80=99s readily apparent in fido-mode, where that=E2=80=99s set to = t already. Unfortunately, I still have no clue how to fix it. I would = appreciate your help! Being able to use the default styles in addition = to flex makes the fido-mode experience smoother, because they return = defaults for no input much faster, I find them to be more predictable, = and it=E2=80=99s when they fail that flex tends to shine most.

Thanks,

Andy

On Jun = 29, 2020, at 7:00 AM, Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> wrote:

Andrew Schwartzmeyer = <andrew@schwartzmeyer.com> writes:

Hi,

Funny = bug, haven=E2=80=99t figured out the cause. It may be hard to repro.

If you have some amount of minibuffer history, = you can cause
icomplete-fido-ret to not accept the = minibuffer-default. An example is
having history such that = 'C-h v' when point is on =E2=80=98completion-styles=E2=80=99
causes =E2=80=98completion-styles-alist=E2=80=99 to be the = first history
element. Since the minibuffer-default shows = =E2=80=98completion-styles=E2=80=99 (being
that it=E2=80=99s= under point, and I=E2=80=99ve not entered any text into the
minibuffer), I=E2=80=99d expect RET to choose = =E2=80=98completion-styles=E2=80=99, but instead
it choses = =E2=80=98completion-styles-alist=E2=80=99 (the head of the presented
candidates, =E2=80=98completion-styles=E2=80=99 is instead = the second candidate).

This repros in = fido-mode, but not icomplete-mode. I took a look at the
relevant functions called on RET for these modes but am = having trouble
finding the issue.

I can't reproduce this.  I think the first step is for = you to try to
identify = which sequence of actions as performed from an Emacs
session started with -Q lead to = the problem.  For the record, I tried

Emacs -Q (master of around two weeks ago)

 C-h v completion-styles = RET
 C-h v = completion-styles-alist RET

type "completion-styles" in *scratch* buffer.  With = cursor on word.

 C-h v RET (quickly, before the completions = appear)
 C-h v = RET (slowly, letting the completions appear)

Both approaches lead to the = variable `completion-styles` being
described.

Jo=C3=A3o

= --Apple-Mail=_0166380F-5849-444E-9F8D-7787DA0506FA-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 04 05:35:29 2020 Received: (at 42101) by debbugs.gnu.org; 4 Jul 2020 09:35:29 +0000 Received: from localhost ([127.0.0.1]:58074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrea0-0003Z6-QE for submit@debbugs.gnu.org; Sat, 04 Jul 2020 05:35:28 -0400 Received: from mail-io1-f47.google.com ([209.85.166.47]:37136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jreZy-0003Yu-Gj for 42101@debbugs.gnu.org; Sat, 04 Jul 2020 05:35:27 -0400 Received: by mail-io1-f47.google.com with SMTP id v6so20954781iob.4 for <42101@debbugs.gnu.org>; Sat, 04 Jul 2020 02:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kq0qf4CAouRE2Nnii9dEFNdlXgTNC85EeS7mCuF4vRg=; b=baj2VSyBbXfyjNn6SmDQMHPbvrt0fyNpgjRmxmzCZQ9dQkQxDq4MQWg7zOEZrHUNwf nBOGRH4kGmvJr7jFtjqtBqNWArmJQhwYcnUxDBmZyWtSd6sb4WC2VUV4W2CjDSsggov3 eduEkxX2PkWLQnz/LafwgO3Syp6padvCCU0FRLac4BN4McCAO+vMAgBYVVRETgePeWow fo68zAQowmaz2t333NuXzlhIGZtN+I2hM5v+vcs4+NGs2kwaAVFEhSK4i3yrbpUkXVYn YLBnbQ3rMp2ofjiocjFO8cpzC0Gag9zB8XGKbkGOoXqQSTl/DNsqbQ1syMrmJLB5y6nt eXYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kq0qf4CAouRE2Nnii9dEFNdlXgTNC85EeS7mCuF4vRg=; b=H/GZHWdo1WSik+HXaFfefwZgEhvc8TMH+lV91ul4CJ/b1JuT1Y7jCcVSXKhRQf3JKy zb3ObDHoDn+Dhg4HTUzXWevOl8h8DaphB77kyhPmuz800HvLAF/zaoAL4c8UkIcE4kEU LlnPf+EeZJkjL3TEg4t0H7599pGJaENq8U9I2PUHgcnWzMAD5l5xtzISirx2fA48y8qD gARX7korkniCtrMBm2Z3+DjRp9mb2OHdQffoRqzAq4/29TDbESoDt14ZO6WdlFXIdqel F8wrKZYPE1KXKTmLBJkpUOm4VabBaBikMuVmFO3+lDuYqonKClN5D8Xk2Kr1qRTaOWgi Vrog== X-Gm-Message-State: AOAM531EnfnVmnqLo0JPuCC3XcRcZPpOLXRw4LOQbWdOjHwjDBJ9I1Dj peKJOOAUl5hNKKHcAOwarqiIw8aQZgid7SUZE2o= X-Google-Smtp-Source: ABdhPJxFa6Uce/Ufisn2PoDPFMO9r517VQMfxsFmQQGKS7aZNj0AXjT1mv++UJU/YEqoGXG8JSIUDqJXXy6oDDnq9wM= X-Received: by 2002:a5d:8407:: with SMTP id i7mr15993899ion.175.1593855320010; Sat, 04 Jul 2020 02:35:20 -0700 (PDT) MIME-Version: 1.0 References: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> <87v9ja9dlb.fsf@gmail.com> <8497A4AC-93AA-4489-AA87-3BA375049092@schwartzmeyer.com> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 4 Jul 2020 10:35:13 +0100 Message-ID: Subject: Re: bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty To: Andrew Schwartzmeyer Content-Type: multipart/alternative; boundary="0000000000002c33ce05a99a5ce0" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42101 Cc: 42101@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000002c33ce05a99a5ce0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Schwartzmeyer wrote > Any clue? I'm sorry Andrew haven't had time to look into it yet, but your analyses help. Just note that Fido-mode is indeed geared primarily to working with flex. But it should be customizable of course. Jo=C3=A3o --0000000000002c33ce05a99a5ce0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Schwartzmeyer <andrew@schwar= tzmeyer.com> wrote

= >=C2=A0Any clue?

I= 9;m sorry Andrew haven't had time to look into it yet, but your analyse= s help.=C2=A0 Just note that Fido-mode is indeed geared primarily to workin= g with flex. But it should be customizable of course.

Jo=C3=A3o
--0000000000002c33ce05a99a5ce0-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 26 00:11:35 2020 Received: (at 42101) by debbugs.gnu.org; 26 Jul 2020 04:11:35 +0000 Received: from localhost ([127.0.0.1]:51539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzY0c-0005FY-QC for submit@debbugs.gnu.org; Sun, 26 Jul 2020 00:11:35 -0400 Received: from mout01.posteo.de ([185.67.36.141]:35146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzY0Z-0005FI-70 for 42101@debbugs.gnu.org; Sun, 26 Jul 2020 00:11:33 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 8E3C716005C for <42101@debbugs.gnu.org>; Sun, 26 Jul 2020 06:11:24 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BDqHv1h6Kz9rxG; Sun, 26 Jul 2020 06:11:23 +0200 (CEST) From: Andrew Schwartzmeyer Message-Id: <3151C929-A606-42FF-B839-C5A0239D4BEE@schwartzmeyer.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_704533F3-CFE9-4B5F-A708-35B31A4C28AA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty Date: Sat, 25 Jul 2020 21:11:21 -0700 In-Reply-To: To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <427CB228-0C09-44A0-A684-0A7C2C294487@schwartzmeyer.com> <87v9ja9dlb.fsf@gmail.com> <8497A4AC-93AA-4489-AA87-3BA375049092@schwartzmeyer.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42101 Cc: 42101@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --Apple-Mail=_704533F3-CFE9-4B5F-A708-35B31A4C28AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This bug can be fixed by deleting the expression: ,(lambda (comp) (string-prefix-p minibuffer-default comp)) from icomplete--sorted-completions. But it=E2=80=99s obviously there for some reason, so idk. > On Jul 4, 2020, at 2:35 AM, Jo=C3=A3o T=C3=A1vora = wrote: >=20 > Schwartzmeyer > wrote >=20 > > Any clue? >=20 > I'm sorry Andrew haven't had time to look into it yet, but your = analyses help. Just note that Fido-mode is indeed geared primarily to = working with flex. But it should be customizable of course. >=20 > Jo=C3=A3o --Apple-Mail=_704533F3-CFE9-4B5F-A708-35B31A4C28AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = bug can be fixed by deleting the expression:

  ,(lambda = (comp)
     (string-prefix-p = minibuffer-default comp))

from icomplete--sorted-completions.

But it=E2=80=99s = obviously there for some reason, so idk.

On Jul = 4, 2020, at 2:35 AM, Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> wrote:

Schwartzmeyer <andrew@schwartzmeyer.com> wrote

> Any clue?

I'm sorry Andrew haven't = had time to look into it yet, but your analyses help.  Just note = that Fido-mode is indeed geared primarily to working with flex. But it = should be customizable of course.

Jo=C3=A3o

= --Apple-Mail=_704533F3-CFE9-4B5F-A708-35B31A4C28AA--