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

VimL не велосипед, это язык обработки текста в рамках и средствами Vim

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

.. насколько vimscript прибит сбоку-то, если честно

настолько, насколько возможно

Вимскрипт, при такой точке зрения, изумителен как инструмент именно и чисто редактирования текстов

как инструмент редактирования текстов неплохи awk и perl, vimscript - нет

Складывается лёгкое ощущение что питонистам откровенно делать нехер

и это тоже, но повторюсь, vimscript хуже бидона по всем параметрам

vimscript - нет...

... как странно.

как инструмент редактирования текстов неплохи awk и perl

Угу. Я добавлю — ed/sed так же неплох. Как инструмент редактирования текстов. Только вот не подскажете почему даже vim для очень большого процента «погроммистов» осилить составляет такую трудность?

А Вы предлагаете awk/perl/sed (это я уже предложил)...

почему даже vim для очень большого процента «погроммистов» осилить составляет такую трудность

потому что режимы, потому что кривой язык расширений, а для IDE-фанов один фиг не торт

Да я, собственно...

... то же про тоже. И по барабану что POSIX 1003.2a (User Portability Extensions (UPE)) определяет ex/vi в числе прочих стандартных утилит. Т.е., если система хотя бы как-то претендует на хотя бы какую-то «совместимость» с POSIX (хотя это и весьма относительное понятие), она должна в числе прочих утилит поддерживать и vi. Его где угодно можно найти в том или ином виде. Но да... IDE-фанбоям по барабану. Им бы «чёнить попейсать». Неизвестно только зачем, главное чтоб на пистоне (впрочем, подставьте здесь что угодно, своих фанатиков у любого языка хватает).

И по барабану что POSIX 1003.2a (User Portability Extensions (UPE)) определяет ex/vi в числе прочих стандартных утилит.

не, это хорошо, стандарты я люблю. Только на всех своих машинах (к счастью, я не одмин), я делаю aptitude purge vim и aptitude install nvi. Ибо нефиг.

Я имел в виду НОРМАЛЬНЫЙ интерфейс.

Работа в голой консоли - то еще удовольствие.

(3) include pending patches and fix bugs

Зачем смотреть новости на http://www.vim.org? В списках рассылки указан именно процитированный мной вариант. Более того, в этой же теме уже прямо отказали включить несколько из этих самых «pending patches». (Точнее, прямо отказали их включить до 7.4, а не вообще.)

улучшить поддержку Python;

python-mode и rope можно будет выкинуть и python будет в vim нативно работать?

python-mode и rope можно будет выкинуть и python будет в vim нативно работать?

Главное чтобы не ввели обязательной зависимости от питона

Чем гвим ненормален?

Тем, что он вполне мог быть как Sublime Text, но он всё еще Gvim.

вполне мог быть как Sublime Text

Ну и пользуйся дальше сублёвом. Что не так-то?

более 950 патчей - минорный релиз. Вот это я понимаю Unix-way
А Mozill'е этого хватило бы чтобы udev догнать по мажорному номеру

Тем, что он вполне мог быть как Sublime Text, но он всё еще Gvim.

А, то есть тебе обидно, что неосиляторство не позволяет стать илитарием. Жри что дают, чо.

python будет в vim нативно работать?

Он нативно работает уже хрен знает сколько лет.

В списках рассылки указан именно процитированный мной вариант

мде... ну да ладно, я с главной утянул, да и смысл не очень то разниться

ex/vi

Казалось бы, причем здесь плагины, vimscript и python. Никто твои мамонтовы выделения трогать не собирается, расслабься, поборничек.

Работа в голой консоли - то еще удовольствие.

Бгг, ты же даже не запустил эту команду. Можешь дальше фапать на пердящий курсор, ага.

Ждем

противоречащие параграфы
ибо плуги ДОЛЖНЫ быть быстрыми

Быстрые плуги и vimscript — вот противоречащие параграфы.

как пример - там есть системная переменная «выделенный текст»
плюс функции которые всё это адекватно обрабатывают и переваривают

Ты будешь сильно удивлен, но snipmate перешел на питон, потому что vimscript не годен для обработки текста. Код на нем — собрание хаков с оглядкой на текущие настройки пользователя.

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

Питонячий интерфейс к буферу — уже существует, прост и гибок в использовании.

Да. А что...

... не так? Кому vim/gvim, а кому и что нипопадя пойдёт. Просто интересно в чём претензии к виму-то? Редакторов же более чем дохера.

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

Хотя, я бы не стал с этим морочиться и просто освоил бы по-нормальному вим. Он более чем конфигурируем для нужд работы.

Просто интересно в чём претензии к виму-то?

Это вопрос не ко мне.

Этааа...

... я, конечно, нижайше прощу всяческих пращщениефф, однако поспешу заметить что эти «мамонтовы выделения» что мои, что Ваши. Это также справедливо для любого, у кого в UA просматривается хоть что-то юниксовое. Ибо это СТАНДАРТ. Один из семейства. И на этом семействе стандартов в нашем мире основано практически всё.

Незнание стандартов не освобождает от необходимости их применения. Пксть даже бессознательно (или неосознанно). :)))

Гм, ты случаем не путаешь vi с vim? То, что в последнем есть совместимость с первым ни о чем не говорит и стандартов никак не касается, так как есть elvis, nvi and so on.

Кстати, posix требует конкретно вот это http://ex-vi.cvs.sourceforge.net/ Им можно невозбранно обмазаться из коробки во фряхе.

OMG, он даже в арче есть в базовой системе. ЧТД, анон, никто в эти стандарты даже палочкой не потыкает.

Не-а...

... не путаю. Изначально был ex. Ex родил vi. Vi родил vim/gvim/elvis/nvi/... По сути, это одно и то же. «Вариации на тему».

Есть даже сream for vim или просто cream. Что-то типа IDE на основе gvim (ЕМНИП, надо проверить). Оно вполне на вимскрипте, но что-то типа M$ DevStudio. Ставил как-то себе давно на «потестить». Судьба данного проекта сейчас неизвестна.

Если не путаешь, то какое отношение vim имеет к POSIX? Почему его разработчики должны оглядываться на стандарт при nocompatible?

Тем, что он вполне мог быть как Sublime Text,

хорошо что он не такое говно.

Чего мне сейчас не хватает (или даже раздражает) в (G)Vim — это тормоза при подсветке длинных строк кода (я не говорю о очень длинных, но даже при обрубании подсветки до 100 символов в строке иногда тот или иной файл тааааак долго распарсивается, что просто ужас).

Потому что...

... nocompatible это nocompatible и есть. Можно так, а можно эдак. Ни кто ни в чём не ограничивает.

ЧТД, анон, никто в эти стандарты даже палочкой не потыкает.

А вот это, сударь, Вы зря... Уверяю Вас что тыкают и активно и тыкают и втыкают. То, что толпа неофитов-иммигрантов из оффтопа до этого не доросла, так это их проблемы. Без хотя бы формального следования стандартам (стандарт это не догма, а руководство к действию) есть все шансы так и остаться быдлокодером.

Кстати, да... Вот скриншотец cream для vim -> http://i1-linux.softpedia-static.com/screenshots/Cream-for-Vim_2.jpg Для gvim оно было посимпатичнее как-то (типа вот так -> http://i.stack.imgur.com/FZMS0.jpg), но даже в таком виде оно мне было без надобности... Но кому-то, может, и сгодится.

Код на нем — собрание хаков с оглядкой на текущие настройки пользователя.

да ты прав, плевать на настройки пользователя, зато всё на питоне

cream

это случайно не та хрень что делает нотпад из вима?

Ну да...

... что-то типа того... Скорее некую такую недо-M$ DevStudio для неосиляторов. Или свежеприехавших из оффтопа. Скажу сразу — не нужно, но кому-то может для начала облегчить жизнь.

Тут вот говорят vimscript это какашка и надо бы на пистоне. А я вот недоумеваю. Посоны-то IDE ваяют, к успеху идут с vimscript'ом...

Тут вот говорят vimscript это какашка и надо бы на пистоне.

Вон новый powerline плагин перевели на пистон - стал жутко тормозить и жрать cpu....

Нууу...

... мне тут вот коллега-анонимус порекомендовал сбегать, да подучить чего-нибудь про х86, да про суперскалярные процессора... ))) Видимо, и Вам это следует сделать... Без этого тайного знания пистон не прекратит тормозить. Ходят слухи что у постигнувших это тайное Дао число ядер волшебным образом удваивается, RAM расширяется динамически до 384Gb и пистон начинает компиляться. Сразу. Но в начале он прекращает тормозить. )))

А как в нём нативно без помощь верёвки открыть, к примеру, определение метода/переменной/класс/объекта по курсору на новой вкладке/новом буфере? Ну и вернуться назад.

Разумеется, без мышки и только клавиатурой.

То, что в vim можно набирать python-код и потом запускать через «python example.py» это я и без вас знаю. Ну и синтаксис он типа подсвечивает, ну ок.

плевать на настройки пользователя

Сдается мне, ты так же хорошо знаешь vimscript как и питонячий интерфейс.

А как в нём нативно без помощь верёвки открыть, к примеру, определение метода/переменной/класс/объекта по курсору на новой вкладке/новом буфере? Ну и вернуться назад.

Так же как и для всех остальных языков — ctags.

Анон, такое ощущение, что ты пытаешься меня уговорить пользоваться стоковым вимом. Никак не могу взять в толк, откуда ты взял что я пользуюсь чем-то другим.

Не-а... :D

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

Да, до rope руки дошли, а ctags почему-то не попробовал. Попробую. Я почему-то (наверное из-за названия) думал, что это для C.

Попробую.

Лучше не пробуй. А возьми это https://github.com/davidhalter/jedi-vim

Олсо, я сейчас активно пилю интеграцию с supplement. Отпишусь как будет готово. Ориентировочно — середина июня.

Vim хорош... Думаю, если позаимствовать идею расширений на Python у Sublime Text 2 - он может вообще стать мегапопулярным редактором.

мде... ну да ладно, я с главной утянул, да и смысл не очень то разниться

Очень даже. Если бы реально имелось ввиду то, что на главной, то в Vim тут же бы включили тот же breakindent. А так ответили

Sorry, that is not a bug fix patch.

I'm sure everybody has their favorite patch that he would like to see included. And eventually they might get included, but for 7.4 I have to set priorities to get it done in a reasonable amount of time.

да ты прав, плевать на настройки пользователя, зато всё на питоне

Вам нравится, когда результат применения регулярного выражения к строке (даже не к тексту в буфере, а к обычной строке в переменной) зависит от настроек пользователя? Причём в разных функциях и командах эти настройки игнорируются по‐разному (в смысле, :substitute не игнорирует ничего, substitute() игнорирует &magic и &cpoptions, но не &ignorecase, :syn игнорирует вообще все настройки). Когда тебе было бы удобно воспользоваться неким текстовым объектом для выбора текста, над которым дополнение хочет работать, но что именно будет им выделено иногда зависит от пользовательских настроек вроде &inclusive. Неправильная настройка &cpoptions вообще может сломать большинство дополнений.

Нет ничего хорошего в том, чтобы результат сравнения «if 'A' =~ 'a'» зависил от пользовательских настроек.

В Python не поменяется синтаксис, если пользователь напишет в vimrc что‐то. С правильным интерфейсом на Python вы всегда знаете, что зависимость от настроек не всплывёт неожиданно.

Вон новый powerline плагин перевели на пистон - стал жутко тормозить и жрать cpu....

Python тут не причём. Просто мы на радостях от относительно нормальной многопоточности сделали интервал опроса статусов файлов в VCS равным 0,2 секунды вместо предыдущего >2 секунд. Сейчас это дело переписано на inotify и жрать CPU powerline более не должен. Тормозов же у меня от него никогда не было.

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

ничего плохого не вижу, однако если есть такая возможность - что плохого?

ничего плохого не вижу, однако если есть такая возможность - что плохого?

Вы, видимо, не программист.

Это совершенно ужасная возможность: она означает, что вы не можете рассчитывать на корректность работы регулярных выражений и даже простых сравнений. Т.е. хотите вы, к примеру, найти все места, где используется определённая переменная, и что‐нибудь с ними сделать. В используемом языке count и COUNT — различные переменные. Но если пользователь установил &ignorecase в 1, то вы получите множество ложных срабатываний на COUNT, а если нет — то нет. Конечно, можно явно указать, хотите вы такое поведение или нет, но об этом указании легко забыть. Особенно с учётом того, что эта настройка игнорируются в некоторых функциях. Причём конкретно &ignorecase влияет ещё до кучи на простые строковые сравнения (==, без регулярных выражения).

В последнем случае дело осложняется тем, что вместо присутствующего во многих языках оператора сравнения == приходится использовать ==# или is#, которых я в других языках не видел. Т.е. если вы пишете в основном не на VimL, то, весьма вероятно, будете по привычке использовать оператор ==, который для строковых сравнений использовать нельзя никогда по указанной причине.

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

vim - а это гуано древнего мамонта ещё нужно?