unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: bcclaro <bcclaro@gmail.com>
To: 67691@debbugs.gnu.org
Subject: bug#67691: 29.1.50; Virtual buffers in fido-mode
Date: Fri, 8 Dec 2023 11:38:49 -0300	[thread overview]
Message-ID: <CAPWro-iP2o0L+XXo+iy5yd236B854LVnXqFRu4GVAi=CE1QrDw@mail.gmail.com> (raw)
In-Reply-To: <CALDnm53BhGCYGBbVDJis5DAmcpHQqoo0AcDwjOTK0NvfdDRqWw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3804 bytes --]

> 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 — 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ão Távora <joaotavora@gmail.com> wrote:

> On Fri, Dec 8, 2023 at 12:29 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> > On 08/12/2023 13:27, João Távora 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ão
>

[-- Attachment #2: Type: text/html, Size: 6004 bytes --]

      parent reply	other threads:[~2023-12-08 14:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 15:19 bug#67691: 29.1.50; Virtual buffers in fido-mode bcclaro
2023-12-08 11:27 ` João Távora
2023-12-08 12:29   ` Dmitry Gutov
2023-12-08 13:22     ` João Távora
2023-12-08 14:07       ` Dmitry Gutov
2023-12-08 14:38       ` bcclaro [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPWro-iP2o0L+XXo+iy5yd236B854LVnXqFRu4GVAi=CE1QrDw@mail.gmail.com' \
    --to=bcclaro@gmail.com \
    --cc=67691@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).