Re: [Comm] LyX

[Alexej Kryukov <akrioukov@mail.ru>]

On Monday 15 September 2003 01:40, DM wrote:
> Hello, Alexej!
>
> Я немножко не про это. А про то, что если в LaTeX чего-то не
> хватает для полноты счастья конкретного редактора, то редактору
> никто не мешает хранить это что-то в комментариях, не создавая
> при этом необходимости в личном формате.

А я именно про это. Как потом добиться появления этого "нечто" 
в печатном документе, если он (печатный документ) всё равно
формируется путем прогона через LaTeX?

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

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

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

Но ведь Вы же не будете его подключать, когда пишете
файл изначально вручную. А на сгенерированных файлах,
значит, навсегда останется родимое пятно в виде еще одного
\include либо \usepackage?

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

Да, отчасти это еще одна расплата за XML (некоторые процессоры
считают, что пробельные символы между тегами -- это не есть
хорошо). Но в результате-то content.xml получается нечитаемым
не только для человека, но и, например, для vim, который
жутко тормозит на длинных строках. А процессор для автоформатирования
придумать, конечно, можно, только это уже не будет иметь отношения
к замыслу разработчиков OOo.

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

Лучше, ибо универсальнее.

> > Тем, что
> > стиль кавычек может различаться в зависимости от языка, и
> > потому удобно иметь универсальную команду, настраиваемую на все
> > случаи жизни.
>
> Кому удобно? Редактору? Да. Пользователю? Не уверен.

Видите ли, во всех случаях, когда некая команда имеет две
записи (сокращенную и полную), сокращенная запись предназначена
для ручной вставки, а полная -- для автоматической генерации.
Так вот, "< "> -- это всего лишь сокращенная запись для 
\flqq{}\frqq{}. Которые LyX и вставляет. А мог бы писать
вообще \guillemotleft{}\guillemotright{}.

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

Затем, что, когда мы печатаем в документе просто <>, LyX
их интерпретирует как \textless{}\textgreater{}. И абсолютно
правильно делает, потому что не во всех шрифтах <> фактически
соответствуют угловым скобкам, и уж тем более не во всех лигатуры
<< >> производят французские кавычки. А чтобы интерпретировать
<<>> буквально, пришлось бы оформлять их как вставку LaTeX-кода.

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

Удобство человека в том, чтобы редактор не тормозил на пустячных
операциях. И какая вообще человеку разница, в каком виде
редактор хранит свои данные, если экспорт в какой-л. human
readable формат не составляет проблемы? Что же до удобства
программирования, то в нём -- залог способности небольшой 
группы программистов в приемлемые сроки отладить небольшую
по объему программу и сделать ее пригодной для использования.
Опять-таки, если уж создатели OOo до сих пор не смогли
добиться безукоризненной работы с xml, то каково пришлось
бы разработчикам LyX при том, что ресурсы их ограничены,
а LaTeX много сложнее в интерпретации, чем xml?

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

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