Comments 53
Радует, что есть очень достойная замена VIM'а в среде Windows без использования всяких «консольных» костылей!
notepad.exe, не?
обязательно начнем использовать notepad, после введения поддержки плагинов, подсветки и консоли
Notepad++ или Sublime Text, не?
начну испольовать sublime как только он появится в консоли, хотя… есть ведь vim. Иногда необходимо дописывать код прямо на сервере и боюсь, что в эти моменты gui инструменты бесполезны, а во всех остальных ситуациях, есть производные от idea
rmate к sublime поможет «дописывать код прямо на сервере» в sublime у себя на компе
качать весь проект из репозитария, что бы у кого-то исправить пару-тройку строк, боюсь это плохая идея. Vim же на сервере подхватит все настройки и можно будет в гостях чувствовать себя как дома., затем сделать долгожданный деплой хотфикса и радоваться происходящему. К тому же, код будет отредактирован максимально безопасно.
Вы идею rmate не поняли, «качать весь проект из репозитария» не нужно, только файл который править хотите. А что бы " гостях чувствовать себя как дома" это вам как раз надо все свои настройки, плагины и прочий хлам на каждый сервер тащить. Да и вообще идея править код на продакшене руками явно от лукавого, настройте уж нормальную систему выкладки кода.
Вы наверное не поняли автора предыдущего комментария. rmate это утилита и плагин к редактору(сейчас он называется rsub), который позволяет через ssh туннель открыватьлюбые файлы на сервере и редактировать их в вашем любимом текстовом редакторе. Например: rmate /etc/hosts в таком случае /etc/hosts откроется в вашем любимом текстовом редакторе, после внесения изменений в файле и сохранив его он автоматически сохранится и на сервере.
Тут главное что не в том что редактор любимый, а в том что он на локальной стороне.
но так же можно ведь писать сразу на тестовом сервере и иметь там свой конфиг vim, что не принуждает Вас настраивать софт или ставить плагины, ведь где бы Вы не были, код будет в одном и том же окне. В том виде, в каком Вы его оставили, словно Вы и не уходили с работы домой, или к другу. Ваша среда — всегда с собой. нужен лишь Putty на флешке, либо ssh, в зависимости от обстоятельств :)
Ну так тогда этот комп и становится «локальным», просто доступ к нему через тонкий клиент. А тут тема всё таки про редактирование файла на удаленной машине.
Вы залили свои правки и тестируете, что все работает как нужно, в это время другой разработчик заливает свой код, который пересекается с вашим. Вы спокойно комитете, пушите и обновляете на боевом, только что же проредили все. И через 1-2 дня или недели — сюрприз — начинает глючить какой-то блок или какая-то очень уникальная ситуация возникает. И чем больше разработчиков, которые любят править и пушить код с тестового или боевого сервера, тем больше таких ошибок. Возможно вы напишите, что работаете с этой тестовой машиной только вы, но тогда это называется машина для разработки.
А если файл огромный, то перед тем, как его открыть, этот инструмент будет его выкачивать целиком?
править код сразу на боевом сервере — удачи!
и как вам такое в голову то пришло? :) или у Вас тестовый = боевой? Правим на тестовом, тестим, пушим, пулим на боевом, схема предельна проста.
Если вы разрабатываете и тестируете один, то возможно это еще и нормально. Но если в команде есть тестер и еще несколько разработчиков, то количество непонятных ошибок будет расти в геометрической прогрессии. Разрабатывать, комитеть и пушить нужно только с сервера для разработки! Все остальное плюс-минус как играть в русскую рулетку на боевом сервере.
Спасибо за rmate!
vim, не?
Сам пользуюсь Notepad++ и мне он вполне по нраву, но вот недавно была статья, что развитие этого редактора здорово затормозилось в последние годы.
Таки VIM(VI) в стандартной поставке в любых юниксах, то этот коммент как бы намекал на сарказм, не?
обязательно начнем использовать notepad, после введения поддержки плагинов, подсветки и консоли
Даже без поддержки плагинов, подсветки и консоли Vim — текстовый редактор. А notepad.exe — смотровая щель в танке и спичка в руках.
Сначала вы этот танк заведите да прогрейте, потом вы на нём доберитесь, куда надо, и только затем — один глаз прищурьте, другой в смотровую щель и туда же спичку вытянутыми пальцами. Останется только нацарапать ей, как стилосом, что нужно (не сломайте!) и повторить всё действо достаточное число раз.
Есть мнение, что проще переписать заново. Сам Брэм Муленар не разбирается уже во всей кодовой базе.
С другой стороны, идея здравая. Хорошо, что проект всё так же open source. Будем следить.
С другой стороны, идея здравая. Хорошо, что проект всё так же open source. Будем следить.
news.ycombinator.com/item?id=7278594
Часть скептиков считает, что главная проблема Vim — это vimscript. Если убрать его, то это будет уже не вим, а если оставить как есть, то переписывание теряет немалую часть своего смысла.
I'm not sure how I feel about this. On the one hand I've been thinking on it for quite a long time already, newer shinier Vim is something I secretly wish for. On the other hand I found it quite problematic. The main problem of Vim is Vimscript. So «newer shinier Vim» is Vim with real programming language instead of vimscript. But it's impossible to remove Vimscript: it won't be Vim anymore. It affects not only scripting itself, but also how we interact with it in command mode, not to say about plugins we have already.
Часть скептиков считает, что главная проблема Vim — это vimscript. Если убрать его, то это будет уже не вим, а если оставить как есть, то переписывание теряет немалую часть своего смысла.
а если сделать транслятор из vimscript в тот-скриптовый-язык-который-будет-испльзоваться-вместо? Тогда большинство планигов можно будет использовать после конвертации, а кодовая база вима при этом упростится. Или у vimscript все настолько плохо что его синтаксис/семантику только вим понимает?
Для VimL нельзя составить синтаксический парсер: значение символов
Это не единственная проблема, но вторую можно просто игнорировать:
Я пока не припоминаю никаких других проблем, но они наверняка найдутся, если вы начнёте писать транслятор.
| и новой строки зависит от контекста выполнения. Сделать хак для парсера, чтобы он нормально это обрабатывал ещё можно, но это не всё: значение тех же символов (особенно первого) также зависит и от состояния интерпретатора, а именно от того, как определена пользовательская команда (если, конечно, именно она стоит до данных символов). То есть вы не можете распарсить строчку «Foo abc|let a=1» пока не выполните предыдущую, так как она может содержать command! -nargs=1 -bar Foo :echo <q-args>, а может command! -nargs=1 Foo :echo <q-args>.Это не единственная проблема, но вторую можно просто игнорировать:
execute 'if '.condition
echo 'True'
endifexecute 'append'
let b=1
.Я пока не припоминаю никаких других проблем, но они наверняка найдутся, если вы начнёте писать транслятор.
Что не додумались запретить, так этоЯ сейчас подумал и понял, что тут дело не в «не додумались». Если в первом случае можно просто написать
execute 'append' let b=1 .
. Впрочем, если ваш парсер будет считать, что тут есть присваивание, то это вряд ли кого огорчит.
if eval(condition), то во втором вы можете захотеть написать execute line_number . 'append' и потом собственно добавляемые строки. Правда это не отменяет тех фактов, что, во‐первых, добавляемые строки можно засунуть в execute и, во‐вторых, я ни разу не видел, чтобы кто‐то использовал append (правда, я уверен, что кто‐то его использует). Так что, возможно, незавершённый append не запрещён, чтобы кому‐то не пришлось возиться с line continuation и кучей дополнительных символов (кавычки, \n и точка для объединения строк).Три факта во вред
append: - подсветка синтаксиса для него предполагает, что завершающая точка должна находиться строго в начале строки (на самом деле она может находиться также на одном уровне отступа с командой
append). Также подсветка не работает сexecute 'append' - при вставке отступ сохраняется
- при использовании
append!(с восклицательным знаком) не решает проблему с отступом, и впридачу не позволяет использовать отступ перед точкой
Это я к тому, что нормальный разработчик обычно предпочтёт не использовать
append, так как с высокой вероятностью ему придётся либо переделывать отступ у вставляемого append текста, либо нарушать отступы в своём тексте. Впрочем, такое останавливает далеко не всех.
Talk is cheap show me the code.
Немного настораживаюсь, когда вижу такие планы (новая архитектура! новая плагинная система! json-rpc! libuv!). На мой взгляд для реалистичности исполнения для первой итерации нужно менее значительные архитектурные изменения и включить в план какие-нибудь фичи которые добавляют в редактор конечной ценности для пользователей, иначе после значительных усилий получается продукт который не имеет пока никаких преймуществ для пользователей.
Немного настораживаюсь, когда вижу такие планы (новая архитектура! новая плагинная система! json-rpc! libuv!). На мой взгляд для реалистичности исполнения для первой итерации нужно менее значительные архитектурные изменения и включить в план какие-нибудь фичи которые добавляют в редактор конечной ценности для пользователей, иначе после значительных усилий получается продукт который не имеет пока никаких преймуществ для пользователей.
Код на Github, там же расположен краткий roadmap («Status» в README), в котором указано, что уже есть и над чем планируется работа. Сразу впиливать json никто не собирается. Конечные ценности в принципе понятны — более чистая кодовая база, меньше ошибок (которых я и без этого не встречал), бóльшая модульность кода.
Я так понимаю, по ссылке на гитхабе импортированные исходники vim-а по большей части? Определенные проблемы там, видимо, есть, потому что функции buf_write (~1500 строк) и readfile (~1800 строк) и впрямь сложноваты для понимания.
Но я слабо себе представляю, как подобное количество кода можно облагородить — проще переписать заново, но есть ли в этом смысл? Самое лучшее, что есть в vim — это модальное редактирование. Самый разумный вариант ИМХО грамотно перенести этот режим в полноценные IDE, потому как скриптовать IDE даже на elisp-е (не говоря о vimscript) та еще боль.
P. S. vim user с семилетним стажем
Но я слабо себе представляю, как подобное количество кода можно облагородить — проще переписать заново, но есть ли в этом смысл? Самое лучшее, что есть в vim — это модальное редактирование. Самый разумный вариант ИМХО грамотно перенести этот режим в полноценные IDE, потому как скриптовать IDE даже на elisp-е (не говоря о vimscript) та еще боль.
P. S. vim user с семилетним стажем
Stretch goals:
[...]
$50,000: Refactor system calls into an abstraction module backed by libuv when compiled to machine code, and backed by a javascript library when compiled to into asm.js through emscripten [...] In a few words, this will port neovim to run natively in modern web browsers.
Полноценный Vim в браузере? Запледжил 50 баксов. :)
Надеюсь доберется до $50000. В перспективе этот код может быть добавлен в Brackets.
Зря донатили :D coolwanglu.github.io/vim.js/web/vim.html
Ну что же, почти за месяц работы легко увидеть значительный рефакторинг в такие важные части проекта как README.md:
Всего $10,000 и качество описания наполеоновских планов вырастет до небес.
Всего $10,000 и качество описания наполеоновских планов вырастет до небес.
Стало интересно, неужели только Readme?
Попробовал восстановить вероятную версию истории процесса начала работы над проектом, основываясь на коммитах из гитхаба:
1. Больше 20 дней назад он сделал большой коммит в разные куски проекта: работа c diff'ом, диграфами, командами Ex и т.п. (внимание, история грузится очень долго и жрет проц);
2. Затем он скорее всего 20 дней оценивал сроки по переработке всей кодовой базы. Да, аудит 300k строк кода за 3 недели это много, но в FAQ сказано, что он уже принимал участие в разработке Vim, так что такая цифра мне кажется вполне реальной;
3. Возможно, параллельно с оценкой сроков продумывал план фаундрайзинга;
4. Затем перед запуском кампании на bountysource отшлифовал Readme — как говорится по одежке встречают :)
Попробовал восстановить вероятную версию истории процесса начала работы над проектом, основываясь на коммитах из гитхаба:
1. Больше 20 дней назад он сделал большой коммит в разные куски проекта: работа c diff'ом, диграфами, командами Ex и т.п. (внимание, история грузится очень долго и жрет проц);
2. Затем он скорее всего 20 дней оценивал сроки по переработке всей кодовой базы. Да, аудит 300k строк кода за 3 недели это много, но в FAQ сказано, что он уже принимал участие в разработке Vim, так что такая цифра мне кажется вполне реальной;
3. Возможно, параллельно с оценкой сроков продумывал план фаундрайзинга;
4. Затем перед запуском кампании на bountysource отшлифовал Readme — как говорится по одежке встречают :)
Что-то мне подсказывает, что большая часть (процентов этак 95) добавленных строк этого коммита это не новый код, а переформатированные автоматическими инструментами уже существующие исходники. И это что-то — сообщение коммита:
"- Process files through unifdef to remove tons of FEAT_* macros
— Process files through uncrustify to normalize source code formatting."
P.S. И чтобы узнать это мне даже не понадобилось грузить всю историю c;
"- Process files through unifdef to remove tons of FEAT_* macros
— Process files through uncrustify to normalize source code formatting."
P.S. И чтобы узнать это мне даже не понадобилось грузить всю историю c;
UFO just landed and posted this here
Обычно есть разумный баланс.
Например, есть плагин к Visual Studio — VsVim. Open-source F# код. Работает очень хорошо, полностью покрывает мой сабсет. Допускаю что есть люди чей сабсет покрыт не полностью, но думаю что таки очень большой процент пользователей Vim будет доволен.
Например, есть плагин к Sublime Text — Vintageous. Open-source Python код. Работает очень плохо, очень легко сломать стейт загнав плагин в перманентное исключение, плюс автор видимо мало пользуется Vim или пользуется другим сабсетом чем я т.к. половина нужной мне Vim функциональности не работает или работает иначе.
Конечно, ряд вещей типа плагинов или всяких Ex фишек типа argdo отсутствует и там и там, но с VsVim приятно работать, а с Vintageous — нет. Т.е. если Vim workflow подразумевает кучу кастомных key bindings и плагинов то наверное никуда не деться.
Например, есть плагин к Visual Studio — VsVim. Open-source F# код. Работает очень хорошо, полностью покрывает мой сабсет. Допускаю что есть люди чей сабсет покрыт не полностью, но думаю что таки очень большой процент пользователей Vim будет доволен.
Например, есть плагин к Sublime Text — Vintageous. Open-source Python код. Работает очень плохо, очень легко сломать стейт загнав плагин в перманентное исключение, плюс автор видимо мало пользуется Vim или пользуется другим сабсетом чем я т.к. половина нужной мне Vim функциональности не работает или работает иначе.
Конечно, ряд вещей типа плагинов или всяких Ex фишек типа argdo отсутствует и там и там, но с VsVim приятно работать, а с Vintageous — нет. Т.е. если Vim workflow подразумевает кучу кастомных key bindings и плагинов то наверное никуда не деться.
Для производных от IDEA ide, также доступен плагин IdeaVim
Пользуюсь Vim часто и давно, но полностью перейти на NeoVim в свое время, помешала неработоспособность плагина YouCompleteMe в последнем. Однако время от времени я обновлял (как я тогда думал) NeoVim и проверял его с моим рабочим vimrc файлом.
Обновлял через homebrew командой:
Однако как в последствии выяснилось, правильно обновлять neovim надо следующей командой:
для поддержки YouCompleteMe плагина, так же надо установить дополнение:
После «правильного» обновления скормил свой vimrc файл без всяких изменений neovim'у и o чудо все плагины работают на ура!
Обновлял через homebrew командой:
brew upgrade neovim
Однако как в последствии выяснилось, правильно обновлять neovim надо следующей командой:
brew reinstall --HEAD neovim
для поддержки YouCompleteMe плагина, так же надо установить дополнение:
sudo pip2 install neovim
После «правильного» обновления скормил свой vimrc файл без всяких изменений neovim'у и o чудо все плагины работают на ура!
Ответ уже явлен миру
Интересно что ответ разделяет мои опасения из комментария выше.
It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly?
Это не клон. Это форк.
Sign up to leave a comment.
Neovim: современный клон текстового редактора Vim