AkelPad

Зачем гадать, сохраняй всё всегда в utf8. Однобайтовые кодировки - реликт, их надо изживать

Не надо изживать. Как тогда фиксить исходники софта 20-летней давности, написанные и откомментированные в TurboC на OEM кодировках типа 866?
Пока ANSI окончательно не развалится, однобайтовые кодировки будут жить и жить.

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

Fr0sT,

Зачем гадать, сохраняй всё всегда в utf8.

Если так поступать с конфигами и локалями, как минимум до добра не доведёт .

Однобайтовые кодировки - реликт, их надо изживать

Если уж и изживать, то utf-8, вряд-ли понравится пишущим на иероглифах (из-за увеличения в разы исходного документа). Если учитывать численное количество таких пользователей, тогда уж изживать юникодом что ли.

Fr0sT
Ну тут плагин ни при чем Я в ничьи настройки не вмешиваюсь.
Deim0s
UTF-8 - одна из полностью покрывающих Юникод кодировок, между прочим самая экономная. А японцы/китайцы и прочие пикграммо-писцы если захотят чтобы их понимали буду сохранять в понятной кодировке.(В крайнем случае японцам для большинства целей и однобайтной кодировки хватит)

FeyFre,

...между прочим самая экономная.

Как же она может быть самая экономная, когда максимальный размер символа в UTF-8 четыре байта (как раз заковыристые иероглифы, вязь и подобные), а в юникоде (UTF-16LE) любой символ занимает два байта. При определённом раскладе, документ в ANSI/OEM 1Мб в юникоде будет не более 2Мб, а в UTF-8 до 4 Мб. Не вдаваясь в детали, попробуйте "крючки" сохранить в UTF-8 и UTF-16LE и сравнить размер файла.

А японцы/китайцы и прочие пикграммо-писцы если захотят чтобы их понимали буду сохранять в понятной кодировке.

Дело совсем не в этом, конфиги и локали "ихние" программы, как правило понимают исключительно в UTF-16LE, в UTF-8 нет. А хороших программ "у них есть". Тут подстраиваться они не под кого не будут.

FeyFre
да к плагину никаких претензий, я Деймосу объяснял, как не париться с кодировками)
Deim0s
ну раз у тебя специфичные требования, тогда просто установи себе дефолтную кодировку utf16. Плагин в самом деле к кодировкам никаким боком не относится.

Как же она может быть самая экономная, когда максимальный размер символа в UTF-8 четыре байта (как раз заковыристые иероглифы, вязь и подобные)

Загляните в спецификацию Юникод и убедитесь:
UTF-8 - специфицирован так, что символ может иметь длину от одного до 6 байт. Причем случаи 5 и 6 байт не встречаются по определению ибо им нету соответствия в Юникод стандарте.(Японский/Китайский/Корейский кодируются тремя)
UTF-16 - специфицирована так, что символы могут быть приставлены только двумя и четырьмя байтами.
Теперь возьмем в равной мере все языки мира(одинаковое количество знаков) и подсчитаем длину в UTF-8 и в URF-16. Кто победит?

Ах, да, ещё не забудьте что UTF-8 очень удобно спроектирован с точки зрения устойчивости к ошибкам, и очень даже не плохо дружит с аппаратными алгоритмами обработки массивов символов.

FeyFre,

Загляните в спецификацию Юникод и убедитесь:

Да часто заглядываю туда, ни какого удовольствия .

UTF-16 - специфицирована так, что символы могут быть приставлены только двумя и четырьмя байтами.
Теперь возьмем в равной мере все языки мира(одинаковое количество знаков) и подсчитаем длину в UTF-8 и в URF-16. Кто победит?

Я думаю победит UTF-16, т.к. вспомогательные символы (суррогатные пары, для которых в UTF-16 требуется 4 байта на символ), в UTF-8 могут обработаться как два отдельных неопределенных символа и занять 6 байт. Дальше не охота углубляться, ибо извечный спор .
А сложно вообще реализовать этот фич реквест? Если сложно то бог с ним. В принципе, для экзотики, можно в имени файла указывать кодировку для шаблона, что то вроде: China_ftp_gb2312.txt

FeyFre, ну для конкретных иероглифов Деймос прав, я проверил на китайском традиционном: 30 байт в utf16 против 43 в utf8.
Deim0s, так что мешает сделать дефолтной utf16 и не париться?

Fr0sT,
Да дефолтная кодировка здесь ни причём. Я прошу у автора возможность, открывать текст в окне AkelPad в кодировке шаблона, что бы в ней (в кодировке шаблона) и сохранять документ. Поясню на примере:
Есть программа, читающая конфиг, к примеру, только в cp1252
Есть шаблон конфига в cp1252, содержащий диакритические символы
Сейчас, при открытии, шаблон определяется и отображается правильно, но кодировка в окне AkelPad выбирается по умолчанию (у меня cp 1251), т.е. при сохранении документа (если шаблон не мой или забыл к примеру) я, или испорчу оригинал, или придётся гадать (какая диакритика cp1250 или cp1252).
То же и с иероглифами или псевдографикой cp866 и много с чем.
ИМХО если бы была возможность открывать в оригинальной кодировке шаблона (ну, конечно, по мере возможностей определения самого AkelPad), то было бы удобнее во многих ситуациях.

То есть устанавливать кодировку для документа такую же, как в шаблоне. Делается одной строчкой, насколько я понимаю, но это уже только если автор захочет. Либо просто он может сказать, что и куда добавить, а ты уже для себя соберешь плаг с этой фичей

Fr0sT wrote:что и куда добавить, а ты уже для себя соберешь плаг с этой фичей

Это изврат.
Deim0s дело предлагает. Шаблон на то и шаблон, чтобы информацию максимально обо всём содержать, в т.ч. и информацию о кодировке.

Ещё пример: файлы *.coder. Я почему-то думал, что файл создастся в той кодировке, что нижна для этих файлов, т.е. 1200... а потом приходится лазить и искать причину, почему подсветка не работает.

Гораздо проще подготовить шаблоны в нужной кодировке, чем потом париться. А если не нужно такое, то готовить все шаблоны в той кодировке, что использует AkelPad при создании нового файла.

Это изврат.

Изврат это когда ни один системный редактор(в прочим как и 99.999% сторонних) не поддерживает работу с альтернативными файловыми потоками NTFS.
Изврат это когда у файла есть три имени(хард-линки), в настройках стоит "не открывать файл дважды", но редактор всё-равно открывает его по всем трем именам сразу.
Изврат это когда файловый менеджер не в курсе что существуют мягкие ссылки, и в случае когда мягкая ссылка ссылается на одну из родительских папок рекурсивный поиск зацикливается в бесконечность.

FeyFre
Это не по теме ("космические корабли бороздят просторы Большого театра" (c)).
Изврат по теме чуть выше, это когда предлагается пересохранять каждый новый файл, вместо того, чтобы 1 раз сохранить шаблон в нужной кодировке.

VladSh
"Тема" этого плагина - заполнять документы предопределенным набором USV-значений. Что с ними потом будет делать редактор, прочие плагины, пользователь этот плагин строго говоря не касается. Никакая дополнительная мета-информация не используется.