View Issue Details

IDProjectCategoryView StatusLast Update
0003583Far ManagerPanelpublic2018-02-27 23:19
ReporterRaistlinAssigned ToDrKnS 
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionfixed 
Platformx64OSWindowsOS Version2008 R2
Product Version3.0 
Target VersionFixed in Version3.0 
Summary0003583: Неправильная сортировка для "й"
DescriptionFar не делает различия между "и" и "й" при сортировке на панелях.
Steps To ReproduceСоздаем файлы с именами "йа" и "ии". Сортировка по расширению. Файл "ии" должен идти раньше "йа", но на деле наоборот.
TagsNo tags attached.
Build5150

Activities

zg

2018-02-19 21:15

developer   bugnote:0015973

у меня так и происходит.

shmuel

2018-02-19 21:17

developer   bugnote:0015974

> Far не делает различия между "и" и "й" при сортировке на панелях.

Это не Фар, это функция Windows API. Возможно есть какой-то флаг, на это влияющий.

shmuel

2018-02-19 21:25

developer   bugnote:0015975

В Total Commander и в Windows Explorer то же самое.

DrKnS

2018-02-20 13:02

administrator   bugnote:0015976

Фар (как и все остальные) сравнивает в контексте (т.е. всю строку), в этом случае разницы действительно нет.
Если вы хотите побуквенной сортировки - включите numeric sort или uppercase before lowercase, это их побочный эффект.

zg

2018-02-21 21:23

developer   bugnote:0015980

а почему у меня так?

Gimp-2.png (15,707 bytes)
Gimp-2.png (15,707 bytes)

shmuel

2018-02-21 21:37

developer   bugnote:0015981

Значит зависит от ещё каких-то факторов.
На моей системе йа идёт впереди ии также и при прямой сортировке по имени, причём во всех трёх вышеперечисленных файл-менеджерах.

2useven10

2018-02-22 00:46

developer   bugnote:0015982

попробуйте ёа ее, если с йа ии всё хорошо.
нагуглилось...

2useven10

2018-02-22 12:33

developer   bugnote:0015983

> Если вы хотите побуквенной сортировки - включите numeric sort
>
5149 -- numeric уже не помогает.
Так и задумано?

DrKnS

2018-02-22 13:45

administrator   bugnote:0015984

Да. Numeric sort теперь тоже многоуровнево-натуральная, если ОС позволяет.

shmuel

2018-02-22 13:51

developer   bugnote:0015985

Мне этот вопрос с "ий" и "её" как бы не досаждает, но если бы досаждал, то за 10 минут можно сделать кастомную сортировку с использованием wcscmp.

2useven10

2018-02-22 14:48

developer   bugnote:0015986

Last edited: 2018-02-22 15:01

View 2 revisions

'Натуральная' прямо скажем выглядит противоестественно.
В русской локали поведение для Ё и Й РАЗНОЕ: "Ё1" < "Е2", "Й1" > "И2"
Может дополнить единственный оставшийся побочный эффект для получения естественной сортировки
возможностью напрямую указать такую сортировку в конфиге?

Кастомная - не для всех.
И как-то у меня нет уверенности, что wcscmp даст нужное сравнение.

shmuel

2018-02-22 14:58

developer   bugnote:0015987

> Кастомная - не для всех.

Кастомная хороша тем, что решает проблему "нужного сравнения", которое разные люди понимают по-разному. Но это уже офтопик.

DrKnS

2018-02-22 15:17

administrator   bugnote:0015988

> Для русской локали поведение для Ё и Й РАЗНОЕ.

Так оно и должно быть разным, судя по вашей ссылке.

Или у нас сейчас одинаковое и это типа багрепорт?

2useven10

2018-02-22 15:59

developer   bugnote:0015989

Windows так сравнивает, да.
Но я такое сравнение правильным назвать не могу.
Не различать при сравнении строк ОБА варианта (как в английской локали) можно признать
логичным, но вести себя по-разному это какой-то бред.

Это, конечно, не баг farmanager (точнее баг не farmanager).
Это хотелка - иметь возможность получить естественную сортировку (думаю не только с моей точки зрения) с минимальными усилиями со стороны пользователя.

DrKnS

2018-02-22 16:16

administrator   bugnote:0015990

Shmuel, а у нас сейчас можно только кастомный критерий сортировки задать или базовую функцию типа strcmp(s1,s2), которая будет использоваться стандартными критериями, тоже можно?

2useven10

2018-02-22 16:29

developer   bugnote:0015991

Last edited: 2018-02-22 17:11

View 3 revisions

wcscmp - сортирует также как система (ожидаемо). как CompareStringOrdinal ("ё" > "я").
поэтому такая кастомизация ничего не даст.
нужный результат может дать принудительное (optional) включение посимвольного сравнения в farmanager.

DrKnS

2018-02-22 16:51

administrator   bugnote:0015992

Я правильно понимаю, что хочется чего-то типа:

--------------------------
string sorting method:
 (*) full, unicode-aware
 ( ) per char

tweaks:
 [x] numeric
 [ ] case-sensitive
--------------------------

2useven10

2018-02-22 17:13

developer   bugnote:0015993

Да. Только вместо
 full, unicode-aware
лучше
 system string sort

2useven10

2018-02-22 17:18

developer   bugnote:0015994

и не совсем понятно как совместить numeric и per char.

DrKnS

2018-02-22 17:28

administrator   bugnote:0015995

Numeric:
os >= win7: numeric может быть system, может быть per char.
os < win7: numeric только per char (если никто не напишет эмулятор system)

Case sensitive:
Для system: убирает NORM_IGNORECASE или LINGUISTIC_IGNORECASE.
Для per char: uppercase before lowercase.

shmuel

2018-02-22 17:40

developer   bugnote:0015996

DrKnS> а у нас сейчас можно только кастомный критерий сортировки задать или базовую функцию типа strcmp(s1,s2), которая будет использоваться стандартными критериями, тоже можно?

Сейчас - только кастомный, но сделать дополнительно второй вариант должно быть не сложно.

2useven10> wcscmp сортирует как CompareStringOrdinal ("ё" > "я"). поэтому такая кастомизация ничего не даст.

Ну не обязательно же wcscmp. Можно легко добавить look-up table и написать свою функцию сравнения в три строчки.

2useven10

2018-02-22 17:58

developer   bugnote:0015997

DrKnS как это отразится в коде я представляю. Просто формально посимвольность и numeric кажутся несовместимыми.

Shmuel для 33 букв алфавита кажется несложно, но добавка должна быть непротиворечива для всего unicode (ucs2) диапазона. Это уже сложнее.

shmuel

2018-02-22 18:04

developer   bugnote:0015998

2useven10> Добавка реализуется достаточно легко. Ну допустим она займёт не 10 минут времени, а час - не в этом же дело, если человеку надо.

DrKnS

2018-02-22 18:49

administrator   bugnote:0015999

> формально посимвольность и numeric кажутся несовместимыми

Формально да.
Однако, непосимвольный numeric в Far появился 18 часов назад, а посимвольный до этого был лет 15 и вроде никто не возражал.

> добавка должна быть непротиворечива для всего unicode (ucs2)

 memcmp же :)

2useven10

2018-02-25 13:53

developer   bugnote:0016000

Значит per char не всегда подходит.
Может просто System/Far string sort?

2useven10

2018-02-27 11:00

developer   bugnote:0016001

Last edited: 2018-02-27 11:04

View 2 revisions

По этому инцу DrKnS вроде как уже всё сделал.
После 5151 в системных настройках надо выбрать инвариантное сравнение,
тогда И должна быть перед Й (Е перед Ё).

PS: Не вижу разницы между ordinal и linguistic...

PPS: Uppercase before lowercase было ближе к делу чем Case sensitive.

DrKnS

2018-02-27 11:10

administrator   bugnote:0016002

linguistic - это CompareString, е вперемешку с с ё.
invariant - это посимвольно по внутренней таблице, uppercase before lowercase, е перед ё.
ordinal - это для настоящих пуристов, по номеру символа. ё после я, Ё перед А.

DrKnS

2018-02-27 11:15

administrator   bugnote:0016003

> Uppercase before lowercase было ближе к делу чем Case sensitive.

Для linguistic это было бы ложью.

2useven10

2018-02-27 11:24

developer   bugnote:0016004

>ordinal - это для настоящих пуристов, по номеру символа. ё после я, Ё перед А.
>
У меня не так (ordinal == linguistic)

2useven10

2018-02-27 11:29

developer   bugnote:0016005

Last edited: 2018-02-27 11:32

View 3 revisions

Уточнение: не так если [ ] Case sensitive.

2useven10

2018-02-27 11:51

developer   bugnote:0016006

>> Uppercase before lowercase было ближе к делу чем Case sensitive.
>Для linguistic это было бы ложью.

[x] Case sensitive - неичего не меняет для linguistic (по карайней мер я этого не вижу).
Т.е. это тоже ложь.
В таком случае луше как было и для linguistic эту опцию отключать.

DrKnS

2018-02-27 15:03

administrator   bugnote:0016008

> [x] Case sensitive - неичего не меняет для linguistic
lua:Menu.Show("abc\nAbc\naBc\nabC\nABc\naBC\naBC\nAbC\nABC", "", 0x20)

> В таком случае луше как было и для linguistic эту опцию отключать
"давайте запретим всё, что непонятно", да.

2useven10

2018-02-27 16:25

developer   bugnote:0016009

>"давайте запретим всё, что непонятно", да.

Давайте не будем передёргивать и называть непонятно что 'Case sensitive'.
Достаточно посмотреть как linguistic/Case sensitive отсортирует файлы:
ab_3 aB_2 Ab_1 AB_0, чтобы понять что название совершенно неуместно.

И не увидел ответа про Ordinal без Case sensitive.

2useven10

2018-02-27 16:28

developer   bugnote:0016010

Last edited: 2018-02-27 16:40

View 3 revisions

И да на мой взгляд из linguistic имеет смысл оставить только то что сейчас linguistic+ case sensitive.
Без этого результат сортировки одинаковых по составу списков будет зависеть от их начального расположения. В зачеркнутом не уверен.

DrKnS

2018-02-27 17:04

administrator   bugnote:0016012

> Достаточно посмотреть как linguistic/Case sensitive отсортирует файлы
Точно так же как и insensitive, т.к. регистр - далеко не первый уровень сравнения и здесь ни на что не влияет. Если предыдущие уровни совпали (см. выше) - будет влиять. Это можно учитывать, можно не учитывать, что и отражает название опции. Это не "вообще все uppercase вначале", нет.

> Ordinal без Case sensitive.
Это upper(a) - upper(b).
ё < а, потому что int(L'Ё') < int(L'А').

И да, на всякий случай - я ничего не убрал:
Linguistic [][] - это как раньше по умолчанию.
Invariant [x][] - это как раньше numeric.
Invariant [][x] - это как раньше uppercase first.
Invariant [x][x] - это как раньше numeric + uppercase first.

Остальные 8 сочетаний - новые.

2useven10

2018-02-27 17:26

developer   bugnote:0016014

Last edited: 2018-02-27 17:38

View 3 revisions

Только моё мнение...
Термин CaseSensitive запутывающий, все 12 сочетаний вряд ли нужны, достаточно:

==================================================================
( ) Ordinal = Ordinal + CaseSensitive (в терминах текущего момента)
( ) Uppercase first = Invariant + CaseSensitive
( ) Invariant
(*) Linguistic = Linguistic + CaseSensitive
===================================================================
[x] Numeric

Всего 8 вариантов.

DrKnS

2018-02-27 21:53

administrator   bugnote:0016017

> все 12 сочетаний вряд ли нужны

Ну вроде бы никто не заставляет пользоваться, если не нужны.

2useven10

2018-02-27 22:29

developer   bugnote:0016018

Конечно нет.
Но при этом у всех будут бесполезные и непонятные режимы сортировки, с успешно запутанными названиями.
И соответствующие вопросы.

DrKnS

2018-02-27 22:33

administrator   bugnote:0016019

> бесполезные

Если вы не видите применения CaseInsensitive - это ещё не значит, что его нет.

Отсортируйте по расширению a.TXT и z.txt, например.

2useven10

2018-02-27 23:19

developer   bugnote:0016020

Хороший аргумент - 4-й пункт Linguistic (при большом желании можно его раздвоить).
Но никак не отдельная опция [x] Case sensitive, применяемая по-разному к 3 разным типам.

Issue History

Date Modified Username Field Change
2018-02-19 21:03 Raistlin New Issue
2018-02-19 21:15 zg Note Added: 0015973
2018-02-19 21:17 shmuel Note Added: 0015974
2018-02-19 21:25 shmuel Note Added: 0015975
2018-02-20 13:02 DrKnS Note Added: 0015976
2018-02-21 21:23 zg File Added: Gimp-2.png
2018-02-21 21:23 zg Note Added: 0015980
2018-02-21 21:37 shmuel Note Added: 0015981
2018-02-22 00:46 2useven10 Note Added: 0015982
2018-02-22 12:33 2useven10 Note Added: 0015983
2018-02-22 13:45 DrKnS Note Added: 0015984
2018-02-22 13:51 shmuel Note Added: 0015985
2018-02-22 14:48 2useven10 Note Added: 0015986
2018-02-22 14:58 shmuel Note Added: 0015987
2018-02-22 15:01 2useven10 Note Edited: 0015986 View Revisions
2018-02-22 15:17 DrKnS Note Added: 0015988
2018-02-22 15:59 2useven10 Note Added: 0015989
2018-02-22 16:16 DrKnS Note Added: 0015990
2018-02-22 16:29 2useven10 Note Added: 0015991
2018-02-22 16:29 2useven10 Note Edited: 0015991 View Revisions
2018-02-22 16:51 DrKnS Note Added: 0015992
2018-02-22 17:11 2useven10 Note Edited: 0015991 View Revisions
2018-02-22 17:13 2useven10 Note Added: 0015993
2018-02-22 17:18 2useven10 Note Added: 0015994
2018-02-22 17:28 DrKnS Note Added: 0015995
2018-02-22 17:40 shmuel Note Added: 0015996
2018-02-22 17:58 2useven10 Note Added: 0015997
2018-02-22 18:04 shmuel Note Added: 0015998
2018-02-22 18:49 DrKnS Note Added: 0015999
2018-02-25 13:53 2useven10 Note Added: 0016000
2018-02-27 11:00 2useven10 Note Added: 0016001
2018-02-27 11:04 2useven10 Note Edited: 0016001 View Revisions
2018-02-27 11:10 DrKnS Note Added: 0016002
2018-02-27 11:15 DrKnS Note Added: 0016003
2018-02-27 11:24 2useven10 Note Added: 0016004
2018-02-27 11:29 2useven10 Note Added: 0016005
2018-02-27 11:30 2useven10 Note Edited: 0016005 View Revisions
2018-02-27 11:32 2useven10 Note Edited: 0016005 View Revisions
2018-02-27 11:51 2useven10 Note Added: 0016006
2018-02-27 15:03 DrKnS Note Added: 0016008
2018-02-27 15:04 DrKnS Assigned To => DrKnS
2018-02-27 15:04 DrKnS Status new => closed
2018-02-27 15:04 DrKnS Resolution open => fixed
2018-02-27 15:04 DrKnS Fixed in Version => 3.0
2018-02-27 15:04 DrKnS Build => 5150
2018-02-27 16:25 2useven10 Status closed => assigned
2018-02-27 16:25 2useven10 Note Added: 0016009
2018-02-27 16:28 2useven10 Note Added: 0016010
2018-02-27 16:39 2useven10 Note Edited: 0016010 View Revisions
2018-02-27 16:40 2useven10 Note Edited: 0016010 View Revisions
2018-02-27 17:04 DrKnS Note Added: 0016012
2018-02-27 17:26 2useven10 Note Added: 0016014
2018-02-27 17:37 2useven10 Note Edited: 0016014 View Revisions
2018-02-27 17:38 2useven10 Note Edited: 0016014 View Revisions
2018-02-27 21:53 DrKnS Note Added: 0016017
2018-02-27 22:29 2useven10 Note Added: 0016018
2018-02-27 22:33 DrKnS Note Added: 0016019
2018-02-27 23:19 2useven10 Note Added: 0016020