Re: [Comm] LyX

[DM <dead_m@list.ru>]

Hello, Alexej!

On Wed, 10 Sep 2003 00:54:08 +0400 You wrote:

> > Риторический вопрос: а почему при установке не проверяется
> > хотя бы системная локаль? Почему при наличии кучи
> > поддерживаемых кодировок не сделано элементарное: настройки
> > кодировки не вынесены в отдельные пакеты, из которых нужно
> > поставить один?
> 
> Не очень представляю, как это сделать... Файл ведь написан
> руками, сам не генерируется и в пользовательские настройки 
> не переписывается. А привязать его к локали сложно потому,
> что LyX ориентирован на многоязычные документы. То есть
> если я помечу какой-то текст как греческий, то входная
> кодировка будет динамически переключаться с cp1251 на
> iso-8859-7. И точно так же какая-то русская
> кодировка должна работать даже при некириллической локали.

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

> Кстати, это одно из удобств LyX (хотя и имеющее ограниченное
> применение): ведь в написанном руками документе смешивать
> несколько входных кодировок всё-таки как-то диковато.

Вот то-то и оно :-) 

> > А зачем ей знать, что будет _дальше_? Достаточно держать в
> > памяти буфер с абзац размером и форматировать его по
> > завершении. С т.з.
> 
> Ну а если текст вгоняется в середину абзаца, потом его делят
> на части и т. д.? Всё равно нужен промежуточный формат чтобы
> это фиксировать.

Опять-таки, во время работы всегда есть текущий абзац, с которым
работает пользователь. Только его и нужно хранить во внутреннем
формате.

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

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

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

> Видели Вы 
> когда-нибудь LaTeX-код, генерируемый TeXmacs?

Не сподобился. У меня с emacs'ом сложные отношения. Не просекаю я
его красоты и привлекательности и стараюсь поэтому не
использовать. 

> Вот там точно в преамбуле стоит \include. А в итоге получается
> файл, который не откомпилировать без костылей.

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

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

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

> Вообще Всегда, когда
> человеко-ориентированный язык выбирают в качестве внутреннего
> формата программы, возникает масса проблем. Вот в oodisc как-то
> обсуждали вопрос о том, что OOo тратит куда больше времени на
> сохранение файла в своем родном формате, чем во вражеский word.
> А откройте Вы этот родной формат в текстовом редакторе --
> сколько всякого мусора там найдете! И именно потому, что его
> старались сделать *правильным* и одновременно использовать в
> качестве внутреннего.

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

> Но, значит, по крайней мере новичков нужно
> к нему приучать, а то они зациклятся на OOo, и никуда дальше
> не пойдут. Хотя, впрочем, знаю и обратное явление: люди
> зацикливаются на MikTeX + WinEdt и не идут дальше на Linux.

Может быть :-)

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