VIM, Windows, quickfix — борьба с кодировкой компилятора

[beresovskiy]

Статья — лучшее подтверждение тому, что всё — от средств компиляции до комментариев в программе должно быть на английском языке.

[int_index]

«Должно быть» — это где-то в идеальном мире, а в нем все уже перешли на Юникод.

[RomeoGolf]

Комментарии на русском — требование заказчика. Компилятор — данность неизбежная. А работать надо.

[amarao]

Я, наверное, буду очень наивен.

Но на рынке железа есть единичные НЖМД с ёмкостью 4*10¹² байт. Неужели в этих условиях нет возможности использовать многобайтовые кодировки unicode? 16-битные, 32-битные, uft-8, uft-16? Неужели экономия на спичках того стоит?

[qw1]

1. Возможно, компилятор чудесного ассемблера написан в 90-е или вообще под ДОС.
2. Возможно, компилятор написан на Cи, у которого с юникодом нехорошо под Windows.
Поясню: строки во многих функциях, например fopen, однобайтовые (utf-16 версия _wfopen — нестандартное расширение MS). Чтобы подружить Си с юникодом, остаётся использовать utf-8 (что в linux и практикуется), однако текстовая консоль Windows почему-то принципиально не хочет поддерживать utf-8, оставляя выбор между utf-16 и любой не-юникодной кодировкой.

[amarao]

cygwin? Любая другая консольная среда, которая не страдает синдромом windows? Я имею в виду, синдром windows-1252, 1251, etc.

[qw1]

Такой софт будет сложнее продать пользователям Windows. Придётся оказывать поддержку с настройкой терминала. Видимо, дешевле в OEM-кодировке оставаться. Ну, или сразу писать софт в unicode с использованием Microsoft-specific функций.

[amarao]

кому какое дело из пользователей, что используется при разработке ПО? На выходе-то там обыкновенный исполняемый файл. А консоль в виндах сто лет юникодная, если ConsoleWriteW использовать, а не *A.

Короче, героическое преодоление грабель, которому научили авторов в юности, которое они сейчас мужественно стараются воспроизвести.

[RomeoGolf]

Иногда огромное дело пользователям, что используется. В моем случае пользователь==заказчик, и кое-что пишет в ТЗ, это раз. А два — чтобы сделать «обыкновенный исполняемый файл» для именно этого процессора существует единственный компилятор от производителя процессора. И менять процессор только из-за локали — смешно, ему нет аналогов.

Не думайте, пожалуйста, что это грабли ради преодоления.

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

[amarao]

ОК, ситуация ясна. Страшное легаси, без которого никак. Да, такое бывает.

[qw1]

Консоль — это только половина беды. Туда же и CreateFileW, и т.п… А-общем, отказ от stdlib в пользу Win32 API

[RomeoGolf]

А можно уточнить, какая связь между НЖМД на много байт, многобайтовыми кодировками и чужим компилятором? Я, честно, не понял.

[amarao]

Это был такой невинный вброс на тему, что надо прекращать работать с однобайтовыми кодировками. Навсегда.

[ZyXI]

Менять настройку encoding где бы то ни было после того, как куда‐либо в память Vim попала хотя бы одна не‐ASCII строка — нельзя. Это написано прямо в справке: второй абзац :h 'encoding'.

Удивительно, что при наличии настроек для кодировки файла, терминала, вывода на печать и внутреннего представления, нет отдельной настройки для кодировки окружения.

И, кстати, не используйте set для установки сложных значений. Есть let:

let &l:makeprg='c:\bin\make.exe $* | c:\bin\iconv\iconv.exe -c -f CP866 -t CP1251'

[mayorovp]

Лично я бы исправил make-файл, а не настройки vim. Почему? Потому что это в дальнейшем позволит разрулить ситуацию, когда из одного и того же make-файла вызываются два компилятора, один из которых пишет в консоль в cp-866, а второй — в windows-1251.

[RomeoGolf]

Тогда, если я запускаю make в консоли, а не в VIM (например, на чужом компьютере), надо сначала научить консоль (на чужом компьютере) выводить в cp1251. Или использовать разные Makefile.

[mayorovp]

Или использовать разные переменные окружения.

PS научить консоль выводить в cp1251 просто — chcp 1251. Другое дело, что очень мало программ с таким режимом совместимы (впрочем, для других он, наоборот, единственный).

[qw1]

Сейчас попробовал: chcp на перенаправление в файл не действует.
А это значит, IDE, вызывая «make.exe > build.log», будет всё время получать лог в кодировке 866, независимо от chcp.

Также пожелание amarao — писать всё в юникоде — не поможет.
Командный интерпретатор весь юникодный вывод сконвертирует в 866 при записи в лог-файл.

[mayorovp]

Разумеется, chcp не действует. Это был совет на случай, когда вызов iconv будет включен в make-файл, а кто-то захочет запустить make из консоли.

[Sap_ru]

а разве этот лог нельзя сразу конвертировать?

[qw1]

Собственно, это решение, предложенное автором статьи, которое здесь объявили костыльным.

[RomeoGolf]

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

Я всего лишь пытался показать, что иногда приходится использовать некий фильтр между командой типа :make и выдачей результатов пользователю. Некий фильтр, например, перекодировку. И что можно найти (или написать) утилиту и вставить ее в соответствующее место. Когда я рылся в интернетах, не нашел такого решения нигде ни разу, по крайней мере, под Windows (в Linux цепочки утилит — норма). Решил сам, внимательно перечитав справку. Мне случайно подумалось, что подобная задача может интересовать не только меня, и предложил решение. Как бы, количество байтов в кодировке вообще ни при чем.

[mayorovp]

По поводу переменных окружения: никто не мешает настроить их на своем компе, или в vim (я не знаю, как, просто идея такая появилась).

PS я с вами не спорю, просто предлагаю альтернативные варианты.