http://mb9x.ginps.com/tools/fte.html

Ссылка найдена на Сахаре.

Чем он лучше того же (g)vim ?
К тому же судя по наличию свежих релизов этот проект находится в коме.

Чем лучше? Привычнее, что ли. VIM - это круто, как раз сейчас скачал и поставил себе 7.0. В 250 страничной доке пока утонул, но двуязычную проверку орфографии запустил.

Вот, с слову, хороший обзор по VIM
http://lug.mgn.ru/?module=articles&c=obzor&b=2&a=6

Насчет развития - я тоже так долго думал. Но выяснилось следующее:
(Sergey Pinigin, Сахара, автор ресурса)
==
Возрождению мешает позиция оставшихся держателей репозитория,
не допускают желающих. Типа все открыто, делайте клона и развивайте, но на это никто не решается т.к. уже были, штуки три, но их развитие завершалось сразу после создания ...
Народ хотел сделать поддержку unicode ...
==
Так вот, Сергей вместе с Александром Бельченко
http://onembedding.com/tools/fte/
выпустили несколько новых релизов, вставили, в частности, поддержку SVN.

Я не утвеждаю, что это The Best, это вообще каждый для себя решает, но по соотношению размера, скорости и фич - этот редактор многих обставил...

Да, VIM не так страшен, как его малюют.
Его уникальная черта - сочетание сложного, навороченного редактора с макросами, расширениями и т.п и простого дубового редактора. Т.е. каждый сможет от VIM взять свое...



Честно говоря, у меня складывается впечатление, что fte создавался, как vim "с человеческим лицом". Взять хотя бы сочетание клавиш Ctrl+]. Но в нем, на сколько я понял, нет той расширяемости, которая свойственна современным мощным текстовым редакторам вроде (g)vim, (x)emacs и им подобным. Зато весит он меньше, да и в освоении попроще.

Последние фиксации репозитория были зимой, когда я их додавил чтоб внесли поддержку subversion.
Релизы особо не нужны, собирается на счет раз , ну может быть два

Вероятно, что так. Интересная статистика:

Какой текстовый редактор вы предпочитаете?
http://www.linux.org.ru/view-vote.jsp?vote=4&back=votes.jsp

Emacs - это вообще нечто страшное, судя по отзывам (если поставить своей целью его более-менее изучить). Один Lisp чего стоит.

В общем, по отзывам, единственный "напрягающий багофич" FTE - auto indent в комментариях. Вероятно, это следствие внутренней простоты редактора.

Вообще, редкатор - это очень серьзный выбор. Я долго жил на ultraedit (используя, мягко говоря, далеко не все его фичи), теперь вот потянуло на что-то более продвинутое, и обязательно мультиплатформенное - все равно надо учиться на Linux работать. Пока "принюхиваюсь" к VIM.

Да, видел эту статистику.
Самое странное, что mc edit побеждает. Хотя объяснение этому есть - многим нужно подправить чуть-чуть, а писать что-то стоящее не нужно. Вот и получается, что в этом случае и mc edit вполне достаточно.



Не страшнее vim. Есть своя специфика, но по большому счету не так страшно. Просто у меня в свое время vim работал быстрее, чем emacs, да и необходимости в расширенных макросах на тот момент не было. Зато теперь начал писать макросы для vim'a и могу сказать, что emacs - сильнее.



Проблема не auto indent, а невозможность его быстрого исправления. Простой пример: не устраивало меня то, что gvim после "end process;" в VHDL не делал reverse tab. Пятнадцать минут и проблема решена + добавлено еще несколько фич к стандартному auto indent для VHDL. Т.е. vim - это не просто редактор, но и конструктор, с помощью которого можно сделать все, что может понадобиться.



Золотые слова! Вот только к сожалению далеко не все люди понимают, насколько может снизить продуктивность некачественный и недалекий редактор.

PS: Был тут спор по поводу прелести редактора MS Visual Studio в части автодополнений. Все были очень сильно удивлены, когда я показал, что и (g)vim тоже есть неплохо работающее автодополнение имен, которое работает не только для объявленных объектов, но и для ключевых слов и всего прочего.

Просто я осознал, что при работе я 90% процентов времени провожу в "шаблонных ситуациях": написать тако-то отформатированный кусок текста, что-то выделить, куда-то поместить выхваченный кусок информации. И начал ощущать интуитивную потребность, чтобы эти действия выполнялись автоматически. Т.е. вот надо мне абзац отформатировать как мне уднобно - нажал батон - и все готово.

По сути, речь идет о формировании моего индивидуального "базиса мышления" (не всего, конечно, а некоторой его части ). И вот под этот базис мне и нужен редактор, ибо все равно 90% времени проводится за работой с текстами. Не графический с понтами, а "обычный" текстовый, но с "фичами".

Кстати, по соему опыту, команда - это когда "базисы мышления" ее членов пересекаюбся % на 50 хотя бы (но не на 100! - иначе будет лажа).Читал про это Пока еще не научился в VIM это "поднимать", но научусь...

:help ins-completion

Help в vim'e - замечательный.

Работает!

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

Пока я не могу сказть, что я осознал VIM. Но аллергии он у меня не вызывает.

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

Это не правильно - править исходники, чтобы изменить поведение редактора относительно форматирования текста или его подстветки.

Все верно, но почему-то emacs забывается быстрее.

Почти 8 лет пользовался обоими редакторами и в итоге победил vim как более дружественный к моим мозгам. А с появлением в gvim tab-ов так вообще на другие редакторы смотреть расхотелось.

Достаточно простой редактор с минималистическими функциями использования в качестве IDE.
Из простоты следует достаточно легкая правка (в том числе и исходников) под себя.
Когда встал вопрос хоть каком-то приличном редакторе под Linux в результате долгого и нудного выбора в качестве отправной точки был выбран именно он. Он по функциональности примерно соответстует самомым продвинутым досовским редакторам 15 летней давности :-).
Из глобальных претензий пожалуй только отсутствие "проекта" :-(.
FTE использую только под Linux. Для других платформ есть гораздо более продвинутые и правильные
редакторы.

Это яркий пример наплевательского отношения к самому себе (как в общем-то и использование встроенного в FAR), как правило такие случаи не лечятся:-((((

В принципе близкое к этому и получилось, только не развивается дальше "официальным" путем.

А в чем плох встроеннэый в FAR + colorer plugin ???

И еще ESC plugin и еще многое чего, только все это вместе называется очень удобный редактор небольшого ОДИНОЧНОГО текстового файла. И по этой причине я им ПОЛЬЗУЮСЬ!

Но! Программерские вещи начинаются со слова "проект". Далее - возможности работать со многими файлами, интеграции разнообразных инструментов (компиляторы, линкеры, make, CVS...), знания tags, templates, мощной навигации, фильтрации, поиска, замены, сравнения.... И только уже где-то потом начинается раскраска (кстати, к раскраске еще и выделение шрифтом неплохо смотрится) и прочие возможности действительно имеющиеся у FAReditor обвешенного plugins.

На самом деле, FAR только что код не сворачивает, остальное есть - подсветка, автозавершение, шаблоны, синтаксис, регэкспы, переходы по файлам, сборка проекта, контроль версий, и прочее, и прочее. Всё шустро и удобно.

Начнем с того, что сам по себе он ничего не умеет почти. Далее идут многочисленные примочки очень разного качества :-( и разной доступности к модификации и с очень разным желанием разных авторов их сопровождать. Гипотетически плагинов можно _самому_ написать море и формально многое что поиметь на базовом движке редактора и файлового менеджера. В том числе и сворачивание кода и прочее прочее.
Более того, именно по такому принципу (голый движок и "плагины" )построен используемый мной под WIN редактор. Разница в том, что в случае РЕДАКТОРА худо-бедно поставляется уже собранный со многими наворотами редактор, который можно (и нужно!) доводить от уже рабочего состояния под себя.
Работа эта большая, но может делаться постепенно и менее трудоемко, чем обязательная сборка с миру по нитке и написание собственных плагинов к FAR.
Ну и еще из личных наблюдений - собственно все виденные _мною_ "поклонники" программирования в FAR себя _вообще_ не утруждали обживанием FAR :-( ну colorer то стоял, но на этом почти всегда и кончалось :-( У меня и то более обжитый FAR - ESC стоит обязательно, дюжина клавиатурных макросов,
несколько мелких плагинов.
В принципе я не отказался посмотреть полностью собранный "программерский" FAR c перечисленными выше фичами и сравнить его с почти 15 летней давности своей сборкой ME 7.00jp for DOS. Думаю, что близкая функциональность может быть достигнута. Вопрос в том, зачем этим заниматься в 2006 году....

А может он запустить make и ходить по тем местам в исходниках, где возникли ошибки компиляции?
Думаю, что нет. И есть еще очень много того, что экономит время разработчика, а значит повышает производительность его труда и его доход. Но если разработчику нужно написать в сутки 36 строчек неотлаженного кода, то тогда FAR + colorer - идеальное решение.

Да, может (плагин True Template). И много другого; именно такого, что экономит время разработчика
Из всех сред предпочитаю именно редактор FAR, обвешанный плагинами. Остальные испробованные среды либо нефункциональны, либо монстроподобны.

Теперь последний вопрос - сколько нужно собирать эту коллекцию плагинов, настраивать ее и подгонять, чтобы все было хорошо и удобно?
Для сравнения - в том же (g)vim нужно только установить его, и все уже есть, из коробки. Плюс ко всему этот самый (g)vim есть не только под виндами, но и под Linux, AIX, *BSD, Solaris и еще кучу платформ, где Far'a нет и в помине.

Устанавливать vim, может, и не надо, но осваивать придётся всё равно. И настраивать под себя тоже. Усилия, вполне сравнимые со скачиванием и настройкой нужных плагинов.
Впрочем, с плагинами поставляются начальные настройки; тот же ТТ изначально настроен на синтаксис нескольких языков, шаблоны и автодополнение нескольких форматов файлов, и поддерживает несколько компиляторов.
Пока что - только под Windows, увы.

Люди, увы, не рождаются со знанием Far'a и его плагинов, которые тоже нужно настраивать и изучать.



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



Думаю, что даже если Far вдруг станет кроссплатформенным, то плагины еще очень долго будут переписывать... Т.к. далеко не все пользователи Far'a сразу ринутся на новые платформы, чтобы изучать их и использовать. В этом плане у (g)vim есть большое преимущество - встроенный язык, который инвариантен по отношению к платформе. Т.е. нужно только пересобрать vim, остальное будет работать без изменений.

Увы, насчет усилий по скачиванию и настройке согласится не могу :-( многие плагины явно носят на себе печать пристрастий Автора и не очень-то настраиваются. Значит лезьть в исходники, если конечно автор их любезно предоставил, разбираться со стилем автора, да и за одно с многообразием языковых и инструментальных пристрастий.... Нет, эти усилия НЕ СОПОСТАВИМЫ.
Про освоение тоже уже писал - одно дело осваивать и обживать уже имеющийся худо-бедно настроенный инструмент, другое дело изобретать или искать непонятно что до начала работы.


Типичную :-( ситуацию с малораспространенными плагинами для FAR, как раз и можно рассматривать на примере именно этого плагина:

И далее:

http://forum.farmanager.com/viewtopic.php?...der=asc&start=0

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

Кстати, над предназначением декларированном автором я просто "плакалъ"


Ну и самое главное ну что-то после чтения более, чем скромной документации возникли сомнения может-ли этот плагин обеспечить:

"Запустить" точно может а вот уже по обработке ошибок, только одно упоминание вскользь без всяких подробностей по настройке фильтрации. Бродить по исходникам (особо обращаю внимание на множественно число файлов), похоже тоже не дано.

zltigo
Текущая версия плагина - 2.05. По ошибкам - ходит. Возможностей у него заметно больше, чем указано в цитате.
Насчёт распространённости - это практически must-have плагин, как Colorer.
В переписывании плагинов нужды не испытываю - устраивают, как есть.

Собственно, я оспариваю утверждение, что программирующий в среде FAR чем-то обделён. И уж конечно, сравнивать её с mcedit совершенно некорректно; ближайший аналог - тот же FTE.

Можно поинтересоваться какие и под какие платформы?

+1
Совсем недавно тоже посмотрел на все прелести настраивания far под себя, бросил даже не начав. Плагинов много, но все они ограниченные в зародыше, нет единого стиля - "кто в лес кто по дрова", доки - 0.

Увы :-( (_искренне_ сожалею), на уровне достигнутом другими редакторами на WIN платформе уже "обделен".

А я и не сравнивал. Никакого сравнения они не выдержат :-). Было краткое :-( упоминание с предполагаемым мной смыслом, что даже много много более продвинутый FARedit не должен быть использован в качестве программерского редактора, хотя если провести опрос тоже пожалуй будет
лидировать.


Где-то, как-то - да. Приблизительные "аналоги" застывший FTE, тот-же (я уже писал) старенький Multi-Edit. Но по любому помянутые "конкуренты" заметно гибче, модифицируемее и легче настраиваемее. A FARedit в 2006 году их "догоняет". Так уж сложилось :-(.
Я очень люблю FAR и использую его потому, что он ЛУЧШИЙ файловый менеджер. Я очень люблю
FAReditor (с плагинами естественно) и использую его потому, что он ЛУЧШИЙ и быстрый редактор небольших одиночных текстовых файлов разнообразного содержания.
Но использование FAReditor для программерских нужд это уже издевательство над самим собой. А время затраченное на попытки заметно его улучшить лучше потратить на выбор и обустройство текстового редактора на более продвинутой платформе.

помянутые "конкуренты" - это vim? emacs?

Я не очень-то оригинален и мой выбор так-же несет на себе печать прожитых лет :-(

1. Под DOS - Multiedit 7.0jp за многие годы был обжит и переписан под себя. Впитал в себя результаты
экспериментов с многочисленными другими редакторами на разных платформах, но выжил остался на своем месте.

2. Под WIN - логичным "продолжением" для меня стал тот-же Multiedit for Windows (какое ужасное качество его движка было в первых выпусках, какие были и есть ЖУТКИЕ исходники , отсутствие документации почти полное), но собственно по началу и выбора почти не было. Сегодня я бы очень осторожно рекомендовал-бы начинающим использовать этот редактор в качестве базы для "своего" в первую очередь из-за повышенной трудоемкости в приведении его в нормальное состояние. Хотя, что считать нормальным - может кому-то именно в одной из default конфигураций он и как родной станет. Я для начала выковыривал из него всякие иконочки, кнопочки, толбарчики ну а уж потом за функциональность брался и перенос накопленных и подсмотренных фич. В результате я имею, то что я хочу. Пока не вижу другой платформы на которую следовало-бы переползать с MEW 9.04, разве только
на 10.0, когда медленно помирающие наследники кибернетиков наконец-то им разродятся.

3. Под Linux - FTE. Изменения на уровне исходников небольшие, макросы тщательно подогнаны под
привычные. Пока живу. В какой-то степени он меня устраивает в качестве минимального редактора, поскольку я как-то незаметно для себя стал пользоватся больше кросскомпиляцией для линуксовых приложений и острота выбора линуксового редактора сгладилась :-).

4. Вообще-то надо наверное на Eclipse со временем переходить :-).....





Увы, это всего ME и FTE упомянутые строкой выше.

Сборка FTE под w32 от 13.09.2006

Один исполняемый файл работает с двумя кодировками ACP/OEMCP (ru: win-1251/dos-866). Кодировка по умолчанию задается в файле конфигурации, переключение по горячей клавише через команду ToggleCP.

Нужен совет. Сейчас работаю с fujitsu и с ARM, хочу перейти на графический редактор, посоветуйте, с какой выбрать? Сейчас их достаточно много, предыдущие советы (в этой теме) были в 2006году. Для меня - чем больше в нем будет наворотов тем лучше . До этого я не пользовался редакторами, желательно чтобы было описание на русском. Читал про SlickEdit, информации много о нем, что скажете ?
- и чайниковый вопрос: я пользовался softune, нужно будет linker к редактору подключать? если правильно понимаю или редактор сам собирает проект? например inline в IAR работает нормально- можно inline_онм сделать большой кусок программы с кучей глобальных переменных, а в softune inline подругому работает и настраивается не так как в iar.. - как с этим быть в граф. редакторе? у него свои опции и макросы? _nop _intrinsic и потом disasembler .. как это всё дело будет работать ?
- кто-нибудь использовал code::bocks применительно к softune ?

Поставь SlickEdit.


Для удобной работы с использованием универсального редактора стоит использовать универсальные инструменты для сборки проектов. В качестве последних можно применять make/scons и т.п. Редактор - это только редактор (ему все платформенные тонкости не важны), компилировать исходные тексты должен компилятор целевой платформы, параметры сборки проекта могут задаваться в параметрах вызова компилятора/линкера или в специальных файлах параметров.

а в редакторе запусить симулятор и дизассемблер не получится?
поставил недавно DAC.. RistanCASE, но там проблема с лицензией..
вопрос: а что означает :
Supported compilers
Fujitsu FFMC-16 Family V3.x
Fujitsu FFMC-8L Family V3.x
Fujitsu FR Family V3.x
???
это из pdf
установил , попытался настроить, но во первых примеры даны только на FR серию MB91 почему то ...? и make файл ..только на эту серию мк. Зачем они это пишут тогда если DAC использует полность softuneовский компилятор ??

А EaseCode из softune запускается, но debuger softunовсий непойму как затавить под EaseCode работать, ini активировал, но кнопка Project->EasyCODE->Start не активна

Не знаю редактора, до такой степени универсального.


Можно сказать что makefile для всех платформ МК Fujitsu одинаков, отличие только в параметрах вызова инструментов.

PS: Сам симуляторы и дебагеры практически не пользовал.

понятно.
а в самом softune только один шрифт кирилистический fixedsys? (все остальные русские буквы не понимают) как поставить свой?

Не пробовал побороть это дело. В самой Softune не редактировал тексты. Как компилятор она сносно работает, а редактор там отстойный.