From: DM <dead_m@list.ru> To: community@altlinux.ru Subject: Re: [Comm] LyX Date: Mon, 15 Sep 2003 01:40:14 +0400 Message-ID: <20030915014014.3f0c2e42.dead_m@list.ru> (raw) In-Reply-To: <200309132209.27179.akrioukov@kengu.ru> 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
next prev parent reply other threads:[~2003-09-14 21:40 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-09-05 15:40 Oleg Vladimirovich 2003-09-05 17:48 ` Alexej Kryukov 2003-09-05 19:49 ` DM 2003-09-06 3:06 ` Gleb Kulikov 2003-09-07 20:46 ` DM 2003-09-06 9:04 ` Alexej Kryukov 2003-09-07 20:38 ` DM 2003-09-08 9:20 ` Alexej Kryukov 2003-09-08 20:28 ` DM 2003-09-08 21:46 ` Alexej Kryukov 2003-09-09 1:28 ` DM 2003-09-09 20:54 ` Alexej Kryukov 2003-09-10 19:39 ` DM 2003-09-12 18:49 ` Формат OO (было - [Comm] LyX) Sergey Lizogub 2003-09-12 6:14 ` æÏÒÍÁÔ OO (ÂÙÌÏ " Serhii Hlodin 2003-09-12 7:20 ` Re[2]: Формат OO (было- " "DM" 2003-09-12 8:30 ` Формат OO (было - " Maxim Britov 2003-09-12 18:21 ` DM 2003-09-13 16:08 ` Alexej Kryukov 2003-09-14 21:49 ` DM 2003-09-15 8:29 ` Alexej Kryukov 2003-09-15 19:11 ` DM 2003-09-15 8:33 ` Maxim Britov 2003-09-13 18:14 ` [Comm] LyX Alexej Kryukov 2003-09-14 0:01 ` Alexander Bokovoy 2003-09-14 21:40 ` DM [this message] 2003-09-15 8:25 ` Alexej Kryukov 2003-09-15 19:25 ` DM 2003-09-15 20:36 ` Alexej Kryukov 2003-09-14 9:31 ` Vitaly Lipatov 2003-09-14 12:18 ` Alexej Kryukov 2003-09-09 10:29 ` Re[2]: " Sergey A. Kolesnitchenko 2003-09-09 16:07 ` Alexej Kryukov 2003-09-17 10:07 ` Andriy Dobrovol's'kii 2003-09-17 11:28 ` Andriy Dobrovol's'kii 2003-09-14 9:13 ` Vitaly Lipatov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030915014014.3f0c2e42.dead_m@list.ru \ --to=dead_m@list.ru \ --cc=community@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Community general discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 community community/ http://lore.altlinux.org/community \ mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com public-inbox-index community Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.community AGPL code for this site: git clone https://public-inbox.org/public-inbox.git