Jump to content

    

one_eight_seven

Участник
  • Content Count

    985
  • Joined

  • Last visited

Community Reputation

0 Обычный

About one_eight_seven

  • Rank
    Знающий
  • Birthday 11/11/1983

Контакты

  • Сайт
    http://

Информация

  • Город
    Москва

Recent Profile Visitors

5301 profile views
  1. На выходных поищу. Но только они не делают из vim'а eclipse, а присобачивают эклипсий движок (по сути - установленный eclipse) к vim'у.
  2. А какое тут оскорбление. Вполне расхожее выражение. Особенно в выборе между тёплым и мягким. Ну или круглым и оранжевым. Разве? а я видел три. Но, возможно, они не очень удачные, поскольку, они тащат за собой, собственно, эклипс. Vim в таких делах нужен только, чтобы был, другими словами - не нужен.
  3. Вы вообще, знаете что такое полный по Турингу язык? Судя по заявлениям - нет. Вопрос в том, что имеет смысл делать в виме, а что не стоит. Весь функционал эклипса, например, можно к нему прикрутить, но это повлечёт за собой весь эклипсий шлак. В этом случае проще и разумнее эклипсом обмазаться.
  4. Прокомментированное вами в тот момент сообщение было именно ответом на ехидный пост со скриншотом стартового окна, который якобы что-то показывает. Согласен с вами, что это глупость несусветная, но вы проверьте цепочку сообщений, тогда будет понятнее моя реакция.
  5. Скачайте gcc для любого микроконтроллера и посмотрите, как это сделано там. Обычно это файл mcu.h там заголовочные файлы для конкретных моделей MCU обмазаны толстым слоем директив препроцессора. Эти директивы основаны на макроопределениях. Макроопределения эти передаются компилятору как параметр командной строки (даже если вы гуй удовлетворяете, мышкой тыкая, в конечном итоге это вызов консольной команды). Т.е. вы это макро явно определяете при настройке инструмента сборки.
  6. Тонких нет. Но компилятор смотрит по полному пути файла. Итак, если у вас один и тот же файл каким-то образом лежит в нескольких местах, то макро будет определено при первом включении файла, и переназначений не произойдёт, прагма же попытается включить код второй раз (файл-то другой). Более того, symlink'и и hardlink'и ещё сильнее усложняют задачу определения того, что файл на самом деле один и тот же. Ну и используя макроопределения можно строить условные компиляции. Как абстрактрый пример, у вас есть несколько разных версий драйвера, которые требуют разного кода для своего использования. С помощью директив условной компиляции вы можете их разделить, в случае pragma, тоже можете. но только тем же самым способом, и у вас к прагме прибавится инклюдгард, и плюсы прагмы уже перестанут быть актуальными. Потому, стандартный путь, классический - это инклюдгарды. Прагма - не хуже, но непонятно зачем. Появись она сразу, возможно, она была бы основным методом, но сегодня уже очень-очень много когда сделано другим способом, и к нему все привыкли. Так что плюсы - иллюзорны.
  7. да, некоторые ещё и оптимизировать это умеют. Этот способ не однозначно лучше, чем метод сиклюдгардами. Что это за последовательность? Что она призвана прояснить?
  8. В разных: у меня на всех машинах одинаковый файл .vimrc, соответственно, в vim всё тоже одинаково. Ну а так в разное время использовал на cygwin, ubuntu, rhel, centos, fedora. Ну а стартовое о чём должно сказать? Давайте будем сравнивать сравнимые вещи и сравним стартовое окно Vim с ярлыком запуска VisualStudio. Что будет более информативно? Разговор шёл о работе в редакторе, а не о любовании на стартовое окно.
  9. Ну и каша. Что в коде, что в этой теме. В общем-то как написано, так и работает. Объявление должно быть раньше, чем использование. Зачем вы делаете определение внутри файла исходников (*.c), если оно используется за пределами этого файла? Такие объявления должны быть в заголовочниках (.h). В файле, где что-то используется, оно тоже должно быть сначала объявлено, да, при этом файл может быть включён в код много раз (#include "somefile.h") и могут произойти переопределения, именно для борьбы с этим в заголовочниках и ставят инклюдгарды (#ifndef FILENAME_H ...)
  10. Всю жизнь и ещё три дня : ) Можно быстро начать с vim-bootstrap (в гугеле ищется на раз-два). Дальше, когда закончится первоначальное обучение, всегда будет возникать желание сделать что-то быстрее, лучше, и тут если умеете бороться с перфекционизмом, то всё достаточно быстро. Берёте рабочий пример, смотрите имеющиеся плагины и выбираете, то, что больше нужно. Скачивание и установка плагинов напрямую из гитхаба, добавлением имени пользователя и названия репо в конфиг файле, достаточно быстро (секунды). Больше времени уходит на поиск в гугле. Также, как выше - дело секунд. Больше времени - поиск, тестирование, как оно - удобно/неудобно в работе, в режиме сравнения. Могу сразу посоветовать vendetta, molokai, большинству нравится одно или второе. Есть. Когда привыкаешь, начинаешь автоматически это делать везде. В Vim есть командный режим, и, в итоге ловишь себя за тем, что где-то в тесктовом редакторе общего назначения появляется :w, :wqa, diw, и постоянно жмякаешь на Esc.
  11. О вас. Ваши рассуждения не согласуются даже с формальной логикой. А это математика уровня средней школы. Вы не освоили. Речь идёт про вим, а вы, ничего не зная о нём говорите о том, что этого в нём нет (это невежество). В качестве того, что вам кажется аргументом, вы приводите то, что этого нет в SlickEdit. Мне неизвестно, есть там это или нет, но это не важно, поскольку SlickEdit - это не Vim. Это нарушение формальной логики (необразованность). Я вам пишу, что важно перемещение по коду, топикстартер в первом посте написал, что ему это важно. Значит, нам это важно. То, что вам это неважно - это не аргумент для всех. Один размер не всем подходит. Вы пишете, что важен хороший парсинг, а с фиговым всё плохо. Ну и что? Пользуйтесь хорошим парсером, с Vim - это не проблема. Естественно, есть языки, на которых программировать в vim - плохая идея - это C#, Java, и другие языки, в которых больше генерируются конструкции, а не пишется код, те, в которых работа с текстом отходит если не на второй, то на третий и четвёртый планы.
  12. Зачем же так своё невежество и необразованность выставлять напоказ? И причём тут slick edit? тем более с приставкой "даже".
  13. Ну не удивительно. Vim и вовсе берёт свои истоки в ed, который был ещё в домониторные времена, и было очень важно создать инструмент, который минимизирует ошибки при наборе кода (и ed сейчас является частью Vim'а). То есть, сделан для быстрого набора текста, не смотря на клавиатуру. Да, уже года три работаю в Vim, в основном, причём, первые два года работал в нём по той причине, что не знал как из него выйти. А теперь мне назачем из него выходить. За это время я понял, что он одинаково хорошо работает в совершенно разных стеках технологий, с разными языками программирования. Смена стека технологий не меняет в работе редактора вообще ничего. Набор текста - не очено большая часть работы. Куда больше - перемещение по тексту. При редактировании очень часто нужно повторять действие. В Vim - это либо точка (.) - повтор последнего действия, либо & - повтор команды, ну либо %& - повтор команды для всего файла. Если это работает на удалённом сервере через ssh, то консольный редактор - чудовищно быстр. Он (и другие редакторы - emacs, или хотя бы sublime) не скрывают технологии за абстракцией самой IDE. Парное программирование (т.е. синхронизация одновременной работы нескольких) есть давным давно с помощью t-mux. Ну и то, что в VS code это стало предлагаться в последнее время говорит о том, что Vim был жив и популярен всё это время не просто так. Да, у Vim относительно крутая "кривая обучения", monkey-coder'ы называют её даже "стеной обучения". Ну, для них есть IDE - и в IDE можно работать и выдавать результат.