From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tadeus Prastowo Newsgroups: gmane.emacs.devel Subject: Re: [pcomplete.el (pcomplete-completions-at-point)] Why max? Date: Wed, 20 Mar 2019 12:00:13 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="222812"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 20 12:00:37 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6YxY-000vq1-IN for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2019 12:00:36 +0100 Original-Received: from localhost ([127.0.0.1]:46104 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6YxX-0002Fe-Cd for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2019 07:00:35 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6YxQ-0002FT-QR for emacs-devel@gnu.org; Wed, 20 Mar 2019 07:00:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6YxP-0007rn-H8 for emacs-devel@gnu.org; Wed, 20 Mar 2019 07:00:28 -0400 Original-Received: from mail-it1-x141.google.com ([2607:f8b0:4864:20::141]:40775) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h6YxO-0007nm-Th for emacs-devel@gnu.org; Wed, 20 Mar 2019 07:00:27 -0400 Original-Received: by mail-it1-x141.google.com with SMTP id l139so31779632ita.5 for ; Wed, 20 Mar 2019 04:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unitn.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nGCFrueKQwq99Ui5PHVOuHMD2U947HRnxuvP+1EkYmE=; b=MVmdsVTfwSsqumKKLmpQSpvg/5BEiW201PcbLS4bvw4z+ftNg7LhqTxIrwWr52NfGr CvEq5h/0o08Y/kUzEd7q5qrlIi3xFprpw3hBJrq+WU1ovTBvnRXdsj97hZsf1yN4ZPyA vQmuU3fa8vktYbLqbQ2HOqjG9is+KR6BS+bq0= 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=nGCFrueKQwq99Ui5PHVOuHMD2U947HRnxuvP+1EkYmE=; b=YL7g+UZ6jyQsmqpRimbKrHl0TaY2E/ASWKV8DZ12wx+ynHpdHc8OLa3jKcgwMlJacV /JMWN8rO9UsIGRAJR+HDUTUZq1MCwW8RSgLSUB8BJdgHHlnEp8yRdC95ik/OQtrx3cES +zp4zYqtezEyuH/lF5XyEyYGpTNmM33Br8Ekh1c+IlhjUhajElRE85NEro1z39y6WpPN amVOoPahpuDudC/pCDqli7DEJe6YdsgrUTwWRVc/CQOEiqGnSvZiT41BB53ioucWtz80 yN52J5e84vLiW3SQi7/ZNHZK8bUqGMmmcmsFMULzvmOdNAJeI51Suv4NaRtAE08KVI9e ZmNQ== X-Gm-Message-State: APjAAAWY7kQRtJaflfeoC/U/71syKWUZN6CYiFv04K6PiPLHM/qTWwU3 NS+VD1nxFCeeqpPZEFu8Nc6+zx/+SFWGrrWGS4jU X-Google-Smtp-Source: APXvYqweQdBOqHdSgCiAaEvIF+pGlCeSN1xQfoF+1LBrBfhmpdpR/yNn3R/yZVWABhYn66nChyewdQu0DSjwwdKAEWc= X-Received: by 2002:a05:660c:6c5:: with SMTP id z5mr4328600itk.160.1553079625102; Wed, 20 Mar 2019 04:00:25 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::141 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:234399 Archived-At: On Wed, Mar 20, 2019 at 3:13 AM Stefan Monnier wrote: > > > M-x shell > > cd /tmp > > mkdir AAAA\ BB\ CCCC > > cd AAAA\ BB > > When I try this (with Emacs `master` but AFAIK this hasn't changed for > quite a while), I get the expected completion to > > cd AAAA\ BB\ CCCC > > what do you get instead? Okay, that magic word does not work. Please try the following magic word (I try it at commit 047c1b19353ff58d8cd45935c7b44c911b70e312): $ emacs -Q M-x shell cd /tmp mkdir ABCD\ EF\ GHIJKL cd ABCD\ EF The echo area shows "No match". With my proposed fix (not yet adjusted to the said commit, I just did C-M-x on my proposed patch), the completion works. The correct magic word seems to depend on the correct combinations of the number of characters and their cases. The occurrence of the magic work in the wild is not rare, though, since I had hit this problem several times till I was compelled last weekend to debug it. What do you think the real problem is? > > Autocomplete fails because (pcomplete-begin) returns the position of > > the first letter A but (length pcomplete-stub) is the length of "AAAA > > BB", which gives the position of the second letter A. The function > > `max', therefore, sets `beg' to the start of the second letter A. > > Consequently, file-name-completion will be asked to complete "AAA BB" > > instead of the correct one "AAAA BB". > > The `completion-table-subvert` and `completion-table-with-quoting` > layers of the completion table are supposed to convert the "AAA\ BB" to > "AAAA BB" and back, so that file-name-completion should see neither > "AAAA\ BB" nor "AAA BB" but "AAAA BB" (which is indeed the string it > needs to do its job correctly). Okay, I will keep it in mind. > > What do you think will break if `min' is used instead of `max' to > > repair the following problem seen using `emacs -Q' at the said commit? > > To some extent the value of `beg` is not tremendously important because > of the `completion-table-subvert` layer, but there are cases where it > does make a difference. I can't offhand remember enough to tell you > which are those cases (IIRC it has to do with cases where completion > wants to change text *before* point, e.g. completing `em-li` to > `emacs-lisp` or /u/s/d to /usr/share/doc) so I can't quite remember when > `min` would be worse than `max` here, but IIRC `beg` is used as a kind > of "modification boundary" (the completion operation cannot modify any > part of the text before `beg`) so I use `max` to minimize the damage in > case the replacement breaks the assumptions made by > `completion-table-subvert`. > > [ As alluded to in the comment just before the code you cite, there's > a fundamental discrepancy between the information that pcomplete > collects and the information that completion-at-point-function needs, > so we do our best to workaround and confine the cases where the > discrepancy bites us. ] Thank you very much for your information. I will keep it in mind. > Stefan -- Best regards, Tadeus