From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#50470: 27.1; 'company-mode' 'eshell' Date: Sun, 5 Jun 2022 01:29:11 +0300 Message-ID: References: <87h7evegav.fsf@debian-BULLSEYE-live-builder-AMD64> <154bd0e9-2779-5a28-5587-a845a982e39f@yandex.ru> <815516d6-262b-4ef1-786e-ec5b4199847c@yandex.ru> <01845bee-7637-76f6-2e86-2e2de91f6f6e@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35354"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: Christophe , 50470@debbugs.gnu.org To: Stefan Monnier , John Wiegley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 05 00:30:45 2022 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 1nxcI8-00093u-40 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jun 2022 00:30:44 +0200 Original-Received: from localhost ([::1]:51532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxcI6-0003Jd-KE for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jun 2022 18:30:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46988) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxcHU-0003JC-1w for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 18:30:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37619) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nxcHT-0008Cm-MX for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 18:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nxcHS-0006Ey-H8 for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 18:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jun 2022 22:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50470 X-GNU-PR-Package: emacs Original-Received: via spool by 50470-submit@debbugs.gnu.org id=B50470.165438176223901 (code B ref 50470); Sat, 04 Jun 2022 22:30:02 +0000 Original-Received: (at 50470) by debbugs.gnu.org; 4 Jun 2022 22:29:22 +0000 Original-Received: from localhost ([127.0.0.1]:59749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxcGo-0006DQ-DF for submit@debbugs.gnu.org; Sat, 04 Jun 2022 18:29:22 -0400 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:41910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxcGm-0006DD-74 for 50470@debbugs.gnu.org; Sat, 04 Jun 2022 18:29:20 -0400 Original-Received: by mail-wr1-f48.google.com with SMTP id k19so14857160wrd.8 for <50470@debbugs.gnu.org>; Sat, 04 Jun 2022 15:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=+b54Yd9DH0OuaK/zRUMHB1mCbqHgp4eniccymX4Zlf4=; b=kibhVVcV47f8FFti5eDesSR2tRSzaj3xNBdcriohxrFO3tUjYsW5kyX/t1SSATvYnZ WPl5mq8W6uOt+uNtnarqdLZcLuSwO4sJH8qjA/x4pZpfL+rQufFA8+EKmDIif3Eieetz q0q5dynAvzJjEd4q5hXMZOi0zf1EKG7wOJMdTqRFseYJNp0eS3HeLCO0qV4SaXjP/cqR hfLnEs8V2fsGq4g19sYG0PD6WQ3/qIwi9NQdrP0sFM8PHcz4MS5nolvqv1fOZi7emsZ2 /S3NzvS5sYaz5ecFYcsDUUcHE+djHMAS9Z5VvvMxa6LGGrAWj4xFcPGT4IVdQX0zkF9t Uo+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=+b54Yd9DH0OuaK/zRUMHB1mCbqHgp4eniccymX4Zlf4=; b=eRMXTX7Lfza/LYjpfmfklATNsGuGwAyfL2FAJ471zV66wfk9UzDBTeC7G+9AHYBvDL jBYLI8RrriFLGd5BmwQBJZ1vQKlpZ8WGvJe9/PVOysa4ANkNvrFHOljXO/2DI0lbpeGl WnyxHrKpnHLM1yp0r3uNWyBXzwbqXsH5/mWcgEW2Tg8RPbLC4SFoq6e0WJ+pUfV52f6H D2JPY3v7PJiyyfVxWlu2agGSpvkIpb1BFm8plH35SMD2FU4gH2UYhtbJg+Og6s8HsrGt NXSiyMd/3GznX/uhIzdkRDvk+c+KcGQDqtUw+5NzrHvpi5J2cdRSySwfxzlCcfcw9F7l fehg== X-Gm-Message-State: AOAM530fwFsT8fzTzYdaakhCa01KtcKZ08X9y3KUG15+dy16MITUCr6D QGtWHoYO18ApxEFSjR2D6nY= X-Google-Smtp-Source: ABdhPJwyR0hx3quH/iYbVBrvv0rm9OsSeaLGhyOhajvOPEC1PmIzuz24Ge/KTchdoulWrynl+WSLRQ== X-Received: by 2002:a05:6000:2a2:b0:20f:d7ca:47b with SMTP id l2-20020a05600002a200b0020fd7ca047bmr14450733wry.298.1654381754108; Sat, 04 Jun 2022 15:29:14 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id d14-20020a5d6dce000000b0020c5253d927sm11292650wrz.115.2022.06.04.15.29.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jun 2022 15:29:13 -0700 (PDT) Content-Language: en-US In-Reply-To: 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" Xref: news.gmane.io gmane.emacs.bugs:233674 Archived-At: It seems like this bug was fixed in bug#55204? Or at least the problems scenarios are not reproducible anymore. The downside compared to my latest patch is that it actually expanded ~/Downl* into a bunch of completions (and the current behavior is "no completions"), but that seems minor. It might be considered a regression, though. On 26.01.2022 01:05, Stefan Monnier wrote: > Hi John, > > Could you explain to me some of the code of `pcomplete-parse-arguments`? > I know that was many years ago but hopefully there's still some fond > memories of how you designed it. > > To be honest, the only part I sort-of understand are the first > 5-6 lines. Then comes the `(let ((begin (pcomplete-begin 'last)))` and > after that I'm lost: it doesn't look like we're parsing arguments > any more. > > E.g. Why/when would pcomplete-stub contain a list rather than a string? > > > Stefan > > > Dmitry Gutov [2022-01-24 03:50:59] wrote: > >> Hi Stefan, >> >> On 23.01.2022 05:23, Stefan Monnier wrote: >>> And the 100% untested patch below is a suggestion for how to try and fix >>> those kinds of bugs. >>> Can someone try and maybe make it work? >> >> I've tried the patch, and it seems to work already, as well as fix this >> particular scenario. (Thanks!) >> >> Might as well install it, I think. >> >> There is a scenario that is more noticeably broken (yet actually better with >> this patch): a modification of bug#18951. Instead of >> >> ls * >> >> try >> >> ls ~/Docu* >> >> ...and [on master] the result is that the asterisk is replaced with the >> "common part" of the possible completions automatically. If there is >> nothing to expand with, the asterisk is similarly deleted. >> >> With your patch, we get the "Buffer is read-only" error in *Messages* >> instead, which is probably an improvement. Because it doesn't modify the >> input, nor break Company completions long-term (after the asterisk is >> removed). >> >> The offending functions is pcomplete-parse-arguments. There is some complex >> global state going on there, but the following addition seems to fix the >> problem: >> >> @@ -790,6 +804,9 @@ pcomplete-parse-arguments >> (common-stub (car completions)) >> (c completions) >> (len (length common-stub))) >> + (unless pcomplete-allow-modifications >> + (setq pcomplete-stub (buffer-substring begin (point))) >> + (throw 'pcomplete-completions completions)) >> (while (and c (> len 0)) >> (while (and (> len 0) >> (not (string= >> >> >> Not sure if this new value of pcomplete-stub is always TRT, but it has >> passed a bunch of my experiments successfully. >