OSDev.org

All started with

candy:> To be proper gnu software it needs to "do one thing and do it well"
curufir:> Care to explain how EMACS slipped through the net?

Candy:>

It didn't even, it's just a really bad interpretation of the one thing

If you want to code well, you must have all your tools at handslength, so you must be able to compile, indent, test, run, debug the code within the editor. Since there are numerous instances of bugs where you want to rip your hear out, even the doctor is appropriate. It's just not what we'd expect from a code editor.

I personally would try, given the current state of computers, to make a streamcompiler, that you can send new-stream commands, so that it is constantly active & loaded. Then, call it from the user agent when a user leaves a piece of code (in the bg) to work on a different one, or when he explicitly wants it to be testcompiled. Then, when all the test compiles still work (indicated with red text in tabs), you can make a testrun because it's automatically linked to the new executable. Seems like a very productive way to code

Curufir:> Nope. I refuse to believe it. It has it's own LISP dialect, little text mode games, command line access etc. Emacs is a shell masquerading as a code editor

mystran:>

While I use Vim instead of Emacs, I've actually considered the MzVim patch that's available to embed MzScheme into ViM. The usability of a code-editor depends critically on the ability to script the editor. Otherwise you end up doing the same thing again, and again, and again, and again. Better design is no excuse, since people have different needs. Hence, the only way to build a NON-bloated code-editor is to build the whole editor around the scripting language.

Here we're back in Jihad land... ::) Subject of today: The one true text editor.

Hence, the only way to build a NON-bloated code-editor is to build the whole editor around the scripting language.

See, that's your opinion. For me, the only way to build a non-bloated code editor is to build it around a decent user interface. Yes, I prefer my code editor to be capable of auto-indenting, syntax highlighting, open-via-FTP, and displaying the functions of a source file via ctags. But most of all, I prefer my text editor to get out of the way so I can focus on my work instead on scripting my text editor.

Personally, I use UltraEdit because it brought its features to my doorstep ("File, Open... wait, open per FTP? Gee, nice feature!") instead of requiring me to hunt for them. Its macro function is quite capable of automating repetitive tasks, and if I need something more sophisticated I'll write up a dedicated script in my favourite scripting language.

Bottom line, tastes differ. The GNU philosophy isn't for everybody, and the less rooted in Unix land you are, the less it's for you.

Gnu is not Unix ...

Well, this Jihadi(me) uses vim on a regular base tu quickly edit some bash script or crawl throu' some log file with any regular expression for it comes quick at hands with such things: short commands for your need at your fingertips - once etched into brains fabric, they don't fade away (hmm ... how do I save and quit?:wq, thats it). I just got used to it.

This Jihadi doesn't throw an axe into the same notch. I don't mind whether vim or emacs is *better*. for his daily kernel code, he uses *kate*, so what say you now?

Anyway, don't get yourself cramped down about emacs versus vim. that's plain crap. Opinion against Opinion, this will not work out, for it lacks good and unbiased arguments, deriving to nothing more than polemics.

@solar: 've heard about this editor. Looks like something that would look fine on my own desktop. Your opinion I can understand best. I don't want to have a text editor in my way when intending to do some coding. It just shall do its job and neither be clever or complicated to use. Just there.

Stay safe folks. This Jihadi 's gonna enjoy the sun which is shining rarely these days.

beyond infinity wrote:
@solar: 've heard about this editor. Looks like something that would look fine on my own desktop.

Windows Shareware. Unless you're willing to fiddle with Wine (seeing you're running Linux), jEdit with a couple of plug-ins probably comes closest.

EditPlus does everything I need. I never really had any time for Emacs or Vi(m).

well that's my oppinion.

srg

ever heard of conText a vey nice one for Windows with a lot of fancy features. also allows user programmable keys for executing the files etc.

hmm, Linux: mcedit ;D
Windows/DOS: notepad,edit.com (and sometimes editpad for some conversion) ;D

Very basic editors, but that's what I like ;D

No! No! No! Use SciTE (tm) ;D

Under Linux (well, FreeBSD anyway), I always enjoyed nEdit. I just wish it had document tabs and used a better toolkit like GTK.

I mainly use Vim; Emacs never really appealed to me.

Two things:

1) I've found out that if you do one thing, and one thing only, it's possible to find a decent editor. If you do a lot of things, and constantly do a lot of things, it's better to have a highly-configurable, scriptable editor. Why? Because while there's a good editor for almost any job, language, whatever, if you're set of tasks changes a lot, you'd end up wasting time switching editors all the time. If you have an editor with a good scripting language, you can add the missing parts you need, and continue hacking.

2) People seem to get quite religious about their editors. Generally, this has nothing to do with which editor is actually better. I've seen people tell me how great 'nano' is, and start learning 'ViM' the day they see me using it, because my ViM happens to have some killer-feature they've secretly missed.

On the other hand, I've seen 'emacs' users look at my ViM, and next day announce that they've reimplemented my feature to emacs. The trick is, if you have sufficiently powerful scripting language, you can add anything. It's just that you don't necessarily miss that stuff because you've never though of it, because it's not there in your favourite editor.

I constantly look at new editors. I'm not going to switch (unless I get a Vi-clone that fixes the few problem I have with Vim, which include not having proper support for slave-processes and not being able to pipe partial lines (selections are line-granularity when piping, an unfortunate feature inherited from vi). On the other hand, every time I see a new editor I think "is there something i'd like to have in my editor" and if there's something, I'll add it (unless it's a small feature and would involve lot of scripting).

I think it's also good for innovation. Having a scripting language in editor teaches one to improve or "refactor" not only the source code edited, but also the editor used to edit it.

That being said, I would never ever again consider an editor without:
- regex-search/replace, just can't refactor without it
- syntax highlight, redefinable for any language
- auto-indentation, at least C-style + Lisp + General (text)
- file-type (eg. language) autodetection and per-filetype editor settings
- parenthesis matching (this speeds up a lot), both movement and visual
- ability to pipe files and selections to arbitary commands
- ability to run arbitary commands (especially make)
- FULL keyboard-shortcut interface. No menus, no toolbars.
- ability to send files to the editor from any shell
- resizeable split windows.. horiz or vert, I don't care.
- ability to do editing like search/replace on a limited region
- unlimited undo and redo
- crashed session recovery

Proper mouse support for pasting/selection is a plus, but not really necessary. CVS integration is nice, but being able to run commands give you that so no special integration is really needed.

There are about a hundred other features I probably rely on, but that's the list that came to my mind without much thinking.

That said, my editor has to work at least in terminal (although I normally use GViM) since remote X is SLOW and I need to remote constantly.

This is lengthy; I want to show how very similar "demands" can lead to very different and incompatible "solutions".

mystran wrote:
If you do a lot of things, and constantly do a lot of things, it's better to have a highly-configurable, scriptable editor.

Which implies that it is upon you to hack the editor to suit your needs. I think this notion is flawed. I have a file to edit. If my editor of choice does not sufficiently support me - by inbuilt features, downloadable plug-in or whatever - the editor is the wrong tool.

Demanding strong scripting features for an editor is confusing editor users with editor developers. Sometimes an XYZ user is also an XYZ developer, but more often they aren't. This is a misconception quite common in GNU land.

That being said, I would never ever again consider an editor without:
- regex-search/replace, just can't refactor without it
- syntax highlight, redefinable for any language
- auto-indentation, at least C-style + Lisp + General (text)
- file-type (eg. language) autodetection and per-filetype editor settings
- parenthesis matching (this speeds up a lot), both movement and visual

Fully ACK.

- ability to pipe files and selections to arbitary commands

Overkill, IMHO. There are only so many things you can do meaningfully with a text selection, and the editor should support that directly without you having to know additional commands to pipe to. For actions on files, there's the shell - that's not the editor's job to do.

- ability to run arbitary commands (especially make)

ACK.

- FULL keyboard-shortcut interface. No menus, no toolbars.

Erm... another thing I dislike in GNU land is that too many developers superimpose their private notion of "good UI" on their product. You want no menus, no toolbars. I want menus and toolbars. An option to enable / disable them would probably make both of us happy, but you sound like an editor having them is inherently bad.

And I strongly dislike having to memorize ESC-colon-q-! or Ctrl-C, Ctrl-X and their ilk. I like to have an intuitive menu layout which also tells me of available shortcuts - I can search for the exotic options, and memorize their shortcuts if I use them often enough, instead of having to hunt down the spell in the manual. That's a design concept, something not only related to text editors but software in general. Some people seem to like the notion of their system being a secret tome of the arcane; I like my system being as intuitively useable as possible.

- ability to send files to the editor from any shell

Well... are there (serious) editors that can't do that?

- resizeable split windows.. horiz or vert, I don't care.
- ability to do editing like search/replace on a limited region
- unlimited undo and redo
- crashed session recovery

ACK. And there we are, you using ViM and lookign down on GUI editor users, and me using UltraEdit and not able to stand using ViM for extended period of times. (I use it for a quick hack-away, a CVS commit message edit, or when I'm in a SSH and don't care for startin up UltraEdit to open-via-SSH, but I can't stand it for any serious editing.)

Proper mouse support for pasting/selection is a plus, but not really necessary.

Absolutely required for me.

CVS integration is nice, but being able to run commands give you that so no special integration is really needed.

Since I use CVS and Subversion on a regular basis, ClearCase and Arch occassionally, I don't care for "integration" at that point. Even if CVS is all you use, procedures are too different from project to project for a catch-all integration in your editor. (One project might be OK with every file-save equalling a commit, others might kill you for that.)

There are about a hundred other features I probably rely on, but that's the list that came to my mind without much thinking.

Macro recording and playback, open-by-FTP/SSH, integrated project management (closing project X and saving all windows / bookmarks, opening project Y where you left of), ctags integration (displaying function lists, jumping to function definitions), integrated diff.

That said, my editor has to work at least in terminal (although I normally use GViM) since remote X is SLOW and I need to remote constantly.

That's why I require open-by-FTP/SSH; as a GUI user, I can't really stand terminal-based editors, and I don't have X Window running as a rule. (Windows / Cygwin user.)

I'm quite a x-emacs fan, mostly because of Query-Replace (with an ease of use and scripting that i haven't met anywhere else), Speedbar (the KATE speedbar fits me aswel) and Describe-key / Global-set-key features.

Now being also a coder-to-the-bones, i also wrote a couple of scripts that allows creations of menus for my window manager out that will send files to an open session of the editor, and a command-line alias that recursively searches for files matching a pattern (say "threads" is resolved in "kernel/src/kernel/mtask/threads.c" and "kernel/src/head/sys/threads.h" which are opened by the running session of the editor)

The feature i still wish the most is an editor able to offer quickly-available list of 'related files' such as seeing all the #include'd files when browsing through a C file.

Whether scripting is wished or not is really a matter of taste. Given my Sarah-Programatzki trend, i couldn't live without it

Whether keyboard or mouse is preferred typically depends on your mouse-handling skillz as well as your mousepad softness. I personally tend to have too imprecise mice on too-dirty mousepads so reaching a 2-pixel-wide bar for resizing/unsplitting frames give me headaches. C-X 2 , C-X 0 and C-X 5 2 are my daily meal

Pype.Clicker wrote: I'm quite a x-emacs fan, mostly because of Query-Replace (with an ease of use and scripting that i haven't met anywhere else), Speedbar (the KATE speedbar fits me aswel) and Describe-key / Global-set-key features.

Now being also a coder-to-the-bones, i also wrote a couple of scripts that allows creations of menus for my window manager out that will send files to an open session of the editor, and a command-line alias that recursively searches for files matching a pattern (say "threads" is resolved in "kernel/src/kernel/mtask/threads.c" and "kernel/src/head/sys/threads.h" which are opened by the running session of the editor)

The feature i still wish the most is an editor able to offer quickly-available list of 'related files' such as seeing all the #include'd files when browsing through a C file.

Whether scripting is wished or not is really a matter of taste. Given my Sarah-Programatzki trend, i couldn't live without it

Whether keyboard or mouse is preferred typically depends on your mouse-handling skillz as well as your mousepad softness. I personally tend to have too imprecise mice on too-dirty mousepads so reaching a 2-pixel-wide bar for resizing/unsplitting frames give me headaches. C-X 2 , C-X 0 and C-X 5 2 are my daily meal

I am very mouse based.

srg