From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Alexej Kryukov To: community@altlinux.ru Subject: Re: [Comm] LyX Date: Sat, 13 Sep 2003 22:14:49 +0400 User-Agent: KMail/1.5.1 References: <000d01c373c4$0b3c95d0$fe03030a@vtgaet> <200309100054.08328.akrioukov@mail.ru> <20030910233929.5d047cb1.dead_m@list.ru> In-Reply-To: <20030910233929.5d047cb1.dead_m@list.ru> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200309132209.27179.akrioukov@kengu.ru> Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: community@altlinux.ru List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2003 18:14:17 -0000 Archived-At: List-Archive: List-Post: 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 и стандартный > упаковщик, то бишь. А лишней информации там нет. Зато: удобно Ну, если нижеследующий фрагмент не содержит лишней информации, то я готов съесть свою шляпу :-) Позднее, ознакомившись Это результат работы перекодировщика, который менял символы Latin1 на кириллицу и одновременно применял к ним форматирование (Times New Roman вместо Times New Roman Cyr). Сдается мне, что при этом OOo ничего ни в каком буфере не держал :-) Но дело даже не в этом, а в том, что это именно расплата за xml с его открывающими и закрывающими тегами. Подобный эффект был бы невозможен в любом формате, где для переключения форматирования используются команды-декларации. > программировать, удобно поддерживать, возможно максимально полное > аварийное восстановление, а потери времени не столь уж велики. Как раз о легкости программирования предыдущий случай заставляет поразмыслить. Наверное, это когда-нибудь поправят, но вот какой ценой?