[Comm] LyX

[Alexej Kryukov]

On Wednesday 10 September 2003 23:39, DM wrote:
> Hello, Alexej!
>
> LyX в ALTовских дистрибутивах ставится из rpm. У rpm есть пре- и
> пост- скрипты. Почему не сделать там динамическую генерацию
> _одной_строки_ при установке пакета? Это один вариант. Второй:
> почему не сделать отдельные пакеты lyx-ru-1251, lyx-ru-koi8,
> таким образом, чтобы их нельзя было установить одновременно и
> обязательно требовался один из них? А в этих пакетах хранить
> файлы настроек с нужной кодировкой? Почему, наконец, просто не
> впихнуть файл ~/lyx/preferences в скелетоны домашних каталогов
> пользователя, которые есть в разных кодировках? Не столь уж много
> места он занимает. Конечно, если пользователь будет переключать
> локали, LyX запутается. Но много ли таких пользователей?

Не столько preferences, сколько ~/.lyx/languages. Вероятно, так можно
сделать, но это, как я понимаю, уже вопрос к Виталию Липатову.
И это, конечно, потребует включения именно сборки с qt в 
базовый дистрибутив -- на xforms правка файла languages мало что
даст.

> > Не верю. Программе-то как раз очень просто вместо подлинного
> > LaTeX оперировать каким-то его сечением, а для части своих
> > внутренних функций определить новые команды.
>
> Уточнение: для тех функций, которые не охватываются LaTeX. А их
> очень немного :-)

То-то и оно, что их немного. А может возникнуть искушение
определить новые команды просто из-за неумения пользоваться
стандартными пакетами (пример чему как раз TeXmacs, см. ниже). Как
только мы примем курс на создание подключаемого файла, от
такого искушения очень трудно будет удержаться :-)

> И ещё момент: для представления того, что не охватывается целевым
> форматом, в программировании давно есть метод, которым пользуются
> разного рода IDE с кодогенерацией. Там дополнительные данные
> просто записываются в комментарии. Кто мешает делать это здесь?

Не понял. Причем здесь это? Ведь документ всё равно будет 
прогоняться через latex. Специальные комментарии могли бы служить
разве что для управления визуальным отображением документа в 
редакторе.

> > Видели Вы
> > когда-нибудь LaTeX-код, генерируемый TeXmacs?
>
> Не сподобился. У меня с emacs'ом сложные отношения. Не просекаю я
> его красоты и привлекательности и стараюсь поэтому не
> использовать.

Не-е-ет. TeXmacs -- это совершенно особый текстовый процессор, к emacs
отношения не имеющий. Родной формат у него основан на SGML, но есть
возможность экспорта в LaTeX, причем в преамбуле сгенерированных
таким образом файлов загружается специальный пакет TeXmacs.sty.
Вот о нем-то и речь. Там, например, определяется команда
\SelectRussian, которая содержит определения вида

  \defА{\CYRA}\defа{\cyra}%
  \defБ{\CYRB}\defб{\cyrb}%

и т. д. (Все 8-битные символы предварительно сделаны активными --
не правда ли, офигительный способ их преобразования в кириллические
текстовые команды?) Дальше идут определения для стандартных строк:

  \renewcommand{\ProofText}{Доказательство}%
  \renewcommand{\AxiomText}{Аксиома}%

и т. д. Аналогичные команды для других языков -- и всё это, как
видите, исключительно от неумения пользоваться Бабелем и его
командами. Вот это я и называю костылями.

> Костылей в виде файла, который подлючён? Так что ж в этом
> страшного? Если мне для компиляции программы кроме gcc
> потребуется ещё и glibc, то это более чем естественно.

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

> > Задача же в том, чтобы генерировать код, по возможности
> > неотличимый от рукотворного. А это сложно.
>
> Я бы сказал, что это невозможно. Но если действительно стоит
> такая цель, то она явно не достигается. Экспортированные из LyX
> файлы я, помнится, долгонько дорабатывал напильником. А сам

Это невозможно лишь потому, что у всякого свое представление
о правильности кода. Привести же документ к некоему усредненно-
"правильному" виду вполне осуществимо.

> LyX-формат по читабельности, ИМХО, гораздо хуже не только
> рукотворного, но и генерённого LyX'ом LaTeX-кода. Именно в силу
> многочисленных переключений, длинных и неудобоваримых ключевых
> слов... Например, слово в кавычках превращается в три(!) абзаца

Я не знаю, почему было так важно обеспечить вставку возврата
строки после каждой команды, но зато убежден, что это уж точно
лучше, чем форматирование всего документа в одну длинную строку
(как в OOo).

> --- открывающиеся кавычки, само слово, закрывающиеся кавычки. Чем
> вызвана необходимость этого? Кому мешали "< "> << >>?

Необходимость вызвана тем, что лигатуры не универсальны, а бабелевские
shorthands введены не от хорошей жизни. Тем, что стиль кавычек может
различаться в зависимости от языка, и потому удобно иметь универсальную
команду, настраиваемую на все случаи жизни. И, наконец, тем, что
символы <> всё равно пришлось бы обрамлять довольно сложными
конструкциями во избежание их интерпретации как \textless{}
\textgreater{}.

> Немножко не так. Не "старались сделать правильным" а
> "использовали общее решение, основанное на технологии,
> значительно превосходящей своими возможностями их потребности, а
> потому в данном случае неизбежно избыточной". XML и стандартный
> упаковщик, то бишь. А лишней информации там нет. Зато: удобно

Ну, если нижеследующий фрагмент не содержит лишней информации,
то я готов съесть свою шляпу :-)

<text:span text:style-name="T4"> П</text:span><text:span
text:style-name="T4">о</text:span><text:span
text:style-name="T4">зд</text:span><text:span
text:style-name="T4">н</text:span><text:span
text:style-name="T4">ее</text:span><text:span
text:style-name="T9">,</text:span><text:span text:style-name="T4">
оз</text:span><text:span text:style-name="T4">н</text:span><text:span
text:style-name="T4">ак</text:span><text:span
text:style-name="T4">о</text:span><text:span
text:style-name="T4">мив</text:span><text:span
text:style-name="T4">ш</text:span><text:span
text:style-name="T4">ись</text:span>

Это результат работы перекодировщика, который менял символы Latin1
на кириллицу и одновременно применял к ним форматирование (Times New
Roman вместо Times New Roman Cyr). Сдается мне, что при этом OOo
ничего ни в каком буфере не держал :-) Но дело даже не в этом, а
в том, что это именно расплата за xml с его открывающими и 
закрывающими тегами. Подобный эффект был бы невозможен в любом формате,
где для переключения форматирования используются команды-декларации.

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

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