Мечты об идеальном текстовом редакторе
Автор: Stephen Bint
Перевод: Юрий Прушинский
Примечание. Это - вторая часть трилогии Стефана о работе с текстом в Линукс. Первая часть опубликована на нашем портале под названием "Преодолевая консольный барьер".
Мне никак не даёт покоя вопрос - как такое могло случиться, что пользователи Windows имеют целый букет прекрасных текстовых редакторов, а для Линукс-консоли до сих пор нет ни одного достойного?! Ведь Линукс лучше, в ней [Гм.. А я всегда считал, что Линукс это "он", а не "она" (операционная система). Наверное, во мне говорит мужской шовинизм. Девчонки, не обижайтесь -- не могу себя вот так сразу переделать. ;-) Прим.ред.] работают лучшие программисты, преданные своему делу, и пишущие лучшие программы во благо всех. [Думаю, что мотивы поступков людей, участвующих в движении Open Source, нельзя описать одной лишь этой фразой. Слишком однобоко получается. К тому же ...благими намерениями выложена дорога... Окончание по вкусу. Прим.ред.] А ведь для программиста текстовый редактор - наиболее важная и нужная вещь. И несмотря на это - консольные редакторы под Линукс просто хлам! Как же так!?
Вспомните, те из нас, кто перешёл с Windows на Линукс, по крайней мере, ожидали, что там будет текстовый редактор с функциями выделения текста мышью и диалоговыми окнами с менюшками. Из всех редакторов такими способностями обладает только mcedit из состава файлового менеджера Midnight Commander. [И как правило, именно его я и использую, если нужно что-то подредактировать по-быстрому. Мнение редактора.] У других нет ни диалогов, ни поддержки мыши, либо эти функции в минимальном наборе и пользоваться ими просто невозможно.
Да и тот же mcedit имеет значительный недостаток. Если вам что-то не нравится в его работе, или вам не хватает какой-то функции, которую вы могли бы добавить, то оказывается, что будет проще написать собственный редактор, чем разбираться в дебрях его исходного кода. А ситуация такова, что mcedit не хватает довольно много функций, и добавить их просто не представляется возможным.
Для чего нам тогда нужна открытость Open Source, если программы настолько сложны и плохо документированы, что не понятны никому кроме автора?
Согласитесь, ведь все мы одинаковы. Все любим писать программы, и ненавидим писать для них документацию. Создавать красивые алгоритмы интереснее, чем объяснять их принцип новичкам. А ведь если бы кто-нибудь взялся и создал бы и поддерживал текстовый редактор, в который можно легко добавлять функции меню на С++ , то это мог бы оказаться последний текстовый редактор. Просто потому что уже никто бы не стал изобретать собственный, если уже есть достойный редактор, который легко модифицируется и расширяется.
Фундаменталисты из лагеря Столлмэна (R.Stallman) будут утверждать, что emacs - расширяемый редактор. Да, действительно, но для его расширения нужно учить второй язык. Кроме того, у редактора изначально остался сырой и неудобный пользовательский интерфейс, который никак не улучшишь, добавляя модули на lisp.
Многие из нас, увлечённые Линукс, нормальные люди, а не супермены. Совершенно излишне и даже жестоко заставлять кого-то изучать второй язык программирования параллельно с основным.
Поэтому Emacs не инструмент. Это тест умственных способностей. Настали времена, чтобы простые люди выступили против высоколобой элиты, для которой изучение emacs сущий пустяк. Ведь согласитесь, вам не нужно было учиться как работать в mcedit, он просто выполняет то, что вы от него ожидали.
Идеальный Редактор должен обладать такими же функциями как и emacs: расширяемый редактор с интуитивно понятным интерфейсом с поддержкой мышки и меню. [Примечание редактора LG: emacs появился ещё задолго до того как появились мышь и меню.] Только вместо того, чтобы учить второй язык для его расширения, всё должно создаваться на С++. Ну и, конечно, придётся написать руководство программиста, с описанием технологии вставки собственных команд меню, а также структуры исходного кода на случай, если вы захотите что-нибудь изменить в самом поведении редактора.
Сейчас я опишу вам каким должен быть Идеальный Редактор. Итак, вы скачиваете его, собираете, и обнаруживаете у него основные функции mcedit. У него есть возможность выделения мышью, возможность работы мышью с меню, ну и диалог открытия файлов, позволяющий перемещаться по директориям при помощи двойного щелчка.
У него есть несколько функций: Открыть Файл, Сохранить Файл, Выход, Вырезать, Скопировать, Вставить, Удалить и Помощь. Но у него нет функции поиска! Не беда, подробный README объяснит, что исходник для функции поиска входит в состав, и опишет как его подключить. Окажется, что необходимые строки кода уже написаны в исходнике, но они просто закомментированы.
Для включения функции поиска вам понадобится:
1. Поместить файл с текстом функции в каталог, где лежат исходники редактора
2. Объявить функцию в начале файла main.cc, к примеру вот так:
int show_search_dlg();
3. Добавить строку в main() (то есть просто её раскомментировать):
ed.add_menu_cmd( show_search_dlg, "Search", "Edit", F2_key, SHIFT_PRESSED );
...которая добавляет команду "Search" в меню "Edit", имеющую "горячую клавишу" Shift-F2.
4. В Makefile добавить (раскомментировать) правило для компиляции исходника и добавить его имя к списку объектов, подлежащих компоновке (линкованию).
5. Запустить Make и убедиться, что функция поиска присутствует в меню.
Следуя вышеописанной процедуре даже новичок поймёт как писать собственные функции меню. Редактор будет глобальной переменной (объектом С++), доступной посредством .h файла в любом исходнике, который напишет пользователь. Его методы (функции, объявленные в классе без описателя), будут считывать состояние всех его внутренних переменных, например позицию курсора или область выделения. Текстовый массив, содержащий редактируемый файл, будет доступен как переменная экземпляра (т.е. элемент объекта-экземпляра класса), так что его можно будет просканировать и изменить в пределах пользовательской функции.
[Всё это конечно замечательно, но если уж автор завёл речь о создании расширяемого редактора, то лучше рассмотреть варинат редактора, использующего плагины. Russian Linux Gazette публиковала перевод на эту тему. Прим.ред.]Вообще-то, установка цвета возлагается на пользователей. Некоторые редакторы предоставляют диалог для смены цветов, но в целом логика диктуется разработчиком.
Идеальный Редактор предоставил бы пользователям лёгкий способ для написания собственных процедур для работы с цветом. Помимо возможности подсветки редких и экстравагантных языков, этот способ раскрыл бы весь скрытый потенциал возможностей работы с цветом.
Только представьте, сколько есть вариантов цветовой подсветки кода, и какую пользу это могло бы дать для его анализа. В зависимости от ваших целей, вы бы могли выделить цветом идентификаторы в зависимости от h-файла, в котором они объявлены, или в зависимости от метода их назначения, или значения . Вы даже сможете выбирать из целого набора цветовых схем нужную при помощи "горячих клавиш"!
Для того, чтобы упростить работу с цветом, Идеальный Редактор будет хранить свои файлы в файловых массивах, содержащих в свою очередь два массива строк - один для текста, а другой для цвета. [Мысль интерсеная, вот только избыток цветов на экране рассеивает внимание. Прим.ред.] Файловый массив будет содержать размеры строк в этих двух массивах таким образом, что каждой букве из текстового массива будет соответствовать байт, отвечающий за её цвет.
Редактор будет прорисовывать цветовой массив при каждом его обновлении, так что всё, что остаётся сделать программисту для задания цвета символу, это изменить нужное значение в цветовом массиве и обновить экран.
Пользователю обычно кажется, что диалоговые окна это всего лишь небольшая часть текстовых редакторов. Но с точки зрения программиста, это совсем не так. Ведь даже поля ввода в диалогах являются практически полноценными окнами. Так что при написании Идеального Редактора, почти наверняка, придётся написать и Идеальную Библиотеку Элементов Управления.
Хорошо написанная и документированная библиотека элементов (widget library) это уже больше, чем просто дополнение к расширяемому редактору. Ведь при её помощи люди смогут улучшать редактор, создавая конфигурационные диалоги, которые в свою очередь упростят процесс настройки программы.
Возьмём к примеру Linuxconf - очень полезный инструмент для настройки, но он угасает, как мертвый язык (видимо здесь и далее автор имеет в виду ещё консольную версию Linuxconf - прим.перев.). А всё из-за того, что он очень сложен, и эта сложность не способствует его развитию и улучшению. Вот если бы переписать Linuxconf с поддержкой мыши и диалогов для X-Windows, он бы смог развиваться и включать модули для настройки любых популярных программ.
Согласитесь, что основным препятствием на пути популярности Линукс является его эзотеризм. То есть никто не пишет ПО для новичков, потому что в Линуксе работают только эксперты. Подумайте, если бы дружелюбные до идиотизма программы не были бы нужны для популярности ОС, тратила бы Microsoft на них столько времени и денег?
Linuxconf для начала было бы хорошо переписать на простой и современной библиотеке элементов, тогда бы он обрёл черты того, чем ему и надо быть - проект, который никогда не закончится. Он будет постоянно прирастать новыми модулями, пока не достигнет того состояния, что с его помощью даже ребёнок сможет настроить любую программу под Линукс.
Я бы хотел, чтобы мои наработки мог использовать любой знакомый с С++. Из-за всего этого низкоуровневого кошмара, связанного с работой мыши и клавиатуры, я создал библиотеку, делающую всё это таким же простым как и в DOS. Я бы даже рекомендовал для написания редактора использовать именно мою библиотеку вместо Slang по нескольким причинам.
Во-первых, размер исходников Slang (включая документацию и демо-программы) в архиве составляет 740Кб, в то время как моя библиотека занимает всего 42Кб. Во-вторых, Slang не умеет работать с мышью. В третьих, схема работы с цветом в Slang очень сложна, а моя библиотека представляет экран в стиле EGA буфера из символьно-цветовых байт-пар. [Для новичков: повторюсь ещё раз -- автор немного некорректно выразился: использование символьной-цветовых пар для отображения символа и его цвета на экране не есть прерогатива EGA. Тот же самый принцип использовался и в CGA-адаптерах. Прим.ред.]
Я написал свою библиотеку в результате безуспешных попыток оседлать Slang. Я не сомневаюсь, что автор Slang намного более профессиональный программист, чем я, но зато я создал библиотеку именно для тех, кто хочет создать первый достойный консольный редактор под Линукс, а не для реализации всех кросс-платформенных возможностей Slang.
Вы можете скачать её отсюда: http://members.lycos.co.uk/ctio/
И в результате с её помощью работать с консолью в Линукс даже проще чем в DOS, ведь все проблемы которые существовали в DOS я просто убрал! Теперь любой кто знает С++ может творить поистине великие вещи, и даже начинающие программисты смогут написать редактор и вышеописанную библиотеку элементов, которые могут изменить историю свободного ПО.
Меня постоянно убеждают, что не нужно заново изобретать колесо. Но я уверяю вас, что я буду ходить по центральной улице и кричать во весь голос: " НЕ НАДО БОЛЬШЕ ЗАНОВО ИЗОБРЕТАТЬ КОЛЕСО! УРА!", но только в тот день, когда кто-нибудь наконец изобретёт действительно КРУГЛОЕ КОЛЕСО.
Теоретически, любой Open Source редактор можно довести до совершенства, но мы почему-то до сих пор ждём консольного редактора с поддержкой мыши, который смог бы усовершенствовать и развивать любой программист с уровнем I.Q. до 170. Без нормальной документации Open Source это Закрытая Книга для простых смертных.
Где ты, С++ программист? Создатель абстрактных машин, шагнувший за рамки материального мира и воплотивший мечту предшествующих поколений изобретателей? Жители прекрасного города Свободного ПО мучаются с квадратными колёсами, и только ты сможешь помочь их беде!
Вы, наверное, всё ещё сидите на мягком месте и подумываете: "Неееее, это не для меня", но тогда для кого? Не для меня, я бездомный. Когда у меня был доступ к компьютеру, я написал библиотеку консольного интерфейса, но сейчас я живу в палатке и только иногда могу выйти в Интернет в нашем центре занятости. Так почему бы не Вам?
А что если это ваша судьба стать автором этого Идеального Редактора - последнего из когда-либо созданных редакторов? И возможно уже через месяц после общественного признания свободного ПО памятник Столлмэну снесут и поставят вместо него ваш?
Slang, автор Джон Э. Дэвис (John E. Davis). Slang позволяет использовать кривые, а также это наиболее подходящая библиотека для работы с клавиатурой, мышью и цветом в текстовом режиме. Если у вас хватит ума, то вы вероятно сумеете использовать основу Slang для консольного интерфейса из исходников Midnight Commander. Он совсем невелик, но позволяет выделять текст в консоли и поддерживает терминалы и telnet.
CTIO, Автор Стивен Бинт (Stephen Bint). Самый простой и на мой взгляд лучший интерфейс для работы с консолью, который я написал. Работает только для Линукс и DOS консоли, не поддерживает rxvt/xterm и telnet (зато всего 42Кб!). О муках её создания читайте здесь.
emacs, автор Ричард Столлмэн (Richard Stallman). Культовая личность в истории свободного ПО.
Stephen Bint
Стивен (Stephen) простой бездомный англичанин, живёт в палатке в лесу.
Питается из консервных банок и курит окурки, найденные на дороге. Хотя он работал
какое-то время программистом на С, но предпочитает называть себя "профессиональным
любителем".
Copyright (c) 2003, Stephen Bint.
