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 · 5 comments
Closed

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

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

Comments

@Fuco1
Copy link

@Fuco1 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

@thierryvolpiatto thierryvolpiatto commented Dec 16, 2014

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 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 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

@thierryvolpiatto thierryvolpiatto commented Dec 17, 2014

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 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants