From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Alexej Kryukov To: community@altlinux.ru Subject: Re: [Comm] LyX Date: Mon, 15 Sep 2003 12:25:12 +0400 User-Agent: KMail/1.5.1 References: <000d01c373c4$0b3c95d0$fe03030a@vtgaet> <200309132209.27179.akrioukov@kengu.ru> <20030915014014.3f0c2e42.dead_m@list.ru> In-Reply-To: <20030915014014.3f0c2e42.dead_m@list.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200309151225.12993.akrioukov@mail.ru> 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: Mon, 15 Sep 2003 08:29:06 -0000 Archived-At: List-Archive: List-Post: 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? > Чрезвычайно небольшой, думается. Введут мой любимый буфер :-), и > всё. Задачка сия давно решена в оптимизирующих компиляторах, > только применить. Потом еще полгода будут вылавливать вызванные этим утечки памяти :-) А когда всё это отладят, мы получим дополнительные тормоза при работе, с которыми, конечно, придется смириться.