Часть редактора Atom переписали на С++, чтобы не так тормозил

Ну, ч такими «бонусами» немудрено что он уже практически все просрал.

больше «зрелых» плагинов

;)

https://trends.google.com/trends/explore?q=/m/0_x5x3g,/m/0b6h18n,vscode

хде?

Да не всё там однопоточненько.

Редактор называется visual studio code или code

VSCODE - это неофициально ;)

Ну и читерство в ваших сравнениях видно невооруженным взглядом, так как Atom - text editor , sublime - software но VSCODE - search term.

Но из наблюдения в быту, на саблайме упорно сидят только упертые «дизайнеры».

Наверно те, кому старт редактора в 0.7с вместо 1.5с критичен ;)

(Моё личное наблюдение)

А зачем вам вообще vim, если для вас insert mode является основным?

Вы понимаете, что иногда люди пишут код, вводят текст, правят что-то?
Именно по этой причине в самом инсерт-моде также есть функция навигации по словам, работа с буффером обмена и даже скроллинг окна (и вообще :help insert-mode).
Редактор не только запускают лишь для того, чтобы пару раз нажать dd в nginx.conf?

Это не косяк философии vim, а косяк использования инструмента.

Он самый, если хотите иначе, это косяк автора в выборе терминологии.

Ну и читерство

Какое читерство? Мне наплевать на vscode. Я вообще саблю использую.

Если вам не нравится ссылка - сделайте лучше.

Думаешь так показательнее?

Саму идею сравнения популярности редакторов по гугл трендам не приветстую.

Вы понимаете, что иногда люди пишут код, вводят текст, правят что-то?

Я это прекрасно понимаю, поскольку vim - это мой основной и единственный редактор кода для плюсов.
Потому для меня странно, что кто-то хочет навигацию в insert mode.

Именно по этой причине в самом инсерт-моде также есть функция навигации по словам, работа с буффером обмена и даже скроллинг окна (и вообще :help insert-mode).

Если у вас insert-mode является основным режимом, значит вы что-то делаете не так.

Редактор не только запускают лишь для того, чтобы пару раз нажать dd в nginx.conf?

Правда?

Блин, я вообще написал вначале по конкретную проблему боже мой: в длинной строке которая перенесена нельзя как обычно быстро передвинуть курсор вверх — любому человеку очевидно, что это неудобно.
Этот редактор про сокращение количества нажатий на кнопки, а не про увеличение — то что можно решить нажатием на стрелку вверх/вниз - требует нажатия esc-g-j/k.
Вы поймите — для вас это не проблема, вы с этим не сталкивались, вы используете редактор единственно верным, одобренным партией образом — писать код на C++, 80 колонок, замечательно — поддерживаю.
Но иногда людям надо открывать файлы с другим количеством колонок, например с какими-то зубодробительными логами или просто текстом написанным не с таким тщанием, в другом редакторе (да вим не единственный редактор на свете).
Считаю свою претензию к виму абсолютно обоснованной — это баг, а не фича.
Боже да просто стрелочки позволить использовать нормальным образом в инсерт-моде ну что такого-то ёлки зелёные.
Нет вы что-то делаете неправильно, будто я вимом пытаюсь слушать mp3.

Думаешь так показательнее?

Хз.
Но сравнивать все треды связанные с саблайм даже там где он не упоминается с узким поиском - несколько неверно

Саму идею сравнения популярности редакторов по гугл трендам не приветстую.

Я тоже.

SO и то лучше.

Атом с VSCODE можно по количеству контрибьюторов сравнивать а с саблаймом - хз как.

Вот что бывает, когда мажоры пишут софт. Редакторы жрущие гигабайты места на жестком диске и написанные на тормознутых тулкитах - ненужны! Есть прекраксный Notepad++, а для истинных ценителей Emacs. Задачу решать надо на том, что задаче подходит, а не потому что модно, стильно и попсово

А в VIM'е в режиме ввода нельзя между строками (т.е. внутри длинной строки разбитой на экране на несколько строк) перемещаться вверх вниз без тормозящего переключения в нормальный режим.

CTRL-O gj/gk
:h i_CTRL-O

тормозящего переключения в нормальный режим.

Ищите что у вас лично тормозит (плагины, автокоманды, терминал по Esc может тупить, ожидая продолжения какой-либо своей команды, особенно если tmux или что-то такое).

Блин, я вообще написал вначале по конкретную проблему боже мой: в длинной строке которая перенесена нельзя как обычно быстро передвинуть курсор вверх — любому человеку очевидно, что это неудобно.

Любому вимеру очевидно, что навигация в insert-mode признак неправильного использования инструмента.

Этот редактор про сокращение количества нажатий на кнопки, а не про увеличение — то что можно решить нажатием на стрелку вверх/вниз - требует нажатия esc-g-j/k.

Вот я и говорю - вам на emacs или любой другой редактор, где insert-mode является единственным и основным режимом.

Вы поймите — для вас это не проблема,

Это для любого вимера не проблема.

вы с этим не сталкивались, вы используете редактор единственно верным, одобренным партией образом — писать код на C++, 80 колонок, замечательно — поддерживаю.

Вы внук бабы Ванги?

Но иногда людям надо открывать файлы с другим количеством колонок, например с какими-то зубодробительными логами или просто текстом написанным не с таким тщанием, в другом редакторе (да вим не единственный редактор на свете).

Если нужно открывать файл в другом редакторе, то какие претензии к виму?

Считаю свою претензию к виму абсолютно обоснованной — это баг, а не фича.

Только пока вы не смогли свою претензию обосновать.

Боже да просто стрелочки позволить использовать нормальным образом в инсерт-моде ну что такого-то ёлки зелёные.

Еще раз, insert-mode не предназначен для навигации. Да, в этом режиме навигация возможна, но лишь как исключение.

Прекрасно знаю про Ctrl-O (временное переключение), этот костыль и использую, другого выбора нет — именно он генерит тормоза, переключение режима в виме это дорогая операция. Тормозит и с плагинами и без.
Может быть у вас супер-мага параллельный VIM который бежит на Intel Xeon 32-ядерном — у меня же прекрасно видно это — VIM просто подзалипает, и становится ватно — такого быть не должно.
Если у вас есть RPi или виртуалка, можете проверить, окунуться во фрактал боли.
Я вобщем-то не спрашиваю совета как это обойти — потому что уже знаю, что никак, нужно самостоятельно писать патч, ни вим-скриптом, ни какими-то другими хаками это не решить. Ну или не писать, а продолжать страдать.

Вообще я понимаю проблему — это как со шрифтами или тирингом, один раз замечаешь и уже везде пишешь ШГ и гоняешь вертикальные линии по экрану в поисках разрывов.
Вы уж простите, что наезжаю на ваш любимый редактор, сам использую, знаю как и что — просто не замалчиваю проблему.

Ищите что у вас лично тормозит (плагины, автокоманды, терминал по Esc может тупить, ожидая продолжения какой-либо своей команды, особенно если tmux или что-то такое).

Возможно у него что-то на InsertEnter / InsertLeave забинжено. Или включена подсветка линии/колонки курсора + что-то лишнее в airline выполняется.

Если нужно открывать файл в другом редакторе, то какие претензии к виму?

Да что за бред? Мне текстовый лог нельзя в виме открыть, серьёзно? Я что писал что я .docx пытаюсь открыть с графиками?

Еще раз, insert-mode не предназначен для навигации. Да, в этом режиме навигация возможна, но лишь как исключение.

Можно ссылку на официальную документацию, а в идеале на цитату самого Муленара?

Может быть у вас супер-мага параллельный VIM который бежит на Intel Xeon 32-ядерном — у меня же прекрасно видно это — VIM просто подзалипает, и становится ватно — такого быть не должно.

Конечно не должно. Сделал на дохлой vps

vim /var/log/messages
vapJ

Вот подсветка на регулярочках в виме лагает только в путь, это да. Сама по себе, во всех режимах.

На самом деле вы правы, это эйрлайн скорее всего. Почему в 2017 редактор должен от этого тормозить?
Почему в случае горизонтального перемещения можно было пойти на компромис, а в случае вертикального нет?
Почему если строка длинная, то у неё совершенно непредсказуемое отображение? (рекомендую попробовать чтобы прочувствовать)
Ну не должно быть так, просто не должно быть.

Вот да, а ведь это не богомерзкий атом казалось бы.
Мне ведь самому обидно, вим действительно мощный, буфферы, регулярки, взаимодействие с системой через "!", навигация по тексту в нормалмоде, конфигурабельность.
ну не на пустом же месте появляются всякие саблаймы и нвимы — вим содержит ряд архитектурных просчётов.

Sublime вообще из другой оперы, а неовим с подсветкой ничего не сделал (и не смог бы, претендуя на роль drop-in replacement). Вот уж где страдать так страдать, syntax off и монохромный терминал типа cool-retro-term для аутентичности.

Ну как я понимаю они там пытаются, прикрутить асинхронные операции для всяких анализаторов кода. По мне бы уж переписали с оглядкой на вим, но с лучшей архитектурой, заодно переименовав табы в лейауты и добавив более проработанный серверный режим.

походил по строчкам (gj/gk), режимы переключаются моментально

Речь идёт про специфический случай в инсерт-мод, воспроизвести можно следующим образом:
конфигурируем:

inoremap <silent> <Down> <C-o>gj
inoremap <silent> <Up> <C-o>gk

Если нужно открывать файл в другом редакторе, то какие претензии к виму?

Да что за бред?

Действительно, бред.

Мне текстовый лог нельзя в виме открыть, серьёзно?

Кто вам запрещает? Вы же сами выше завели речь об открытии файла в другом редакторе.

Можно ссылку на официальную документацию, а в идеале на цитату самого Муленара?

Давайте я вас просто с Брэмом познакомлю, че уж там.

Проверил маппинги, всё прекрасно бегает курсорами, тестил на этой портянке, гиф не знаю как сделать, пишу то же что и в первый раз писал -- чините свой сетап.

PS. nvim какой-то, near HEAD.

Сейчас ещё окажется, что у ТСа тормозит переключение из-за настроек эмулятора терминатора, с тайм-аутом на esc или из-за общей тормознутости выбранного эмулятора терминала.

А он и не ТС, мы тред угнали.

Честно не понимаю, как может тормозить текстовый редактор.

Легко. На каждый символ создавать структуру с цветом, начертанием, подчеркиванием etc., обходить всё это как можно чаще.

У меня такой маппинг:

inoremap <silent> <Down> <C-o>gj
inoremap <silent> <Up> <C-o>gk

Соглашусь, у меня без плагинов ( vim -u NONE ) тоже прекрасно бегает.
Вы мне предлагаете без плагинов и настроек (а у меня их там всего 8, это совсем ничего по сравнению с другими) использовать?

Я использую Konsole и xfce4-terminal. Можете предложить не тормознутый терминал, без таймаутов на esc? Не xterm или urxvt случаем?

А если серьёзно, есть ли какой-нибудь шелл _не_ браузерный _без_ html/css, _не_ на ноде, типа баша? Чтобы ему можно было скармливать json'ы, собирать выхлопы grep'ов, удобно делать конвейеры и пр. извращения типа раздачи одного выходного потока двум процессам?

Хз. PowerShell?

Хз. PowerShell?

Нет. На js.

А он и не ТС, мы тред угнали.

А, мля :)

У меня такой маппинг:

А у меня такой:

nnoremap <up> <nop>
nnoremap <down> <nop>
nnoremap <left> <nop>
nnoremap <right> <nop>
vnoremap <up> <nop>
vnoremap <down> <nop>
vnoremap <left> <nop>
vnoremap <right> <nop>
inoremap <up> <nop>
inoremap <down> <nop>
inoremap <left> <nop>
inoremap <right> <nop>

ну кдешный кейт и саблайм не тормозят в таких условиях, код подсвечивают, редактируют.

Как kate и sublime связаны с эмулятором терминала?

Не xterm или urxvt случаем?

Чем не устраивает urxvt?

Как kate и sublime связаны с эмулятором терминала?

Я говорю про общее качество работы ПО как продукта. Окей, забудем про тормоза при вертикальной навигации в сложных строках в инсерт-моде.
Почему VIM не может показать нормально строку которая по какой-угодно причине не умещается на экране без принудительного разбиения переводами строки?
Ну бросьте это настолько вопиющее нарушение юзабилити, что я не знаю — мне кажется, что отрицать это бессмысленно.
И единственный аргумент тут ну а вы разбейте, а потом соберите заново если вам надо. Почему емакс/нано/мцедит может то же самое показать нормально, предсказуемым образом и не потребуется нкиакого дополнительного шаманства.

Чем не устраивает urxvt?

Так вы его рекомендуете? Не устраивает крайне сложным процессом настройки. Xresources, вот это вот всё. И ещё я помню была там проблема с рендерингом некоторых шрифтов когда я пытался к нему подступиться.

Почему VIM не может показать нормально строку которая по какой-угодно причине не умещается на экране без принудительного разбиения переводами строки?

Что значит не может? Можно включить :set wrap, можно выключить :set nowrap.

На мой взгляд, самое ужасное - это viml и движок подсветки.

И единственный аргумент тут ну а вы разбейте, а потом соберите заново если вам надо.

Кто вам привел такой аргумент? Да и какой же это вообще аргумент?

Почему емакс/нано/мцедит может то же самое показать нормально, предсказуемым образом и не потребуется нкиакого дополнительного шаманства.

Так и вим может. Просто вам почему-то хочется его использовать исключительно в режиме insert-mode.

Так вы его рекомендуете?

Я им пользуюсь и весьма им доволен.

Не устраивает крайне сложным процессом настройки. Xresources, вот это вот всё.

Один раз настроить и забыть.

И ещё я помню была там проблема с рендерингом некоторых шрифтов когда я пытался к нему подступиться.

Допускаю, что могут быть проблемы, но я не припомню проблем.

Так и вим может. Просто вам почему-то хочется его использовать исключительно в режиме insert-mode.

Я уже отказался от примера с инсерт-модом не выдумывайте и читайте чуть внимательнее.

Что значит не может? Можно включить :set wrap, можно выключить :set nowrap.
Так и вим может. Просто вам почему-то хочется его использовать исключительно в режиме insert-mode.

Вы попробуйте на больших(гигантских, 4-8-10k символов, можно окно уменьшить для наглядности) строках и посмотрите как просто прыгает вся строка (уже не в инсерт-моде, пока не про него речь сейчас), при переходе к другой строке, иногда пропадают части строк, иногда заменяются на @@@ (строка продолжается типа).
И я молчу про забавный глюк при рисовании colorcolumn, который рисуется только на первом встреченном в строке 80 символе (в любом режиме, не только в инсерт-моде, не беспокойтесь, но пожалуйста сами проверьте). Сейчас ведь не последует ответ про: ТРУ ВИМ-ХАКЕРЫ НЕ ИСПОЛЬЗУЮТ COLORCOLUMN ?

Кто вам привел такой аргумент? Да и какой же это вообще аргумент?

А это я как вы, додумываю вашу логику, как вы про мою горячую привязанность инсерт-моду. Хотя я просто описываю конкретное неудобство, исправить которое никакая философия не мешает — это архитектурная проблема, это проблема недосмотра; вим ничего не потеряет если всё это будет починено.

Вы понимаете, что иногда люди пишут код, вводят текст, правят что-то?
Вы попробуйте на больших(гигантских, 4-8-10k символов, можно окно уменьшить для наглядности) строках

Ну нормальный такой код на 4-8-10к символов в строке.

Создал новый файл, вставил в него 100+К строк, смержил их в одну (секунд 5 ушло у вима на это). Сделал :set wrap - перемещение тормозит, даже курсор моргает.
Все плагины оставил включенными. У вас в этом претензия к виму?

И я молчу про забавный глюк при рисовании colorcolumn, который рисуется только на первом встреченном в строке 80 символе

Пустые строки, колонка рисуется там, где я указал (у меня два значения - set cc=81,101.

как вы про мою горячую привязанность инсерт-моду.

Я ничего не придумал, а только прочитал ваше заявления.

Сделал строку в 10099 символов, включил wrap, курсор перемещается без каких-либо проблем вообще в пределах одной строки (gj / gk).

Все плагины оставил включенными. У вас в этом претензия к виму?

И к этому тоже.

Пустые строки, колонка рисуется там, где я указал (у меня два значения - set cc=81,101.

Сделал как вы указали (set cc=81,101) бекграунд меняется только у первого 81 и потом 101 символа в большой строке. На второй и последующих строках мягко разбитыми wrap'ом. Рекомендую посмотреть как это сделано в Sublime том же, намного нагляднее получится, чем мои объяснения. «set cc=81» — это скорее хак, а не фича реализованная надлежащим образом.

Сделал строку в 10099 символов, включил wrap, курсор перемещается без каких-либо проблем вообще в пределах одной строки (gj / gk).

В нормал-моде? Ну так у меня тоже. Сейчас вы опять напишите про то, что я в инсерт-моде сижу и вообще пытаюсь psd-реадктировать в виме.

Я пишу про косяки которые постепенно тянут VIM вниз; даже сам автор понял что нужна, например, асинхронность и реализовал хоть какую-то, два кей семнадцать же ну.

На второй и последующих строках мягко разбитыми wrap'ом.

Блин. На второй и последующих строках мягко разбитыми wrap'ом colorcolumn не рисуется.

Я не понял суть багета. Тебе кто-то запрещает в vim пользоваться стрелочками?

Для insert mode я вообще делал биндинг на alt+hjkl, чтобы руку не смещать на стрелочки, потому что так удобнее.

Развели тут истерию на кучу постов на ровном месте.

Эм, а разве должно? Формально это та же строка, и цифры уже давно убежали за 81 и 101. С чего бы это заново рисовать?

Должно, это на интуитивном уровне всем понятно, в виме это реализовано как хак.
Внимание на PNG:
https://my.mixtape.moe/mpydyx.png
Текст идентичен, настройки переноса тоже.
На заднем плане sublime и там направляющая рисуется как положено (через весь массив букв «…aaaaa…»), до самого низа.
Если говорить о colorcolumn в вакууме, то наверное не должно, наверное не для этого вообще придумано. Но другого способа реализовать направляющую-индикатор 80 колонки просто нет. Хаком я называю это потому, что чуть стоит отойти от самого распространённого способа использования и он тут же разваливается(как и положено костылю на самом деле).

Для insert mode я вообще делал биндинг на alt+hjkl, чтобы руку не смещать на стрелочки, потому что так удобнее.

Проблема не в биндинге, а в реализации навигации на уровне архитектуры.

Я не понял суть багета.

Могу лишь порекомендовать перечитать заново и провести те эксперименты которые я приводил (предварительно установив airline; даже из-за наличия плагина такого быть не должно в редакторе из 2017 года).

На заднем плане sublime и там направляющая рисуется как положено (через весь массив букв «…aaaaa…»), до самого низа.

Погоди, я тебя правильно понял: ты жалуешься на то, что в текстовом редакторе с UI рисуется на фоне полосочка, которая не рисуется в консольном редакторе (учитывая консоль и всё с ней связанное)? Ты же понимаешь, что полосочка в саблайме рисуется не по тексту и строкам, не по номеру колонки. И тот факт, что оно проходит у тебя через одну строку несколько раз (как в твоём случае) - это не значит, что это правильное решение.

Проблема не в биндинге, а в реализации навигации на уровне архитектуры.

Так ты объяснишь в чём суть проблемы? Тут полтреда идёт спор, а объяснить ты так и не можешь. VIM - это МНОГОРЕЖИМНЫЙ текстовый редактор. И режим ВСТАВКИ - только один ИЗ режимов. Для навигации используется обычный режим. В режиме вставки возможности навигации, разумеется, ограничены (мы же помним, да, что задача VIM - избавиться от стрелочек, чтобы пальцы всегда оставались на буквенном блоке клавиатуры) - для навигации используются те же кнопки, которые вводят текст. Для этого и были реализованы режимы. Если тебе прямо так уж НЕОБХОДИМО постоянно использовать навигацию в режиме ВСТАВКИ - берёшь и биндишь нужные тебе сочетания. Лично я проблем с этим не встречал с тех пор, как разобрался и настроил. Но я не гуру vim.