Ctags: Универсальные теги ctags вставляют недопустимые символы `utf-8` для определенных файлов

Для меня это звучит как # 1275: новая опция pattern-length-limit обрезает произвольную позицию байта, которая оказывается в середине последовательности символов. См. # 163, # 640 и # 1018.

Что-то вроде https://github.com/universal-ctags/ctags/issues/1275#issuecomment -274489859, вероятно, должно быть реализовано, чтобы исправить это.

@ alphaCTzo7G см. # 1807, исправляет ли это правильно?

@ b4n , спасибо за быстрый ответ ...

В файле, который я разместил здесь _identifier.py , используя фиксацию # 1805, ctags больше не вставляет недопустимые символы / сокращения в произвольном месте.

Я опробую этот PR на моей реальной системе в течение следующих нескольких дней, чтобы увидеть, работает ли он для всех моих репозиториев или вызывает другие ошибки.

Поскольку ctrlp и ctrlp-py-matcher - очень популярные плагины, было бы здорово, если бы # 1807 был объединен, чтобы vim и другие пользователи текстового редактора могли использовать ctrlp и ctrlp-py-matcher не беспокоясь об этой проблеме.

Был еще один файл, который, как я обнаружил, вызывал проблемы с vim.eval , и он содержал недопустимые символы utf-8 как определено grep -axv '.*' misc.html ( misc.html в https: / /github.com/alphaCTzo7G/test). Я заметил, что ctags вставляет недействительные символы utf-8 в файл тегов из misc.html .

Имеет ли смысл для ctags обнаруживать недопустимые символы в файлах и вместо этого заменять их чем-то вроде того, что предложил здесь @tonymec ? (замените недопустимую последовательность одним или несколькими экземплярами символа (U + FFFD REPLACEMENT CHARACTER), который предназначен именно для этой цели.): https://github.com/vim/vim/issues/3213#issuecomment -405211243 ?

IIUC, ctags (я имею в виду Exuberant ctags, это только одна из доступных программ ctags) распространяется отдельно от Vim (даже если его автор знает Bram и даже если они иногда работают вместе, чтобы Vim и ctags работали лучше вместе.

С точки зрения ctags законно рассматривать текст программы как просто строку байтов: независимо от того, является ли это кодировка UTF-8, Latin1, Latin9 или какой-либо другой кодировкой ISO 8859, пробел равен 0x20, жесткая вкладка - 0x09, разрыв строки - 0x0A, возможно, ему предшествует 0x0D и т. д .; и нулевой байт, равный 0x00, не должен появляться в текстовом файле. Ctags обрабатывает каждую программу одинаково, независимо от того, в какой ASCII-совместимой кодировке она написана, и поэтому ему не нужно заботиться о том, что есть что. Только для некоторых диковинных кодировок, таких как EBCDIC, необходимо рассматривать текст как определенно не-ASCII (в EBCDIC, IIRC, AI - это 0xC1-0xC9, JR - 0xD1-0xD9, SZ - 0xE2-0xE9, 0-9 - 0xF0-0xF9. , и я не помню, каковы коды для пробела, табуляции, разрыва строки, тире, подчеркивания и т.д .; но вы видите, что с точки зрения ASCII это действительно диковинно).

ИМХО, в случае ctag действует старый добрый принцип: мусор на входе, мусор на выходе.

С наилучшими пожеланиями,
Тони.

@tonymec .. имеет смысл .. Я понимаю, что могут быть и другие программы генерации тегов, но universal-ctags является наиболее популярным, и среди людей, использующих universal-ctags я предполагаю, что большая часть это vim пользователей.

Поэтому мне интересно, могут ли эти 2 работать, или у вас есть другие идеи, как обрабатывать файлы, содержащие недопустимые символы utf-8 ?

1. Я также заметил, что в ctags есть опция +iconv , которая позволяет использовать libiconv . При использовании в командной строке iconv может удалить недопустимые символы utf8 . Поэтому мне интересно, если я передам --input-enconding=utf-8 и --output-encoding=utf-8 , тогда все недопустимые символы utf-8 будут заменены на допустимые символы utf-8 .

Это объясняется в разделе 1.3.4 https://media.readthedocs.org/pdf/ctags/latest/ctags.pdf :

Two new options have been introduced (--input-encoding=IN and --output-encoding=OUT). Using the encoding specified with these options ctags converts input from IN to OUT. ctags uses the converted strings when writing the pattern parts of each tag line. As a result the tags output is encoded in OUT encoding. In addition OUT is specified at the top the tags file as the value for the TAG_FILE_ENCODING pseudo tag. The default value of OUT is UTF-8. NOTE: Converted input is NOT passed to language parsers. The parsers still deal with input as a byte sequence. With --input-encoding-<LANG>=IN, you can specify a specific input encoding for LANG. It overrides the global default value given with --input-encoding

1. предоставьте редактору возможность обрабатывать недопустимые символы utf8 . В этом случае либо vim.eval должно быть исправлено, либо должна быть функция vimL которая может анализировать и удалять недопустимые символы utf-8 перед передачей в vim.eval ..

@ alphaCTzo7G Я согласен с @tonymec и его выводом.

К сожалению, очень сложно распознать правильную кодировку - и я настаиваю на правильности, потому что легко найти кодировку, в которой ввод был бы технически допустимым, скажем, большинство, если не все 8-битные кодировки, но зная, правильное ли это один сложен или невозможен: скажем, как можно быть уверенным между, например, ISO 8859-1 и 8859-15? Решения включают сложный эвристический анализ частоты использования и контекста; или более наивная идея, применимая к некоторым языкам, таким как HTML, заключалась бы в извлечении оператора кодировки внутри файла, но это также может быть неверным.

Кроме того, ctags здесь находится в затруднительном положении: многие, если не большинство потребителей, не обрабатывают кодировки, а сгенерированные теги должны соответствовать на уровне байтов. Например, grepping для шаблона тега или даже имени не будет преобразовывать кодировки за вас, поэтому тег должен соответствовать файлу на уровне байтов. Это было легко, когда все, о чем нам нужно было заботиться, это ASCII, но нам больше не повезло… UTF-8 не был принят достаточно рано.
Это также относится к идее замены символами-заполнителями: что потребитель может сделать с таким символом замены? По крайней мере, он должен обращаться с этим определенным образом.

Однако, если вы довольны заменой недопустимого UTF-8 на U + FFFD или их удалением, возможно, вы могли бы просто постобработать вывод ctags?

@ b4n , ценю ваш комментарий. На самом деле я имею дело в основном с файлами в кодировке utf-8 кодировку utf-8 для файлов, которые я создаю. К сожалению, как вы упомянули, я использую библиотеки, которые иногда имеют произвольные кодировки.

Я использую vim-gutentags , и он обеспечивает функцию постобработки. Хотя я мог вручную выполнить постобработку файла тегов, чтобы все файлы utf-8 символы post-processing в vim-gutentags , это не сработало. . Так что я подумал, что, может быть, лучше придумать более надежное решение ... но если его не существует, мне придется изучить его снова ...

Чтобы определить кодировку файла, не можете ли вы использовать базовые библиотеки за одним из этих параметров: https://stackoverflow.com/questions/805418/how-to-find-encoding-of-a-file-in-unix -via-scripts

например enca , file , uchardet , enguess ? Это все возможности командной строки ... но где-то должна быть какая-то библиотека, которая может быть использована внутри ctags возможно. Я предполагаю, что из-за количества кодировок, как вы упомянули, никогда не удастся точно предсказать кодировку, но простое решение, которое покрывает большую часть этого, может быть лучше, чем ничего ...

Я попробую --input-encoding (and/or --input-encoding-<LANG>) and --output-encoding options .. Не уверен, будет ли он работать все время, потому что вполне возможно, что некоторые файлы будут иметь разные кодировки в одном и том же репозитории, если только ctags вычислит исправляет кодировку индивидуально и выводит ее в желаемом формате.