From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Real-To: Date: Mon, 15 Sep 2003 01:40:14 +0400 From: DM To: community@altlinux.ru Subject: Re: [Comm] LyX Message-Id: <20030915014014.3f0c2e42.dead_m@list.ru> In-Reply-To: <200309132209.27179.akrioukov@kengu.ru> References: <000d01c373c4$0b3c95d0$fe03030a@vtgaet> <200309100054.08328.akrioukov@mail.ru> <20030910233929.5d047cb1.dead_m@list.ru> <200309132209.27179.akrioukov@kengu.ru> Organization: =?KOI8-R?Q?=F7_=D6=C9=DA=CE=C9_=D7=D3=A3_=CE=C5_=D4=C1=CB=2C_?= =?KOI8-R?Q?=CB=C1=CB_=CE=C1_=D3=C1=CD=CF=CD_=C4=C5=CC=C5=2E=2E=2E?= X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 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: Sun, 14 Sep 2003 21:52:32 -0000 Archived-At: List-Archive: List-Post: Hello, Alexej! On Sat, 13 Sep 2003 22:14:49 +0400 You wrote: > > Почему, наконец, просто не впихнуть файл ~/lyx/preferences в > > скелетоны домашних каталогов пользователя, которые есть в > > разных кодировках? Не столь уж много места он занимает. > > Конечно, если пользователь будет переключать локали, LyX > > запутается. Но много ли таких пользователей? > > Не столько preferences, сколько ~/.lyx/languages Да, именно это и имелось в виду. > > И ещё момент: для представления того, что не охватывается > > целевым форматом, в программировании давно есть метод, > > которым пользуются разного рода IDE с кодогенерацией. Там > > дополнительные данные просто записываются в комментарии. Кто > > мешает делать это здесь? > > Не понял. Причем здесь это? Ведь документ всё равно будет > прогоняться через latex. Специальные комментарии могли бы > служить разве что для управления визуальным отображением > документа в редакторе. Я немножко не про это. А про то, что если в LaTeX чего-то не хватает для полноты счастья конкретного редактора, то редактору никто не мешает хранить это что-то в комментариях, не создавая при этом необходимости в личном формате. > Не-е-ет. TeXmacs -- это совершенно особый текстовый процессор, Я ж говорю, не сподобился. Даже не смотрел, ответ объясняется исключительно названием, которое автоматически перевелось у меня как <>. > определяется команда\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:style-name="T4">о text:style-name="T4">зд text:style-name="T4">н text:style-name="T4">ее text:style-name="T9">, text:style-name="T4"> оз text:style-name="T4">н text:style-name="T4">ак text:style-name="T4">о text:style-name="T4">мив text:style-name="T4">ш text:style-name="T4">ись > > Это результат работы перекодировщика, который менял символы > Latin1 на кириллицу и одновременно применял к ним > форматирование (Times New Roman вместо Times New Roman Cyr). > Сдается мне, что при этом OOo ничего ни в каком буфере не > держал :-) И в этом его ошибка :-) > Но дело даже не в этом, а в том, что это именно > расплата за xml с его открывающими и закрывающими тегами. > Подобный эффект был бы невозможен в любом формате, где для > переключения форматирования используются команды-декларации. То есть, опять-таки, вопрос в выборе: Пингвин против Терминатора :-) Удобство человека против удобства программирования редактора. Я за человека. > > программировать, удобно поддерживать, возможно максимально > > полное аварийное восстановление, а потери времени не столь уж > > велики. > > Как раз о легкости программирования предыдущий случай > заставляет поразмыслить. Наверное, это когда-нибудь поправят, > но вот какой ценой? Чрезвычайно небольшой, думается. Введут мой любимый буфер :-), и всё. Задачка сия давно решена в оптимизирующих компиляторах, только применить. ----------------------------------------------- DM: dead underscore m at list point ru