[Comm] LyX

[DM]

Hello, Alexej!

On Sat, 13 Sep 2003 22:14:49 +0400 You wrote:

> > Почему, наконец, просто не впихнуть файл ~/lyx/preferences в
> > скелетоны домашних каталогов пользователя, которые есть в
> > разных кодировках? Не столь уж много места он занимает.
> > Конечно, если пользователь будет переключать локали, LyX
> > запутается. Но много ли таких пользователей?
> 
> Не столько preferences, сколько ~/.lyx/languages

Да, именно это и имелось в виду.

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

Я немножко не про это. А про то, что если в LaTeX чего-то не
хватает для полноты счастья конкретного редактора, то редактору
никто не мешает хранить это что-то в комментариях, не создавая
при этом необходимости в личном формате. 

> Не-е-ет. TeXmacs -- это совершенно особый текстовый процессор,

Я ж говорю, не сподобился. Даже не смотрел, ответ объясняется
исключительно названием, которое автоматически перевелось у меня
как <<Emacs for TeX>>.

> определяется команда\SelectRussian, которая содержит
> определения вида
> 
>   \defА{\CYRA}\defа{\cyra}%
>   \defБ{\CYRB}\defб{\cyrb}%
> 
> и т. д. (Все 8-битные символы предварительно сделаны активными
> -- не правда ли, офигительный способ их преобразования в
> кириллические текстовые команды?) Дальше идут определения для
> стандартных строк:
> 
>   \renewcommand{\ProofText}{Доказательство}%
>   \renewcommand{\AxiomText}{Аксиома}%
> 
> и т. д. Аналогичные команды для других языков -- и всё это, как
> видите, исключительно от неумения пользоваться Бабелем и его
> командами. Вот это я и называю костылями.

Так ведь приведённые примеры говорят не о ценности самого подхода
к вопросу, а о качестве реализации этого подхода.

> > Костылей в виде файла, который подлючён? Так что ж в этом
> > страшного? Если мне для компиляции программы кроме gcc
> > потребуется ещё и glibc, то это более чем естественно.
> 
> Даже если исключить клинические случаи, подобные
> вышеописанныму, зависимость кода от подключаемых файлов (помимо
> явно заданных пользователем) -- это, IMHO, всегда плохо.
> Ибо если мы будем дорабатывать сгенерированный файл вручную,
> то загрузка "лишних" пакетов, естественно, вызовет наше
> раздражение, и придется тратить время на чистку кода на предмет
> избавления его от ненужных нам зависимостей.

С тем, что такой пакет будет <<лишним>>, я не согласен. 

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

Именно. 


>  Привести же документ к некоему усредненно-
> "правильному" виду вполне осуществимо.

Ну разве что... 

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

А это опять-таки не ОО, это XML. Хотя, в принципе, ничто не
мешает произвести автоформатирование этого XML, причём без потери
его читабельности для ОО. 

> > --- открывающиеся кавычки, само слово, закрывающиеся кавычки.
> > Чем вызвана необходимость этого? Кому мешали "< "> << >>?
> 
> Необходимость вызвана тем, что лигатуры не универсальны, а
> бабелевские 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 с его открывающими и закрывающими тегами.
> Подобный эффект был бы невозможен в любом формате, где для
> переключения форматирования используются команды-декларации.

То есть, опять-таки, вопрос в выборе: Пингвин против Терминатора :-) 
Удобство человека против удобства программирования редактора.
Я за человека.

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

Чрезвычайно небольшой, думается. Введут мой любимый буфер :-), и
всё. Задачка сия давно решена в оптимизирующих компиляторах,
только применить.

-----------------------------------------------
DM: dead underscore m at list point ru