I've used JOE for 15 years. I recently upgraded form JOE 3.x to 4.4 and was unimpressed with the recent decline in quality to the point of considering switching editors. Hopping between open/close braces with ^G no longer counts nested pairs correctly; TAB now randomly inserts 2 or 3 spaces instead of the 2 I have it configured for and that my files use; and my home-key settings in my config file are ignored.
I'm completely baffled how the developers can add such bugs to a stable, decades-old product. Regardless of whether the bugs get fixed, it's shaken my confidence that I can trust JOE not to screw up my work. (Even 3.x JOE gets into screwed-up states and crashes from time to time; I trust 4.x JOE even less. Even the "save often" mantra I'm cautious about, since I don't want to save data from a screwed-up state. That's worse than straight-up crashing.)
Yes, it looks like both the joerc and the ftyperc formats have changed in a non-backward-compatible way. At least, wiping those fixed the ^G issue for me. (I can't tell yet about the indent issue since I can't reproduce that reliably; if it persists I will file a bug report.)
Thanks for all your work developing and maintaining JOE. My apologies for such a negative earlier post; I would not get so easily frustrated if I did not rely on JOE every day :)
I used joe in Slackware exclusively throughout the 2000s until I started having issues as well. I would save a file, script wouldn't work, open it back up and my changes never committed. I switched to nano and had no more issues, and I've been using nano at the console since then (and Geany in X).
It wasn't reliable back then, but that was nearly ten years ago. I'm sure it's improved since then. And honestly, it could have been just one regression that was soon fixed, but I had already moved on and I generally don't look back when something like that happens.
Right – "fixed the bug that ate my files" isn't good enough. I need to feel confident that the next version of the software won't introduce another similar bug.
The best "protection" I've seen in this space is to log all changes to the edited document, through a simple (and therefore easy to prove correct) code path. The only editor I've ever seen do this was a Xilinx schematic editor. The editor crashed all the time, but I never lost work, since on restart, the editor simply replayed what it had in its log. (This was fun to watch!) Of course this method isn't foolproof, but it went a long way making me feel confident my work wouldn't be lost.
I once wrote a script to periodically back up the text contents of my terminals, JOE 2.x crashed so frequently (losing my work). JOE 3.x crashes less frequently, and I can tell when it's about to (block-selecting starts acting up), but it's unpredictable enough that I could in no way describe how to reproduce it in a bug report, and I often don't have cores enabled on the machines I'm working on.
I love love love the interface, which keeps me on it, but I've been bitten enough to lose trust that I won't get bitten in the future.
I've also been using Joe for roughly 15 years. Its the least crap editor that I've found or perhaps the one that I remember the key bindings for. I don't get upset about things that don't work as I want them to. I'm quite happy to use a stable and very capable editor.
Obviously if I had a real snag with it I would start with bug reports and if that didn't get the problem sorted, then I would either get my wallet out and hire a programmer or fix it myself.
I found JOE while looking for a free cross-platform, preferably open source editor that could handle huge files with ease - you know, file sizes that make most editors choke and die (or make your system freeze while trying to allocate an insane amount of memory). Even vim isn't especially effective handling very large files. JOE was the first (and for the time being, the only) free cross-platform editor I found that handles the largest of files easily.
Found it here (noticed this link was submitted to HN in the past):
Tried joe again recently after using nano, and one of the first gotchas i ran into was that joe asked if i wanted to throw data away. That is the polar opposite of what nano, and i dare say most programs, ask upon exiting with unsaved changes.
Edit: Seems that i was still using an older version, and said behavior has changed in more recent versions.
Perhaps you used Ctrl-C, which means abort. The message is there to prevent you from accidentally discarding your file.
If you use Ctrl-K Q, then it works the way you expect. Notice that it says "Hit Ctrl-K Q to exit or Ctrl-K H for help" when you first start the editor. I added this beginning with version 4.2 for this very reason.
Also, if you try "jpico" JOE further emulates nano (pico is nano's predecessor).
I know Yes/No remains very usable in a terminal, but seriously, why is there not consensus about the question of verbs vs Yes/No alternatives in dialogs yet?
I always thought the verbs were obviously better. Better the quicker you're reading the dialog, and most users don't bother reading it all.
For GUIs I 100% agree it should always use verbs. For command lines I think there's a very long history of confirming destructive things and allowing for /usr/bin/yes, so verbs don't quite make sense.
I think GUIs took so long coming around because of the command line.
The question "Do you want to save" on exit (which some software asks) is destructive when answered "no" (you lose shat you've typed and efited). I've always found it wrong, as in most other cases answering yes is destructive ("do you want to format?")
I mostly live in my IDE and its editor doesn't have a concept of unsaved changes and doesn't ask. Meanwhile it has undo/redo, browsable local history and VCS integration. What's the benefit of having changes unsaved?
Don't you ever go into a file, start playing around with an idea, decide you don't like it after all, and want to revert to the on-disk version? That's probably my most common use of leaving changes unsaved.
I don't know what editor the GP is talking about, but I would love an editor which had some sort of persistent edit-buffer. So, my work is always saved somewhere, and simply committed to the file I'm working on when I click "save".
I don't see the benefit of the editor saving the file to disk without being told to. My editor has that feature too (although it's not active, by default), and I've never understood why that would be desirable.
A lot of what I do is under version control, but not everything is, and a 3-character "revert buffer" command makes more sense to me than a longer VCS command that will also discard changes that might already be present in the on-disk version of the file.
It just strikes me as a feature where I'd have to rebuild my basic assumptions of how an editor works, without the incentive of a worthwhile improvement to the workflow.
My editor does this independently of VCS, so that's not an issue. I get it, "last saved to disk" is a save point that is meaningful to you. The world you can move to is a world where you can have any number of these save points. "last saved to disk" would be "go back ten minutes" but you'll also "go back five" or whatever else. It's a much more general way of working.
I was basically forced into using vi (school Solaris box with few editors installed and little space to compile more). A little muscle memory makes basic editing easy, and knowing the connections to "ed" helps things make more sense.
Easy stuff takes a small amount of knowledge, but more advanced features make the editor worthwhile for long-term use.
That was one of the reasons I gave up on using Joe for system administration. It showed rather big mismatch between my mental model of how a system editor should work and what Joe did.
Mh. On the one hand, the backup feature has saved my ass more times than I can count, but on the other hand for some software (hello nginx!) and their conf.d directories it can get nasty as well - not cool when you reboot the server and nginx doesn't start because there's a backup file with duplicate directives...
I would argue that scrolling is the sanest default for systems administration since text files are usually formatted to a fixed width and are sensitive to line breaks.
Yet try to edit with horizontal scrolling XML or JSON file written without line-breaks. Or perhaps some other config files written on assumption that a terminal window will always be maximized and get at least 200 character width.
In my opinion an editor for system administration should try to show as much information as possible by default and horizontal scrolling is an opposite of that.
Who's Joe? Is he still around? There's a bit of history about the editor here but not too much about Joe himself (well, he appears to have children and own a house these days :-) [1]).
I used to think that way too. But you may want to get up-to-date with the situation and reconsider - as others have mentioned, since changing owners, SF has been working hard to fix their conduct and reputation.
(Also, in this case: Joe is a classic, well-known piece of software.)
They haven't done that for a long time now, ever since they changed owner. The site is ugly and old fashioned, and a little spammy with the ads at times, but that's it.
If you invite me to a dinner party and I shit on the table it doesn't really matter how much I claim I'm reformed you're not going to invite me back unless you're really short on company. If there's any other source then there's no reason one would spend time checking out if sourceforge is really reformed or they just did a legal manoeuvre and started hiding the malware better.
That describes me and I didn't follow its course after the crapware thing so it had a terrible reputation with me until I just learned about the acquisition in this thread. I wouldn't be so sure.
Yea, it's no longer owned by the Dice/Slashdot people. Still that stigma and the bundled adware pushes from the previous owners has kinda tainted them.
I'm glad to see it's still going. Freshmeat/Freecode is now a time capsule sadly.
SourceForge and Slashdot are both owned by BIZX. They bought them both from DHI (Dice) back in the start of 2016. The sale was announced in January of 2016. BIZX is pronounced like 'physics' but with a B. As near as I can tell, BIZX is an advertising company.
I'm completely baffled how the developers can add such bugs to a stable, decades-old product. Regardless of whether the bugs get fixed, it's shaken my confidence that I can trust JOE not to screw up my work. (Even 3.x JOE gets into screwed-up states and crashes from time to time; I trust 4.x JOE even less. Even the "save often" mantra I'm cautious about, since I don't want to save data from a screwed-up state. That's worse than straight-up crashing.)