JOE Hits 3.0 519
orasio writes " Joe's Own Editor , a unix editor very much like the old Turbo-Pascal 4 editor, or WordStar, used and enjoyed by us console freaks who still miss the old DOS days, and cannot finish understanding vi's modes, has been revamped, adding syntax highlighting and internationalization support after many years without new features. The Sourceforge project is open for contributors since a year ago, but this is the first major feature improvement, that brings new life to JOE as a neat console-based programmer's editor." Joe is one undervalued program -- less arcane than vi, less cumbersome than emacs.
Make that Turbo Pascal 3... (Score:5, Informative)
Re:VI is everywhere. (Score:1, Informative)
Re:GUI editors can't fix XF86Config, want edit clo (Score:4, Informative)
Re:Anyone have a replica of MS-DOS EDITOR? (Score:1, Informative)
Re:VI is everywhere. (Score:3, Informative)
I just installed JOE into my home directory at uni after I got sick of using VI. A few path tweaks and it all runs smoothly.
I can use VI, but I hate using it.
A first step, but Unicode support is incomplete (Score:5, Informative)
If you load a file with non-BMP characters in it they will come out as garbage. If you try to input any such characters it will mess up every single characters except those with a code point less than 128.
Re:GUI editors can't fix XF86Config, want edit clo (Score:3, Informative)
Actually, for Windows users migrating over to *nix, 'ee' [easyeditor] would be much more intuitive. The only problem [as I see it] with ee is the different implementations between different platforms--different control key sequences for the same action, depending upon OS.
Why is that?
Re:Joe vs. vi vs. GUI based editors (Score:1, Informative)
[esc] ZZ might do what you want.
"Joe was a nice alternative for DOS refugees when vi was the only other choice, but X-windows based editors make everything nicer...try middle click cut-and-paste for starters."
Try it in GVim.
"Unless we are all sitting at green Wyse 50 terminals, why are we still so married to command line editors?"
Remote sessions for example.
Re:Value (Score:4, Informative)
Vim can be used as the editor in Visual Studio [sourceforge.net].
... a win98 edit.com clone for linux? (Score:5, Informative)
A typical Emacs user rates the virtues of their editor as power, extensibility and flexibility.
Those are Unix-type virtues. Over in the GUI desktop world, they don't count for much. What people want is simplicity and discoverability. Multiple ways to do things, ways that are similar between different programs. No macros, no customisation, no syntax highlighting, no language-specific optimisations, because they're not programmers and they're not programming. Thus they don't want or need a programmers' editor. They want a users' editor.
The MS-DOS 5+ editor is a model of these virtues for a text-mode app. It's CUA-compliant, the Wordstar standard for the 1990s and onwards, it can be driven from the keyboard or mouse, as you prefer, using standard commands, and is as close to a Windows (or indeed MacOS) app as you can get in an 80x25 console.
It's good.
And I know of no free xNix product anything like it.
No syntax files for c++ yet (Score:4, Informative)
Re:Joe vs. vi vs. GUI based editors (Score:5, Informative)
I'll address these in opposite order (which I think may be in reverse of priorities, but I'm not sure):
A plain xterm with a minimal border takes less screen real estate than a GUI editor. Screen real estate is a limited commodity - I'll do more or less anything to get more space for what I'm actually working on instead of decorations. And what I'm working on is the text I'm editing, not the buttons and menus that sit there.
A "command-line-based editor" (started from command line and run in the same window allows me to edit a file *in the same visual context as I already was*. This means that I have less of context change than if I either start a new window or use an editor launcher to get a buffer in an already running editor.
And finally, a terminal-based editor gives me flexibility to use the same editor in most contexts I use an editor. I can run it in a console to fix up a config file on a machine that hasn't got X yet, I can run it remotely on a server that isn't supposed to have X installed, I can run it on a remote machine I don't trust to have an X connection to my box (as an X connections allows keyboard snooping), I can run it when I sit on a Windows box with no X and should fix an issue with a server for a customer that use Windows desktops and Unix servers, I can run it when there is enough latency for X to be a pain, I can run it against servers where an X based editor takes too much resources (yes, these exists - for instance, I'd feel bad about running an X based editor on the FreeBSD.org servers, for resource reasons), etc, etc, etc.
Basically, there are a couple of direct UI advantages to terminal based editors compared to X based editors, as well as there being a lot of times it just isn't feasible to run an X editor. Until an X editor in itself is noticably better than the terminal based editors (and that day may come, but I don't know of any X based editor that is clearly better) people like me will keep running only terminal based editors, instead of running an X based editor with a side-dish of a *different* terminal-based editor whenever we can't run the X-based one.
Eivind.
There are no modes (there is a spoon). (Score:3, Informative)
The whole "insert mode" versus "command mode" thing in vi?
It's a mistake. There is no "insert mode".
VI is a command-oriented editor. You're always entering a command. The "insert mode" is just an incomplete insert command. The command structure of VI is basically a simplified subset of TECO.
Once one quits thinking of it as being in this mode or that mode, and thinks of inserting text as a command, 99% of the problems people seem to have with vi just drop away.
Re:VI is everywhere. (Score:5, Informative)
Let me help clear up some of your confusion about vi versus vim:
There are two misunderstandings here. The first is that there are multiple modes in vi. In reality, there is just what you think of as command mode, and within command mode there is an insert command. The insert command start with an "i", and ends with an escape. The stuff inbetween is inserted into the buffer.
This explains why the backspace does what it does in vi. The backspace allows you to move backwards (destructively) in the text that you are inserting as part of the current insert command. It doesn't move you around in the buffer; it moves you within the insert command. (To make things a little more convenient, vi displays the text you type as part of the insert command in the position in which it will be inserted after the insert command completes.)
Indeed. The delete key is not supported as part of a insert command. vim may have added this as an extension, but that's a vim thing and not a standard vi thing. So if you want to delete destructively to the right, you'll have to finish the insert command you're doing.
Well, of course you're not leaving insert mode. You're finishing an insert command. The reason the cursor moves where it does is that at the end of an insert command, the cursor is put on the last character inserted. If you are inserting the string "abc", then you would type "i", then "abc", then escape. Once you have typed the "c", you are still executing an insert command, the cursor always moves after the character you've just typed. But when you hit escape, you have finished the insert command, and the cursor goes to the last character of the string you inserted.
Note that this is actually the more consistent way to do things. In vi, when you are using movement commands (hjkl, etc.) to move around, your cursor must always be on a real character that exists in the document. It cannot be in the space after the last character on the line. (The exception is blank lines, but there is no way to be on a real character then, so you have to make this exception.) So naturally, after you have inserted text at the end of a line, your cursor cannot be AFTER the last character, because this is an illegal position for the cursor within vi. So it must land on the last character. Now, should it behave differently when inserting in the middle of the line? I don't think so. If I insert "abc" somewhere, I want the cursor to be in the same place relative to the newly-inserted string regardless of whether I inserted it at the beginning, end, or middle of the line. Anything else will just create a situation where I sometimes have to look at the screen and see what the state of the program is before I can continue typing, which is a big waste of my time.
This is really easy to explain. The reason for this is that vi was invented and was popular before arrow keys were a standard thing on all keyboards. These days, they are pretty standard, but still don't exist on all devices (like cell phone and PDA keyboards). vi will work with most any type of terminal, therefore it doesn't assume that arrow keys exist and it uses other keystrokes instead (namely, hjkl). It could be extended to support arrow keys, which would be nice if you are really used to arrow keys, but honestly, arrow keys are pretty danged far out in right field away from the more useful keys, so using the
Re:A first step, but Unicode support is incomplete (Score:3, Informative)
There WAS a Joe for DOS. (Score:3, Informative)
Check SIMTEL's archives. Ages and ages ago there was a version of Joe for DOS, but Joe gave up on it since it was a pain in the ass to develop for DOS with all that 64K memory segment crap.
Anyhow, a quick Google turned up this file [atomki.hu]. It's version 2.2, which doesn't have up-to-date features, but it runs.
FTE (Score:3, Informative)
Re:Anyone have a replica of MS-DOS EDITOR? (Score:3, Informative)
tm
joe also has jpico jvi jmacs jstar (Score:5, Informative)
So it is a great way to 'move up the ladder' of editor functionality/productivity.
Incidentally, the first unix editor I used was 'ed'. For those arguing for an editor to be used on every system, it should be the ancient 'ed' which is even a part of the rescue shells like sash(this is what you use when glibc gets messed up somehow or you messed up ld.so.conf and none of your dynamically linked binaries work, ;).
Re:Joe vs. vi vs. GUI based editors (Score:2, Informative)
Re:Great news, but.. (Score:2, Informative)
I am going to give a try to Joe 3.0 now.
Re:GUI editors can't fix XF86Config, want edit clo (Score:2, Informative)
JOE? How about JED? (Score:3, Informative)
I guess if we're going to whore our favorites, go here [jedsoft.org] to learn more about JED.
Re:Joe vs. vi vs. GUI based editors (Score:3, Informative)
Well, for starters, when you spend a good deal of time editing text files (source, confs, whatever), vi can be marvelous for doing a lot of work with just a few keystrokes. Delete a word, delete a line, delete to this mark, search and replace, yank and paste, all easily done with 2-3 keypresses.
When having to do edits over a console link, every keystroke counts if you're doing a great deal of editing. I learned vi specifically for this reason when performing emergency firewall rule changes or fixes over a 9600 baud serial connection at my last job.
How come that is the only argument I hear from people about why vi is so great?
When you are put in a situation where you have to edit something on a UNIX system that you are unfamilar with, or any Solaris system that's recently been reinstalled, knowing vi makes doing any editing task very easy.
Not everyone is faced with these sorts of situations, and not everyone has a significant need to use/learn vi (note I never said there was a steep learning curve, I picked up on basic skills in less than a day). For the reasons mentioned above, knowing how to use vi was incredibly useful and saved me a good deal of time. Learning it was a minimal investment that had a significant benefit in my case.