Emacs is exactly like a religion. A western religion, at least, operates by testing the faith of its participants. The god coldly allows babies to die of unexplained illnesses, violence to affect the innocent, wars to break out, natural disasters to ruin everything. That we mortals have faith that this is a loving and intelligent, all knowing god causes us to question reality itself, our selves, our church or temple, and our religious leaders. But this questioning followed by resolve, strengthens character. Or, ruins character. It could really go either way, which is why so many object to religious pursuits.
But in Emacs we find a solution.
It is impossible to really know if Emacs is truly the One True Editor. There are arguments on all sides. Emacs, though Gnu, adheres to the First Unix Commandment, Thou Shall Do It Well, but it violates the Second Unix Commandment, Thou Shall Solvith One Small Problem at a Time. Yet, in so doing, Emacs transcends the sphere of applications and becomes like The Operating System, thus obviating the second rule. Emacs can be the Operating System, yet it cannot exist without the Operating System. Emacs and the Operating System are separate, yet in its maximally configured glory, Emacs is so like an Operating System that the two form a duality. With self documentation and the ability to execute the contents of a buffer, they truly become one.
So in this way, Emacs is exactly like God in all but two ways: Emacs is useful, and we can prove Emacs exists.
But the true mystery of Emacs comes from the question: Is it the best editor or not?!?! In my personal journey in search of an answer to this question, over two years now, I have gone back and forth, bouncing between two utterly opposite ends of the spectrum, with respect to this question. Emacs is so powerful that it must be the best editor. Emacs is so arcane that it must be pure evil. When I feel down on Emacs, I look at vi. vi is a seductress. In its simplicity it is a nude, virginal beauty that seems to acknowledge that I alone exist in all the world, and it alone exists to serve my modal desires. And then suddenly I feel dirty and realize that I may be consorting with the world's most evil application, at least with respect to home row key command configurations.
How many times have I typed "ctrl-x ctrl-f .emacs" and then gazed at my configuration file, trying to figure out what it all means?!? Verily, in using the editor, I am astounded at its speed and cleanness one minute, and frustrated by its crappy fonts and inability to automatically handle word wrap the next. I am enticed by the prospect of playing a game of chess with my text editor one minute, and frightened by the potential mix of Major and Minor Modes the next. I fall in love with the Command Chords, then I worry that if my Control or Meta key breaks, all will be lost, forever.
For years, I struggled with configuring the god-beast to work with my needs, so serve my humble desires, and each time ran into the unbelievable frustration of discovering that I am the only person in the world who wishes to spell check my text or bold a word, or use HTML mode without creating an entire web page or simply chose a file to open without having to traverse multiple frames to select it when in true terminal mode. Or am I? Am I merely the only person who prefers not to feel pain whenever I try to type up a simple grocery list?
Then, recently, I started speaking in tongues.
global-font-lock-mode t. set-face-background 'highlight "#444". ... defun my-matlab-mode-hook ()... (let ((line-text (delete-and-extract-region start end))) ...
.... yes, I began, suddenly, to speak with a lisp. I am channeling Richard Stallman. Holy crap. Or, should I say, Holy Gnu.
Emacs is a religion. It gives you everything a religion gives you. Your character is tested by the constant test of faith that learning the software is all worth it, and will eventually get you to a higher place. But in case that does not work, have a Plan B for getting high some other way. It is enigmatically of the OS and is an OS itself. Emacs builds strength, especially of the outer two fingers (the pinkey and the one next to the pinkey). But it is different from religion, because you can use it to type stuff.
I was recently told, by a gnu guru maximizer of emacs that we do not exchange .emacs files. One builds one's .emacs file on one's own through the consistent practice of The Zen. So do not send me your .emacs files, especially if you do a lot of work with standard text files that use long-line-mode, auto-fill-mode, and some html coding and possibly even html friendly markdown language. Please.
In the mean time, I chose to believe in emacs. I will not let the seeming inability to do the simplest things stop me. Because every time, so far, that I have turned away from The One True Editor, I have later returned and figured out how to do what I failed to do before.
At least it is not longer written in TECO.
Personally I like html-helper-mode rather than the default but that just might be that I used it first when I started editing web pages.
For someone who went off the deep end in emacs coding, do meta-X calendar then 'p f' or 'p a' for the more scientifically inclined.
I am the only person in the world who wishes to spell check my text or bold a word, or use HTML mode without creating an entire web page or simply chose a file to open without having to traverse multiple frames to select it when in true terminal mode.
Er. What? M-$ spell checks one word. M-x ispell-region spell checks a region. M-x flyspell-mode does on-the-fly spell checking - like open office or firefox (except that emacs flyspell-mode goes back to at least 1996, before either of those programs existed.) flyspell-prog-mode turns on flyspell-mode, but only for comments and strings. Note flyspell-mode is on by default for text buffers.
This is all very well documented, and the other tasks you're having trouble with are equally trivial, and well documented. Emacs has many difficult to learn aspects, but you have not listed them.
For someone who went off the deep end in emacs coding, do meta-X calendar then 'p f' or 'p a' for the more scientifically inclined.
That's nothing. Look here:
g m n c calendar-next-calendar-round-date
g m n h calendar-next-haab-date
g m n t calendar-next-tzolkin-date
g m p c calendar-previous-calendar-round-date
g m p h calendar-previous-haab-date
g m p t calendar-previous-tzolkin-date
(from C-h b , while in calendar .)
Use C-h F to understand what these functions do:
C-h F calendar-previous-tzolkin-date
39.9.4 Converting from the Mayan Calendar
Here are the commands to select dates based on the Mayan calendar:
`g m l'
Move to a date specified by the long count calendar
`g m n t'
Move to the next occurrence of a place in the tzolkin calendar
`g m p t'
Move to the previous occurrence of a place in the tzolkin calendar
`g m n h'
Move to the next occurrence of a place in the haab calendar
`g m p h'
Move to the previous occurrence of a place in the haab calendar
`g m n c'
Move to the next occurrence of a place in the calendar round
`g m p c'
Move to the previous occurrence of a place in the calendar round
To understand these commands, you need to understand the Mayan
calendars. The "long count" is a counting of days with these units:
1 kin = 1 day 1 uinal = 20 kin 1 tun = 18 uinal
1 katun = 20 tun 1 baktun = 20 katun
Thus, the long count date 188.8.131.52.6 means 12 baktun, 16 katun, 11
tun, 16 uinal, and 6 kin. The Emacs calendar can handle Mayan long
count dates as early as 184.108.40.206.3, but no earlier. When you use the
`g m l' command, type the Mayan long count date with the baktun, katun,
tun, uinal, and kin separated by periods.
The Mayan tzolkin calendar is a cycle of 260 days formed by a pair of
independent cycles of 13 and 20 days. Since this cycle repeats
endlessly, Emacs provides commands to move backward and forward to the
previous or next point in the cycle. Type `g m p t' to go to the
previous tzolkin date; Emacs asks you for a tzolkin date and moves point
to the previous occurrence of that date. Similarly, type `g m n t' to
go to the next occurrence of a tzolkin date.
The Mayan haab calendar is a cycle of 365 days arranged as 18 months
of 20 days each, followed a 5-day monthless period. Like the tzolkin
cycle, this cycle repeats endlessly, and there are commands to move
backward and forward to the previous or next point in the cycle. Type
`g m p h' to go to the previous haab date; Emacs asks you for a haab
date and moves point to the previous occurrence of that date.
Similarly, type `g m n h' to go to the next occurrence of a haab date.
The Maya also used the combination of the tzolkin date and the haab
date. This combination is a cycle of about 52 years called a _calendar
round_. If you type `g m p c', Emacs asks you for both a haab and a
tzolkin date and then moves point to the previous occurrence of that
combination. Use `g m n c' to move point to the next occurrence of a
combination. These commands signal an error if the haab/tzolkin date
combination you have typed is impossible.
Emacs uses strict completion (*note Strict Completion::) whenever it
asks you to type a Mayan name, so you don't have to worry about
llewelly: I know those codes. But my browser just underlines the wrong words.
I need to learn how to turn on options by default better than I'm doing now.
As to the date stuff ... Now we're talkin' !!!
This is the second time this week I've had reason to bring out this quote:
I trust vi to simply mangle my text on a wrong keystroke, not wipe my filesystem, refinance my house, make large political contributions on behalf of dead relatives, drive while intoxicated or consort with demons, all of which (I suspect) emacs could perform with an accidental Meta-Meta-Keystroke.
-- Bob Apthorpe in c.l.p.m
Well I was referring to the full package. The commands I gave were just to drop the invoker in it.:-) I'm almost surprised they didn't throw astrological positions in (though there is M-X phase-of-moon).
Personally I've got my firefox set up so I can invoke aquamacs as the editor for the text edit boxes.
I want emacs to interact with google docs.
I was introduced to Esc Meta Alt Control Shift on a dual 486DX-50 with 32MB RAM running some sort of SVR3.2.
With a german PC keyboard Eight Megabytes Almost Continuesly Swaping was of not much use.
Certainly not compared to Robelle Q-Edit with which I hacked my RPGIII and JCL sources on a HP3000 micro :-)
If you are worrying about fonts in displaying files, you probably want to WYSIWYG too much. You choose a font for emacs to work with, that displays the data so that it is most easily recognized. The most common font problem I have is 1 versus l. But emacs was never intended to by WYSIWYG, and if your are expecting what emacs displays to resemble output on a page, you should not be using emacs. Emacs is a text editor with features, it is not a word processor.
Oh, if this posting works, tell people running NoScript to allow scienceblogs.com
In my first Linux installation, circa 1998, there was an icon for emacs on my X-windows desktop. It was a kitchen sink. As I discovered more and more about emacs, I realized that the kitchen sink representation was entirely appropriate, because everything but the kitchen sink could be found in emacs. Seriously. That's also what's wrong with emacs. Seriously wrong with it.
You wrote:" ... adheres to the First Unix Commandment, Thou Shall Do It Well, but it violates the Second Unix Commandment, Thou Shall Solvith One Small Problem at a Time. "
If you are going to use old English, Thou Shalt use it correctly. Solvith is not a word either. Solveth may be but it would not follow "shalt". It is the equivalent of the modern "solves". You would not say "You shall solves something".
So your commandment would be:
"adheres to the First Unix Commandment: Thou Shalt Do It Well, but it violates the Second Unix Commandment: Thou Shalt Solve One Small Problem at a Time."
Go east or west Vi is the best. EMACS doesn't even come close. Take it from someone who has put 7yrs into using both editors in detail. There is even a GUI based Vi editor for those of you afraid to use the command line Vi.
Thats not to say that Emacs is a bad editor. It is a great editor but Vi is simply better. I could get into the details of why Vi is better but I just don't have the time to tell you of its many advanced features.
The post from Vi Meister could have been made by my old dissertation advisor - same sentiment, and he would engage in great tooth gnashing whenever any of his students used a different editor.
I must say, I groaned out loud at this: "...yes, I began, suddenly, to speak with a lisp."
Quite the clever pun, Greg.
All hail vi.
It really is like a religious war. Each side has adherents of varying levels of devotion. Neither side really acknowledges the criticisms of the other, and any reasons they give for their devotion really just boil down to personal preference or level of experience with one over the other.
I know vim can do so much more than I can do with it, but I record my macros and sling my regexen and it does what I need and I love it.
Something like this has been discussed here recently; see the link from my name, below.
As for emacs (thesis) vs. vi (antithesis), the synthesis is viper-mode: "It is emacs, and it is vi, both at the same time. Astonishingly (at least, astonishing to me) the key assignments for emacs and vi are almost entirely disjoint. So, no compromises."
The evil (small "e") of emacs is not some Manichaeist or Lovecraftian Evil. It's just ordinary incrementalist evolutionary cruftiness piled upon cruftiness. Emacs doesn't resemble Cthulhu, it resembles a camel, and for the same reasons that a camel does (and doesn't). Or, it resembles our pathetically misbegotten chordate eye, with optical sensors on the back side of the retina and little hourglass-shaped optical fibers to try to conduct a few photons from the front to the back.
Our relationship with emacs is like that between aphids and ants. Messy and weird it may be, but it sort of works.
A (small)pox on both your houses. Pico/nano or a graphical editor. (I'm partial to BBEdit or MacOS X TextEdit, and Kate if I need something on Linux.)
If you are worrying about fonts in displaying files, you probably want to WYSIWYG too much.
That is an unfair accusation of wussiness! I have vision issues at this range and I need clear fonts. That's all I want is a clear font. I have a very good WYSIWYG editor for when I need that.
For a readable font you can do no better than "Linux Libertine" (not to be confused with "Liberation"). I can hardly believe Libertine is not the default on every distribution. Anyway it's easy enough to add. My browser is set to use Libertine for all text rendering, regardless of what face the page says it wants.
Emacs does everything? Does it run Linux?
And about fonts, my requirements are:
- Latin-1, Greek, and math symbols
- regular, italic, and bold styles
- serif for pretty printing on paper
- sans serif looks better on screen, especially in small sizes
- monospace for ASCII graphics
- hinted for screen use
- free as beer to avoid legal hassles
I prefer the DejaVu family. Libertine is a serif-only font. Mixing it with sans serif or monospace from other families will probably foul up line height.
Emacs does everything? Does it run Linux?
Oh man, I wish you hadn't said that ....
I know that from within Emacs, I can run a shell. So with a little tweaking .... maybe with a virtualizer. Yeah, no problem. But what we need is embedded Linux designed for Emacs. Linumacs.
Emacs, though Gnu, adheres to the First Unix Commandment, Thou Shall Do It Well
My opinion on that is different. I tried to learn Emacs once, but it didn't take me long to discover that the XON and XOFF terminal flow control signals (ctrl-Q and ctrl-S) were assigned to commonly used functions, so that my editing session was constantly freezing up. Screwing up basic keyboard assignment defaults is not Doing It Well.
It looks like a Vi vs. Emacs fight breaking out. I'd just like to remind all that there are more choices in life. Nedit is my favorite X-based editor. It is way faster that Gedit. and Pico/Nano are good for operating in a text window.
I'll have to look at Nedit. I use Gedit and love it.
But what I'm really thinking is that one does not use Emacs for the editing. What I want is an emacs framework with Gedit as the actual editor in a given frame.
Eight Megabytes And Constantly Swapping
Shows how old that is.
And of course the recursive...
EMACS Makes All Computers Slow
hinschelwood: I just don't worry about that so much. Right now, firefox is using about 3.0 percent of my memory. Xorg 1.3. When I check my email, Evolution soars to about 2 percent. Emacs is running at around a half of a percent. Gedit is using slightly more than emacs.
See, the reason emacs is efficient in terms of memory is that it can replace many other functions and run in a session with now X. That is how I would use it on the cheap old laptop. Of course, on any normal machien with four to eight gigs, I'd run it in a window and not worry about it at all.
Greg is you use ubuntu--training wheel linux--you can use any of 3 emacsen. The one called "emacs-snapshot" anti-aliases the font nicely.
You haven't revealed yet your addiction to the analyst. Go ahead, we are all your friends, we won't tell very many people :).
Ah, the analyst. I prefer Eliza, actually.
Oh, man, you opened up a can of worms. For the record, I'm a vi man. But I have a live-and-let-live attitude. You want to use emacs? Fine, just don't try to pass legislation requiring that the "strengths and weaknesses" of vi be taught in the schools.
I go back and forth too. I like Vim and Vile on the vi side of the aisle, and XEmacs amongst the emacsen. I particularly recommend notes-mode for Emacs, a truly wonderful way to keep track of either notes or journal entries. This mode indexes, organizes, dices, slices... and all in ASCII text, God's own text format.
(For real emacs fun, look up "psychoanalyze-pinhead" or "dissociated-press".)
Me, I use vi for small, quick edits, and emacs for big coding jobs with multiple files. Another Unix commandment: Use The Right Tool For The Job.
Maybe an editor like vi or gedit in an x-window environment is the best way for the large coding jobs. ... if only the "clipboard" was better.
To me, having to work on Tru64, HP-UX, Linux and Solaris of various vintages, "it all dependeth on the version" seems to describe the problem better than "yah boo, emacs/vi is better than vi/emacs"
When I saw the title of this article, I thought "Oh dear. Oh dear, oh dear." :-)
Serious Q: Are the Mac OS X GUI versions of EMacs any improvement over the "classical" versions in being less arcane with respect to keys, etc.? (I looked into this a long time ago, but it was too early in their development really.)
I generally prefer TextWrangler/BBEdit for the 98%+ of what I'm doing that is reasonably straight-forward. (You can work with files over the wires via ftp from within the editor.) But I vary it sometimes for a range of reasons.
Greg: Nedit is surprisingly good. It feels a bit like a clone of an earlier version of BBEdit in many ways. I used to use it for a particular reason, unlike BBEdit/TextWrangler, rectangular cut'n'paste was actually fast.
Ray: I'm with you on the right tools thing, I even resort to nano for tiny fixes on small files :-)
So are we going to do a TeX/Latex versus MS Word war also?
Other useful (to me) emacs features
1. Kill and yank rectangle
kill/yank is a key feature. I just wish the keybindings were different. Also, as Linux in Exile writer pointed out to me last night, regex searches over selected parts of the text. That's cool.
etags .. wassat?
Just to egg on the battles:
regex searches over selected parts of the text
So can TextWrangler/BBEdit :-)
I've nothing against Emacs really, just having fun...
My UNIX instructor forced me to use vi. His argument: vi is installed everywhere (Win* being, once again, the outlier). Therefore I'm biased. But oh the many times I began with an emacs tutorial and continued using vim!
I don't know if emacs has such an awesome diff mode as vim does, where you can visually compare two files (vi -d file1 file2) and modify them both, using 'do' (diff-obtain), 'dp' (diff-put) and C-w w (next buffer). I just love this.
Yeah... the Emacs font configuration and ugliness problems are gone in GNU Emacs versions â¥ 23, thank God: http://golux.podzone.net/piccy (that's Deja Vu Mono apart from the preview-latex images). You can change font from a proper font dialog now and do per-buffer font scaling (C-x C-Â±). Deja's got good unicode coverage as you can see if you use e.g. TeX input method (I have it set as the default for C-\ switching).
I expect Ediff mode can do that, Marko - it certainly could be made to do it without too much effort. In fact I doubt there is anything Emacs cannot do or be made to do and it blows every other errm... âeditorâ out of the water as far as I'm concerned. All that stuff about Unix tool philosophy and kitchen sinks is just some weirdness which some ascetic programmers and system administrators (perhaps justifiably for them) seem to believe. For normal people, having everything there in one place (including such marvels as AUCTeX and calc and org-mode and...), all capable of interacting with each other and being modifiable and extensible with Lisp, is simply invaluable.
My latest test of faith: I wrote up a long and complex blog pot using autowrap and long lines mode, and when I got done, there were no long lines . I don't know why that happened
Are modes supposed to randomly go away when they want to? (There i go blaming the software again...)
Hi Greg, if you had auto-fill-mode on as well as longlines-mode, I'd guess the (real) auto-fill line wrapping would trump the purely visual line wrapping of longlines-mode.
If you're not sure what's really there in the buffer, M-x whitespace-mode (or whitespace-newline-mode) will show you.
So, auto-fill ruins the text (by ruins I mean inserts hard returns that I did not put there, or soft returns that won't go away when the text is copied and pasted) and Longlines mode keeps the text from being ruined (if run by itself)
However, the problem is that longlines mode does not handle the text properly, in that words are broken across lines arbitrarily. Therefore, even if the text as a stream of date in a buffer or file is not ruined, it is visually annoying.
Yeah - not good - but longlines mode has been superseded by Visual-Line mode in GNU Emacs 23 which doesn't break up the words. I expect you weren't the only one to complain :) It's not released officially yet but it's usually very stable this near to release and your distro probably has a snapshot package for it.
Interesting. My version of snapshot (a week old) does not seem to have that, but I'm probably invoking it wrong. I pobably didn't install everything.
It is astonishing that after 22 version of this software, which dates way back in time, it is only now that a very basic function that has bee present in all other text editors for a decade is just being thought up. This truly is a religious experience!
Aha! Actually, something else is going on. longlines-mode is what I want, and it works. The problem is, how to get it to turn on automatically when emacs opens a text file. I hooked it to text file mode, but it still does not turn on automatically. My problem here is that I don't know what I'm doing when it comes to lisp. Or elisp to be exact.
Ideally, text mode with longlines and cua turned on would work for me.
(setq default-major-mode 'text-mode)
(add-hook 'text-mode-hook 'text-mode-hook-identify)
(add-hook 'text-mode-hook 'longlines-mode)
(add-hook 'text-mode-hook 'text-mode-hook-identify)
(add-hook 'text-mode-hook 'cua-mode)
of course, cua mode is still kinda funky. A ctrl-c does not copy stuff onto the system clipboard, but only to some special emacs clipboard.
Hmmm... my mistake: indeed longlines, which I see is still here in 23 as well as the new thing, doesn't break words. In general I find that if some expected basic function/behaviour isn't present in Emacs, usually either its just not the default - perhaps because it's not considered 'proper emacs style' - and needs configuring, or it's not been included but it can be found on emacswiki or somewhere.
I don't know about cua mode but maybe something here will help: http://www.emacswiki.org/emacs/CopyAndPaste
You'd probably be happier with Emacs 23 -- which is pretty much stable at this point. It has the equivalent to cua and longlines-mode built into the core, so these features are much more robust.