
Big things to expect from Emacs 25 - signa11
http://endlessparentheses.com/big-things-to-expect-from-emacs-25.html
======
ed0
I personally use Vim but I like Emacs as well. They are both great. But they
are getting old and it shows. Compare them to the super nice text rendering of
ST3. I understand one cannot use ST3 from the terminal but that's fine. I can
continue to use vim in that case. But 99% of my time is spent in graphical
environment and I want a modern editor with nice font rendering and all. But
still, IMHO Vim and Emacs are better text editors than ST3. Why can't we have
best of both worlds? Implement core vim functionality as a backend service and
provide a modern frontend with nice rendering (by using Skia for example).
Same goes for Emacs. It's time to move on but keep the best of Vim and Emacs.

~~~
pmoriarty
I don't use Sublime Text, so I don't really understand what's so great about
its text rendering.

But.. how great can it be?

Both vim and emacs (and the terminals they run in) can use the fonts that your
operating system has available on them. So what's the problem? And how is that
inferior to what you get in Sublime Text 3?

Genuinely curious.

Second, while a nice look is great and all, I'm more interested in sheer
power, not eye candy. I guess I'm more of a function over form guy, and both
vim and emacs could look a lot worse than they do now and I'd still prefer
them over virtually any other text editor out there.

If there's something that other text editors can do that makes them more
_powerful_ than vim or emacs, I'd love to hear about it. That's happened in
the past. Sometimes there's been some feature that they don't have. And
usually, not much later, vim and emacs both clone that feature.. absorb and
expand, and move on.

~~~
melling
I find it much quicker to navigate buffers in Sublime. Code completion is
usually built-in, both html and variable names in whatever language I'm
developing (eg div<TAB>). Multiple cursors are great too.

I'm sure Emacs has modules for whatever or I could build it, but why waste the
time. I'd rather pay someone to provide a solution that saves me time. I still
keep emacs open for macros. Emacs is great for defining a keyboard macro and
repeating it's 1000 times.

~~~
barrkel
Emacs's keyboard macros are one of its weaker areas, IMO. C-g cancels
recording, but if you accidentally invoke the wrong command and end up in a
minibuffer prompt, C-g is the reflexive way to get out of it - terminating the
record. So you need to enter your command sequence with zero errors and no use
of C-g for it to be of any use. I find multiple cursors more usable in
practice, since you can see the results of various navigations simultaneously
(at least for those instances that are visible on screen).

I use emacs because it functions the same on Windows, Linux, OS X and Solaris,
all the platforms I use across work and home. I use it in the terminal rather
than the GUI, because then it functions the same whether over ssh or locally -
and no, TRAMP is not quite good enough. And finally, I use emacs because I've
had it with learning a different IDE every couple of years. At this point, I
want to invest my muscle memory and macro library in something with some
longevity. I want something where getting my settings and modules all
installed is no more effort than a git clone.

If I could pay someone for something that did all this for me, I would, but
the solution would look a lot like emacs: highly scriptable, with a consistent
terminal interface across all 4 platforms I use. Ideally it would use a much
stronger, faster version of Lisp, although its dynamic scope lookup is
actually convenient for layering new behaviour on top of existing code.

(On switching buffers, I use helm + projectile, which does incremental
filtering search over file names. For navigating projects, I find helm-git-
grep is often more useful than trying to remember a file name - this is an
incremental regex search across the whole project, using git grep. No other
IDE I use is quite as quick to switch buffers as my emacs config.)

~~~
melling
Multiple cursors only seem to work for simple things, which is good enough a
lot of the time. However, incremental search in a macro is very useful, for
example.

C-( do-searching-ESC-deleting-etc C-)

There's a new Emacs StackExchange:
[http://emacs.stackexchange.com](http://emacs.stackexchange.com)

Maybe it'll become enough of a database that it'll be much easier to figure
out how to add the "missing" features in Emacs. Currently 720 questions. Let's
see how often it's used.

~~~
barrkel
What you would do with an incremental search inside a macro, I'm much more
inclined to do with a regex search and replace. I generally only use search at
the end of my macros, to find the next "instance" that need to be run over.

------
cujo
I love emacs, but it seems like most of my programming for pay is trending
towards languages where there is a huge advantage to using a "modern" ide. I'm
talking mainly of java/jvm languages and objc here.

I don't expect emacs (the community really) to all of a sudden provide awesome
packages for that type of development, but it saddens me that I get more
locked in to these other ides that I don't view as generally superior.

~~~
nyir
At least for Java (and probably most other languages) (emacs-)eclim can
leverage Eclipse functionality (for Emacs, Vim, ...). So you'll get the same
completion, refactoring methods and so on.

[https://github.com/senny/emacs-eclim](https://github.com/senny/emacs-eclim),
[http://eclim.org/](http://eclim.org/)

~~~
craigching
How do I not know about this?!?!?! Thanks for sharing the link, do you have
any experience to share? Does it work well?

EDIT: If this works as advertised here [1] then I am all in!

[1] --
[http://www.skybert.net/emacs/java/](http://www.skybert.net/emacs/java/)

~~~
3rd3
It would actually be cool to have a ninite.com for Emacs configurations, where
one could choose from the best pre-configured crowd-sourced Emacs versions for
several use cases and platforms (e.g. web-design, Java-programming or
reproducible research). Sure, extending Emacs from scratch is fun, but many
people are probably reluctant having to spend many hours to achieve a good
configuration because they are not guaranteed to benefit from the result.

------
gnufx

      "Dynamically loading libraries is a big deal, and it's closer than ever."
    

Sigh. Dynamically loaded C extensions were working long ago
<[https://lists.gnu.org/archive/html/gnu-emacs-
sources/2002-04...](https://lists.gnu.org/archive/html/gnu-emacs-
sources/2002-04/msg00012.html>). It wasn't even a "big" thing -- most of the
change was in the build system.

rms wouldn't let them in because he (via Moglen?) thought they would undermine
the copyleft. That was worrying as a design criterion was to make them
(almost?) equivalent at compile time and after loading to things built into
the Emacs core normally, so that derived work status should be clear in a
court.

Perhaps eventually someone will re-do other things, like replacing the GC.

------
elwell
Concurrency in elisp would bring the benefits that Chrome brought with it's
thread-per-tab design. I feel like I'm in the 80's when I can't touch my other
windows while the repl gets loaded; and crossing my fingers that it doesn't
crash emacs.

~~~
hollerith
What "REPL" do you use that locks up Emacs while it loads?

Unless I am very much mistaken, cmuscheme.el (a.k.a. Inferior Scheme mode) and
all the other modes derived from Comint do not ever lock up Emacs.

~~~
rprospero
Not a repl, but I often have to stop coding for five minutes when I load up
gnus.

~~~
RBerenguel
I switched to nognus for better speed, and recently made the jump to mu4e with
offlineimap. And I'm already in love, so fast and non-blocking when refreshing
emails! Of course, I could have had offlineimap with gnus, but it was a
tedious setup (when I checked) and mu4e was quite a breeze. Local indexed
search is so good I'm don't care that much now about filing emails anymore.

------
zura
One question for long time Emacs users - do you notice any significant changes
compared to e.g. 10 or 20 years ago versions of Emacs? Same question applies
to vim users I believe...

Like, for instance, there are huge advancements from MSVC 97 to MSVC 2013...

~~~
unhammer
Some things that come to mind:

* --daemon with emacsclient was a big improvement in usability (ie. "instant startup" by keeping it running all the time)

* As others have said, there's been a surge in elisp packages lately, thanks to package.el and friends

* Changing color themes and fonts used to be a real hassle, but no more.

* Unicode (and bidi) Just Works now, no magic incantations in ~/.emacs needed any more

* org-mode! Ten years ago, org-mode was just started and not yet a part of Emacs. I think I first installed it as an addon around 2005, but at the time it was quite barebones compared to what it is now … (and of course installing it and keeping it up-to-date was a lot more work than doing the same for any third-party package now).

\-----

This question prompted me to look at
[https://en.wikipedia.org/wiki/GNU_Emacs#Release_history](https://en.wikipedia.org/wiki/GNU_Emacs#Release_history)
– other things I enjoy from that list include:

* good fullscreen support in X,

* lexical binding (not something you need most of the time, but indispensible when you do need it),

* docview (PROTIP: docview is better than most pdf viewers for copy-pasting text from pdf's),

* nXML (awesome XML editor),

* dbus bindings – can be handy,

* tramp! ohmydog tramp didn't even exist ten years ago!

And people were using c-mode to highlight CSS files … So yes, significant
changes noticed :-)

~~~
josteink
Awesome post. I've been using emacs for a while, but the great thing about
emacs is that it just keeps on giving.

DocView was new to me, and indeed, it does seem to do a good job at rendering
PDFs. Now I just need to learn how to work it.

------
ZenoArrow
Some great features listed for Emacs 25, sounds promising.

Personally I hope that Ergo Emacs can be merged into the main Emacs branch, as
an alternative keybinding option (not a mode). Some might say, why not just
use Ergo Emacs? The way I see it, it's too much work for a small group of
developers to create new key bindings for all Emacs packages. By moving it
into mainline (as an option), package developers know the option is available
by default and can choose whether they want to support it.

~~~
ZenoArrow
Marked down for that? Why?

~~~
mwfogleman
Because this is a wishlist, not a changelog.

~~~
ZenoArrow
I somewhat doubt it was anything to do with me mentioning a version number,
and all to do with having the audacity to suggest I'd like a comprehensive
keybinding alternative (it's the weakest element in Emacs, in my personal
opinion).

------
JasonFruit
What I want from Emacs 25 is to not have to use vi when I want to edit a large
file without line-breaks. Okay, maybe I need a more powerful machine — but I
shouldn't.

~~~
hollerith
I'm guessing that the reason you resort to vi is that scrolling through the
editing buffer is slow.

Have you tried visiting the file with M-x hexl-find-file?

~~~
JasonFruit
No, but why would I want to edit it as hex? Maybe I'm missing something
obvious?

~~~
hollerith
In Hexl mode, scrolling is vastly faster -- and it shows the file as
characters as well as as hex somewhat like the Unix program strings does.

M-: (hexl-find-file (concat invocation-directory invocation-name))

It's no big deal, but if it is not the speed of scrolling, then I do not
understand what it is about Emacs that discourages you from using it on large
files without line-breaks.

~~~
JasonFruit
That is an improvement, but I still wish I could open it like any other text
file. Still, thanks for a viable method.

