I don't think it's a coïncidence.
Editors are tools for your fingers. There are huge penalties to being good with an editor if you are forced to use a different one. I use emacs for writing things other than code (email, web forms like this very comment) not just because I think it's better than whatever built-in editor is provided for the task, but because it hurts so badly to use something other than emacs.
The converse point is that there are huge benefits available if you give up all your existing editing tools and spend some time (and yeah, it can be months to years) getting really, really good at just one. Really, that one has to be emacs or vim, which are the only editors out there designed to scale to this level of specialization.
It always makes me sad to watch other people work and see how much time they spend fighting with their editor, moving their hand around to the arrows or mouse or function keys, fighting with the presentation logic of their word processor to get the page break on the right spot on the screen, etc... It doesn't have to be that way.
I'm not taking a stand on the argument one way or the other, just pointing out how similar they sound. You said:
"There are huge benefits available if you give up all your existing editing tools and spend some time (and yeah, it can be months to years) getting really, really good at just one. Really, that one has to be emacs or vim, which are the only editors out there designed to scale to this level of specialization."
How does this differ from:
"There are huge benefits available if you give up all your existing languages and spend some time (and yeah, it can be months to years) getting really, really good at just one. Really, that one has to be Lisp, which is the only language out there designed to scale to this level of specialization."
Whether you agree or disagree with the sentiments, haven't you heard people expressing those sentiments in much the same terms?
Uh, no. You're making an editorial point that they both seem equally silly, you just aren't saying that. If your only purpose to posting was a bland linguistic analogy with no bearing on the subject being discussed, then I withdraw my argument on the grounds that your post is unimaginably boring. :)
But to respond: the sentences differ in that one statement is truer than the other. "Hugs are good." and "Suffering is good." use the same language too, but you wouldn't use that as part of a sideways argument that huggers are insane, would you?
At the risk of appealing to authority, I do not consider this essay silly: http://www.paulgraham.com/avg.html
What I was doing is making a commentary about the similarity between cultures, or perhaps mindsets, or perhaps people.
Now, if you want to believe that when I say X, that I really mean Y, and when I assert "No, I really meant X," that I am lying and I meant Y but have some sort of duplicitous reason for telling you that I meant X, that is your right.
But I'm going to have to let you go your way on this issue, and I will go mine.
I have spent more time thinking about the nature of programming languages than editors, so I will perhaps ruin a perfectly good neutral statement by talking about my own beliefs. I think there is such a thing as a power continuum in languages. I have no idea whether Haskell is more powerful than Clojure, but I am comfortable describing Java as far down the continuum from Scheme.
I also think there is such a thing as design in programming languages, and I think it has value. So while Python may be less powerful than some other languages in an absolute sense, I understand why many people choose it. It is well-designed in exactly the same way that the original iPod (No Wireless. Less Space Than A Nomad. Lame.) was well-designed. And by well-designed, I don't mean "Has all the features, " I mean, "Has a carefully selected set of features that complement each other."
Given my beliefs, I understand people who prefer to work with more powerful languages and why they might argue that you never need to step down the power continuum. Makes sense. I also understand people who argue a certain tool that is less powerful in an absolute sense but has a design that suits them in some fundamental way. I even understand people who argue that certain languages are more powerful and well-designed, like Haskell.
I honestly don't have a strong feeling that either person is wrong, and I'm fairly comfortable saying that we haven't done enough research to settle the matter empirically.
So no, I am certainly not ridiculing Lisp users who claim that there is no need to step down the power continuum. They may be right, and we don't have enough solid evidence to disprove their claims, just what amounts to folklore about readability and design patterns and significant whitespace and monkey-patching.
Likewise, I cannot really argue with an emacs evangelist. Who can say that such an argument is anything except Blub? I value certain well-designed text editors--I have been enjoying Byword lately--but can I prove that I'm more efficient with Byword than I would be if I spent two weeks or a month or a few years becoming an emacs guru?
So anyways, no I was not being derisive, but I don't fault anybody for wondering if I had something on my mind considering that I tried very hard to say nothing about whether Emacs is or isn't superior to Byword, or whether Ruby is or isn't an acceptable Lisp.
> I don't think it's a coïncidence.
This invites the reader to ask "Well, then what's the reason?" And you as the author haven't stated what you think is the answer, which makes the careless reader (in my defense, it's a single post!) bring up a cached thought for the answer. In my case, I see passive arguments all the time that use the same style you tried to use neutrally, where the arguers try to lead the reader to conclude the other side is brain damaged without specifically saying so.
Anyway, interesting case on miscommunication and careless reading. :)
Simple text editor = simple + powerful
Emacs = complex + powerful
Lisp = simple + powerful
Blub = complex + powerful
I think most people prefer simple + powerful. And this isn't black and white - Blub can often be simpler for X simple task. However the real yard stick is whether as your problem domain gets more complex does Blub suddenly lose its veneer of simplicity?
I always bring up Alan Kay in these kind of threads but his observations are always so damn salient - agglutinative PLs (features) vs style PLs (simple principles).
I've got some other more complex customizations that I don't use very often, for example a set of functions that let me cycle through various background/text color schemes. For awhile I had that mapped to f8. I've also effectively used hotkeys that generate documentation/comment templates. But those tend to come and go, and when I'm not using them they don't interfere at all.
Beyond a few fundamental things, emacs is only as complex as it needs to be. Yes, it's a fairly large base install compared to vi, or a simple text editor, but so far it's never been big enough to get in my way.
Emacs seems quite simple to me, actually. Intimidating at first, sure. Complex to master, but simple to use.
Then again, there's an obvious difference between something that is difficult to learn and something that is difficult to use. In fact most tools require training at first to use them, and Emacs is not any different.
Or perhaps it was just that he didn't bash my favorite editor :)
- developing software while on a flight?
- recording field data for an experiment?
- using hibernate or sleep to save power?
- connecting to a projector for a presentation?
I've been trying to get into clojure which entails installing clojure-mode, swank-clojure, leiningen (which brings the pain of maven) and slime. This is where emacs has always broken down for me. Once I step outside the distro provided packages I find broken tutorials, unspecific versions, and instructions written like:
First install package.el.
Add to your .emacs: (add-to-list 'package-archives '("marmalade" . "http://marmalade-repo.org/packages/"))
C-x C-e to evaluate it, and you're good to go!
Except that didn't work in two of the three emacs installs I have. Any time I need to download an elisp file I dread reading the instructions. Too often the author forgot that he loads some other required package in his 1000 line .emacs/init.el file. Then you end up with half a set of instructions.
I think the only solution to the problem would be package maintainers providing instructions for how to install their package in a specific vanilla version of emacs from scratch with no other changes. But if they have to give up their custom emacs configs they won't be able to write up an explanation.
1. Download lein from
2. Launch lein (self-install) from the command line.
3. Run lein plugin install swank-clojure 1.3.0 on the command line.
4. When you first run swank, it may complain you do not have project.clj or something like that, because it expects to be launched form inside a project directory. You may create a dummy project directory (cd; lein new dummy; cd dummy).
You need to run the above steps once, to install. Run the following at the beginning of a clojure session:
5. Run lein swank on the command line.
6. In emacs, run slime-connect (with the default parameters, most likely).
In case I have garbled the above, I am sure someone will correct me. Although I did it both on Windows and MacOs and it worked. (On Windows, I use bash shell form the MinGW project, but I see no reason for the standard Windows shell not to work.)
Separately, you may want to install clojure-mode from the same repository.
Wish I had thought of that a week earlier! Could have saved us a lot of time at the meetup.
(The way you posted still works fine, so if you've already got it set up there's no need to switch.)
A single emacs function to update/start clojure seems a good way to go, however I had it in the past and as soon as the dependencies broke I had to go in and figure out what was going on under the hood and how to fix it. Which is educational but distracting. Will your setup still work in 12 months?
Thanks for all the effort in bringing Clojure to the masses! :-)
P.S. Got an error -- will submit a bug report. EDIT: wrote a blog comment instead.
The clojure-mode available through elpa ( clojure-mode 1.7.x) is not new enough to deal with swank-clojure which needs 1.9.x (specifically I was after M-x clojure-jack-in)
Plus, the elpa instructions don't include emacs23 because it allegedly comes with 23 (even though the elpa website does not say this). But elpa is not included in emacs 23 on Gentoo.
And thus an evening of mine is lost to trying to get the same emacs environment running on my Gentoo desktop and Ubuntu laptop.
Obviously my problems could be from a lack of experience with Emacs, but I hate that using a text editor is so hard.
And another example is the pain of trying to build wanderlust from scratch which requires apel, flim and semi. Some of which were ONLY hosted on abandoned FTP servers. Luckily Dave Abrahams recently moved those scattered and abandoned packages to a single place https://github.com/wanderlust
I'm not claiming to be a genius level programmer here, but I don't think I have to make that claim either. There's something seriously wrong with Emacs when an experienced programmer has serious issues setting up a basic development environment.
For comparison's sake, I hit "comfort-level" with Vim within two weeks, including a fully customized .vimrc, colour files and keyboard navigation. After a month of using Emacs I was somewhat comfortable with the keyboard shortcuts for basic navigation, but didn't know how to do several things that I could do in Vim. I also had no idea how to add syntax highlighting for language X - managing only to get it working for one dialect of Lisp and nothing else. Ah, and installing from ELPA had a nice tendency to show me error messages instead of actuall installing anything.
Bah, sorry for the rant. It just frustrates me when I hear about Emacs and how great it is, and I totally get on-board with it, but then it's just this fustercluck of configuration hell that never ends well.
This is due to the SLIME developers' insistence on making everyone run from CVS trunk. I wish I were joking, but they really seem to have no interest in creating stable release packages, so I have to go in and try to make it work without their cooperation.
Now I'm confused about how my other installs have it working.
Quite frustrating as I was using ELPA in my fork of the Aquamacs Emacs Starter Kit: https://github.com/evangineer/aquamacs-emacs-starter-kit
They seem to have changed the instructions again. The folks developing swank-clojure seem to keep changing their install strategy. Boo on them. Near as I can tell, installing from ELPA, installing swank-clojure through Leiningen, running swank-clojure through Leiningen, and calling 'M-x slime-connect' should still work.
"But elpa is not included in emacs 23 on Gentoo."
Holy crap, I just checked this and you're right. (The Gentoo package maintainers seem to have a problem with letting other package managers compete with their precious portage however, so I'm not surprised.) In this case, I'd suggest that the Gentoo devs should be the ones to warn you.
"Obviously my problems could be from a lack of experience with Emacs, but I hate that using a text editor is so hard."
I don't know what to tell you. The problems you listed aren't your fault and they're Emacs' I'd blame the package maintainers in the Gentoo episode but the Clojure stuff is because the Clojure developers still can't decide how they want their stuff to work. I can't blame them much for that. Experience would help, but I doubt that I have that much more than you. I've had similar episodes installing plugins for Eclipse.
ELPA/package.el is broken as far as I'm concerned. el-get is a breath of fresh air by comparison.
Once that has had a stable release, this will become a lot easier. In the mean time, the link to package.el for Emacs 23 is right at the top of marmalade-repo.org: http://bit.ly/pkg-el23
"In the mean time, the link to package.el for Emacs 23 is right at the top of marmalade-repo.org: http://bit.ly/pkg-el23
You know that, but nothing on the page indicates it. In fact, that page leads me to believe it is the same version as tromey.com hosts. It isn't made clear that marmalade is a fork rather than an additional repository.
Plus that package.el does not integrate (or include instructions on how to integrate) with Emacs the same way the one from tromey.com does when you run the code on http://tromey.com/elpa/install.html
By the way, take that as intended - I love emacs very much, but as with people so with software - the little things a beloved gets wrong can be unbelievably annoying... :)
On the bright side, look at what we're discussing here: the default regex syntax and pretty colors. Compare that to about five years ago, when we'd be instead discussing how to compile Emacs in a way that had fricking TrueType font support. Emacs has come a long way.
That said, the number of people who hate on Elisp is surprising to me. No, a hacked-up version of Maclisp is not the best Lisp in existence. But, seriously, you're competing against vimscript. Will even the most diehard Vim addict actually argue that vimscript is even comparable to Elisp?
In my experience namespaces only introduce notation to distinguish modules but so does a simple convention.
I just can't do that without any fancy tools as soon as namespaces introduce ambiguity that I can't resolve when I look at a narrow region of a file.
Although this looks like a regular prefix. How does the namespaced elisp propose to refer to entities from other namespaces?
If anyone is interested, this gets rid of the splash screen + chrome:-
(setq inhibit-splash-screen t)
(if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))
(if (fboundp 'tool-bar-mode) (tool-bar-mode -1))
(if (fboundp 'menu-bar-mode) (menu-bar-mode -1))
It surprises me that you could come away from org-mode thinking that the developers thought you should stick everything in one file. One of the main strengths of org-mode is the way it frees you to put stuff into separate files, wherever you want, and then use the agenda to consolidate them into a single view.
Having said that, yes, org-mode is freaking awesome.
Besides, to quote Wikipedia:
EMACS: initial release: 1976, 34–35 years ago
Vim: initial release 1991, 19–20 years ago
vi: was written by Bill Joy in 1976 (as extension of `ex' editor)
The debacle's been raging for way longer than 20 years.
On the other hand, if you want something more modern: http://man.cat-v.org/plan_9/1/acme
Really GNU emacs is related to ITS emacs in the same way that vim is to BSD vi: it's a cleaner and much more powerful reimagining of the original that shares some interface details but no implementation.
The editor I had been using for years. :)
As you work with emacs and customize it to work with your flow, your hands, and your keyboard, it starts to feel as comfortable as old shoes. Over time, the incremental efficiencies add up, and it becomes clear that a non-customizable editor just isn't as useful.
Contrary to parfe's experience, I've had good experience with Emacs packages, but then again, I don't use very intrusive addons, and keep my emacs pretty up-to-date.
I started using vim, and at first, it was kind of hard to get used to all the commands and remember everything... but after a while (1~2 weeks) it felt so fluid and easy – everything makes kind of sense, it's easy to install new plugins (pathogen ftw!), it's easy to hack those plugins, themes (most of the time) just works.
There are things Emacs can do which VIM will never do. And vice-versa. They are separate editors embracing separate philosophies.
Lastly, keep in mind that this is 40 year old software, and considering that it's done a great job keeping up with the times.
Please check back with http://jlongster.com/ in a few months, I have plans to start doing this kind of stuff there.
Much like unix, this is how emacs has managed to stay relevant despite the popularity of the IDE market. It's easy to configure and extend by defining abstractions and composing functions.
Most of the clutter is gone, but all of the nice IDE features (refactoring, immediate error detection, etc.) are still there. It's a nice way to work.
Most of my co-workers don't understand how I can work that way. I tell them it's all about learning (or modifying) keybindings.
Usability is, according to wikipedia "the ease of use and learnability of a human-made object" Ease of use and learnability isn't exactly emacs strong points. As an obvious example you need to learn emacs-lisp to unlock its potential.
Capable: absolutely. Easy to use: definitely not.
Emacs is easy to use and easy to learn, once you learn some of its basic quirks.
It's easy to use:
To start emacs, just type emacs. To open a file, type C-x f, then the path to the file (you can use tab-complete to enter the path). This automatically opens the file in a new buffer. You can open as many files as you like, and switch between the buffers with C-x b. To split the screen and see two buffers at once, you can use C-x 2 or C-x 3 depending on whether you want them aligned vertically or horizontally. Text entry and basic editing use most of the same conventions as the unix command line. C-a to go to the beginning of a line, C-e to go to the end, C-k to kill, C-y to yank. C-s forward-searches for a word. C-s again searches for the next instances.
Emacs is easy to learn:
To get a list of keybindings, such as the ones I mentioned above, type C-h b. This presents a list of hotkeys mapped to functions. The function names are descriptive. To get a more detailed description of any function in the list, simply put the cursor over the function name and hit enter. Press q to go back to your buffer.
Navigating the buffers can get complicated sometimes, and the function names can be archaic and definitely take some getting used to. There's also a lot of information available and it can be challenging to sort through it. But, all that information IS available and usually easy to get. That makes it easier to learn in the long run.
Also, to address your example, you don't need to know emacs-lisp to start appreciating its capability, and once you do start customizing basic configuration it's not too much more difficult than any other configuration language. From my .emacs, for example:
(global-set-key "\M-[" 'start-kbd-macro)
(global-set-key "\M-]" 'end-kbd-macro)
(global-set-key "\C-b" 'switch-to-buffer)
(setq inhibit-splash-screen t)
So usability has two separate definitions.
> Capable: absolutely. Easy to use: definitely not.
Actually, using Emacs is quite easy to use once you've learned it. Most operations can be done with much greater economy of motion than its main competitors. (vim excluded) It's the learnability aspect where it fares poorly, at least in the context of users who have been raised in a WIMP paradigm.
I find it easy to use--i have it on every platform and use it for almost all of my tasks.
But the third category I think you are leading up to here is the difficulty in learning. I admit that is not small.
What are the two different philosophies?
There was a Salon article about people still using XyWrite. As mentioned in the post, GRRM is one of the people still using WordStar. I know that Steven Brust is using Emacs.
: from the front matter of http://dreamcafe.com/firefly.html
"I use emacs, which might be thought of as a thermonuclear word processor."
- In the Beginning was the Command Line http://www.cryptonomicon.com/beginning.html
We don't know if it still applies.
The differences between vim and emacs are so fundamental that once someone goes down the emacs path it's not uncommon to never turn back.
This reminds me of various people I have worked with in the past who have wondered why I ever bothered with the complexity of searching and replacing with regular expressions, when you can just do a normal search and replace, watch for matches that match the more complicated thing you're actually looking for, then replace them by hand...
P.S. I'm not sure why I'm being downvoted. It's what I do. There's really no debate about whether grep is faster than VS search.
This is true, so why did I go with vim?
Well first, I'm primarily using Ruby not Java, so the magic available in IDEs is somewhat diminished. But more to the point, vim is really well optimized for the widest array of types of editing. It also has the advantage of critical mass open source immortality.
So when I hone my vim/emacs skills, it's an investment for the next 50 years, during which time I'll have no problem using my preferred editor on my preferred platform with whatever languages happen to be striking my fancy.
Which modern IDEs and what features? I have used eclipse for months before deciding I was better off with emacs with eclim-mode anyway to provide the only two features of eclipse I liked: the compiler and the ability to see the members of an object (occasionally).
It was like a root canal. If I was on fire.
Seriously--I'm not an Eclipse fan by any stretch, but Open Type alone saves me hours of frustration a week. Its code completion isn't nearly as good as Visual Studio's, but is a lot better than ctags. And its source generation (implement getters/setters, override inherited methods, even just basic context-aware renaming) is fantastic, too.
IME--and this is something of a generalization because I know fantastic programmers who use vim and emacs, and I use either where I have to--the folks who tout them are either using languages where IDEs are less effective (although this is still dubious--NetBeans has surprisingly good intellisense for PHP and Ruby, at least) or don't realize what the IDEs can do for them on a regular basis.
the linux kernel is 14 million lines of code and the size of its source tree is 500MB, you are working on a source tree that is ten times the size of linux? 140M lines of code? In any case it can't be all 140M LoC in a couple thousand java files so something should be clarified.
> I'm not an Eclipse fan by any stretch, but Open Type alone saves me hours of frustration a week.
ido-mode plus tags file worked well to replace Open Type for me. Before that I used a stupid five line bash script.
> don't realize what the IDEs can do for them on a regular basis.
Or maybe you don't realize what you can do with a good editor. Good, modern IDEs have some good features, better than what you can do with emacs/vim however:
a. they are not good editors (and insist on being one)
b. they are not good window managers (and insist on managing your windows)
c. their usefulness degrades quickly depending on the build system/language you use. If you need to quickly glance at the source of a library you just downloaded they are no help at all.
As for "not realizing what a good editor can do"--remind me how I get context-sensitive renaming or method extraction in emacs or vim? These features are critical when you're dealing with sufficiently gigantic amounts of code (especially the crufty kind), and if I really wanted I could get a full set of vim keybindings for Visual Studio (albeit the Eclipse ones aren't quite as accurate).
(And can we lay this holier-than-thou claim about "good editors" to rest already? The idea that editors that don't require six fingers on each hand or a modal personality are "not good editors" is patently silly and I have no interest in stooping to that level. You don't like them. That does not make them "not good," it means you don't like them. I grew out of that sort of thing when I was 15 or so, and am pretty much identically productive, in terms of just writing text, in emacs or a standard editor; I'm close in vim, but I only picked vim up a few months ago. When you stop identifying yourself based on your text editor of all things it stops being a material factor in your ability to get things done.)
You don't but I did tell you that IDE do some things better.
> method extraction
After the third time eclipse crashed and deleted code while I was trying to do this I'm not really sure how you can get method extraction working in eclipse either.
> And can we lay this holier-than-thou claim about "good editors" to rest already? The idea that editors that don't require six fingers on each hand or a modal personality are "not good editors" is patently silly
Agree, but it's also silly to think that any editor is a good editor and the ones in IDEs are not.
> I grew out of that sort of thing when I was 15 or so
Talk about holier-than-thou...
I've used JBuilder, Eclipse, NetBeans, and Visual Basic 6. None of them address a fraction of the things I actually need or like to do on a regular basis (edit files remotely, browse directories, use a shell, actually edit text efficiently). At work my Emacs session has files open in four different programming languages. There's nothing stopping people from writing refactoring tools for Emacs (take a look at Xrefactory), it's just that grep and dired and search-replace are universal tools that are good enough for all occasions. If you need something else it's easy enough to use macros or write elisp code to do it (ever try writing an Eclipse plugin? that works with multiple versions of Eclipse?).
You are assuming that your use case is typical. It's not. Eclipse may be better at your use case, but it fails miserably at the things typical Emacs and vim users need.
Because it pays the bills, and pays them quite well.
> it's just that grep and dired and search-replace are universal tools that are good enough for all occasions. omething else it's easy enough to use macros or write elisp code to do it
Extract a superclass or an interface with them. Automatically and contextually build your getters/setters in Java/properties in C#, respecting visibility and implementing proper logic in the case of constant or final fields.
I'm not going to hold my breath waiting for you to do either. Emacs is nice enough, but it's absolutely silly to claim that context-insensitive tools are "good enough for all occasions."
And I would be pretty easily called a user of both emacs and vim. Both are tools for specific use cases. They are not, as the strange culture of text-editor-worshippers would like to claim, inherently superior as editors simply because you know them.
Why don't you just go into investment banking or law or medicine instead? All those careers pay a lot more than doing copy-paste on millions of lines of crap Java code, which I highly doubt you like doing anyway.
I pay the bills by doing things I'm interested in.
--- Emacs user that uses a lot of "IDE esque" features
I used to use pymacs and ropemacs with python, but it broke in hard to determine ways, and then on my latest project it was horribly slow, so I stopped.
I still live in emacs
If I know what I'm looking at, go-to definition is perfectly fast even in huge projects. (My day-to-day project is quite large.)
I know the generalized search sucks/is slow, I've been meaning to fix it myself for some time.
Perhaps I was guilty of hyperbole, and "magic" is excessive. But stuff that comes out of the box in the above IDEs, and in its out-of-the-box state is slicker, easier to use and requiring less effort on one's own part than in emacs:
- Symbol browsing with search by substring, so you can leap to a symbol knowing only its name or part thereof;
- Project file browsing with search by substring, so you can open a file by name or part thereof;
- Pretty reliable jump-to-symbol with context sensitivity (so p.xyz, say, will take you to the right xyz), so you can find something given a valid mention of it in the source code;
- Popup code completion without my having to do anything funny or wait for the next build;
- Refactoring - OK, actually my use of refactoring tools could probably be done in emacs without making me want to die, but I know people who like 'lift method' and all that other junk, which would be basically a manual process in emacs.
I tried a couple of things to try and bring this stuff to emacs. M-x imenu, M-x ctags, CEDET and ido-mode are the ones that stick in my mind. None of them were up to much, though I wrote some helper functions to combine ide-mode and imenu, and I was somewhat pleased with the result. Then I upgraded emacs, and they stopped working. I took this as a sign, and didn't bother rewriting them. I don't use emacs for C/C++ any more.
[waits for somebody to post the 4000 character Regex that actually does this correctly]
My projects are usually not large enough that it matters. If they were, I suspect my typical response would be that I would simply install the appropriate mode for emacs and use that.
Use Emacs 23 to create a distraction-free writing environment using org-mode, darkroom-mode & markdown-mode.
In this case, I read it as "A good read if you want to know how/why/whether to use Emacs-23 as a distraction-free writing environment."
The post has other value, of course, and I wouldn't object if someone else were to write something like:
tl;dr: Emacs continues to evolve, e.g. It's now as good a tool for writers as Scrivener or dedicated distraction-free editors.
That would give me another reason to read the post if I wasn't persuaded by the first. Summaries (including the title, natch) provide some value that a simple upvote score does not capture.
I find "Too Long Don't Read" to be a dismissive attitude that I don't want here on HN, so I almost always vote down such comments (yes, including the ancestor here). But I appreciate executive summaries, and frequently vote them up to encourage their creation even if I didn't find the article itself compelling.
I realize that "TL;DR" is "just an abbreviation", but parsimony encourages me to conclude that it still connotes the words that it abbreviates and represents an attitude I do not like. Perhaps I'm reading too much into word choice, but in the end, word choice is really what makes the comments here worth reading.
Yes we do. They serve to save people time.
They serve to save people time.
For me, tldr is a favor folks more interested than me in some subject do, and I should do the same when I subject I really care turns up.
tldr is an act of love.
(defun switch-full-screen ()
(shell-command "wmctrl -r :ACTIVE: -btoggle,fullscreen"))
(global-set-key (kbd "<f12>") 'switch-full-screen)
(defun switch-full-screen ()
(x-send-client-message nil 0 nil "_NET_WM_STATE" 32
'(2 "_NET_WM_STATE_FULLSCREEN" 0)))
;;; Full-screen mode
(defun toggle-max-window ()
(set-frame-parameter nil 'fullscreen
(if (frame-parameter nil 'fullscreen)
(global-set-key (kbd "<C-M-return>") 'toggle-max-window)
sudo apt-get install emacs23-nox
I would accept no substitutes at this stage.
"2010-11-25 Thu: Maybe the times where Org mode could change hard-core vi users into honorable Emacs users are coming to an end? A Vim clone of Org mode is be written by Herbert Sitz, and judging by the videos it looks promising."
Haven't used it, though.
The previous poster complained that none of the Vim plugins that try to mimic or clone org-mode "seem complete". That is definitely the wrong way to look at things. Org-mode is a huge app that's been heavily developed for six or seven years now. In some ways org-mode is probably like Microsoft Word: probably 75% of its users access only about 25% of its features, although many of them access a different 25%.
Why try to develop an org-mode clone in Vim, then? Mostly as a personal project I started for fun. I tried switching to Emacs just so I could use org-mode. Even with Viper and Vimpulse add-ons Emacs felt too clunky to me. I had previously worked on a Vim outliner and I knew that part wouldn't be too hard to replicate in Vim. I decided not to stop there and I've gone on to a lot of other features, although it's a fledgling project. In particular, I need to get some decent documentation done. There are a ton of features in my clone that users have no idea are even there. I think so far most of them (like most org-mode users?) use it mostly for simple outlining.
The Vim clone uses a file format compatible with org-mode and actually calls out to an Emacs server to have org-mode do exports to LaTeX/PDF, HTML, etc. So pure document authoring (as opposed to PIM/task management stuff), is one task that the Vim clone probably can do a decent job of now. Adding footnote support is on the list (there's already a Vim footnote plugin that I plan to modify to work with the org-clone).
Secondly, rewriting Emacs would be a major undertaking and which modern language would it be? My choice would be Common Lisp, for other developers it would be Clojure, Haskell, Python, Ruby, etc. Whatever choice it would be, you'd lose developers who would rather see Emacs rewritten in one of the other languages. Even worse they might spawn forks in their own favourite languages.
Emacs has its warts, but it's your best choice if you want a serious editor.
Bashing an editor because its support for programming languages whose programmers have chosen other platforms, is not fair. Comparing Emacs to Eclipse or Netbeans when it comes to Java development is not fair, just like comparing Eclipse or Netbeans to Emacs when it comes to Common Lisp development is not fair either.
Using a general-purpose editor instead of a specialized tools means that everything you learn will serve you in every other editing task.
If you are not serious about editing text, then you will be
But, truth to be told, Emacs isn't even an editor: it is an Emacs Lisp interpreter which by default runs a program to edit text.
If you are not serious about editing text, then you will be served by many other editors.
* Being needlessly argumentative
* Borderline trolling. You _know_ how these arguments go.
* Fallaciously arguing that tools cannot be compared based on how well they get the job done
(IDEs vs 'editors') rather than their implementation
* Getting pissy about downvotes and posting multiple times instead of editing
I've been using Emacs for quite some time now, and before immersing myself into it, and even after, I've compared it to other major editors. Eventually, I realized that no other editor can stack against it, if you are really serious about getting the most out of your editor, and reaping the highest return of investment out of the time you spent learning it.
Maybe some people don't like the idea, but just like there are superior languages, as PG as neatly demonstrated, there are superior tools. Things you can accomplish with Emacs, you really can't with other Blub editors.
Oh, and when I talk about Emacs, I'm not talking about its editing model, which I agree, is somewhat cumbersome. Vim's editing model is way superior, and it's my editing model of choice, but Emacs' implementation is better. Vim enthusiasts are aware of the limits of their editor. For a story, read here: http://bradbeveridge.wordpress.com/2007/06/21/how-a-vim-user...