Live data from Hacker News

Let's just use Emacs

beastwithin.org

41–50 of 169 posts

Re: Let's just use Emacs

#41
post #24

Earlier quoted context omitted.

> do we really need "tl;dr" type comments here on Hacker News Yes we do. They serve to save people time.

They would save more time by simply not coming here. They can save lots and lots of time by not reading anything. Additional knowledge takes time to read and then adds time to your decision making process. Too many choices. These people should just write out a schedule and keep to it perfectly. No distractions, no extras, no discovery. No need for people to read things to understand them. Simply let someone else read…

I think your criticism would carry more weight if this news site wasn't a firehose linkdump format.

Re: Let's just use Emacs

#42
post #31
post #15

Earlier quoted context omitted.

> A lot of modern IDEs provide features that are pretty close to magic, compared to what emacs sports. 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).

I work on a 5GB source tree at work with a couple (or more? I haven't looked) thousand Java source files. After my last machine decided it would be a good time to crap out and I started over with a new OS X install, I tried working strictly with vim and emacs and our scripts (written by vim aficionados, it seems) to navigate around the codebase. It was like a root canal. If I was on fire. Seriously--I'm not an Eclips…

> I work on a 5GB source tree at work with a couple (or more? I haven't looked) thousand Java source files.

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.

Re: Let's just use Emacs

#44
post #42
post #31

Earlier quoted context omitted.

I work on a 5GB source tree at work with a couple (or more? I haven't looked) thousand Java source files. After my last machine decided it would be a good time to crap out and I started over with a new OS X install, I tried working strictly with vim and emacs and our scripts (written by vim aficionados, it seems) to navigate around the codebase. It was like a root canal. If I was on fire. Seriously--I'm not an Eclips…

> I work on a 5GB source tree at work with a couple (or more? I haven't looked) thousand Java source files. 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…

No, it's not all code, but glorified shell script call-outs from vim, etc. have to walk the entire thing far too often for my liking. (Unless something has recently changed, tags files have to be rebuilt in their entirety after a svn up - Eclipse just reindexes the changes.)

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

Re: Let's just use Emacs

#45

tl;dr Use Emacs 23 to create a distraction-free writing environment using org-mode, darkroom-mode & markdown-mode.

I'm not directing this at you personally, even though I am responding to your comment, but do we really need "tl;dr" type comments here on Hacker News?

IMO, "tl;dr" is a misnomer. Or at least, I don't value such a thing as an alternative to reading the post. There's no way that one line captures the whole article, it captures that one person's main takeaway. Rather than assuming that such a thing tells me everything I need to know, or thinking it can help me understand the nuänces of the discussion, I take it as one reader's executive summary which will help me decide whether to read the entire post.

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.

Re: Let's just use Emacs

#46
post #35

tl;dr Use Emacs 23 to create a distraction-free writing environment using org-mode, darkroom-mode & markdown-mode.

For linux environments, instead of darkroom-mode you can put this in your .emacs file to toggle fullscreen: ;;; Fullscreen (defun switch-full-screen () (interactive) (shell-command "wmctrl -r :ACTIVE: -btoggle,fullscreen")) (global-set-key (kbd " ") 'switch-full-screen)

or

  sudo apt-get install emacs23-nox
;-)

Re: Let's just use Emacs

#47
post #10
post #4

Earlier quoted context omitted.

He mentioned being affected by cognitive dissonance when referencing other editors - he was probably thinking of vim :)

A lot of modern IDEs provide features that are pretty close to magic, compared to what emacs sports. The emacs user response to this generally seems to be something like, "Code navigation can't be as good as M-x rgrep", and "How can refactoring ever be as good as C-M-%?" 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 replacin…

your argument about code navigation in emacs is inaccurate, though "M-x rgrep" is used heavily. at least there are gtags. and now there is auto-complete. For C/C++/Obj-C, clang+auto-complete stand there.

Re: Let's just use Emacs

#48
post #38
post #37

Earlier quoted context omitted.

Whenever installing software for Emacs, it's usually worth checking ELPA http://tromey.com/elpa/ (which comes installed on Emacs by default now,) to see if the package is there already. The ELPA provide both slime and clojure-mode and they work out of the box with swank-clojure. You'll still need to install Leiningen/Cake with swank-clojure separately, but there isn't much Emacs can do to help there.

Ah, but now you're not following the instructions provided by swank clojure which says to use marmalade (which is an elpa extension/replacement/clone/additional repository?) 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 com…

Emacs 23 does not come with ELPA installed. The next version of Emacs (24) is going to have a package manager included by default (it is based on ELPA) that will allow you to use Marmalade. If you are using Emacs 23 (which you probably are if you installed from your distro's package manager) then you should use ELPA. If you installed Emacs from a nightly build then you can use Marmalade.

Re: Let's just use Emacs

#49
post #38
post #37

Earlier quoted context omitted.

Whenever installing software for Emacs, it's usually worth checking ELPA http://tromey.com/elpa/ (which comes installed on Emacs by default now,) to see if the package is there already. The ELPA provide both slime and clojure-mode and they work out of the box with swank-clojure. You'll still need to install Leiningen/Cake with swank-clojure separately, but there isn't much Emacs can do to help there.

Ah, but now you're not following the instructions provided by swank clojure which says to use marmalade (which is an elpa extension/replacement/clone/additional repository?) 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 com…

"Ah, but now you're not following the instructions provided by swank clojure which says to use marmalade (which is an elpa extension/replacement/clone/additional repository?)"

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.

Re: Let's just use Emacs

#50
post #11
post #9

You think 20 years from now people will still be voting up articles about Emacs and Vim? just curious

Yes. They are bound to be discovered and re-discovered by every generation. They are the kind of tools that get the job done. There's also still a lot to be discovered about those editors themselves. 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 lo…

The EMACS package for TECO on ITS isn't an ancestor of modern GNU emacs, which began as a rewrite (based on Gosling's Unix emacs) in 1984. They are both "emacs" in the sense that they are modeless screen editors that share the same default keystrokes.

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.

Post reply on HN