From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#60411: 29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil Date: Fri, 06 Jan 2023 14:59:08 +0200 Message-ID: <83mt6vvmxv.fsf@gnu.org> References: <87zgb5lx6y.fsf@oracle.com> <6c9d91cffcdbff97f034@heytings.org> <87lemot7ek.fsf@gmail.com> <0a62cbaeff1ee0497715@heytings.org> <226b32f79f7db2be1bbe@heytings.org> <226b32f79f65b964c636@heytings.org> <86sfgp5ihl.fsf@mail.linkov.net> <8dea9f3e0e993e0bd0a9@heytings.org> <83a62ww4bo.fsf@gnu.org> <371ba1d0be9671d4a3a4@heytings.org> <83v8lkujt0.fsf@gnu.org> <371ba1d0be87d64ed419@heytings.org> <83tu13vqlb.fsf@gnu.org> <371ba1d0bed233c2fbd3@heytings.org> <83pmbrvonx.fsf@gnu.org> <371ba1d0becbcd718fdb@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18759"; mail-complaints-to="usenet@ciao.gmane.io" Cc: kahatlen@gmail.com, 60411@debbugs.gnu.org, monnier@iro.umontreal.ca, juri@linkov.net To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 06 14:00:16 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pDmKW-0004jl-O9 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 06 Jan 2023 14:00:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pDmKN-0000Qp-DH; Fri, 06 Jan 2023 08:00:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDmKI-0000QO-RX for bug-gnu-emacs@gnu.org; Fri, 06 Jan 2023 08:00:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pDmKI-0000UB-HR for bug-gnu-emacs@gnu.org; Fri, 06 Jan 2023 08:00:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pDmKI-0008P8-CM for bug-gnu-emacs@gnu.org; Fri, 06 Jan 2023 08:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Jan 2023 13:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60411 X-GNU-PR-Package: emacs Original-Received: via spool by 60411-submit@debbugs.gnu.org id=B60411.167300994632215 (code B ref 60411); Fri, 06 Jan 2023 13:00:02 +0000 Original-Received: (at 60411) by debbugs.gnu.org; 6 Jan 2023 12:59:06 +0000 Original-Received: from localhost ([127.0.0.1]:54001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDmJN-0008NW-JL for submit@debbugs.gnu.org; Fri, 06 Jan 2023 07:59:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDmJL-0008N0-Dw for 60411@debbugs.gnu.org; Fri, 06 Jan 2023 07:59:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDmJF-0000Iw-Lq; Fri, 06 Jan 2023 07:58:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=PaddRk7oEFlWBj6nYSRfckt8jcA94FDDDk5ct6T67Ms=; b=sg/YPxV8Ikki PGVyu9pdwLKulid7zT4o2aq7z6NlO7V3J+z9GK5UUabthZfr0UcoxjSwqSm+2AZfnmPbipAFwEjA9 xDSMNW+SOWbuDgbG+Kcsjz7ts5za5F9REUX2X8dXNn151k3dU9aj1RxPrn+rcAU2/mviEhskUZQHF A3eyLKOCcqHgOMmAm/mqisWTRE2Gq6Gux8DklT3AqvN6vOtbU3dO4vOv/yeoRU2kmdvYkPa2KkfRq ViQ9rZJbktrJ41aAGsUdxOr2Mu7kiqqBAzc8cIvfu7OSgcRZ0aqAmLvEV8I9mDEqfUbCrpyQwbXVN 3Wm7nTBSxmvtAKymkoTphA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDmJ8-0006Uj-7V; Fri, 06 Jan 2023 07:58:57 -0500 In-Reply-To: <371ba1d0becbcd718fdb@heytings.org> (message from Gregory Heytings on Fri, 06 Jan 2023 12:39:46 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252703 Archived-At: > Date: Fri, 06 Jan 2023 12:39:46 +0000 > From: Gregory Heytings > cc: kahatlen@gmail.com, 60411@debbugs.gnu.org, monnier@iro.umontreal.ca, > juri@linkov.net > > > > > > That's very surprising to hear. AFAIU, it just looks for some special > > text property (in next-completion). So it sounds like a very simple > > breakage of logic, where "next" means "the first one" when you are > > exactly at BOB. > > > > The problem is that minibuffer-next-completion is supposed to move to the > first completion when it is called for the first time, to the next > completion when it is called for the Nth time, and to the first completion > again when it is called for the Mth time (where M is the number of > completion candidates). Right. > If point is at BOB, and if there is nothing before the first completion, > next-completion finds that there is a text property there, and therefore > moves to the end of the current completion (the first one) and to the > beginning of the next completion, with the two calls to > next-single-property-change. > > There is nothing in the current logic of the code with which it is > possible to make a distinction between "this is the first call" and "this > is not the first call". Didn't you just say that the difference between "first" and "next" is "the first call"? Can't we make the logic be based on that instead of assuming that the format produces an empty string under certain conditions?