Я работаю с проектом, состоящим из почти сотни файлов, причем файлы расположены в различных каталогах. И я обратил внимание на то, что много времени у меня уходит на поиск файла, который я собираюсь редактировать. Поэтому, хотелось бы иметь некий список файлов, между которыми я смог бы переключаться довольно быстро; и хотелось бы чтобы Emacs автоматически считывал этот список при запуске. Соответственно, интересно существуют ли скрипты\плагины которые позволили бы мне сделать это?
Я понимаю, что вопрос глупый, но поиск ничего не дал
Здравствуйте, sch, Вы писали:
sch>Добрый день.
sch>Я работаю с проектом, состоящим из почти сотни файлов, причем файлы расположены в различных каталогах. И я обратил внимание на то, что много времени у меня уходит на поиск файла, который я собираюсь редактировать. Поэтому, хотелось бы иметь некий список файлов, между которыми я смог бы переключаться довольно быстро; и хотелось бы чтобы Emacs автоматически считывал этот список при запуске. Соответственно, интересно существуют ли скрипты\плагины которые позволили бы мне сделать это?
Это не совсем то, что ты спрашивал, но при запуске emacs может открывать те файлы, которые оставались
открытыми на момент его последнего выключения. Активация этой возможности — "M-x desktop-save".
Здравствуйте, dyattle, Вы писали:
D>Это не совсем то, что ты спрашивал, но при запуске emacs может открывать те файлы, которые оставались D>открытыми на момент его последнего выключения. Активация этой возможности — "M-x desktop-save".
Большое спасибо за подсказку, это почти то, что мне нужно.
Здравствуйте, sch, Вы писали:
sch>Добрый день.
sch>Я работаю с проектом, состоящим из почти сотни файлов, причем файлы расположены в различных каталогах. И я обратил внимание на то, что много времени у меня уходит на поиск файла, который я собираюсь редактировать. Поэтому, хотелось бы иметь некий список файлов, между которыми я смог бы переключаться довольно быстро; и хотелось бы чтобы Emacs автоматически считывал этот список при запуске. Соответственно, интересно существуют ли скрипты\плагины которые позволили бы мне сделать это?
sch>Я понимаю, что вопрос глупый, но поиск ничего не дал
есть приблуда для емакса — ecb (список файлов и каталогов она тебе покажет).
а список открытых файлов в buffers показываются.
Здравствуйте, Rastafarra, Вы писали:
sch>>Я понимаю, что вопрос глупый, но поиск ничего не дал R>есть приблуда для емакса — ecb (список файлов и каталогов она тебе покажет).
Ничего себе "приблуда". R>а список открытых файлов в buffers показываются.
Все указанные проблемы решаются ecb. Даже в ntemacs.
. После ее C>прочтения вы поймете, что никакой workspace вам не нужен, так как C>юниксоиды уже 30 лет живут без него, а значит он не нужен.
Вот ты прикалываешься, а доля правды в твоих словах изрядная.
Я не emacs-ом, а vim-ом пользуюсь, но быстрое открытие нужных мне файлов -- без проблем. Во-первых, команда :e делает автокомплит по <tab> -- часто хватает всего нескольких нажатий, чтобы нужный файл открыть. А после того, как файл открыт, то переключение между буферами через :b и автокомплит по <tab> -- еще быстрее. А еще в vim можно сессии создавать -- тогда после повторного входа в vim редактор стартует в том же состоянии, что и при сохранении сессии.
и возможности автокомплита при открытии файлов и переключениями между буферами серьезно расширяются. Сейчас набираешь :e <tab> и получаешь список подходящих файлов. Аналогично и с :b.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
C>>юниксоиды уже 30 лет живут без него, а значит он не нужен.
E>Вот ты прикалываешься, а доля правды в твоих словах изрядная. E>Я не emacs-ом, а vim-ом пользуюсь, но быстрое открытие нужных мне файлов -- без проблем.
Ага, а еще 20 лет назад, других автомобилей здесь, кроме жигулей, волг и запорожцев не было. Но это никак не говорит о том, что это были лучшие автомобили и что только ими нужно пользоваться до сих пор.
Прошу прощения у всех за оффтопик. Но мне надоедают одни и те же религиозные войны.
Я успел еще на перфокартах задания на 1022 повводить, но это их никак не делает абсолюной истиной.
И что бы то ни было, но MSVC6, 7, как IDE, реально очень удобен (это не объективное понятие в первую очередь, а субъективное) для промышленного программирования. Кстати CBuilder не сильно хуже (остальное — это глюки самой Борланд, ну не захотели они довести до ума хорошую идею).
И скорости написания кода, которую я могу получить под MSVC, под Unix' овыми продуктами (IDE) получить не получается. Хотя Eclipse CDT начинает приближаться к этому.
И мне по большому счету глубоко наплевать на принятую в Unix или Windows религию, как наплевать на православную, католическую, буддизм, ислам, и т.д. кому это нужно, пусть они и развлекаются. Меня интересует в первую очередь молоток со всей необходимой мне функциональностью (нужным количеством кнопочек и функций — если мне нужно отшлифовать достаточно большую деревянныю поверхность, я не буду несколько дней возиться со стеклышком, а куплю шлифовальную машинку, как я решу вопрос с купилами, это моя личная проблема), чтобы я мог не отвлекаться на сугубо механические вещи.
. После ее > C>прочтения вы поймете, что никакой workspace вам не нужен, так как > C>юниксоиды уже 30 лет живут без него, а значит он не нужен. > Вот ты прикалываешься, а доля правды в твоих словах изрядная. > Я не emacs-ом, а vim-ом пользуюсь, но быстрое открытие нужных мне > файлов -- без проблем. Во-первых, команда :e делает автокомплит по > <tab> -- часто хватает всего нескольких нажатий, чтобы нужный файл > открыть.
Я знаю, но вот визуальный workspace помогает глазами искать названия
файлов — так что в большинстве случаев достаточно просто подвести к
файлу курсор и нажать enter. Часто это бывает намного быстрее, чем
набирать имя файла (даже с autocomplete'ом), особенно если он лежит в
другом каталоге.
Ну и в workspace'е есть приятные фишки. Например, можно выделить
несколько файлов и сразу их открыть. Еще очень удобно делать diff'ы —
выделяем два файла и diff'аем их.
> А после того, как файл открыт, то переключение между буферами через :b > и автокомплит по <tab> -- еще быстрее.
А вот это меня вообще жутко бесит.
Я привык работать так, что у меня в каждый момент активно 3-4 приложения
(FAR, MSDN, VS и возможно FireFox). В VS у меня обычно тоже бывает
открыто 3-4 файла с которыми я сейчас непосредственно работаю. Это
помогает сосредотачиваться на текущей задаче, не отвлекаясь на другие.
ViM и Emacs, как я понял, больше ориентированы на то, что будет открыто
одновременно куча буфферов, между которыми можно переключаться. И
буфферы с текстом скорее рассматриваются просто как представление
файлов, а не как открытые документы.
Здравствуйте, Vzhyk, Вы писали:
E>>Вот ты прикалываешься, а доля правды в твоих словах изрядная. E>>Я не emacs-ом, а vim-ом пользуюсь, но быстрое открытие нужных мне файлов -- без проблем.
V>И что бы то ни было, но MSVC6, 7, как IDE, реально очень удобен (это не объективное понятие в первую очередь, а субъективное) для промышленного программирования. Кстати CBuilder не сильно хуже (остальное — это глюки самой Борланд, ну не захотели они довести до ума хорошую идею).
Интересно, а что гигабайты кода, написанного в и под Unix в emacs-ах и vim-ах -- это все не промышленное программирование?
Промышленное программирование у меня больше асоциируется с применением систем контроля версий, систем учета багов, систем планирования времени и пр. А текстовый редактор в этом комплексе занимает не самое лидирующее место.
V>И мне по большому счету глубоко наплевать на принятую в Unix или Windows религию, как наплевать на православную, католическую, буддизм, ислам, и т.д. кому это нужно, пусть они и развлекаются. Меня интересует в первую очередь молоток со всей необходимой мне функциональностью (нужным количеством кнопочек и функций — если мне нужно отшлифовать достаточно большую деревянныю поверхность, я не буду несколько дней возиться со стеклышком, а куплю шлифовальную машинку, как я решу вопрос с купилами, это моя личная проблема), чтобы я мог не отвлекаться на сугубо механические вещи.
Вот интересно. Данный топик начинался с того, что человек пожаловался на то, что у него не получается быстро переключаться между файлами. Странно, не правда ли, что emacs -- это редактор с почти 20-ти летней историей и в нем не придумали способа для облегчения этого действия? Более вероятно, что придумали, просто sch этого способа не знает. У меня, когда я начинал работать в vim были похожие проблемы, но оказалось что в редакторе все для этого есть -- нужно только найти.
. Все просто -- нужно использовать максимально подходящий для задачи инструмент. В твоем случае make -- не совсем удобный инструмент. Но ведь в Unix-е их множество. Посмотри в сторону тех же Scons или Boost.Jam. Это, имхо, основа Unix, и об этом здорово MaximE сказал (Re[10]: Аналоги COM-интерфейсов в Unix
Здравствуйте, Cyberax, Вы писали:
>> А после того, как файл открыт, то переключение между буферами через :b >> и автокомплит по <tab> -- еще быстрее. C>А вот это меня вообще жутко бесит. C>В VS у меня обычно тоже бывает C>открыто 3-4 файла с которыми я сейчас непосредственно работаю. Это C>помогает сосредотачиваться на текущей задаче, не отвлекаясь на другие. C>ViM и Emacs, как я понял, больше ориентированы на то, что будет открыто C>одновременно куча буфферов, между которыми можно переключаться.
и в чем отличие? и там и там "куча" буфферов... и там и там можно переключаться...
C>И буфферы с текстом скорее рассматриваются просто как представление C>файлов, а не как открытые документы.
я не понял. то, как показывает VS сильно отличается от того что показывает емакс или вим?
и чем?
Rastafarra wrote:
> C>открыто 3-4 файла с которыми я сейчас непосредственно работаю. Это > C>помогает сосредотачиваться на текущей задаче, не отвлекаясь на другие. > C>ViM и Emacs, как я понял, больше ориентированы на то, что будет открыто > C>одновременно куча буфферов, между которыми можно переключаться. > и в чем отличие? и там и там "куча" буфферов... и там и там можно > переключаться...
В VS _нет_ кучи буфферов — есть открытые документы, которые изображаются
в виде табов в области редактирования. В Emacs/ViM ориентируются на то,
что я буду просто переключаться между файлами по мере необходимости, при
этом меня не должно волновать открыт ли файл в данный момент.
> C>И буфферы с текстом скорее рассматриваются просто как представление > C>файлов, а не как открытые документы. > я не понял. то, как показывает VS сильно отличается от того что > показывает емакс или вим? > и чем?
Здравствуйте, Cyberax, Вы писали:
C>В VS _нет_ кучи буфферов — есть открытые документы, которые изображаются C>в виде табов в области редактирования. В Emacs/ViM ориентируются на то, C>что я буду просто переключаться между файлами по мере необходимости, при C>этом меня не должно волновать открыт ли файл в данный момент.
это как так?
перейдем к примерам.
вот я открыл емакс.
смотрим в buffers — пусто.
открываем файл. и еще 2.
смотрим в buffers — появилось 3 файла.
надо еще что-то открыть — открываем. в новый буфер.
надоел буффер — закрывем (при желании сохранив).
ну разве что в виде табов не отображаются , хотя табы — штука спорная, ихмо.
что же есть такое эти табы в VS как не аналог буферор в емаксе?
Здравствуйте, Cyberax, Вы писали:
C>Я знаю, но вот визуальный workspace помогает глазами искать названия C>файлов — так что в большинстве случаев достаточно просто подвести к C>файлу курсор и нажать enter. Часто это бывает намного быстрее, чем C>набирать имя файла (даже с autocomplete'ом), особенно если он лежит в C>другом каталоге.
Я начинающий емаксер, но штатными средствами не проблема его не набирать:
нажимаем ctrl-x d, набираем имя директории (автококомплит),
получаем dired — примерный аналог одной панели нортон коммандера:
C>Ну и в workspace'е есть приятные фишки. Например, можно выделить C>несколько файлов и сразу их открыть. Еще очень удобно делать diff'ы — C>выделяем два файла и diff'аем их.
Групповые операции тоже есть, diff оттуда есть, есть diff файла с его бэкапом одной кнопкой etc.,
а то чего нет, наверное несложно добавить.
Есть еще speedbar, но мне он пока никак.
C>А вот это меня вообще жутко бесит. C>Я привык работать так, что у меня в каждый момент активно 3-4 приложения C>(FAR, MSDN, VS и возможно FireFox). В VS у меня обычно тоже бывает C>открыто 3-4 файла с которыми я сейчас непосредственно работаю. Это C>помогает сосредотачиваться на текущей задаче, не отвлекаясь на другие. C>ViM и Emacs, как я понял, больше ориентированы на то, что будет открыто C>одновременно куча буфферов, между которыми можно переключаться.
Емакс нет, он позволяет в любой момент открыть еще окон (фреймов, окнами там называют то, что внутри фрейма),
причем кнопками (ctrl-x 5 2), переключаться между ними и.т.д.
C>И буфферы с текстом скорее рассматриваются просто как представление C>файлов, а не как открытые документы.
Непонятно. Я разницы, например, со студией не улавливаю.
Зато что меня в емаксе удивило — это единственный виденный мной редактор, который по умолчанию
умеет подсвечивать <> в с++ темплейтах.
z00n wrote:
> Я начинающий емаксер, но штатными средствами не проблема его не набирать: > нажимаем *ctrl-x d*, набираем имя директории (автококомплит), > получаем dired — примерный аналог одной панели нортон коммандера
Вместо этого всего в VS мне нужно только нажать Ctrl-Shift-l, и у меня
будет _иерархический_ (чего от dired'а не дождешься) список файлов в
проекте.
> Групповые операции тоже есть, diff оттуда есть, есть diff файла с его > бэкапом одной кнопкой etc., > а то чего нет, наверное несложно добавить.
Мне не нужна сотня способов выделения, мне нужен прежде всего быстрый
способ выбрать нужный файл. dired этому ну никак не соответствует.
> Емакс нет, он позволяет в любой момент открыть еще окон (фреймов, > окнами там называют то, что внутри фрейма), > причем кнопками (ctrl-x 5 2), переключаться между ними и.т.д.
Мне не нужны несколько окон. Мне нужен способ организации workspace'а —
его я не нашел.
eao197 wrote: > > > Интересно, а что гигабайты кода, написанного в и под Unix в emacs-ах и > vim-ах -- это все не промышленное программирование?
Я ничего об этом не писал про гигабайты кода. Но и на запорожцах
некоторые умудрялись по многу наезжать (не водитель, сколько километров,
не скажу). Но это никак не говорит о том, что запорожец лучшая машина, и
ничего не надо менять.
> Промышленное программирование у меня больше асоциируется с применением > систем контроля версий, систем учета багов, систем планирования времени > и пр. А текстовый редактор в этом комплексе занимает не самое лидирующее > место.
Вот эта часть сильно зависит от того, кем ты данный момент времени
являешься в процессе разработки. И если говорить с точки зрения именно
программиста, которому надо найти баг в программе, которая до тебя была
наворочена так, что в дрожь при первом взгляде на код бросает (при чем
это никак не зависит от того под какой операционкой ее изначально писали).
И речь не про текстовый редактор, в первую очередь, а про IDE, которая
без единого лишнего телодвижения с моей стороны дает мне быструю
навигацию по дереву классов, дереву файлов и зависимостей между
различными частями проекта. При установке курсора на нужную мне
переменную выдает мне ее тип, одним нажатием кнопки перебрасывает на
место ее определения. В отладочном режиме при наведении курсора мышки
высвечивает ее значение. Да, я соглашусь, что это все "шоколад", без
которого можно обойтись, но автоматическая стиральная машина, такой же
"шоколад" (несколько тысяч лет стирали руками и ничего, сколько кг белья
перестирано за это время).
> > Или взять твой соседний топик: makefile, .d и .o файлов в отдельные > директории <http://rsdn.ru/forum/Message.aspx?mid=1492808&only=1>
. Все просто -- > нужно использовать максимально подходящий для задачи инструмент. В твоем > случае make -- не совсем удобный инструмент. Но ведь в Unix-е их > множество. Посмотри в сторону тех же Scons или Boost.Jam. Это, имхо, > основа Unix, и об этом здорово MaximE сказал (Re[10]: Аналоги > COM-интерфейсов в Unix
Я и не спорю с тем, что это не совсем подходящий инструмент для данной
задачи (хотя я предполагал другое, не думал, что make споткнется о такую
достаточно простую вещь). Это вещь не необходима, но мне, больше
нравиться, когда временные файлы, создающиеся во время компиляции и
сборки складываются в отдельную папку, а не в ту в которой находится код.
А выбор инструмента, как это не странно звучит, но очень часто
определяется не программистом, и даже не, как теперь принято говорить,
"архитектором проекта".
> <http://rsdn.ru/forum/Message.aspx?mid=1483208&only=1>):
Здравствуйте, tamburin73, Вы писали:
>> Интересно, а что гигабайты кода, написанного в и под Unix в emacs-ах и >> vim-ах -- это все не промышленное программирование? T>Я ничего об этом не писал про гигабайты кода. Но и на запорожцах T>некоторые умудрялись по многу наезжать (не водитель, сколько километров, T>не скажу). Но это никак не говорит о том, что запорожец лучшая машина, и T>ничего не надо менять.
Если вы привыкли ездить на Мерседесе, это не означает, что БМВ хуже.
>> Промышленное программирование у меня больше асоциируется с применением >> систем контроля версий, систем учета багов, систем планирования времени >> и пр. А текстовый редактор в этом комплексе занимает не самое лидирующее >> место. T>Вот эта часть сильно зависит от того, кем ты данный момент времени T>являешься в процессе разработки. И если говорить с точки зрения именно T>программиста, которому надо найти баг в программе, которая до тебя была T>наворочена так, что в дрожь при первом взгляде на код бросает (при чем T>это никак не зависит от того под какой операционкой ее изначально писали). T>И речь не про текстовый редактор, в первую очередь, а про IDE, которая T>без единого лишнего телодвижения с моей стороны дает мне быструю T>навигацию по дереву классов, дереву файлов и зависимостей между T>различными частями проекта. При установке курсора на нужную мне T>переменную выдает мне ее тип, одним нажатием кнопки перебрасывает на T>место ее определения. В отладочном режиме при наведении курсора мышки T>высвечивает ее значение.
>> Юниксовый путь — решить конкретную задачу конкретным простым и мощным >> кодом, а не создавать обобщенных монстров на все случаи жизни. T>Это уже религиозные предпочтения. А IDE, для нескольких языков T>программирования, я бы не назвал таким монстром.
IDE по определению такой монстр. Потому как Integrated Development Enviroment.
sch>Я работаю с проектом, состоящим из почти сотни файлов, причем файлы расположены в различных каталогах. И я обратил внимание на то, что много времени у меня уходит на поиск файла, который я собираюсь редактировать. Поэтому, хотелось бы иметь некий список файлов, между которыми я смог бы переключаться довольно быстро; и хотелось бы чтобы Emacs автоматически считывал этот список при запуске. Соответственно, интересно существуют ли скрипты\плагины которые позволили бы мне сделать это?
Конечно, немного не в тему, но хотел бы поделиться своим опытом работы с большим проектом в Emacs. Я обычно оперирую в уме не файлом, а классом или функцией, и прыгаю на нужное определение при помощи, например, tags. Через некоторое время большинство нужных файлов оказывается загружено, и тут используется swbuff (настроить переключение на C-TAB и задействовать фильтр буферов, скажем, только cpp-файлы).
Длинные же списки всех файлов, по-моему, скорее мешают, чем помогают.
