В чём Вы пишете???

[x-yuri]

эх, все свелось к попыткам уличить кого-то в чем-то...

Про UNIX-way. Возьмём любую CVS (хоть git, хоть svn, хоть ещё что). UNIX-way говорит: вот есть утилита командной строки, ей и пользуйтесь. Редактируешь код в любимом редакторе, надо посмотреть, что изменил, идёшь в командную строку, там смотришь.
Более удобный для пользователя подход (но менее удобный для программиста): в редактор встроена поддержка CVS, редактор тебе прямо в коде подсвечивает, что ты наменял. В проводник встроена поддержка CVS, прямо в нём подсвечивается статус файлов. И, разумеется, есть отдельная утилита для работы с CVS.
Т.е. когда пишешь код, хочется, чтобы всё нужное было под рукой. Когда работаешь с файлами -- чтобы всё нужное было под рукой.

В данном случае фраза "командной строки" не важна, её можно опустить. Важно, что есть отдельная утилита.

у тебя неправильное представление о unix-way. Но давай для начала озвучим более подробный вариант:
1. Пишите программы, которые делают что-то одно и делают это хорошо.
2. Пишите программы, которые бы работали вместе.
3. Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.
Обрати внимание на второй пункт. Да по сути все эти пункты нацелены на взаимодействие. В windows такого нету или заметно хуже с этим. А лучше всего это видно в shell (ну или он меня просто больше интересует). Поэтому, скорее всего, Gozar и прицепился к "командной строке".

Так вот, во-первых прикол в том, что оно под рукой, просто у тебя другие представления о том, что такое "под рукой". И не надо никуда идти, командная строка прямо там, в редакторе (в vim, по-крайней мере).

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

В-третьих, подсветка изменений в коде не противоречит unix-way. Просто хорошо сделать редактор - это слишком нечеткая цель, как впрочем и со всякими другими принципами. И не единственная. Первый вопрос, который возникает: "А это действительно важно, подсветка изменений в коде?" Аналогично со статусом файлов. Если для тебя это важно, ты можешь либо переделать чужой плагин, либо написать свой (при чем не обязательно на java). Если для тебя это очень важно, ищи что подсвечивает. Но часто, если чего-то нету, это значит, что это не важно, не так важно или мало кому важно. Вот семантический поиск по проекту, это для меня сейчас важно. Но может я просто что-то не так делаю Вот, Gozar, ты как думаешь, нужен или нет?

но пользоваться всем этим зоопарком неудобно.

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

я даже представить боюсь сколько времени займет тоже самое (написать скрипт) на винде для повторения сложной задачи.

отнюдь, powershell мне понравился. Да, именно так должен выглядеть bash под windows а не всякие cygwin'ы...

[x-yuri]

...

Первый вопрос, который возникает: "А это действительно важно, подсветка изменений в коде?" Аналогично со статусом файлов. Если для тебя это важно, ты можешь либо переделать чужой плагин, либо написать свой (при чем не обязательно на java). Если для тебя это очень важно, ищи что подсвечивает.

или может они в emacs уходят? Я только теоретически представляю, что это такое. Сложно сказать, то ли это редактор, то ли shell (operating system masquerading as an editor) со своей почтой и т.п. Кстати, Эрик Реймонд в свое время назвал его Like IDE, Only Better. И непонятно, это unix-way или не unix-way. Что скажешь, Kolyaj?

Кстати, узнал сегодня, что Кен Томпсон (а точнее Bell Labs) переписал Unix и проект до сих пор развивается. Но не думаю, что он был нацелен на коммерческий успех.

KenThompson, one of BellLabs inventors, once said "Unix wasn't fun anymore" and "Why is X so big?" when describing why they wrote Plan9.

http://c2.com/cgi/wiki?PlanNineFromBellLabs

Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

[Gozar]

ты как думаешь, нужен или нет?

Из важного для меня сейчас на приоритетном месте стоит: чтобы не глюкало, пусть с недостатками, но чтобы совсем не глюкало

Я потихоньку углубляюсь в командную строку и чем дальше я углубляюсь, тем дальше я от IDE, а может и нет.

А так мне не важно в чём писать, я не успеваю сейчас задумываться, у меня сейчас форум наполовину написан, нужно до НГ закончить, люди ждут, хотят общаться, уже комменты как форум используют.

[monolithed]

Я потихоньку углубляюсь в командную строку и чем дальше я углубляюсь, тем дальше я от IDE, а может и нет.

В первом случае основной инструмент клавиатура, во втором мышь.
Однако если мы говорим о привычках и предпочтениях, то это личное дело каждого, мне например проще писать код в IDE (использовать для этого *nix-way: ee, ed, vi не обязательно), а компилировать и заливать в репозиторий через shell (make && svn commit -m 'some')

Это твое личное дело, куда поворачивать: направо или налево
Двигаться вперед или остаться тут
Это никого не ебет, ты сам выбираешь маршрут

[x-yuri]

В первом случае основной инструмент клавиатура, во втором мышь.

не обязательно

Однако если мы говорим о привычках и предпочтениях, то это личное дело каждого, мне например проще писать код в IDE (использовать для этого *nix-way: ee, ed, vi не обязательно), а компилировать и заливать в репозиторий через shell (make && svn commit -m 'some')

мы как бы пытаемся говорить об объективных факторах А учитывать их или нет - это действительно личное дело каждого, если они вообще существуют...