И не осилите, поверьте мне.
Вим бесполезно пытаться осилить потихонечку, это как учиться плавать в ванне.
Надо просто садиться и начинать в нем работать целый день. Первую неделю будет мучительно, месяц — тяжело, через год привыкните, через пять не будете понимать как вы жили до этого.
Вимеры тоже не могут, поэтому для вима есть плагин который вам подсветит номер ;)
Но вот например даже по той строчке что вы привели. Я очень часто использую фичи вида —
* скопировать в буфер обмена целиком приведенный список. (3 нажатия)
* скопировать в буфер целиком приведенный список не включая символы [] (3 нажатия)
* удалить все адреса начиная с того на котором стоит курсор и до символа ] (3 нажатия)
* окружить список вместо [] тегами <pre> (5 нажатий)
* отправить этот список на pastebin и скопировать ссылку в буфер обмена (5 нажатий)
(даже вот этот комент я пишу в виме который автоматически открылся у меня файрфоксом и он красиво подсвечивает мне вышеприведенный список )
Если после этого вы не замечаете ничего необычного при работе, то вы — тру вимер и можете проводить в InsertMode сколько угодно времени и не обращать внимания на комментарии нубов.
Ну вот как минимум нашел одну старую багу. Rope до сих пор считает что документация к питоновскому коду может быть только ascii и никаких юникодных символов там быть не может. (
Да я не жалуюсь. ) Просто было интересно, может быть что-то в мире новое изобрели, а я и не заметил.
Хотя насчет ничего не нужно, не соглашусь — pylint в виме, например, делает жизнь намного приятнее.
Про питон — это вы rope и ropevim имеете в виду? Они у вас правда хорошо работают? Я просто повозился, помучился, нашел там баги, попереписывался с автором. Но в результате у меня прижился только AutoImport
[e-max@e-max pypy]$ ./pypy-c
Python 2.7.2 (e4568fc96f21+, Apr 11 2012, 07:59:26)
[PyPy 1.8.1-dev0 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``pypy is like sausages''
>>>> str.len = property(lambda self: len(self))
Traceback (most recent call last):
File "", line 1, in TypeError: can't set attributes on type object 'str'
Если делать ребейз перед слиянием фич в мастер, а потом merge с --no-ff, то никакой паутины не будет.
На самом деле я двумя руками за правку истории перед сливанием и публикацией. Правда я считаю что маленькие коммиты и --no-ff это добро. Часто, я в процессе rebase -i, наоборот разбиваю коммиты на несколько мелких.
Я вот как раз мотивирую всех делать вот такие мелкие фиксы в отдельных коммитах.
Потому что иногда бывает, что в коммит содержит какое-то важное и нетривиальное изменение на пять строк. Ну и плюс человек, чтобы не плодить коммиты в нем же сделал какое-то «мелкое и неважное изменение» — типа убрал пробелы перед концами строк в половине строк файла.
В результате в этом важном и нетривиальном диффе сам черт ногу сломит. И, если это важное изменение не заработает, то при откате коммита получим еще и откат кучи мелочей.
Коммит должен быть маленьким, по возможности атомарным и в нем должно быть то, и только то, о чем написано в комментарии этого коммита. Это очень упрощает жизнь.
А что именно в ней должно привлекать? Если мержи сделаны с помощью --no-ff вы в любой момент можете открыть gitk и увидеть что вот — эта фича началась вот тут, закончилась вот тут, не читая описание к каждому коммиту.
Что касается лаконичности, то если лаконичность это синоним «давайте уместим фичу в три гигантских коммита», то я определенно против. Когда я делаю ревью кода, я люблю смотреть маленькие, аккуратные диффы, а не на простыню на десятки экранов.
Как человек 6 лет использующий на работе Logitech Marble, а дома обычную мышку отвечаю — никаких особенных ощущений не вызовет. Удобно и то и другое, но от трекбола рука устает меньше.
Я не satas, но как человек использующий эту клаву лет пять, могу сказать что очень удобно)
Правда у этой клавиатуры есть минус — после нее вам будет тяжело на обычной.
5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.
Справедливости ради надо сказать, что это не совсем правда. В git вполне можно, при неосторожном обращении, потерять что-то важное.
Создаете ветку -> добавляете файлы -> удаляете ветку.
Все — ваши файлы буду жить до первого git gc.
В меркуриале, как я понимаю, ничего никогда не исчезает в принципе.
Да понятно почему. Я не уверен конечно что будущее за ФЯ, но почему к ним вернулся интерес совершенно понятно. Главный тренд сейчас в том, что мы уперлись в вертикальное масштабирование и активно начали развивать горизонтальное. Завтра вам придется запускать приложение так, чтобы оно легко масштабировалось на сотни ядер. Готового и простого решения как это делать у мейнстримных императивных и ООП языков нет. У функциональных с этим проще.
Кто придумает в этом направлении конфетку и протолкнет ее, тот и получит рынок.
cs[<pre>Наврал кстати, можно короче cs[
Вим бесполезно пытаться осилить потихонечку, это как учиться плавать в ванне.
Надо просто садиться и начинать в нем работать целый день. Первую неделю будет мучительно, месяц — тяжело, через год привыкните, через пять не будете понимать как вы жили до этого.
Но вот например даже по той строчке что вы привели. Я очень часто использую фичи вида —
(даже вот этот комент я пишу в виме который автоматически открылся у меня файрфоксом и он красиво подсвечивает мне вышеприведенный список )
Прописываете в конфиге
Если после этого вы не замечаете ничего необычного при работе, то вы — тру вимер и можете проводить в InsertMode сколько угодно времени и не обращать внимания на комментарии нубов.
Если замечаете, то упс… )
Хотя насчет ничего не нужно, не соглашусь — pylint в виме, например, делает жизнь намного приятнее.
[e-max@e-max pypy]$ ./pypy-c
Python 2.7.2 (e4568fc96f21+, Apr 11 2012, 07:59:26)
[PyPy 1.8.1-dev0 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``pypy is like sausages''
>>>> str.len = property(lambda self: len(self))
Traceback (most recent call last):
File "", line 1, in TypeError: can't set attributes on type object 'str'
На самом деле я двумя руками за правку истории перед сливанием и публикацией. Правда я считаю что маленькие коммиты и --no-ff это добро. Часто, я в процессе rebase -i, наоборот разбиваю коммиты на несколько мелких.
Потому что иногда бывает, что в коммит содержит какое-то важное и нетривиальное изменение на пять строк. Ну и плюс человек, чтобы не плодить коммиты в нем же сделал какое-то «мелкое и неважное изменение» — типа убрал пробелы перед концами строк в половине строк файла.
В результате в этом важном и нетривиальном диффе сам черт ногу сломит. И, если это важное изменение не заработает, то при откате коммита получим еще и откат кучи мелочей.
Коммит должен быть маленьким, по возможности атомарным и в нем должно быть то, и только то, о чем написано в комментарии этого коммита. Это очень упрощает жизнь.
Что касается лаконичности, то если лаконичность это синоним «давайте уместим фичу в три гигантских коммита», то я определенно против. Когда я делаю ревью кода, я люблю смотреть маленькие, аккуратные диффы, а не на простыню на десятки экранов.
Правда у этой клавиатуры есть минус — после нее вам будет тяжело на обычной.
Справедливости ради надо сказать, что это не совсем правда. В git вполне можно, при неосторожном обращении, потерять что-то важное.
Создаете ветку -> добавляете файлы -> удаляете ветку.
Все — ваши файлы буду жить до первого git gc.
В меркуриале, как я понимаю, ничего никогда не исчезает в принципе.
Кто придумает в этом направлении конфетку и протолкнет ее, тот и получит рынок.