Become a fan of Slashdot on Facebook


Forgot your password?
Software Operating Systems Unix Linux

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.
This discussion has been archived. No new comments can be posted.

JOE Hits 3.0

Comments Filter:
  • by MavEtJu ( 241979 ) <slashdot.mavetju@org> on Tuesday April 27, 2004 @06:29AM (#8981766) Homepage
    Make that Turbo Pascal 3 which has the wordstar-like editor. Version 4 and later had a full blown GUI, which got later replaced by Borlands TurboVision IDE. Which made it, at least for me, the best CUI there was.
  • Re:VI is everywhere. (Score:1, Informative)

    by Anonymous Coward on Tuesday April 27, 2004 @06:57AM (#8981906)
    just another editor
  • by Blackknight ( 25168 ) on Tuesday April 27, 2004 @06:59AM (#8981916) Homepage
    It's not a clone but mcedit is pretty nice. It's included with the mc program which is also a nice file manager.
  • by Anonymous Coward on Tuesday April 27, 2004 @07:02AM (#8981931)
    Link: []
  • Re:VI is everywhere. (Score:3, Informative)

    by rugger ( 61955 ) on Tuesday April 27, 2004 @07:07AM (#8981955)

    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.
  • by lokedhs ( 672255 ) on Tuesday April 27, 2004 @07:08AM (#8981961)
    Joe does not have proper unicode support, contrary to what many people claim. It only supports BMP, the fist 64K of characters out of the more than 1 million possible characters.

    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.

  • by bplipschitz ( 265300 ) on Tuesday April 27, 2004 @07:12AM (#8981978)
    Clearly GUI editors aren't much use until you can get X running. I use vi my self, but none of the existing Linux text mode editors use the "standard" keyboard shortcuts such as cntl-c for copy. To old win/dos users I would recommend pico as the least esoteric of the non-X editors. Does anyone know of a win98 clone for linux?

    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?
  • by Anonymous Coward on Tuesday April 27, 2004 @07:22AM (#8982023)
    "Everyone should use Joe because CTRL-k-d is so much easier and more intuitive than ESC :wq!"

    [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)

    by Schwuk ( 52764 ) <(moc.kuwhcs) (ta) (kuwhcs)> on Tuesday April 27, 2004 @07:36AM (#8982106) Homepage
    Vi(m) [] can be used on Windows - I use it all the time.

    Vim can be used as the editor in Visual Studio [].
  • by Lproven ( 6030 ) on Tuesday April 27, 2004 @07:55AM (#8982225) Homepage Journal
    That is the question, all right.

    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.
  • by MoobY ( 207480 ) <> on Tuesday April 27, 2004 @08:14AM (#8982338) Homepage
    Too bad they have provided only a limited list of syntax files. As an example, there is no syntax highlighting file for C++ programs yet.
  • by Eivind Eklund ( 5161 ) on Tuesday April 27, 2004 @08:37AM (#8982552) Journal
    Why am I "married" to command line editors? There are really two reasons: Flexibility of context for use, availability in the context I am, and the price of screen real estate.

    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 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.

  • I know, this is about JOE, not VI, but the submission DOES bring up an almost universal misconception people have about vi.

    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)

    by Anonymous Coward on Tuesday April 27, 2004 @09:10AM (#8982844)

    Let me help clear up some of your confusion about vi versus vim:

    Backspace key won't work correctly when you want to delete text which was there already before you entered insert mode.

    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.)

    Forget about the delete key, you'll have to quit insert mode and use x

    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.

    And for some reason, when you leave insert mode, the cursor magically moves one position to the left

    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.

    When you accidentally use your arrow keys at an unexpected moment, your file gets messed up and/or you sometimes automatically leave insert mode

    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

  • by geoffspear ( 692508 ) * on Tuesday April 27, 2004 @09:25AM (#8982982) Homepage
    Actually, the U in UTF means "UCS", as in "UCS Transformation Format 8". The U in UCS means "Universal", as in "Universal Character Set".
  • by Croaker ( 10633 ) on Tuesday April 27, 2004 @09:39AM (#8983159)

    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 []. It's version 2.2, which doesn't have up-to-date features, but it runs.

  • FTE (Score:3, Informative)

    by cheesybagel ( 670288 ) on Tuesday April 27, 2004 @09:59AM (#8983413)
    FTE [] also has menus. But the project seems dead...
  • by Tmack ( 593755 ) on Tuesday April 27, 2004 @10:05AM (#8983486) Homepage Journal
    If you have any emacs experience, JED is very similar. Ctrl-@ hightlight your block, ctl-k to kill, ctl-y to yank it back in wherever. Or, ctl-x x [0-9]+ to insert into a buffer by number, then ctl-x g [0-9]+ to bring it back. I also love the replace command (esc-x replace_cmd), as it runs in interactive mode by default, can replace everything, only what you tell it, or nothing at all, and shows you each item before changing it. The multiple level undo rocks too (ctl-_). Oh, and when doing debugs, ctl-[ g is indespensable, letting you jump to a line by its number (given from debug/crash output), and if you're ever stuck, ctl-g will cancel, ctl-x c will exit.


  • by Danny Rathjens ( 8471 ) <slashdot2@ra[ ] ['thj' in gap]> on Tuesday April 27, 2004 @10:19AM (#8983622)
    I've never tried the others, but jpico is really great for those that first learned pico. jpico is just a symlink to joe, but when run that way all of the pico keybindings like ^K and ^U to cut/paste lines work; except now you have many of the features pico is missing like search and replace.
    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 and none of your dynamically linked binaries work, ;).

  • by the chao goes mu ( 700713 ) on Tuesday April 27, 2004 @11:23AM (#8984445)
    Techincally, :!man vi is onscreen help. Not well organized, or user-friendly. But you can get onscreen help from vi.
  • Re:Great news, but.. (Score:2, Informative)

    by Ocrad ( 773915 ) on Tuesday April 27, 2004 @11:48AM (#8984772) Homepage
    I also use Joe. In fact GNU Ocrad [] is written with it.

    I am going to give a try to Joe 3.0 now.

  • by mikecron ( 686696 ) on Tuesday April 27, 2004 @11:48AM (#8984777)
    You're referring to Midnight Commander [].
  • JOE? How about JED? (Score:3, Informative)

    by ThisIsFred ( 705426 ) on Tuesday April 27, 2004 @12:18PM (#8985192) Journal
    Oh sure, JOE gets on the front page of Slashdot. How about JED? It's like the missing editor that Emacs never had. It's also got built-in S-Lang scripting, has built-in syntax highlighting, session recovery, drop-down menus, and has been ported to many platforms.

    I guess if we're going to whore our favorites, go here [] to learn more about JED.
  • by lactose99 ( 71132 ) on Tuesday April 27, 2004 @06:35PM (#8990520)
    What exactly is it that vi's steep learning curve gives people apart from a feeling of "eliteness", that can't be found elsewhere in easier to use software? What's the pay-off?

    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.

Variables don't; constants aren't.