LINUX.ORG.RU

Vim, подбор плагинов и настройка

 ,


0

7

Начал засматриваться на vim в качестве основного редактора.

Поставил ultisnips и youcompleteme - у меня трешак какой-то, по TAB работает только автокомплит из всплывающего списка, для разворачивания сниппетов юзаю Ctrl + t - не очень удобно.

В общем, посоветуйте, пожалуйста, плагины такого рода:

  • нормальные сниппеты, с возможностью дописания своих (не хочется учить 3 месяца, как писать сниппет, если мне надо добавить 1,5 команды, а также научить после $this по нажатию "-" сразу ставить знак "->", а по "--" ставить «=>»);
  • автоподстановка имён файлов (например, «css/ma» и по табу - «css/main.css» или список имён файлов с возможностью выбора, _крайне_ желательна возможность научить его, где он должен смотреть по алиасам вида @web, чтоб он мог по этому алиасу предлагать файлы.
  • Для работы с проектами уже посоветовали nerdtree - если есть что-то лучше и удобнее - я весь во внимании

Может ещё какие-то удобные плагины.

Насчёт языков: html, css, js, php и perl. С остальным пока не сталкивался.

★★★★

Последнее исправление: ekzotech (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

Кстати, и просто vi ничего не пишет: одни тильды.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

vim интерективней vi интерактивней ex интерактивней ed интерактивней sed

После ed и пользования sed можно и sam -d насладится.

да и вообще !cmd

вообще видимо программируемые инструменты всё ещё не стали общим местом, нет пока необходимости, ещё не все кодэманки пхп освоили.

а в целом from

http://www.columbia.edu/~rh120/ch106.x09


Grep is listed in the Manual for Version 4 Unix which is dated 
November, 1973. The date given for the creation of grep is March 3, 1973, 
following the creation of pipes.(43) The creation of grep, McIlroy 
explains, was followed by the invention of other special purpose software 
programs that could be used as tools. He writes:
 
     "A while later a demand arose for another special-purpose 
     program, gres, for substitution:  g/re/s.  Lee McMahon 
     undertook to write it, and soon foresaw that there would be 
     no end to the family:  g/re/d, g/re/a, etc.  As his concept 
     developed it became sed, a tool of remarkable utility that 
     is largely unappreciated today, because it capitalizes on 
     the perfect familiarity with ed that was universal ten years 
     ago, but no more.  Sed covers a lot of needs.  For example, 
     we have never seen fit to adopt the widespread `head' 
     utility because `sed 10q' does just as well."(44)
 
     What McIlroy refers to as "the unarticulated notion of 
software tools...brought home by the liberation of...grep from 
within the editor" has become one of the significant achievements 
of the Bell Labs research work on Unix. By making it possible to 
use `grep' to search for a data pattern in a file, without having 
to use an editor to go inside the file, the Bell Labs researchers 
discovered that they could create a plethora of software tools 
to be used in varying combinations, thus facilitating the 
customized application by a user, a goal sought by those doing 
research in programming.(45)
 
     McIlroy explains that the notion of "software tool" only became 
articulated among the Bell Labs researchers with the publication of the 
book "Software Tools" by Kernighan and Plaugher. "Still unnamed in our 
circles," McIlroy notes, "until Kernighan and Plauger wrote their book, 
the idea nevertheless became a guiding principle."(46) McIlroy adds that 
"We were definitely building tools before K&P, though we lacked the 
suggestive word."(47)

     Describing how the notion of software tools helps to create an 
effective programming environment, Brian W. Kernighan and Rob Pike, 
authors of The Unix Programming Environment, explain that each tool is 
designed to be used with other tools and achieving this end is more 
important than how each is designed internally.(48) The most important 
aspect considered with each tool is the function that the tool is to 
have. New tools are designed once a new function is intended.

     "The guiding principle," they write, "for making the 
choice should be that each program does one thing. Options are 
appropriately added to a program that already has the right 
functionality. If there is no such program then a new program is 
called for. In that case the usual criteria for program design 
should be used: the program should be as general as possible, its 
default behavior should match the most common usage and it should 
cooperate with other programs."(49)
 
     Thus Unix, according to Kernighan and Pike, created "a
new style of computing, a new way of thinking of how to
attack a problem with a computer. This style," they explain,
"was based on the use of tools: using programs separately or
in combination to get a job done, rather than doing it by
hand, by monolithic self-sufficient subsystems, or by
special-purpose, one-time programs."(50)
 
     The philosophy of using software tools that developed from 
research in Unix is outlined in the "Foreword" to the special 
issue of The Bell System Technical Journal published in 1978, 
on "The Unix Time-sharing System." Describing the principles 
which they have found to be an important component of the Unix 
philosophy of software design, the researchers write:
 
     "UNIX utilities are usually thought of as tools -- sharply 
     honed programs that help with generic data processing tasks. 
     Tools were often invented to help with the development of 
     UNIX programs and were continually improved by much trial, 
     error, discussion, and redesign, as was the operating system 
     itself. Tools may be used in combination to perform or 
     construct specific applications."(51)
 
     They explain that a distinctive style evolved as part of 
Unix research. "Unix software works smoothly together; 
elaborate computing tasks are typically composed from loosely 
coupled small parts, often software tools taken off the 
shelf."(52)
 
     "Sophisticated tools to make tools have evolved," they 
observe. (53) Software development tools such as "nroff"
and "troff" were created. Not only was it important to create 
tools, but soon tools to create tools, like "yacc" and "lex",
were developed. "Yacc" and "lex" were used to create numerous 
little languages and applications like eqn and awk that greatly 
enhanced the popularity of Unix. 

     The evolution of the tool "diff" created by McIlroy, a commonly used 
software tool, is an example of how tools were continually improved, 
based on the experience gained using them. McIlroy reports how he based 
his work on algorithms created by others and then he tried three 
different algorithms before settling on the one finally used.(54) Other 
Unix tools were created through a similar process. Each program was 
created to fulfill some simple capability and was called a tool. The 
programs were designed to be fun to use and to be helpful to programmers. 
Among the principles guiding the toolbuilders were:

     "(i) Make each program do one thing well. To do a new job, 
     build afresh rather than complicate old programs by adding 
     new features.

     (ii) Expect the output of every program to become the input 
     to another, as yet unknown, program. Don't clutter output 
     with extraneous information. Avoid stringently columnar or 
     binary input formats. Don't insist on interactive input.

     (iii) Design and build software, even operating systems, to 
     be tried early, ideally within weeks. Don't hesitate to 
     throw away the clumsy parts and rebuild them.

     (iv) Use tools in preference to unskilled help to lighten a 
     programming task, even if you have to detour to build the 
     tools and expect to throw some of them out after you've 
     finished using them."(55)
 
     "Our goals throughout the effort," write Ritchie and 
Thompson, in describing the research objectives of their work on Unix,
"when articulated at all, have always been to build a comfortable 
relationship with the machine and to explain ideas and inventions 
in operating systems and other software." (56)
qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Для консольки есть классный mcedit, больше ничего и не нужно. Все равно не так уж и часто возникает нужда зайти по ssh на далекий комп и в консольке отредактировать файлег.

Eddy_Em ☆☆☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.