From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: bcclaro Newsgroups: gmane.emacs.bugs Subject: bug#67691: 29.1.50; Virtual buffers in fido-mode Date: Fri, 8 Dec 2023 11:38:49 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000a7961060c008de8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4268"; mail-complaints-to="usenet@ciao.gmane.io" To: 67691@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 08 15:40:21 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 1rBc1d-0000tk-8I for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Dec 2023 15:40:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rBc1E-00072s-7Z; Fri, 08 Dec 2023 09:39:56 -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 1rBc18-00071h-NE for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 09:39:52 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rBc17-0008Ah-Rz for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 09:39:50 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rBc1K-0005WE-QQ for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2023 09:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: bcclaro Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2023 14:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67691 X-GNU-PR-Package: emacs Original-Received: via spool by 67691-submit@debbugs.gnu.org id=B67691.170204638921154 (code B ref 67691); Fri, 08 Dec 2023 14:40:02 +0000 Original-Received: (at 67691) by debbugs.gnu.org; 8 Dec 2023 14:39:49 +0000 Original-Received: from localhost ([127.0.0.1]:44285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBc16-0005V3-2V for submit@debbugs.gnu.org; Fri, 08 Dec 2023 09:39:48 -0500 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:43365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBc13-0005Ud-Cp for 67691@debbugs.gnu.org; Fri, 08 Dec 2023 09:39:46 -0500 Original-Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-50c04ebe1bbso2020714e87.1 for <67691@debbugs.gnu.org>; Fri, 08 Dec 2023 06:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702046366; x=1702651166; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=2WhoDya8xKDRLW5fuDOiub9jKofViJ2u7eC2cH1zAOI=; b=WJi41O82/7+xStpA6XzVVq4Z2jFclfE0nH5+697pg+4XqJEDAVnyJQZwfJhn2KR9ot bKfGmSkM6Td9m8lIZSl4qV2gnhcTdle+UzfUAi34hYM1UOKP1HPwobh2o09nP3AWi1s1 hAErVkMaNuJd85NSeXjP5kSLW+9L2TYDpcc38/fmpdfD0WsszH3Wrb4YHasWvc+HtjW4 HORoiGvWVQl5bZJL74sGgcQFu8SlyGTB9bPX44qR61O/9+oEa/tcB/oEOGIxcXlgghnB U9BFBL6FXCgkyv6VyHy1BH6Cq0rR78IxACcKzawPA2qAl19vKix/jIScN+y5Wbfg++T3 HxAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702046366; x=1702651166; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2WhoDya8xKDRLW5fuDOiub9jKofViJ2u7eC2cH1zAOI=; b=Vrt2C3gnvBRMntnKw0534lsBKzp6XbWSERFpBLBoeYLKzLTq2/hdJssO+EfG+cPsju /jVZaEp/trPgLXeIokjikJiHHQIJqOVO+/cVP5kvPrWe+ATtlPnymVjmgof9CHz3bu1u wKFTPFz7L6Q3NgGEuriLqrXDTn/k//9WwEDiN1QwqHLKcsFFGDUmBHm8AFruONVlj3F7 mG1ObmsjjsHZk5C92b3KEOCTlfn5W6zsExboa6jUbLz58zowoQBUoaL3r0iTIp8p5mAY NDNKU6kI7ausN+hiAPCQJCXNWkcfIJ+dggowFqynGzSLPiKGRIop7ZXNxB/KBmziR6bg gM3Q== X-Gm-Message-State: AOJu0Yz7ceeOz8La2KOHSdDtx6k4Bu+EKlII3NHzA4PsAwq2CD49XtpE XrkDl1qSiz1mV6JpFrK+diOIT3nMn11+OhT55PyIgmq1HaI= X-Google-Smtp-Source: AGHT+IHqeTRKufFt8cEhxLevuuCtdRSMuyzhIYgi09W7tjNbeOFtYq5EqoFYr950uDMXpG9i4BGtrLhQiqzWvQFoSPQ= X-Received: by 2002:a05:6512:3c96:b0:50b:c50c:dbc4 with SMTP id h22-20020a0565123c9600b0050bc50cdbc4mr227639lfv.0.1702046366069; Fri, 08 Dec 2023 06:39:26 -0800 (PST) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:275781 Archived-At: --0000000000000a7961060c008de8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Is a "closed buffer" a "killed buffer"? Indeed. So the feature request would be to keep killed buffers as options to switch to, the idea being that buffers recently used are more likely to be opened than other buffers. The same idea motivates the recentf feature request, the difference being that recent buffers might mean buffers that were opened on a previous Emacs run. This latter feature seems to subsume the former, but I don't know how the actual implementation goes since I use fido-mode =E2=80=94 I just felt like= it would be nice to have recent files and buffers as completion candidates to commands like find-file and switch-to-buffer. Expanding on this, when I am working on a project, I just use project-find-file to find files that are not in the same directory my current buffer is in faster. But if I want to edit a configuration file somewhere, or a file in /tmp, it takes longer to find it, which is something I'm hoping this feature will help alleviate. > Maybe this feature (and also the preceding one, I guess) could be > argued for in terms of changes to Emacs's completion frontend > so that it is available to fido, icomplete, vanilla completion, > and maybe more. Yes, that makes sense to me. > So including files in a buffer list? Seems odd, but then ido had a lot of oddities. > So, if I were to work on something for Fido, it would be that > feature (which, importantly, doesn't mix buffers with files in > the same bag). It is indeed. The feature you describe would make me happy; if I killed the buffer for a file I wouldn't mind find-file'ing the file again if I had this feature to help. On Fri, 8 Dec 2023 at 10:23, Jo=C3=A3o T=C3=A1vora w= rote: > On Fri, Dec 8, 2023 at 12:29=E2=80=AFPM Dmitry Gutov w= rote: > > > > On 08/12/2023 13:27, Jo=C3=A3o T=C3=A1vora wrote: > > >> Also somewhat relevant, from the same question: > > >> > > >>> Is there a way to get recentf entries to be appended after the open > > >>> buffers when I call switch-to-buffer using fido-vertical-mode? > > >> I'm not the OP but I was in need of much the same functionality. > > > Maybe this feature (and also the preceding one, I guess) could be > > > argued for in terms of changes to Emacs's completion frontend > > > so that it is available to fido, icomplete, vanilla completion, > > > and maybe more. But I don't understand exactly what the > > > feature does (though here it seems simpler than in the previous > > > one). > > > > It's the same feature. > > > > I think ido-use-virtual-buffers's docstring has a good explanation. > > > > So, two parts: > > > > - Using entries from recentf in the list of buffers to switch to. > > - Color them differently somehow. > > So including files in a buffer list? Seems odd, but then ido > had a lot of oddities. > > Anyway, I think what I miss most about Ido also solves the > problem of going to recently visited files. In Ido, I could > ido-find-file, type a fragment of a file name and then M-p to > cycle between those old files that match that pattern > > In vanilla completion, icomplete, etc (and this includes fido-mode), > M-p doesn't do this search. The workflow for this appears to be M-r > for previous-matching-history-element but that asks me to input > a regexp, which is not necessarily the completion style I have > configured. Even when I do that, it doesn't seem to work very well, > doesn't seem to go into the recentf list, or at least is confusing > enough that I don't bother trying it. But I still miss that feature > after many years away from Ido. > > So, if I were to work on something for Fido, it would be that > feature (which, importantly, doesn't mix buffers with files in > the same bag). > > Jo=C3=A3o > --0000000000000a7961060c008de8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Is a= "closed buffer" a "killed buffer"?

Indeed. So the feature request would be to keep killed buffers as options to=20 switch to, the idea being that buffers recently used are more likely to=20 be opened than other buffers. The same idea motivates the recentf=20 feature request, the difference being that recent buffers might mean=20 buffers that were opened on a previous Emacs run.=C2=A0

This latter feature seems to subsume the former, but I don't know how the= =20 actual implementation goes since I use fido-mode =E2=80=94 I just felt like= it=20 would be nice to have recent files and buffers as completion candidates=20 to commands like find-file and switch-to-buffer. Expanding on this, when I am working on a project, I just use project-find-file to find files=20 that are not in the same directory my current buffer is in faster. But=20 if I want to edit a configuration file somewhere, or a file in /tmp, it=20 takes longer to find it, which is something I'm hoping this feature wil= l help alleviate.

= > Maybe this feature (and also the preceding one, I guess) could be
&= gt; argued for in terms of changes to Emacs's completion frontend
> so that it is available to fido, icomplete, vanilla completion,
> and maybe more.

Yes, that makes se= nse to me.

>= ; So including files in a buffer list?=C2=A0 Seems odd, but then ido had a = lot of oddities.

> So, if I were to work = on something for Fido, it would be that
> feature (which, importantly, doesn't mix buffers with files in
> the same bag).

It is indeed. The feature you describe would make me happy; if I killed=20 the buffer for a file I wouldn't mind find-file'ing the file again = if I=20 had this feature to help.

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, 8 Dec 2023 at 10:23, Jo=C3=A3o= T=C3=A1vora <joaotavora@gmail.c= om> wrote:
dmitry@gutov.dev> wrote:
>
> On 08/12/2023 13:27, Jo=C3=A3o T=C3=A1vora wrote:
> >> Also somewhat relevant, from the same question:
> >>
> >>> Is there a way to get recentf entries to be appended afte= r the open
> >>> buffers when I call switch-to-buffer using fido-vertical-= mode?
> >> I'm not the OP but I was in need of much the same functio= nality.
> > Maybe this feature (and also the preceding one, I guess) could be=
> > argued for in terms of changes to Emacs's completion frontend=
> > so that it is available to fido, icomplete, vanilla completion, > > and maybe more.=C2=A0 But I don't understand exactly what the=
> > feature does (though here it seems simpler than in the previous > > one).
>
> It's the same feature.
>
> I think ido-use-virtual-buffers's docstring has a good explanation= .
>
> So, two parts:
>
> - Using entries from recentf in the list of buffers to switch to.
> - Color them differently somehow.

So including files in a buffer list?=C2=A0 Seems odd, but then ido
had a lot of oddities.

Anyway, I think what I miss most about Ido also solves the
problem of going to recently visited files.=C2=A0 In Ido, I could
ido-find-file, type a fragment of a file name and then M-p to
cycle between those old files that match that pattern

In vanilla completion, icomplete, etc (and this includes fido-mode),
M-p doesn't do this search.=C2=A0 The workflow for this appears to be M= -r
for previous-matching-history-element but that asks me to input
a regexp, which is not necessarily the completion style I have
configured.=C2=A0 Even when I do that, it doesn't seem to work very wel= l,
doesn't seem to go into the recentf list, or at least is confusing
enough that I don't bother trying it.=C2=A0 But I still miss that featu= re
after many years away from Ido.

So, if I were to work on something for Fido, it would be that
feature (which, importantly, doesn't mix buffers with files in
the same bag).

Jo=C3=A3o
--0000000000000a7961060c008de8--