Slashdot Mirror
GNU Coughs Up Emacs 22 After Six Year Wait
lisah writes "After keeping users waiting for nearly six years, Emacs 22 has been released and includes a bunch of updates and some new modes as well. In addition to support for GTK+ and a graphical interface to the GNU Debugger, 'this release includes build support for Linux on AMD64, S/390, and Tensilica Xtensa machines, FreeBSD/Alpha, Cygwin, Mac OS X, and Mac OS 9 with Carbon support. The Leim package is now part of GNU Emacs, so users will be able to get input support for Chinese, Tibetan, Vietnamese, Thai, Korean, and other languages without downloading a separate package. New translations of the Emacs tutorial are also available in Brasilian Portuguese, Bulgarian, simplified and traditional Chinese, Italian, French, and Russian.'"
Use the unicode2 branch from emacs CVS, not this release. Hopefully emacs 23 won't take as long as emacs 22. 8-(
Why choose?
...but is it art?
Assuming you mean Esperanto, you can get started here: Emakso
And lucky for me, I press those with my left hand, which doesn't have carpal tunnel.
I'm a VIthian and don't have RSIs yet. I started to get carpal just a bit in my right hand about '86 or so - but switching the mouse to the other side (along with folding in the feet so the keyboard lies flat flat and adding a minimal wrist pad) cleared it up and has held it off for another 20 years so far. I just celebrated my 60th and am still typing away furiously every day.
Switching sides on the mouse has a two minute learning curve once you've added these two aliases:
### "three-button" version of X:
### alias rightmouse 'xmodmap -e "pointer = 1 2 3"'
### alias leftmouse 'xmodmap -e "pointer = 3 2 1"'
### "five-button" version of X:
alias rightmouse 'xmodmap -e "pointer = 1 2 3 4 5"'
alias leftmouse 'xmodmap -e "pointer = 3 2 1 4 5"'
Mirroring the buttons lets you do mirror-motion on pressing them, which is just about automatic. I occasionally switch to the other side and am full speed either way.
But it wasn't carpal that made me stick with vi rather than switching to emacs.
Back when I bought my first unix box (in the early '70s) it only had two meg and used a motorola 8010 so it couldn't do demand paging to run a task bigger than the real RAM. Emacs wouldn't fit.
Since then I've occasionally looked into switching. But every time I do I see that EMACSians take about half-again as many keystrokes to do the things I do heavily. So in addition to the learning curve it would be a step backward in productivity, at least initially.
I considered using a vi emulation mode - until I discovered that (at the time) it had TWO of them, with different divergences from "real vi". B-b Rather than trying to solve the "donkey between two bales of hay" dilemma I stuck with vi.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Someone on a slashdot post or blog somewhere posted instructions on how to build and install carbon emacs from CVS. I've used it on my PowerBook, and two MacBook Pro's (Core Duo, then Core 2 Duo) with great success.
s co emacs ./configure --enable-carbon-app
.bashrc so that I can easily launch it from the command-line. The best part is that when you launch it in the background with a file argument, emacs grabs focus when it comes up. The emacs that requires Apple's X11 would never come to the front on launch.
c s -g 110x40 --no-splash"
Here's the instructions I saved:
mkdir ~/tmp
cd ~/tmp
cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/emac
cd emacs
make bootstrap
make
sudo make install
Then I put the following in my
alias emacs="/Applications/Emacs.app/Contents/MacOS/Ema
(you may want to adjust the columns and width from 110 and 40 to your own preference)
NOTE: I haven't tried this since 22 was officially released.
If you want an editor like EMACS that follows the UNIX philosophy, take a look at mg, from the OpenBSD team (now runs pretty much anywhere). Most people who use EMACS, however, would feel horribly lost on something like mg, since it's the non-UNIX-like nature of it that is its strength.
I am TheRaven on Soylent News
It would be similar...
Really, there's nothing in Emacs to figure out - since it has a menu, you can save and so faroth using that, if you don't feel like learning the keyboard commands (whch have a huge amount of depth and are logically organized).
You load files and the appropriate mode should be applied. You get more out of it if you learn some modal specific commands (like autoflow comments in C mode) but you can always go without them.
The feature I still find most powerful is macro recording, if you ever decide to go in for a second look - C-x ( starts a key board macro, C-x ) ends recording, and C-x e runs the macro you last recorded.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Many years ago they used to accuse emacs (not entirely unjustified) of using lots of memory, "Eight Megabyte And Constantly Swapping". However, emacs still uses 8MB (in fact when I start it in text mode there is only 6.2MB resident) whereas other editors, even simple ones, have overtaken emacs in this respect and use many times more.
So it is quite ironical that emacs used to be a pig, but nowadays is lean and mean compared to most other editors. Still it is more powerful than most.
One of the improvements for v22 is in the macro handling. F3 now starts recording, F4 ends recording, and F4 again runs the last recorded macro. Easier to remember than the old shortcuts (which still work), and perhaps more useful for an Emacs novice. There's other changes to the macro handling as well; it's even sweeter than it was before.
cd emacs/mac
./make-package --self-contained
Makes a .dmg which includes an installer. Self-contained means all the support files end up in the Emacs.app directory, so nothing is installed in /usr.
A few historical notes:
:). The influence of actual Lisp Machine Emacsen on GNU Emacs is rather limited (remember that Stallman wasn't a big fan of the commercial Lisp companies!).
:)
:) (And I don't think most Emacs users would have too much trouble with it: it only implements a tiny subset of the GNU Emacs commands, but it gets them right.)
1. Emacs predates the Lisp machines, it was originally developed for the MIT mainframes (in TECO, with TECO as an extension language). GNU Emacs has its origins mostly in Multics Emacs, a port to a different mainframe/OS, both the first Emacs implemented in Lisp and the first Emacs extended using Lisp (also the only standard Multics program using Lisp
Of course, none of these systems were even remotely Unix-like, so you're entirely correct that Emacs doesn't care about the Unix philosophy
2. mg predates OpenBSD (it dates from the eighties, based on MicroEMACS), though the version in OpenBSD is probably the only maintained one. It isn't very Unixy: no regular expression search/replace, no filtering text through pipes (both of these are pretty much defining for the Unix philosophy). It's just as much Emacs as you could get in a 16-bit micro
You most likely meant http://www.emacswiki.org/.
I think it depends a lot on how many systems you use, both now and in the future, and also your rate of learning.
If I'm a new Java programmer I'll probably get more out of Eclipse than vi or Emacs; if I'm using Windows I might get more out of Visual Studio than vi or Emacs. But that's just in the short term. In the long term, the language and operating system might change, but the need to work on text files is likely to still be there. If I'm using multiple languages or OSes now, or if I expect that I'll be using different languages or OSes in the future, it means I'm likely to change IDEs. Each time I change, I'm learning from scratch. This means I don't get more than a decade of becoming an expert with one editor; instead I learn the most common tasks but not the advanced features.
With vi(m) or Emacs, I get something that's not optimized (specialized) for one environment, but instead something that's general-purpose and adapts to many different systems, and I can carry what I learn from one system to the next. I've been using vi and Emacs on Solaris, OS/2, Linux, Windows, Mac, with C, Scheme, C++, Java, Ruby, Python, Perl, SML, and many other languages. I could've used Visual Age on OS/2, but most of what I learned would not have been that useful when I switched to Eclipse on Linux, and most of that would not be useful when I switched to Visual Studio on Windows, and most of that would not be useful when I switched to XCode on Mac. Instead, I'm using a tool that's less optimal for my current needs, but it's something that I can keep using for other needs.
It extends beyond programming to my editing of text files, email, messages for newsgroups, HTML, my diary, my calendar, blogs, XML, config files, etc. Do you use Visual Studio for editing your blog, or do you use a different editor? Do you use yet a different editor for HTML? For email? I think it's a reasonable way to go but I find that I only use the simplest editing functions when I use lots of editors, because I can't count on features being available as I switch from one context to another.
It's a tradeoff, and I don't know for sure whether it's better to be a novice with specialized tools or an expert with a single general-purpose tool. I'd consider vi(m) and/or Emacs if you're editing a whole lot and expect to be editing on many different systems, languages, etc. I'd stick to IDEs if you're using one system a lot and don't expect to switch often, or if you don't edit enough that there's any benefit to learning vi(m) or Emacs.
This is from Emacs 21:
M-x name-last-kbd-macro
to give the macro a name
M-x insert-kbd-macro
to insert it as Lisp code in the current buffer.
The VIM Quick Reference Card is nice. Hang it on your wall.
In "vi" under older SunOS, even arrow keys didn't work! Who decided that h-j-k-l should be used instead of arrows !?!?
As with many bizarre bits of vi, the answer seems to be historical. Early terminals of course did not have arrow keys. The hjkl keys actually had arrows on them, so it made sense then.
Same goes for the escape key; it was where Tab is now, so it was easier to hit. (Now I find ctrl-[ easier to hit than escape.)
Penny - plain text accounting
You can also use the functions the sibling comment suggests to create your own macro saver (I had one that saved my macros into my emacs folder in saved-macros.el).
Also, there's an emacs extension called "better-registers". Better registers allow assignment of keyboard macros into "registers". Registers are basically variables that are assigned to keyboard keys. So you can assign a macro, string, number, or whatever into a variable associated with a key, and then perform operations on that variable (increase number, run macro) via shortcut keys. Its also pretty useful for keyboard macros (as you can have an increasing number, etc inside a macro).