Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why GNU Emacs?

elephly.net

Post reply on HN
Print view View original

101–110 of 317 posts

Re: Why GNU Emacs?

#101

Post by lispm »

lottin wrote: post #30
flogic wrote: post #15

Apparently, I'm feeling ranty today... I've used Vi and Emacs as my primary editor. Now I've moved on to Sublime Text 3. Despite being powerful tools Vi and Emacs have probably harmed the state of Unix text editing. They've kept antiquated UIs from before keyboards were an text editing UIs were standardized. It's kinda sad that MS Dos, Windows and MacOS have all had a plethora of powerful editors with convenient stan…

What is true is that Vi and Emacs are deeply tied to the Unix tradition. Whether they are 'antiquated' or whether there are 'better' alternatives is a matter of opinion. Personally I haven't seen any other editor that comes close.

Maybe GNU Emacs, because it was originally written for Unix. Emacs itself came from ITS/Teco. Lisp-based Emacs came from the MIT Lisp Machine (using Lisp Machine Lisp as implementation language) and Multics Emacs (using Maclisp as implementation language).

Re: Why GNU Emacs?

#102

Post by gkya »

benaiah wrote: post #98
gkya wrote: post #89

Earlier quoted context omitted.

I'm on 24.5, and I don't know how it was in the past, but Emacs' default minibuffer reading functionality is good enough that Ido, Ivy, Helm or whatnot seem superfluous to me. I can type C-x C-f ~/Git/projectx/src/ding/~/.xombrero/runtime//etc/fstab RET it will do the correct thing, and it will give visual feedback. Also I can type M-x rev-bu RET and it will run revert-buffer, and if I type TAB instead of RET, it wil…

This works great if you have all the commands memorized. If you don't, fuzzy matching in ido is a fantastic way to find commands and variables that do what you want (Emacs has a great tendency to name user-facing commands very sensibly a lot of the time). Most of the time I can use C-h f and C-h v to figure out how to configure something without having to read the documentation. In addition, ido and flx-ido provide m…

I do not have all the commands memorised. But how emacs completes changes upon where you hit tab. if you type M-x re-bu TAB, it will show revert-buffer, re-builder, etc. If you hit TAB when cursor is at the beginning, like M-x buffer M-b TAB, it will show any command with buffer in it. Then you can C-x o to the Completions buffer and use any search tool on it, e.g. isearch-forward-regexp.

Re: Why GNU Emacs?

#103

Post by trothamel »

melling wrote: post #93
sklogic wrote: post #61

Earlier quoted context omitted.

Eight Megabytes And Constantly Swapping.

That fits in level 3 cache these days: http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,204...

Yes, but if you want to do something else with your computer, you'd have to swap it out to proper RAM.

Re: Why GNU Emacs?

#104

Post by gkya »

lispm wrote: post #100
gkya wrote: post #80

Earlier quoted context omitted.

Running emacs like "$ emacs " is like booting a computer, editing a single text file, and then "$ shutdown -h now".

Not really. GNU Emacs is no operating system. It has no network stack, no framebuffer interface, no file system implementation, etc. It provides interfaces to those. As such it does not initialize hardware and it starts no OS during startup. GNU Emacs starts a Lisp environment, loads a memory dump, runs various initialization code, etc.

Oh, thankfully someone told me that emacs does not have framebuffers and filesystems. It doesn't have wireless drivers too!

My grandparent comment was an analogy, for illustrating how it's not the optimal way to use emacs, as a command line program invoked to operate on one file and then closed and reopened.

Re: Why GNU Emacs?

#105

Post by curt15 »

pjmlp wrote: post #70
groovy2shoes wrote: post #67

Earlier quoted context omitted.

All of the BSDs.

Which of them is certified as such?

Who really cares about whether something is "certified" UNIX? Certification is not some seal of quality. "Unix" is commonly understood to denote "functional" unix systems as well for lack of a more convenient term.

Re: Why GNU Emacs?

#106

Post by ScottBurson »

lottin wrote: post #64
losvedir wrote: post #46

> Sometimes people who use computers ask me why I would use something as “bloated” as Emacs for text editing. Usually they remark that Emacs is a hold-over from a by-gone era, much too large compared to editors like “vi”, and that they are quite content using a variant of vi or some Notepad-like editor. This feels like a very out of date sentiment to me. I know a decade ago this was the perception, and well know the…

I guess bloated means compared to 'instant startup'. Vi starts always instantaneously, whereas Emacs can have a noticeable delay, even if it's only a fraction of a second. Hence the perception that is bloated. Of course compared to the others you mention is quite fast.

Emacs has a different usage model. Instead of starting a new Emacs for every file you want to edit, keep one running and edit all your files in it. If you're working on multiple projects, have one Emacs for each project and switch between them.

Re: Why GNU Emacs?

#107

Post by comice »

benaiah wrote: post #36
tptacek wrote: post #20

Earlier quoted context omitted.

There's a lot of antiquated stuff in Emacs, but despite the almost total lack of a modern UI toolkit for extensions, there are also interfaces in Emacs that are better than anything available elsewhere --- reasons to launch Emacs even if you don't need its expressive power for editing. Magit is a good example, Helm is another, org-mode another, FlyCheck another. If Emacs looked as good as Sublime, I'd be marginally h…

Helm may be the most flagrant example of a terrible package that remains inexplicably popular. I haven't uninstalled it yet, because there are a few packages that use helm that don't have ido equivalents yet, but I try to minimize my usage of it as much as possible. Issues include: - Significant performance issues - Constant bugs - updates often break the package completely, especially if you're using the melpa versi…

make sure you're using the stable melpa repository. The unstable (default) melpa repo is just builds direct from the master branches of the projects. melpa stable is builds from release tags.

since switching from unstable to stable melpa, I've not had anything break.

Re: Why GNU Emacs?

#108

Post by lispm »

gkya wrote: post #104
lispm wrote: post #100

Earlier quoted context omitted.

Not really. GNU Emacs is no operating system. It has no network stack, no framebuffer interface, no file system implementation, etc. It provides interfaces to those. As such it does not initialize hardware and it starts no OS during startup. GNU Emacs starts a Lisp environment, loads a memory dump, runs various initialization code, etc.

Oh, thankfully someone told me that emacs does not have framebuffers and filesystems. It doesn't have wireless drivers too! My grandparent comment was an analogy, for illustrating how it's not the optimal way to use emacs, as a command line program invoked to operate on one file and then closed and reopened.

The analogy wasn't that great. Booting a machine has nothing to do with typical uses of Emacs. There are many applications which are long running and are working on multiple documents - it's just another mode of working with an application.

One can use GNU Emacs just fine as an editor which starts and quits on a single file. 'emacs -q' starts in a few milliseconds on my Mac. I use single file edits with Emacs on the terminal all the time. Though I usually also have a long running instance of Emacs - but then it is used as a Common Lisp IDE, not just as an editor.

Then one can setup an Emacs editor server.

Or start the Editor and leave it running. This is no different from, say, a CAD program or any typical application on the Mac, where usually a single instance of an application keeps running, editing multiple documents.

Re: Why GNU Emacs?

#109

Post by gleb »

benaiah wrote: post #36
tptacek wrote: post #20

Earlier quoted context omitted.

There's a lot of antiquated stuff in Emacs, but despite the almost total lack of a modern UI toolkit for extensions, there are also interfaces in Emacs that are better than anything available elsewhere --- reasons to launch Emacs even if you don't need its expressive power for editing. Magit is a good example, Helm is another, org-mode another, FlyCheck another. If Emacs looked as good as Sublime, I'd be marginally h…

Helm may be the most flagrant example of a terrible package that remains inexplicably popular. I haven't uninstalled it yet, because there are a few packages that use helm that don't have ido equivalents yet, but I try to minimize my usage of it as much as possible. Issues include: - Significant performance issues - Constant bugs - updates often break the package completely, especially if you're using the melpa versi…

For M-x I like smex. Like fuzzy ido but without the bugs and purpose built for M-x - it just works. smex persistently remembers how often you use different commands, and uses this to sort the initial list of completions - very handy.

  (require 'smex)
  (smex-initialize)                       ; is this needed?
  (global-set-key [(meta x)] 'smex)
  (global-set-key [(shift meta x)] 'smex-major-mode-commands)

Re: Why GNU Emacs?

#110

Post by dopu »

merpnderp wrote: post #41
FenugreekAcerb wrote: post #18

Earlier quoted context omitted.

Yeah or you should install Atom and be spied by Google Analytics [1]. Let's take the creepiness of the web to the desktop. [1]: https://atom.io/faq

I've found VS Code a great alternative to Atom for that level of editor (fast and light). Don't tell me it does something equally as awful?

You should know better; it's made by Microsoft. However, like with Atom, you can disable telemetry:

https://code.visualstudio.com/Docs/supporting/FAQ#_how-to-di...

Post reply on HN