Комментарии 65
Это прекрасно.
Прекрасные притчи) Единственное, не пойму, зачем называть их какими-то «коанами». Судя по информации в википедии, с данными притчами это слово имеет не так много общего.
Коаны давали мастера Дзен своим ученикам для решения. Считается, что решая коаны, можно постичь истиннуб природу Дзен. Это действительно притчи, но каждая содержит в себе коаны мастера.
Обычно в коанах главную роль выполняет противоречие, из-за которого ученик и «достигает просветление». А здесь скорее небольшие вполне логичные рассказы.
Вероятно, вы уже обрели просветление, раз вы видите в них логику :) Я встречал много «продвинутых пользователей», которые читали эти притчи с насмешкой и непониманием.
Ну и как бы сам автор зовет их коанами, значит и переводчику негоже отсутпать от авторского стиля
Ну и как бы сам автор зовет их коанами, значит и переводчику негоже отсутпать от авторского стиля
Не могу назвать себя продвинутым пользователем UNIX, sed и awk вызывают у меня трепет отнюдь не предвкушения, а необходимость написать скриптик на баше — вздох, обильный гуглеж и курение манов, но ничего парадоксального в этих коанах не вижу. UNIX тем и хорош, что не требует входа в особое состояние разума.
Отлично! Большое спасибо за изящество.
Я понял, что я ничего не понял. Сократ ли я?
Большое спасибо!
Шикарно!
«И помни, Нео! Знать путь и пройти его это не одно и тоже!»
Спасибо, поучительно!
Очень напомнило "Суждения об информационной безопасности мудреца и учителя Инь Фу Во, записанные его учениками".
Очень напомнило "Суждения об информационной безопасности мудреца и учителя Инь Фу Во, записанные его учениками".
> vim — мощнейший на данный момент консольный текстовый редактор.
Воу-воу, полегче! Попахивает холиваром)
Спасибо, коаны шикарны, многих нигде ещё не читал.
Воу-воу, полегче! Попахивает холиваром)
Спасибо, коаны шикарны, многих нигде ещё не читал.
Коан и должен вызвать холивар. В первую очередь в голове читающего.
Мой комментарий относился не к коану, а к комментарию переводчика к нему.
Спор vim/emacs/else чрезвычайно стар, давать определение vim-у как «мощнейший консольный текстовый редактор» очень уж необъективно, на мой взгляд. Ну и это вправду ведёт к холивару в большинстве случаев на определённых ресурсах.
Спор vim/emacs/else чрезвычайно стар, давать определение vim-у как «мощнейший консольный текстовый редактор» очень уж необъективно, на мой взгляд. Ну и это вправду ведёт к холивару в большинстве случаев на определённых ресурсах.
Рад, что вам понравилось!
Насчёт vim-а, признаю, это был комментарий с подвохом (сейчас поправлю). Я его оставил просто чтобы посмотреть, спросит ли кто-нибудь об этом. На деле я ко всем редакторам питаю искреннее уважение, даже к такой экзотике как acme и wily. Очень жаль, что вас заминусовали из-за меня.
Насчёт vim-а, признаю, это был комментарий с подвохом (сейчас поправлю). Я его оставил просто чтобы посмотреть, спросит ли кто-нибудь об этом. На деле я ко всем редакторам питаю искреннее уважение, даже к такой экзотике как acme и wily. Очень жаль, что вас заминусовали из-за меня.
> На деле я ко всем редакторам питаю искреннее уважение, даже к такой экзотике как acme и wily.
Признаться, пришлось погуглить про них, ранее даже не слышал. Спасибо вам ещё раз, теперь уже за эту отсылку — acme чертовски впечатлил.
> Очень жаль, что вас заминусовали из-за меня.
Не думаю, что из-за вас. Это хабр, мне стоило быть осмотрительнее.
Признаться, пришлось погуглить про них, ранее даже не слышал. Спасибо вам ещё раз, теперь уже за эту отсылку — acme чертовски впечатлил.
> Очень жаль, что вас заминусовали из-за меня.
Не думаю, что из-за вас. Это хабр, мне стоило быть осмотрительнее.
Master Foo and the Editor Wars
Нежелание развиваться за мудрость выдаётся, однако…
Зачем изобретать новые языки программирования? Их же придётся изучать! Лучше всё писать на ассемблере. Другие языки не нужны.
Аналогичную фразу можно сказать про вообще что угодно. Всегда можно что-то илучшить, и действительно, потом это улучшение нужно будет кому то изучать. Но порой лучше «день потерять, потом за час долететь».
ни Emacs, ни Vi, ни любой другой текстовый процессор не обладает всеми возможностями, что мне нужны.Вы не обрели просветления. Потому что не было даже попытки улучшить имеющиеся инструменты (vim и emacs дополняемые), а уже потом хвататься за напильник и молоток, чтоб сотворить новый инструмент.
…
Я напишу лучший редактор на свете. Он будет делать всё, чего я захочу. Он будет делать всё, чего захочет кто угодно. И мир станет лучше, потому что…
Вы попали в точку. Я даже приведу точную цитату от ESR (The Art of Unix Programming: The Right Size of Software):
The corrective to this tendency comes straight from the old-school Unix hymnbook. It is the Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do—that is, when attempts to partition the problem have been made and failed. This maxim implies an astringent skepticism about large programs, and a strategy for avoiding them: look for the small-program solution first. If a single small program won't do the job, try building a toolkit of cooperating small programs within an existing framework to attack it. Only if both approaches fail are you free (in the Unix tradition) to build a large program (or a new framework) without feeling you have failed the design challenge.
А здесь будет уместна притча «Master Foo and the Ten Thousand Lines».
НЛО прилетело и опубликовало эту надпись здесь
Я наверняка чего-то не понимаю, но что vi[m], что emacs у меня вызывают одну ассоциацию…
Вот и с ними также — да, потенциально можно работать очень эффективно, но порог вхождения настолько крут, что невольно задаешься вопросом: а оно точно того стоит?
А именно:
В каком-то фантастическом романе правящий компьютер создал синтетический язык для общения с кастой своих жрецов-слуг. Этот язык использовал пропускную способность речевого аппарата человека практически полностью, но требовал пары лет брутальных уроков а-ля собака Павлова, и все равно перед каждым использованием требовалась предварительная «настройка» с помощью этакого «камертона».
Вот и с ними также — да, потенциально можно работать очень эффективно, но порог вхождения настолько крут, что невольно задаешься вопросом: а оно точно того стоит?
Сейчас появилось много хороших редакторов (atom, sublime), так что в некоторых областях емакс с вимом уже проигрывают.
С другой стороны, у них есть свои ниши, в которых они будут ещё долго хороши.
С другой стороны, у них есть свои ниши, в которых они будут ещё долго хороши.
Ну, сложность vi[m] слегка преувеличена, там реально нужно запомнить десяток команд. Как, собственно, и в любом современном редакторе для эффективной работы. Другое дело, что в vi[m] разделен режим ввода команд и режим редактирования и потому у новичков он работает всего лишь в двух режимах: «бибикает» и «все портит».
В общем, тем, кто не хочет заморачиваться, стоит запомнить простое сочетание: (esc), ":", «q!» — выход без сохранения изменений.
В общем, тем, кто не хочет заморачиваться, стоит запомнить простое сочетание: (esc), ":", «q!» — выход без сохранения изменений.
Порог вхождения в эмакс настолько крут не потому что эмакс принципиально сложен, а потому что это отражение трагедии современного высшего образования в области информатики и компьютерных наук. После паскаля, бейсика и PHP лисп действительно кажется синтетическим средством изобретенным инопланетянами, при том что его полное описание заняло у автора аж целый непомерный лист формата A4.
Порог вхождения в emacs настолько крут ни в коем случае не из-за языка. Lisp — вполне простой для освоения язык. Для сравнения тот же Vimscript — кошмар и ужас. А попытки как-то автоматизировать работу в vim вызывают желание побиться головой о клавиатуру.
Проблема с emacs во взрывающих мозг комбинациях клавиш. Чтобы модифицировать инструмент под себя мне надо научиться хоть как-то работать с базовой версией. Но как я могу научиться работать с ней, если я не могу запомнить ни одну комбинацию клавиш?! В emacs есть курс для новичков: он выглядит как издевательство, у меня пальцев не хватает на базовые действия в нем, не говоря уже о том, чтоб повторить это без подсказки.
Проблема с emacs во взрывающих мозг комбинациях клавиш. Чтобы модифицировать инструмент под себя мне надо научиться хоть как-то работать с базовой версией. Но как я могу научиться работать с ней, если я не могу запомнить ни одну комбинацию клавиш?! В emacs есть курс для новичков: он выглядит как издевательство, у меня пальцев не хватает на базовые действия в нем, не говоря уже о том, чтоб повторить это без подсказки.
Единственная программа, в которой вменяемо подошли к хоткеям — Idea. Там есть Ctrl+Shift+A, помогающий выучить остальные комбинации. Будь нечто подобное в emacs — освоить его стало бы несравнимо проще.
Я с вами согласен в этом ключе — хотелось бы, чтобы хоткеи подсказывались в процессе работы ненавязчиво, но неоднократно, как при полном поиске нужной функции в Ctrl+Shift+A. У vim, конечно, есть vimtutor и интерактивный учебник, но нет-нет, да и обнаруживаешь себя на tips wiki в поисках очередной фичи.
В emacs есть программа Guide Key которая делает именно это.
Вот это? kai2nenobu/guide-key
Это совершенно не то же самое, что Ctrl+Shift+A в Idea. Ctrl+Shift+A проводит полнотекстовый поиск по описанию действия. guide-key — поиск по части комбинации.
Это совершенно не то же самое, что Ctrl+Shift+A в Idea. Ctrl+Shift+A проводит полнотекстовый поиск по описанию действия. guide-key — поиск по части комбинации.
Ближайший аналог в Emacs — встроенная команда apropos, C-h a, но она не ищет по описанию действия. Среди всего разнообразия дополнений есть что-то похожее, но как по мне учебник и гугл таки уместнее.
Комбинации клавиш принципиально вызывают проблемы независимо от программы и самих сочетаний. Они ужасны везде, не только в Emacs. Например сочетания Ctrl-Z, Ctrl-X, Ctrl-C и Ctrl-V абсолютно невменяемы и нелогичны, насколько я могу о них судить. Они привычны, потому что фактически стали частью современной культуры, но это не меняет их сути. В Emacs большинство сочетаний клавиш имеют осмысленное значение, как в vi: forward, backward, next, previous, word, line, kill, yank, transpose, uppercase, capitalize, save, find, search, reverse, end, zap, qoute, indent, open, delete, и т.д — это из тех что лично я использую все время.
Они логичны в том плане, что на раскладке QWERTY эти четыре очень часто выполняемых действия посажены на клавиши рядом с левым Ctrl, поэтому нет нужды ставить пальцы на шпагат. =)
Ctrl-A, Ctrl-C и Ctrl-S в этом плане повезло — не только легко нажать, но и буква совпадает по смыслу. Хотя смысловое совпадение — штука обоюдоострая из-за синонимов. Ведь пользователю придется вспоминать, какой глагол использовался для, скажем, поиска: search, find или look.
Ctrl-A, Ctrl-C и Ctrl-S в этом плане повезло — не только легко нажать, но и буква совпадает по смыслу. Хотя смысловое совпадение — штука обоюдоострая из-за синонимов. Ведь пользователю придется вспоминать, какой глагол использовался для, скажем, поиска: search, find или look.
Поставьте пакет ergoemacs — он во многом дублирует хоткеи «нормальных» редакторов, Ctrl+C, Ctrl+V и прочие плюшки там что называется из коробки.
Я когда-то давно начал использовать вим из-за того, что ни один редактор не мог оставить меня довольным собой, я всех и не вспомню, в каждом мне в итоге хотелось изменить ряд вещей. Одни лагали, другие были неудобны, третьи поддерживали очень ограниченный список языков, в других нельзя было кастомизировать тривиальные вещи и т.д. и т.п. А о вим я был наслышан как о редакторе, который можно вертеть и крутить, что ж, это оказалось чистой правдой.
С тех пор я серьёзно прокачал конфиг, и то, как я работаю в виме с целой сворой плагинов сейчас, напоминает работу в «голом» vim очень отдалённо, автоматизировал кучу вещей и привык к куче комманд, которые позволяют мне вместо нудного для меня тыкания по всяким «стрелочкам» и елозинья мышкой производить целевые действия, часто используемые комбинации доведенны до рефлексов. Что меня по прежнему не перестаёт радовать, — я могу заставить редактор подстроиться под меня, он не навязывает мне свою рутину.
Сейчас мне сложно себе представить переход на другой редактор, в том смысле что я вряд ли смогу также тщательно заточить под себя другой редактор (разве что какой-нибудь emacs), это как минимум потребует немало времени, и скорее всего мне прийдётся принять целый ряд ограничений, и я не вижу никакой объективной пользы от перехода. Я часто вижу чужие редакторы у коллег, и я в первые минуты вижу ряд недостатков и ограничений и когда я спрашиваю у коллег, как бы они сделали то-то, оказывается что это они педалят вручную и скорее всего в их редакторе просто нет более краткого решения. Vim начинает делать практически всё, как только я начинаю в этом нуждаться.
По вопросу могу сказать, что если вы нюфаг, или вас итак всё устраивает, вы эффективно решаете свои задачи, то оно того наверняка не стоит, т.к. рвать шаблон будет сильно, особенно первый месяц непрерывной работы, если только для фана, авось зацепит. Первое время вы будете думать по большей части о редакторе, а не о коде. Если же вас смущают ограничения вашего редактора, которые вы не можете преодолеть, то однозначно стоит попробовать vim, т.к. он не возбраняет изменять себя до неузноваемости.
Большая однако паста получилась.
P.S. Нюфагам — первым делом ремапьте capslock чтобы использовать его вместо ctrl (даже если не пользуетесь vim-ом).
С тех пор я серьёзно прокачал конфиг, и то, как я работаю в виме с целой сворой плагинов сейчас, напоминает работу в «голом» vim очень отдалённо, автоматизировал кучу вещей и привык к куче комманд, которые позволяют мне вместо нудного для меня тыкания по всяким «стрелочкам» и елозинья мышкой производить целевые действия, часто используемые комбинации доведенны до рефлексов. Что меня по прежнему не перестаёт радовать, — я могу заставить редактор подстроиться под меня, он не навязывает мне свою рутину.
Сейчас мне сложно себе представить переход на другой редактор, в том смысле что я вряд ли смогу также тщательно заточить под себя другой редактор (разве что какой-нибудь emacs), это как минимум потребует немало времени, и скорее всего мне прийдётся принять целый ряд ограничений, и я не вижу никакой объективной пользы от перехода. Я часто вижу чужие редакторы у коллег, и я в первые минуты вижу ряд недостатков и ограничений и когда я спрашиваю у коллег, как бы они сделали то-то, оказывается что это они педалят вручную и скорее всего в их редакторе просто нет более краткого решения. Vim начинает делать практически всё, как только я начинаю в этом нуждаться.
По вопросу могу сказать, что если вы нюфаг, или вас итак всё устраивает, вы эффективно решаете свои задачи, то оно того наверняка не стоит, т.к. рвать шаблон будет сильно, особенно первый месяц непрерывной работы, если только для фана, авось зацепит. Первое время вы будете думать по большей части о редакторе, а не о коде. Если же вас смущают ограничения вашего редактора, которые вы не можете преодолеть, то однозначно стоит попробовать vim, т.к. он не возбраняет изменять себя до неузноваемости.
Большая однако паста получилась.
P.S. Нюфагам — первым делом ремапьте capslock чтобы использовать его вместо ctrl (даже если не пользуетесь vim-ом).
О каких недостатках речь и в рамках каких задач? А то не очень понятно, как в разработке текстовый редактор может тягаться, например, с полноценной IDE, заточенной под работу с проектами.
О недостатках:
Я могу продолжать далее, если угодно.
А если Вы хотите услышать ответ по поводу «тягаться с IDE», то перечислите мне то, что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины и я дам вам ответ каким образом я решаю ту или иную задачу в Vim.
- Часто отсутствие полного контроля с клавиатуры, часто приходится прибегать к использованию мыши, особенно неприятно, когда эти действия становятся более менее частыми;
- Я не знаю другого редактора, который бы так же хорошо был заточен под 10-и пальцевую посадку, чтобы не было необходимости постоянно передёргиваться на «стрелочки» и обратно, а то и на мышь, руки всегда посажены в одном месте;
- Отсутствие комманд для быстрой контексто-зависимой навигации по коду, например, я смотрю на экран, хочу попасть в такое-то место, в вим я смотрю на relative-номер строки, делаю 10j (опускаюсь на 10 строк вниз), а потом допустим иду до первого символа “:” (f:) и удаляю всё что между “{” и “}” ( di} ), в прочих редакторах наикратчайший путь, как правило — взять в руки мышь и началь ей что-то выделать, для меня это довольно нудно;
- В vim я например набросал свой костыль для очистки пробелов и табов на концах строк, который делает именно то, что мне нужно, и повесил хук на запись в файл, он учитывает текущие настройки отступов, чтобы в случае чего не резать табы на пустых строка (т.к. в проекте так принято, для того чтобы легче было визуально воспринимать), чтобы не резать такие отступы также и в комментариях, т.к. это не пустые строки, которые могут иметь пробелы/табы на окончаниях и т.д., то есть применил вообще свой, достаточно замороченный алгоритм, каждый день мои коллеги испытвают проблемы, их редакторы либо режут лишнее, либо не режут вообще, а я решил проблему единоразово, написав свой кастомный хук;
- Отсутствие гибкости в биндах на сочетания клавиш, часто нельзя переопределить поведение стандартных сочетаний, необходимость в «аккордах», это основная фича вима, последовательные комбо, ;
- Отсутствие возможности повторить последнее действие, аля сделать это ещё N раз;
- Отсутствие возможности заменять одну часть системы на другую, либо сильная ограниченность в этом, в виме большинство задач, вроде каких-нибудь сниппетов или навигации по файлам выполняется с помощью различных плагинов, и если мне не нравится один путь, я всегда могу выбрать другой, настроить его под себя, например файл я могу открыть целой своро способов (fuzzy search из ctrlp, релятивное открытие в ctrlspace, дерево файлов nerdtree, дефолтные способы вроде :e :o, которые могут быть также весьма наглядны с помощью wildmenu), работа с табами/буфферами/окнами (стандартные способы, ctrlspace, всякие бары, которые кастомизируются и отображают необходимую тебе информацию);
Я могу продолжать далее, если угодно.
А если Вы хотите услышать ответ по поводу «тягаться с IDE», то перечислите мне то, что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины и я дам вам ответ каким образом я решаю ту или иную задачу в Vim.
что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины
Самое банальное — рефакторинг в большом проекте.
Это возможно для определённых языков, в которых структура проекта достаточно прозрачна (где такая автоматизация по сути возможна), у меня не возникало задач, где это можно было бы автоматизировать и я об этом не задумывался, то есть инцидента не возникало, не могу дать ответ, т.к. работаю в основном с ЯП, к которым это в большинстве случаев не применимо.
Прошло время и у меня появился ответ на ваш вопрос про рефакторинг (сам пользуюсь): CtrlSF
Насчет зависимости от мыши — мне не попадалось ничего подобного ни в одном приличном редакторе. Все пункты меню вызываются стандартными шоткатами или стрелками. А в мощных редакторах можно настроить комбинации клавиш для любых действий. Мышь является лишь альтернативой.
Что я имею в других редакторах?
— организацию проекта в виде дерева файлов с легкой навигацией по нему. Замечу, что файлы проекта != всем файлам в директории и субдиректориях.
— список функций в конкретном файле и быстрый переход по методам других классов в рамках проекта
— автокомплит, использующий названия переменных, методов и объектов всего проекта
— маркировка строк не влияющая на содержимое файлов
— привязка раскладки панелей к конкретному проекту.
— возможность «сворачивать» блоки
— собственно, функционал для отладки — панель с содержимым стека/переменных, брекпоинты и т.д.
Из дополнительных фич: поиск/замена в файлах проекта. Неограниченное undo/redo. Переключение на hex-view с некириллическим шрифтом (это спасало от целой бездны боли, связанной с русско-латинскими «c» и «o»). Визуальное превью текста для навигации. История клипборда.
Я тоже могу продолжать далее, если угодно. :-)
Что я имею в других редакторах?
— организацию проекта в виде дерева файлов с легкой навигацией по нему. Замечу, что файлы проекта != всем файлам в директории и субдиректориях.
— список функций в конкретном файле и быстрый переход по методам других классов в рамках проекта
— автокомплит, использующий названия переменных, методов и объектов всего проекта
— маркировка строк не влияющая на содержимое файлов
— привязка раскладки панелей к конкретному проекту.
— возможность «сворачивать» блоки
— собственно, функционал для отладки — панель с содержимым стека/переменных, брекпоинты и т.д.
Из дополнительных фич: поиск/замена в файлах проекта. Неограниченное undo/redo. Переключение на hex-view с некириллическим шрифтом (это спасало от целой бездны боли, связанной с русско-латинскими «c» и «o»). Визуальное превью текста для навигации. История клипборда.
Я тоже могу продолжать далее, если угодно. :-)
- В NERDTree можно фильтровать содержимое, не знаю на счёт конкретно вашей ситуации, и что конкретно из себя представлют файлы проекта в директории отдельно от каких файлов? Какие файлы в той же директории не являются файлами проекта?
- TagBar, gf (и ещё некоторые), возможно конечно в Вашей IDE это работает более навороченно;
- В Vim прекрасный автокомплит, по всем словам из всех октрытых файлов, так же есть куча вариаций с помощью плагинов, опять же по всем файла проекта и прочее, автокомплит у меня в виме работает ощутимо лучше, чем у моих коллег, предпочитающих IDE, при чём они сами это признают;
- Это всё тоже есть в Vim, если я правильно Вас понял, поясните что Вы понимаете под «маркировкой строк»?
- Тут нужно представить вашу ситуацию в ваккуме, что у вас за «панели»? Кастомный набор фреймов в Vim также реализуем, при чём независимый в каждом табе, и в каждом воркспейсе (например воркспейсы из ctrlspace);
- В vim-е есть фолды, как и везде, которые могу работать в пачке разных режимов, по вложенности, по синтаксису, по маркерам в комментариях и т.д.
- В виме вполне себе возможна конпеляция из него с получением отчётов, более гибко с брейкпоинтами я сам не видел, но не исключено что можно присобачить, возможно это будет хуже, чем в Вашей IDE.
Приведите пожалуйста в пример редакторы, которые, как Вы сказали, хороши для работы с клавиатуры?
1. Да все, что угодно: документация в doc/pdf, временные файлы, дампы базы, логи, служебные файлы SVN/CVS/GIT и так далее. Практически любая система контроля версий разделяет содержимое проекта и содержимое директорий. Соотв. редакторы должны уметь работать только с проектом, чтобы тот же поиск по всем файлам не застрял на каком-нибудь тридцатигигабайтном дампе базы.
2-3. Приведу пример. Я написал класс Fuzz с методом buzz и комментариями к нему. Потом я где-то завел переменную f класса Fuzz. Автокомплит должен мне автоматом показать метод buzz( ) и комментарий к нему, как только я наберу «f.» в области видимости объявленной переменной. А если я наведу курсор на f.buzz(), то в IDE есть возможность по хоткею сразу перейти к функции buzz конкретного класса Fuzz.
4. В UE можно расставлять метки на строках сочетанием клавиш Ctrl+F2, а затем по нажатию F2 перемещаться по ним. Удобно для отладки. При этом информация об этих метках хранится где-то самим редактором никак не затрагивая содержимое файла.
В качестве универсального редактора я использую UltraEdit, а в качестве IDE в последнее время в основном Eclipse.
2-3. Приведу пример. Я написал класс Fuzz с методом buzz и комментариями к нему. Потом я где-то завел переменную f класса Fuzz. Автокомплит должен мне автоматом показать метод buzz( ) и комментарий к нему, как только я наберу «f.» в области видимости объявленной переменной. А если я наведу курсор на f.buzz(), то в IDE есть возможность по хоткею сразу перейти к функции buzz конкретного класса Fuzz.
4. В UE можно расставлять метки на строках сочетанием клавиш Ctrl+F2, а затем по нажатию F2 перемещаться по ним. Удобно для отладки. При этом информация об этих метках хранится где-то самим редактором никак не затрагивая содержимое файла.
В качестве универсального редактора я использую UltraEdit, а в качестве IDE в последнее время в основном Eclipse.
- Не понял, важно чтобы ваш редактор открывал pdf/doc? оО Мне кажется для этого должен нужен не редактор кода, а соответсвующий целевой софт;
- Временные файлы есть в вим из коробки, более того, можно написать например `:earlier 15m` и получить состояние файла 15 минут назад, есть плагин gundo, который по факту представляет из себя версионирование файла с ветвлениями по временным точкам аля git, когда вдруг это нужно, очень удобная плюха;
- Что вы понимаете под фичей редактора/IDE «дампы базы, логи»?
- Для гита и прочиз CV целая свора плагинов, которые помимо прочего связываются ещё и с другими плагинами;
- Для этого есть набор плагинов, видел демо, но сам не пользовал, ничего подсказать не могу, т.к., повторюсь, работаю в основном с ЯП, где это малоприменимо;
- Метки в Vim есть, как я уже говорил раньше, и они тоже не затрагивают содержимое файла.
1. К сожалению, вы потеряли контекст обсуждения.
Речь шла о поддержке работы с файлами проекта и отличии их от всех файлов в директории проекта вообще. Потому как в директории проекта могут оказаться бинарные файлы типа doc/pdf, многогигабайтные дампы базы и рабочие логи на которых поиск завязнет навсегда, а так же многое другое, в чем не нужно искать и что не нужно отображать в списке на быстрое открытие.
2. Т.е. работаете с ЯП, в котором нет ни ООП, ни структур, ни библиотек? Я заинтригован. Ассемблер?
Речь шла о поддержке работы с файлами проекта и отличии их от всех файлов в директории проекта вообще. Потому как в директории проекта могут оказаться бинарные файлы типа doc/pdf, многогигабайтные дампы базы и рабочие логи на которых поиск завязнет навсегда, а так же многое другое, в чем не нужно искать и что не нужно отображать в списке на быстрое открытие.
2. Т.е. работаете с ЯП, в котором нет ни ООП, ни структур, ни библиотек? Я заинтригован. Ассемблер?
- Тогда я не понимаю почему вы решили, что это не реализуемо в Vim;
- javascript, в виду отсутствия единого пути ООП, модулей и прочего, — статический анализ очень затруднителен, я видел у коллег, как их IDE безуспешно обваливались при попытке найти корни например объявленных конструкторов исключений, которые генерируются динамически в виде простого хеш-мапа.
1. Так я и не решил, я просто не видел такого решения, вот и спросил. По-умолчанию vim не умеет почти ничего, но плагины могут это исправить. Вот мне и интересно, есть ли готовые решения для работы с проектами в своем формате или же cvs/svn/git. И если есть, то насколько они адекватны.
2. Некоторые проекты на некоторых других языках занимают мегабайты (а порой и десятки мегабайт) кода и содержат сотни классов и полусотни библиотек. Там для меня поддержка IDE крайне важна, поскольку довольно сложно помнить все параметры всех методов всех классов, зачастую имеющих одинаковые или схожие названия
2. Некоторые проекты на некоторых других языках занимают мегабайты (а порой и десятки мегабайт) кода и содержат сотни классов и полусотни библиотек. Там для меня поддержка IDE крайне важна, поскольку довольно сложно помнить все параметры всех методов всех классов, зачастую имеющих одинаковые или схожие названия
Вот красивый компьютер — первые 1000 слов памяти — прерывания, последние 1000 слов памяти — регистры внешних устройств. Но! Работать будет медленно, поэтому мы сделаем для внешних устройств прямой доступ в память — пусть пишут в параллель с центральным процессором. Давайте еще сделаем порты ввода-вывода для ускорения. Давайте память видеокарты добавим к памяти компьютера для ускорения записи.
Windows — давайте выжмем из электроники по максимуму и поиграем. Linux — давайте сделаем все канонично-логично и не спеша поработаем.
Путь Unix — отсутствие вирусов, только отсутствие вирусов и ничего кроме отсутствия вирусов. Все эти рассказки есть лишь рекомендации по реализации пути Unix.
Windows — давайте выжмем из электроники по максимуму и поиграем. Linux — давайте сделаем все канонично-логично и не спеша поработаем.
Путь Unix — отсутствие вирусов, только отсутствие вирусов и ничего кроме отсутствия вирусов. Все эти рассказки есть лишь рекомендации по реализации пути Unix.
что хорошо бы использовать эквивалент «печать»
Как насчет чего-нибудь вроде «я приложил руку к...» (проектированию, строительству,… этих домов)?
Гм. ed — не потоковый редактор. Он линейно-ориентированный, да, но при этом вполне интерактивный. Потоковый редактор — это sed. Stream Ed.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Полный перевод Unix-коанов на русский язык