Once, I used Emacs. All I did with it was play in the land of elisp. I never got any real work done. Then, a passionate friend converted me to Vim. I only ever used it to do battle with my .vimrc. I never got any real work done. Now, I use Atom. Click a button, install a feature. No more distractions. I wish it were faster though; I can never get any real work done.
Why GNU Emacs?
121–130 of 317 posts
Re: Why GNU Emacs?
#122But then the lowest emacs layer of crap appears which can not be fixed. It includes issues like lack of multithreading, elisp being the least capable and at the same time by far slowest lisp dialect. Stuff like the lack of ability to move the cursor off screen. Inherent jumpiness while scrolling which can not be fixed and really strains my eyes. And don't even try to look at the C source, it is the worst historically grown ifdef hell you will ever experience.
And finally there is the community which lacks disposition to unify or work together. It is more like a community of loners where each of his own produces personal "modes" which are inconsistent to use and most of the time conflict which each other. The most important reason for this might be lisp itself. It is inherently hard to read other peoples lisp code. So everybody writes his own.
Re: Why GNU Emacs?
#123Earlier 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…
That's not true. Helm doesn't just insert .asterisk, which is why it supports out of order matching. If one searches for "file rename" Helm will find rename-file, while typing "filerename" in ido it will not find it. In ido one would have to do "filerename"
> Dictatorial maintainers that only allows options and features that they deem the "right way" to do it.
Helm is already criticized by many ido fans for having too many features, now it's also criticized by ido fans for not having more (despite it having way more than ido).
> Constant bugs
This is because helm is constantly changing and improving. ido is not changing, and most extensions to it are very hacky.
I prefer ido, but helm is a good tool that's perfectly usable that tons of people like and does a lot more than ido.
Re: Why GNU Emacs?
#124Re: Why GNU Emacs?
#125I haven't used it, nor Vim/Emacs. Just came across it during researching the two. Spacemacs appears to have excellent documentation though.
Re: Why GNU Emacs?
#126I use both Emacs and Vim and Emacs is slow. Often I would issue commands too fast for Helm to pick it up. It has rich environment and a lot going for it, but it is slow. Excuse to have "full featured" environment does not stand because Sublime Text is very much full featured and very fast. Anyhow, while Vim is still my goto editor, Emacs has a lot going for it and I fire it up when I work on Elixir because of superio…
Actually, advanced IDEs like Idea only feel fast because they do most of the stuff asynchronously. Afaict neither vim nor emacs are excessively good at it.
Re: Why GNU Emacs?
#127Earlier 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…
I find ido unusable for find-file, because of how it splits up directory from filename. So I use the builtin completion.
But I rarely open files using find-file anymore. ido-use-virtual-buffers is magical. For commonly opened files it let you use switch-to-buffer whether the file is opened or not.
(require 'recentf)
(recentf-mode t)
(setq recentf-max-saved-items 200)
(setq ido-use-virtual-buffers t) ; include recentf files
While, something like this works better with helm: (require 'yari)
(define-key ruby-mode-map [(meta h)] 'yari-helm)Re: Why GNU Emacs?
#128Earlier quoted context omitted.
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.
I would instantly disregard anyone who says this. Just run it in daemon mode and connect with emacsclient.
Re: Why GNU Emacs?
#129Earlier quoted context omitted.
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…
> An atrocious version of "fuzzy matching" (you have to separate terms with spaces, which are then turned into ".asterisk" (can't type a single asterisk in HN comments) and everything's concatenated into a regex to match) That's not true. Helm doesn't just insert .asterisk, which is why it supports out of order matching. If one searches for "file rename" Helm will find rename-file, while typing "filerename" in ido it…