Быстрый доступ совсем тогда окажется не быстрым, когда тебе нужно подержать день-другой пару вееров вкладок по определённой теме, особенно когда суммарно их 20 и более, а в день ещё пару таких промежуточных "воркспейсов" возникает, и это в конце-концов единый быстрый доступ, а не сепарированный по 3-ём разным направлениям например, не так ли?;
Вот когда вкладок реально много (>20), — путаешься, да ещё как!
Когда работаю, держу по несколько групп вкладок минимум, каждая под свою задачу, могу спокойно вырубать браузер на пустой группе, когда снова возвращаюсь к работе, просто открываю нужную группу, при этом, пока я её не открою — вкладки грузиться не будут, что экономит ресурсы при том, что у вас зарезервирована целая свора вкладок, ориентироваться в которых в пределах одной группы (то-есть без данной фичи вовсе), — вообще непредставляется реальным.
Вот подходит коллега допустим, нужно решить какую-то задачу, и вместо того чтобы засорять веер и без того из 10 вкладок по теме, просто открываю новую группу, решаем задачу, и после открываю предыдущую группу обратно. Закладки и близко по скорости и удобству не решат эту задачу.
Например я являюсь активным пользователем данной фичи, но плагин вроде бы польностью повторяет функционал, так что как по мне это даже лучше, даёшь юникс-вей во все поля!
Тогда я не понимаю почему вы решили, что это не реализуемо в Vim;
javascript, в виду отсутствия единого пути ООП, модулей и прочего, — статический анализ очень затруднителен, я видел у коллег, как их IDE безуспешно обваливались при попытке найти корни например объявленных конструкторов исключений, которые генерируются динамически в виде простого хеш-мапа.
Не понял, важно чтобы ваш редактор открывал pdf/doc? оО Мне кажется для этого должен нужен не редактор кода, а соответсвующий целевой софт;
Временные файлы есть в вим из коробки, более того, можно написать например `:earlier 15m` и получить состояние файла 15 минут назад, есть плагин gundo, который по факту представляет из себя версионирование файла с ветвлениями по временным точкам аля git, когда вдруг это нужно, очень удобная плюха;
Что вы понимаете под фичей редактора/IDE «дампы базы, логи»?
Для гита и прочиз CV целая свора плагинов, которые помимо прочего связываются ещё и с другими плагинами;
Для этого есть набор плагинов, видел демо, но сам не пользовал, ничего подсказать не могу, т.к., повторюсь, работаю в основном с ЯП, где это малоприменимо;
Метки в Vim есть, как я уже говорил раньше, и они тоже не затрагивают содержимое файла.
В NERDTree можно фильтровать содержимое, не знаю на счёт конкретно вашей ситуации, и что конкретно из себя представлют файлы проекта в директории отдельно от каких файлов? Какие файлы в той же директории не являются файлами проекта?
TagBar, gf (и ещё некоторые), возможно конечно в Вашей IDE это работает более навороченно;
В Vim прекрасный автокомплит, по всем словам из всех октрытых файлов, так же есть куча вариаций с помощью плагинов, опять же по всем файла проекта и прочее, автокомплит у меня в виме работает ощутимо лучше, чем у моих коллег, предпочитающих IDE, при чём они сами это признают;
Это всё тоже есть в Vim, если я правильно Вас понял, поясните что Вы понимаете под «маркировкой строк»?
Тут нужно представить вашу ситуацию в ваккуме, что у вас за «панели»? Кастомный набор фреймов в Vim также реализуем, при чём независимый в каждом табе, и в каждом воркспейсе (например воркспейсы из ctrlspace);
В vim-е есть фолды, как и везде, которые могу работать в пачке разных режимов, по вложенности, по синтаксису, по маркерам в комментариях и т.д.
В виме вполне себе возможна конпеляция из него с получением отчётов, более гибко с брейкпоинтами я сам не видел, но не исключено что можно присобачить, возможно это будет хуже, чем в Вашей IDE.
Приведите пожалуйста в пример редакторы, которые, как Вы сказали, хороши для работы с клавиатуры?
Это возможно для определённых языков, в которых структура проекта достаточно прозрачна (где такая автоматизация по сути возможна), у меня не возникало задач, где это можно было бы автоматизировать и я об этом не задумывался, то есть инцидента не возникало, не могу дать ответ, т.к. работаю в основном с ЯП, к которым это в большинстве случаев не применимо.
Часто отсутствие полного контроля с клавиатуры, часто приходится прибегать к использованию мыши, особенно неприятно, когда эти действия становятся более менее частыми;
Я не знаю другого редактора, который бы так же хорошо был заточен под 10-и пальцевую посадку, чтобы не было необходимости постоянно передёргиваться на «стрелочки» и обратно, а то и на мышь, руки всегда посажены в одном месте;
Отсутствие комманд для быстрой контексто-зависимой навигации по коду, например, я смотрю на экран, хочу попасть в такое-то место, в вим я смотрю на relative-номер строки, делаю 10j (опускаюсь на 10 строк вниз), а потом допустим иду до первого символа “:” (f:) и удаляю всё что между “{” и “}” ( di} ), в прочих редакторах наикратчайший путь, как правило — взять в руки мышь и началь ей что-то выделать, для меня это довольно нудно;
В vim я например набросал свой костыль для очистки пробелов и табов на концах строк, который делает именно то, что мне нужно, и повесил хук на запись в файл, он учитывает текущие настройки отступов, чтобы в случае чего не резать табы на пустых строка (т.к. в проекте так принято, для того чтобы легче было визуально воспринимать), чтобы не резать такие отступы также и в комментариях, т.к. это не пустые строки, которые могут иметь пробелы/табы на окончаниях и т.д., то есть применил вообще свой, достаточно замороченный алгоритм, каждый день мои коллеги испытвают проблемы, их редакторы либо режут лишнее, либо не режут вообще, а я решил проблему единоразово, написав свой кастомный хук;
Отсутствие гибкости в биндах на сочетания клавиш, часто нельзя переопределить поведение стандартных сочетаний, необходимость в «аккордах», это основная фича вима, последовательные комбо, ;
Отсутствие возможности повторить последнее действие, аля сделать это ещё N раз;
Отсутствие возможности заменять одну часть системы на другую, либо сильная ограниченность в этом, в виме большинство задач, вроде каких-нибудь сниппетов или навигации по файлам выполняется с помощью различных плагинов, и если мне не нравится один путь, я всегда могу выбрать другой, настроить его под себя, например файл я могу открыть целой своро способов (fuzzy search из ctrlp, релятивное открытие в ctrlspace, дерево файлов nerdtree, дефолтные способы вроде :e :o, которые могут быть также весьма наглядны с помощью wildmenu), работа с табами/буфферами/окнами (стандартные способы, ctrlspace, всякие бары, которые кастомизируются и отображают необходимую тебе информацию);
Я могу продолжать далее, если угодно.
А если Вы хотите услышать ответ по поводу «тягаться с IDE», то перечислите мне то, что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины и я дам вам ответ каким образом я решаю ту или иную задачу в Vim.
Я когда-то давно начал использовать вим из-за того, что ни один редактор не мог оставить меня довольным собой, я всех и не вспомню, в каждом мне в итоге хотелось изменить ряд вещей. Одни лагали, другие были неудобны, третьи поддерживали очень ограниченный список языков, в других нельзя было кастомизировать тривиальные вещи и т.д. и т.п. А о вим я был наслышан как о редакторе, который можно вертеть и крутить, что ж, это оказалось чистой правдой.
С тех пор я серьёзно прокачал конфиг, и то, как я работаю в виме с целой сворой плагинов сейчас, напоминает работу в «голом» vim очень отдалённо, автоматизировал кучу вещей и привык к куче комманд, которые позволяют мне вместо нудного для меня тыкания по всяким «стрелочкам» и елозинья мышкой производить целевые действия, часто используемые комбинации доведенны до рефлексов. Что меня по прежнему не перестаёт радовать, — я могу заставить редактор подстроиться под меня, он не навязывает мне свою рутину.
Сейчас мне сложно себе представить переход на другой редактор, в том смысле что я вряд ли смогу также тщательно заточить под себя другой редактор (разве что какой-нибудь emacs), это как минимум потребует немало времени, и скорее всего мне прийдётся принять целый ряд ограничений, и я не вижу никакой объективной пользы от перехода. Я часто вижу чужие редакторы у коллег, и я в первые минуты вижу ряд недостатков и ограничений и когда я спрашиваю у коллег, как бы они сделали то-то, оказывается что это они педалят вручную и скорее всего в их редакторе просто нет более краткого решения. Vim начинает делать практически всё, как только я начинаю в этом нуждаться.
По вопросу могу сказать, что если вы нюфаг, или вас итак всё устраивает, вы эффективно решаете свои задачи, то оно того наверняка не стоит, т.к. рвать шаблон будет сильно, особенно первый месяц непрерывной работы, если только для фана, авось зацепит. Первое время вы будете думать по большей части о редакторе, а не о коде. Если же вас смущают ограничения вашего редактора, которые вы не можете преодолеть, то однозначно стоит попробовать vim, т.к. он не возбраняет изменять себя до неузноваемости.
Большая однако паста получилась.
P.S. Нюфагам — первым делом ремапьте capslock чтобы использовать его вместо ctrl (даже если не пользуетесь vim-ом).
XMPP уже частично решил то, что вы описали, с помощью транспортов. Но это костыль, было бы гораздо лучше, если бы был открытый и прозрачный протокол, не крышованый всякими анальными патентами.
Telegram по прежнему централизованный и проприетарный (за частичным исключением клиента, на сколько мне известно). Все эти мейнстрим мессенджеры, крышуемые компаниями, не заменят XMPP/Jabber и IRC, ну или Tox в конце-концов.
А зачем вообще иметь перманентных жён/детей? Вот какова ваша личная мотивация? Оно стоит того, чтобы пожертвовать целым рядом свобод, а то и вообще целиком посвятить этому свою жизнь?
Повышенные частоты дискретизации имеет смысл применять при оцифровке аналогого сигнала, то-есть допустим при записи материала на студии, т.к. побочный ультразвук накладывается в слышимый диапазон методом «вращения колеса в обратную сторону», что по сути является «шумодобавлением», а аналоговые фильтры, применяемые в звуковых картах для среза ультразвука, далеко не так совершенны как цифровые. Впрочем при достаточном качестве железа, его малошумности — этот эффект будет незначительным. Ещё имеет смысл использовать опять же при записи для борьбы с джиттером, но сейчас железо стало достаточно качественным, и проблем с джиттером практически не возникает вообще.
Уже давно использую ноду и npm для деплоя фронт-енда, лучше npm, grunt/gulp для этого ничего не нашёл, тем более такого удобного и универсального, большая база модулей на все случаи жизни, один раз только что-то писал специфичное для grunt, свой плагин. В конечном итоге начали повторяться какие-то шаблонные вещи, тогда сделал отдельный npm-пакет как обёртку над gulp, которая настраивается с минимальным порогом вхождения через package.json в локальном проекте, научить нюфагов делать `npm install` и `gulp`/`gulp --production`/`gulp watch` гораздо проще, чем проделывать дополнительные манипуляции, свойственные некоторым другим яп и их дефолтным менеджерам пакетов.
Во фронтенде не раз использовал three.js для панорам, который весит поболее 230кб (минифицированный 430кб), и грузить его надо, только когда дело до панорам доходит. Тут RequireJS себя с лучшей стороны показывает, предоставляя такие возможности.
Прошу прощения за оффтопик, но разве нельзя было обойти такое узкое место как липкий бит для рута? Это же большая дыра, какое-нибудь переполнение буфера даже не в самом хромиуме, а в библиотеке, которую он использует — и мы имеем привилегии суперпользователя.
Вот подходит коллега допустим, нужно решить какую-то задачу, и вместо того чтобы засорять веер и без того из 10 вкладок по теме, просто открываю новую группу, решаем задачу, и после открываю предыдущую группу обратно. Закладки и близко по скорости и удобству не решат эту задачу.
Приведите пожалуйста в пример редакторы, которые, как Вы сказали, хороши для работы с клавиатуры?
Я могу продолжать далее, если угодно.
А если Вы хотите услышать ответ по поводу «тягаться с IDE», то перечислите мне то, что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины и я дам вам ответ каким образом я решаю ту или иную задачу в Vim.
С тех пор я серьёзно прокачал конфиг, и то, как я работаю в виме с целой сворой плагинов сейчас, напоминает работу в «голом» vim очень отдалённо, автоматизировал кучу вещей и привык к куче комманд, которые позволяют мне вместо нудного для меня тыкания по всяким «стрелочкам» и елозинья мышкой производить целевые действия, часто используемые комбинации доведенны до рефлексов. Что меня по прежнему не перестаёт радовать, — я могу заставить редактор подстроиться под меня, он не навязывает мне свою рутину.
Сейчас мне сложно себе представить переход на другой редактор, в том смысле что я вряд ли смогу также тщательно заточить под себя другой редактор (разве что какой-нибудь emacs), это как минимум потребует немало времени, и скорее всего мне прийдётся принять целый ряд ограничений, и я не вижу никакой объективной пользы от перехода. Я часто вижу чужие редакторы у коллег, и я в первые минуты вижу ряд недостатков и ограничений и когда я спрашиваю у коллег, как бы они сделали то-то, оказывается что это они педалят вручную и скорее всего в их редакторе просто нет более краткого решения. Vim начинает делать практически всё, как только я начинаю в этом нуждаться.
По вопросу могу сказать, что если вы нюфаг, или вас итак всё устраивает, вы эффективно решаете свои задачи, то оно того наверняка не стоит, т.к. рвать шаблон будет сильно, особенно первый месяц непрерывной работы, если только для фана, авось зацепит. Первое время вы будете думать по большей части о редакторе, а не о коде. Если же вас смущают ограничения вашего редактора, которые вы не можете преодолеть, то однозначно стоит попробовать vim, т.к. он не возбраняет изменять себя до неузноваемости.
Большая однако паста получилась.
P.S. Нюфагам — первым делом ремапьте capslock чтобы использовать его вместо ctrl (даже если не пользуетесь vim-ом).