Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make use of helm-buffers-sort-transformer customizable #763

Closed
Fuco1 opened this issue Dec 16, 2014 · 8 comments
Closed

Make use of helm-buffers-sort-transformer customizable #763

Fuco1 opened this issue Dec 16, 2014 · 8 comments
Labels

Comments

@Fuco1
Copy link

Fuco1 commented Dec 16, 2014

With no narrowing, helm-buffers-list lists the buffers in LRU order. However, as soon as I narrow, it sorts them by buffer name length. I consider this an anti-feature: I usually want to jump to the least recently used, not to the shortest buffer matching a pattern.

Is there any reason at all to re-sort the candidates?

@thierryvolpiatto
Copy link
Member

Matus Goljer notifications@github.com writes:

Is there any reason at all to re-sort the candidates?

Because I think this is really handy.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

@Fuco1
Copy link
Author

Fuco1 commented Dec 16, 2014

Can you explain the reasoning? I don't see any advantage in bringing buffers with short names to the front, they are no more relevant to the search query than any other buffer. Recently used buffers, however, are relevant because they are being used and they should be accessed in the fastest way possible.

@tuhdo
Copy link
Contributor

tuhdo commented Dec 17, 2014

@Fuco1 I think it is because it is used for simple ranking. The shortest candidates have the highest match to the provided Helm patterns. Since helm-buffers-list can do fuzzy matching, such ranking is relevant. However I agree with you that we should leave the buffer ordering intact with most recently used buffers at the top. No sorting, only filtering.

@thierryvolpiatto probably we can have an option to disable buffer sorting and leave the order as it is?

@thierryvolpiatto
Copy link
Member

Matus Goljer notifications@github.com writes:

Can you explain the reasoning? I don't see any advantage in bringing
buffers with short names to the front, they are no more relevant to
the search query than any other buffer. Recently used buffers,
however, are relevant because they are being used and they should be
accessed in the fastest way possible.

Your more recent buffers are on top at startup, if you search a buffer,
it is because it is not on top, and the search is regexp based, I don't
see why we should sort by recent usage, i.e if I type helm in pattern I
want helm.el popup on top, not the helm-something.el buffer I used 10mn
ago and I have finished with it.
For your particular usage, (It seem you don't like helm-buffers-list) I
suggest you turn on helm-mode on and use C-x b.

You can consider this as Wontfix.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

@Yevgnen
Copy link

Yevgnen commented Aug 15, 2016

I think when one use helm-recentf, he may want to find the most recent file that contains the prefix he typed. At least for helm-recentf. For other commands like helm-find-files, the matching of the pattern is more important, of course.

#1507

CeleritasCelery pushed a commit to CeleritasCelery/helm that referenced this issue Dec 31, 2018
At init helm, buffers are ordered by recency, However after we begin to
narrow down to select a candidate, the buffers change to being sorted
by length. This is nonsensical because more often then not we are
looking for the most recent buffer matching the pattern, not the
shortest. See emacs-helm#763 for details.
CeleritasCelery added a commit to CeleritasCelery/helm that referenced this issue Jan 1, 2019
At init helm, buffers are ordered by recency, However after we begin to
narrow down to select a candidate, the buffers change to being sorted
by length. This is nonsensical because more often then not we are
looking for the most recent buffer matching the pattern, not the
shortest. See emacs-helm#763 for details.
CeleritasCelery added a commit to CeleritasCelery/helm that referenced this issue Jan 31, 2019
At init helm, buffers are ordered by recency, However after we begin to
narrow down to select a candidate, the buffers change to being sorted
by length. This is nonsensical because more often then not we are
looking for the most recent buffer matching the pattern, not the
shortest. See emacs-helm#763 for details.
bgwines referenced this issue in bgwines/doom-config Jul 13, 2020
@fred-apex-ai
Copy link

fred-apex-ai commented Jan 23, 2024

I stumbled across this old issue today. The behavior I see today is that helm-recentf behaves like helm-buffers-list was described above but for files only. In spacemacs, I most often use list-buffers which has an initial sort order that is neither lexical nor LRU, and it's the same output for helm-buffers-list

@thierryvolpiatto
Copy link
Member

thierryvolpiatto commented Jan 23, 2024 via email

@fred-apex-ai
Copy link

@thierryvolpiatto I noticed what the root cause is. I have multiple emacs frames, and helm-buffers-list tries to be clever and omits the buffers that open in other frames. With a single frame, the results are initially sorted according to LRU, then lexical when entering characters. And all non-visible buffers are present.

The fix you mention indeed helps, but as the name suggests, only when there is a tie between matches, which doesn't happen so often. Thank you for the quick answer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants