Ticket #1894 (closed enhancement: fixed)
Panel Sort order "not Case Sensitive" should not mix dotfiles with others
| Reported by: | SzG | Owned by: | andrew_b |
|---|---|---|---|
| Priority: | minor | Milestone: | 4.7.5 |
| Component: | mc-core | Version: | master |
| Keywords: | Cc: | zaytsev | |
| Blocked By: | Blocking: | ||
| Branch state: | Votes for changeset: | committed-master |
Description
If the panel sort order is not case sensitive, the dotfiles (hidden) are mixed up with the others, as if the dot were not there.
I think it's confusing as dotfiles are very special.
A more user-friendly order would be dotdirs, dirs, dotfiles, files, same as with the case-sensitive order.
But the perfect solution would be dirs, files, dotdirs, dotfiles.
Change History
comment:1 in reply to: ↑ description Changed 15 years ago by andrew_b
- Priority changed from major to minor
- Type changed from defect to enhancement
comment:2 Changed 14 years ago by andrew_b
- Owner set to andrew_b
- Status changed from new to accepted
- severity changed from no branch to on review
Created 1894_sort_hidden_files branch. Parent branch is master.
changeset:ee6ad963e7179ea5dc46bbe6ab4f489b57c354d7
comment:3 Changed 14 years ago by wayfarer
Let me propose an alternative solution here.
In version 2.8 of GLib new function "g_utf8_collate_key_for_filename" was introduced, exactly for this purpose - to have correct sorting of filenames:
Unfortunately, it still doesn't consider all special chars, but at least dots are handled properly - and it's a big part of a problem. So maybe it is worth using?
It's really the collation table, which should be blamed: as far as I understand, in all locales special symbols are just ignored during collation. In C locale it works right, cause there collation order is just the same as order of standard ASCII codes.
OTOH, it's probably a right solution for general-purpose sorting to ignore special chars. But sorting of file names has its specialties. So IMHO using above mentioned function and asking GLib guys to extend it to deal with other chars would be the better solution than trying to fix collation tables.
comment:4 Changed 14 years ago by slavazanko
So IMHO using above mentioned function and asking GLib guys to extend it to deal with other chars would be the better solution than trying to fix collation tables.
Well, we've supported older version of glib 2.8 (for LTS distros). Even if GLIB-guys will fixed collation tables i don't think that they fixed glib-2.8.* branch (and all newest). They fixed just last version of glib.
comment:5 Changed 14 years ago by slavazanko
- Votes for changeset set to slavazanko
- Milestone changed from 4.7 to 4.7.5
comment:6 Changed 14 years ago by angel_il
- Votes for changeset changed from slavazanko to slavazanko angel_il
- severity changed from on review to approved
comment:7 Changed 14 years ago by andrew_b
- Status changed from accepted to testing
- Votes for changeset changed from slavazanko angel_il to committed-master
- Resolution set to fixed
- severity changed from approved to merged
Merged to master.
changeset:4aec2187e1cea62b328221354841a7052bda73dc
comment:8 Changed 14 years ago by andrew_b
- Keywords stable-candidate added; sort order, case sensitive, dotfile removed
comment:10 Changed 14 years ago by andrew_b
- Keywords stable-candidate removed
- Status changed from testing to closed
comment:11 Changed 14 years ago by SzG
Thanks!
Replying to SzG:
As ls -la does.
Some users request the ls-like behaviour (#1586).
I disagree. I prefer see hidden files/dirs first.