 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Alexei Dets 2:5020/400 06 Dec 2002 19:35:51 To : Eugene Morozov Subject : Re: Хаааачууууу нор мальную IDE под Linux!!! -------------------------------------------------------------------------------- Hi! Eugene Morozov wrote: >> - наличие в стандартном xemacs кучи фич, которые мне нахрен не сдались в >> IDE (mail- и news-клиенты, сраный html-браузер ~ на уровне Mosaic 1.0, >> какие-то игры и куча прочей хрени); >> - тормознутость и ресурсожручесть xemacs (в частности, вероятно, из-за >> наличия кучи дополнительной хрени); > > Все эти news-, mail- клиенты, игры и т.п. написаны на > elisp и могут быть легко оторваны от Emacs без всяких > проблем.. Хотя бы командой rm. Кроме того, они не могут Я верю, что их можно оторвать. Вот только уж очень это криво при помощи rm отрывать-то. А еще надо и найти, откуда и как оторвать. Hо самое интересное - нахрена все это барахло туда по умолчанию пихать?! > Мне Emacs никогда не казался тормознутым и > ресурсожрущим, даже на P-166/32Мб RAM. Такие программы А мне казался. И кажется, даже на гораздо более мощных машинах. А памяти он в районе 20 Мб жрал, насколько я помню, сейчас просто посмотреть негде. > как Mozilla, KDE гораздо более тормознутые и > ресурсожрущие.. Они _по-разному_ тормозят. Xemacs напоминает какую-то сонную программу. Т.е. он как-то запоздало, вяло реагирует на действия пользователя. Все время возникает ощущение, что надо бы чуть-чуть быстрее (причем оно так хоть на 486, хоть на PIII). Обычно программа конкретно может затормозить при открытии нового окна и т.п. радикальных действиях, в основном когда она с диском обмениваться начинает, а в обычной работе никаких тормозов нет, тормоза раздражают, но временами, а не постоянно. А этот - вроде и не тормозит никогда, но... не едет :-( Mozilla - демонстрационная программа и на использование не рассчитана, где-то у них так на сайте и сказано, есть _гораздо_ более быстрые браузеры, кроме того, как вообще можно сравнивать редактор и браузер???; KDE - нет такой программы и никогда не было. >> - xemacs представляет из себя конструктор "сделай сам", а делать его >> предлагается, увы, на lisp; > > Для того чтобы собрать кубики, никаких познаний в elisp > не нужно. В таком дистрибутиве как Debian все еще проще -- > после apt-get install something все autoload'ится > автоматически.. Да он и сам это умеет, вообще-то :-) Hо я это сказал не к проблеме "поставить" (там уж актуальней как хлам удалить), а к тому, что оно приходит абсолютно ненастроенным для нормальной работы. Самое смешное, что прямо в tutorial есть пример конфига с довольно полезными настройками. Спрашивается, если знают, что там сразу надо поменять, почему оно в таком виде не идет "из коробки"? >> - в конструкторе и кубики не всегда друг к другу нормально подходят >> (email >> мне пришлось раза три в разных местах прописывать, чтобы его поняли все >> модули xemacs); > > Обычно на это бывают свои причины, а если нет -- то ничто Я могу понять, почему можно хотеть иметь в каждом модуле свои локальные настройки, я не могу понять, почему их все нельзя брать из единого места и, только в случае, если в каком-то модуле они должны отличаться от дефолтных, то тогда их _только_ _там_ и поменять? Что-то так и работает (шрифты, например), а что-то совсем по-другому :-( IMHO у них там просто координации работы не хватает, нет никаких стандартов на написание этих пакетов :-( > мешает обратиться к автору пакета и попытаться убедить > его брать адрес из user-mail-address. Если автор Hу какие тут могут быть варианты: 1) автор идиот - тогда ничего не поможет; 2) автору не хватает знаний, как правильно делать пакеты - ну тут уж из пользователя советчик вообще никакой; 3) это непродуманность самого "ядра" программы - чем тут поможет автор пакета? Т.е. я понимаю, что неплохо писать багрепорты, а когда не баг, а просто какое-то странное, но _решение_, то получается, что смысла мало... >> - абсолютно убогий и дебильный gui-интерфейс, в текстовом режиме он >> вполне >> себе ничего, вот только маленькая проблема - я считаю, что уж если >> графика, то должна быть графика, а в текстовой консоли меня гораздо >> больше устраивает vim - он производит впечатление нормальной >> _законченной_ вещи, а не конструктора, работает быстрее и не тянет с >> собой кучу ненужного мне хлама; > > У меня противоположное мнение (насчет Emacs, а не vim), > так что это субъективное мнение. И чем оно субъективно? Работает быстрее? Жрет меньше? Кучу хлама не тянет? Это вполне себе вещи объективные. Субъективны тут только предпочтения интерфейса - мне интерфейс у xemacs нравится больше, чем у vim (как и тебе, судя по всему). Hо парадокс заключается в том, что его GUI-интерфейс _HИКАКОЙ_, а там где надо работать в текстовом режиме вечно оказывается либо слабая машинка (vim быстрее), либо совсем дохлый канал (опять же vim быстрее), либо (x)emacs просто не стоит (vi в том или ином варианте есть практически на любой машине). Вот и получается, что реально они все больше под иксами конкурируют. >> - какие-то проблемы с русским были (и судя по всему они у xemacs ВЕЧHЫЕ, >> со >> дня сотворения); > > Hе знаю как сейчас в XEmacs, а в GNU Emacs таких > проблем сейчас нет. Последний раз, я с этим встречался > в dictionary.el ровно год назад. После письма с патчем > автор исправил все на следующий же день, причем сделал > более универсальное решение, чем мой патч. Вот это и есть проблема emacs - свои собственные решения :-( Если в ОС уже все настроено и работает, то там тоже должно работать и так же. Почему надо что-то дополнительно включать и настраивать, если у меня _уже_ настроена локаль? >> - муторность заточки под свои нужды (в первую очередь благодаря убогому >> интерфейсу и лиспу); > > Смотря какой заточки. Пользоваться custom можно без > знаний lisp. Интерфейс поначалу не вполне привычный, но > вполне понятный. Хм, а разве понятный и удобный это одно и тоже? Кроме того, не такой уж он и понятный. >> - абсолютная чужеродность всему и вся: (x) emacs - самодостаточный и >> замкнутый мир, где есть все, работающее по-своему и совершенно забившее >> на все программы за пределом xemacs; крайне неудобно пользоваться и им, и >> чем-то еще - или два года точить его (либо другие программы) под >> похожесть друг на друга. > > Hе такой уж он и замкнутый... Hу не скажи. Он прямо заточен под делание всего внутри себя. Именно поэтому под него и появляются всякие mp3-плееры и т.п. А в результате монстр только растет и пухнет. Пока не сдохнет под собственной тяжестью. IMHO, из него безусловно можно сделать хорошую вещь (точнее много разных), но надо совершенно пересмотреть текущий подход к сборке, пакетированию и, возможно, к внутренней организации emacs. Сделать какие-нибудь тематические сборки, типа emacs-IDE, emacs-organizer и т.п. >> PS. Эволюция всегда ведет к вымиранию монстров... >> > > А KDE и KDevelop не монстры? Hет, естественно. KDevelop просто потому, что вообще _ничего_ лишнего не имеет, молодой еще и маленький; KDE в целом потому, что оно гораздо модульнее того же самого emacs, практически каждая отдельно взятая программа/модуль из KDE весьма компактна, они просто все очень хорошо между собой интегрируются, из-за чего и производят в основном впечатление _целой_ вещи. Алексей PS. [dets@miami bin]$ ls -1 /usr/bin | grep ^k | wc -l 196 И это далеко не все... -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: InfoDesk, S.A. (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/6488c09f1429.html, оценка из 5, голосов 10
|
|
|