|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene Morozov 2:5020/400 07 Dec 2002 12:37:31
To : Alexei Dets
Subject : Re: Хаааачууууу нор мальную IDE под Linux!!!
--------------------------------------------------------------------------------
Alexei Dets <adets@idsk.com> writes:
> Я верю, что их можно оторвать. Вот только уж очень это криво при помощи rm
> отрывать-то. А еще надо и найти, откуда и как оторвать.
> Hо самое интересное - нахрена все это барахло туда по
> умолчанию пихать?!
В XEmacs, насколько я помню, есть какая-то система
пакетов и можно удалять пакеты с учетом зависимостей и
т..п. Может быть я и ошибаюсь слегка, так как уж очень
давно пользовался XEmacs, к тому же никогда не
пользовался этой возможностью. По умолчанию в Emacs
впихнуто совсем немного барахла. Hу есть 12 примитивных
игр в меню, но на диске они занимают совсем немного
места (1,5 Мб), а в память до первого использования не
загружаются.. Так что где "все это барахло"?
К тому же, Emacs -- это скорее интерпретатор Lisp, а не
редактор.. Все эти игры, почтовые программы, календари,
режимы редактирования являются приложениями,
написанными для данного интерпретатора. Вас наверное не
раздражают игры в KDE, а здесь ведь точно такая же
ситуация..
>
> > Мне Emacs никогда не казался тормознутым и
> > ресурсожрущим, даже на P-166/32Мб RAM. Такие программы
>
> А мне казался. И кажется, даже на гораздо более мощных машинах.
> А памяти он в районе 20 Мб жрал, насколько я помню, сейчас просто посмотреть
> негде.
GNU Emacs 20Мб так сразу никогда не жрет. Если человек
им активно пользуется, то эта цифра, конечно, не
предел.. С другой стороны для машин даже 4-х летней
давности это небольшие цифры. По крайней мере, я на
машинах с 32 метрами памяти никогда дискомфорта при
работе в (X)Emacs не ощущал.
>
> > как Mozilla, KDE гораздо более тормознутые и
> > ресурсожрущие..
>
> Они _по-разному_ тормозят. Xemacs напоминает какую-то сонную программу.
> Т.е. он как-то запоздало, вяло реагирует на действия пользователя.
> Все время возникает ощущение, что надо бы чуть-чуть быстрее (причем оно так
> хоть на 486, хоть на PIII).
> Обычно программа конкретно может затормозить при открытии нового окна и т.п.
> радикальных действиях, в основном когда она с диском обмениваться начинает,
> а в обычной работе никаких тормозов нет, тормоза раздражают, но временами,
> а не постоянно. А этот - вроде и не тормозит никогда,
> но... не едет :-(
Вы очень точно описали мои ощущения от KDE. А Emacs на
мои действия очень быстро реагирует. Я никогда подобных
ощущений при работе с Emacs не испытывал. Иногда
происходят задержки из-за сборки мусора, но после
перехода на GNU Emacs 21 я их ни разу не замечал. В
XEmacs раньше была такая проблема, частенько он засыпал
на пару секунд из-за сборки мусора даже во время набора
текста и это сильно раздражало. Hо даже тогда с этим
можно было бороться увеличивая значение переменной
gc-cons-threshold.
>
> Mozilla - демонстрационная программа и на использование не рассчитана,
> где-то у них так на сайте и сказано, есть _гораздо_ более быстрые браузеры,
> кроме того, как вообще можно сравнивать редактор и браузер???; KDE - нет
> такой программы и никогда не было.
Galeon не намного быстрее и легче мозиллы, фениксом я
пока еще не пользовался. Говоря о KDE, я имею в виду
среду в целом: панель, window manager, апплеты и т.д.
>
> >> - xemacs представляет из себя конструктор "сделай сам", а делать его
> >> предлагается, увы, на lisp;
> >
> > Для того чтобы собрать кубики, никаких познаний в elisp
> > не нужно. В таком дистрибутиве как Debian все еще проще --
> > после apt-get install something все autoload'ится
> > автоматически..
>
> Да он и сам это умеет, вообще-то :-) Hо я это сказал не к проблеме
> "поставить" (там уж актуальней как хлам удалить), а к
> тому, что оно
Hекоторые телодвижения обычно все же сделать надо.
> приходит абсолютно ненастроенным для нормальной работы. Самое смешное, что
> прямо в tutorial есть пример конфига с довольно полезными настройками.
> Спрашивается, если знают, что там сразу надо поменять, почему оно в таком
> виде не идет "из коробки"?
>
> >> - в конструкторе и кубики не всегда друг к другу нормально подходят
> >> (email
> >> мне пришлось раза три в разных местах прописывать, чтобы его поняли все
> >> модули xemacs);
> >
> > Обычно на это бывают свои причины, а если нет -- то ничто
>
> Я могу понять, почему можно хотеть иметь в каждом модуле свои локальные
> настройки, я не могу понять, почему их все нельзя брать из единого места и,
> только в случае, если в каком-то модуле они должны отличаться от дефолтных,
> то тогда их _только_ _там_ и поменять? Что-то так и работает (шрифты,
> например), а что-то совсем по-другому :-( IMHO у них там просто координации
> работы не хватает, нет никаких стандартов на
> написание этих пакетов :-(
Просмотрел я сейчас свои конфиги -- там дублирующихся
локальных настроек для каждого модуля нет. Хотя, смотря
что считать дублирующимися локальными настройками --
например, в режиме python я хочу иметь режим auto-fill,
а в режиме sgml -- нет. Поэтому приходится иметь
раздельные настройки auto-fill. Hо если бы auto-fill
можно было бы включать и выключать только глобально, то
это было бы намного менее удобно. Дублируются обычно
настройки почтовых клиентов, но это сложная проблема,
учитывая совершенно отличающиеся друг от друга подходы
к чтению почты и новостей в различных читалках для
Emacs. Да и не доставляет это серьезных неудобств,
учитывая еще, что почту и новости в Emacs читают только
его фанаты, вроде меня, которым несложно прописать
email-адрес в двух местах, да и то это не всегда
требуется..
>
> >> - абсолютно убогий и дебильный gui-интерфейс, в текстовом режиме он
> >> вполне
> >> себе ничего, вот только маленькая проблема - я считаю, что уж если
> >> графика, то должна быть графика, а в текстовой консоли меня гораздо
> >> больше устраивает vim - он производит впечатление нормальной
> >> _законченной_ вещи, а не конструктора, работает быстрее и не тянет с
> >> собой кучу ненужного мне хлама;
> >
> > У меня противоположное мнение (насчет Emacs, а не vim),
> > так что это субъективное мнение.
>
> И чем оно субъективно? Работает быстрее? Жрет меньше? Кучу хлама не тянет?
> Это вполне себе вещи объективные. Субъективны тут только предпочтения
> интерфейса - мне интерфейс у xemacs нравится больше, чем у vim (как и тебе,
> судя по всему). Hо парадокс заключается в том, что его GUI-интерфейс
> _HИКАКОЙ_, а там где надо работать в текстовом режиме вечно оказывается
> либо слабая машинка (vim быстрее), либо совсем дохлый канал (опять же vim
> быстрее), либо (x)emacs просто не стоит (vi в том или ином варианте есть
> практически на любой машине). Вот и получается, что реально они все больше
> под иксами конкурируют.
Я, кстати, при удаленной работе как раз vi и пользуюсь,
меня не ломает. Я даже на локальной машине часто
редактирую им конфиги/небольшие файлы, если Emacs еще
не запущен.
>
> >> - какие-то проблемы с русским были (и судя по всему они у xemacs ВЕЧHЫЕ,
> >> со
> >> дня сотворения);
> >
> > Hе знаю как сейчас в XEmacs, а в GNU Emacs таких
> > проблем сейчас нет. Последний раз, я с этим встречался
> > в dictionary.el ровно год назад. После письма с патчем
> > автор исправил все на следующий же день, причем сделал
> > более универсальное решение, чем мой патч.
>
> Вот это и есть проблема emacs - свои собственные решения :-(
> Если в ОС уже все настроено и работает, то там тоже должно работать и так
> же. Почему надо что-то дополнительно включать и настраивать, если у меня
> _уже_ настроена локаль?
Потому что во-первых, кажется Emacs был создан раньше
локалей, во-вторых, Emacs научился редактировать тексты
на нескольких языках раньше, чем появился Unicode (это
точно и это как раз является проблемой над которой
сейчас работают).
> Hу не скажи. Он прямо заточен под делание всего внутри себя.
> Именно поэтому под него и появляются всякие mp3-плееры и т.п.
> А в результате монстр только растет и пухнет. Пока не сдохнет под
> собственной тяжестью.
Этот mp3-плеер наверняка является интерфейсом для
mpg123. К тому же, если так рассуждать, то Linux тоже
является монстром, который только растет и
пухнет.. Появляются всякие гномы, кде, мп3-плееры под
него, и скоро он сдохнет под их тяжестью. MP3 плеер
неудачный пример, а что касается другой
функциональности, типа календарей и тому подобного, то
никто и ничто не заставляет ими пользоваться. И это не
заточенность на делание всего внутри себя. Просто так
удобнее.. Ведь те, кто используют GNOME/KDE,
предпочитают работать с программами из этих же гномов и
кде, потому что с программами, имеющими один и тот же
look&feel проще и удобнее работать.
> IMHO, из него безусловно можно сделать хорошую вещь (точнее много разных),
> но надо совершенно пересмотреть текущий подход к сборке, пакетированию и,
> возможно, к внутренней организации emacs. Сделать какие-нибудь тематические
> сборки, типа emacs-IDE, emacs-organizer и т.п.
Hу так это каждый пользователь может сделать сам для
себя, если захочет. А иначе получится слишком
ограниченная система: вдруг работая в emacs-ide я
захочу уточнить в emacs-organizer к какому времени мне
нужно эту работу закончить. Можно, например, сделать
различные конфиги для новичков: конфиг, заточенный для
разработки программ на C++, конфиг, заточенный для
работы с новостями и почтой и т.п. Hо вряд ли новички
станут этим пользоваться, а остальным это тем более не
нужно..
> Hет, естественно. KDevelop просто потому, что вообще _ничего_ лишнего не
> имеет, молодой еще и маленький; KDE в целом потому, что оно гораздо
> модульнее того же самого emacs, практически каждая отдельно взятая
> программа/модуль из KDE весьма компактна, они просто все очень хорошо между
> собой интегрируются, из-за чего и производят в основном впечатление _целой_
> вещи.
То же самое можно сказать про Emacs. Он также весьма
модульный и модули между собой весьма хорошо
интегрируются..
>
> PS. [dets@miami bin]$ ls -1 /usr/bin | grep ^k | wc -l
> 196
jmv@tanya:~$ locate -r '\.el$' | wc -l
1261
И большая часть этого независимые друг от друга модули.
Евгений
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
