Emacs: The Editor for the Next Forty Years [video](media.emacsconf.org)
media.emacsconf.org
Emacs: The Editor for the Next Forty Years [video]
https://media.emacsconf.org/2019/26.html
271 comments
> Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration.
Hear hear. I've been using Emacs since the late 70s when my int file was a compiled TECO library that other people also used.
Nowadays my init file is only a few dozen lines and when I log into some random machine (with no init file) most things simply work without surprising me.
It is highly customizable but it doesn't mean it must be customized.
Hear hear. I've been using Emacs since the late 70s when my int file was a compiled TECO library that other people also used.
Nowadays my init file is only a few dozen lines and when I log into some random machine (with no init file) most things simply work without surprising me.
It is highly customizable but it doesn't mean it must be customized.
And it will only get better once it understands LSP, better than it does now. It's a pale copy of VSCode's incredible LSP implementation: for a user, simply clicking the button to install the extension automagically configures a fully functional language environment; even for C++. Most of the time.
When last I tried to get decent C++ support working with Emacs, about a year ago, it was still a mess of compiling rtags/cquery, installing global, configuring per-project variants, sacrificing ungulats, hail baphomet.
When last I tried to get decent C++ support working with Emacs, about a year ago, it was still a mess of compiling rtags/cquery, installing global, configuring per-project variants, sacrificing ungulats, hail baphomet.
I've been using Emacs' lsp-mode (https://github.com/emacs-lsp/lsp-mode) for professional Python development for months now and it's been a great experience. It requires a little more work than I'd like to get it working with virtual environments (making sure the LSP server process is running in your venv, mainly), but I would argue that's a problem with the Python ecosystem, not lsp-mode itself.
And for statically typed languages (I've tried Rust and Go) the lsp-mode experience is flawless and works out of the box.
And for statically typed languages (I've tried Rust and Go) the lsp-mode experience is flawless and works out of the box.
I switched from emacs to Pycharm for python development, out of frustration with what most packaged tools was getting me, relative to what PyCharm did with no effort and little frustration at all. Too many half-maintained packages, put together, fighting incompatibilities.
However, LSP really may change that.
However, LSP really may change that.
LSP will definitely change that.
I've tried lsp for Go and found it a bit lacking at this point. For example, does lsp for Go in Emacs allow searching for the implementers of an interface? Or the interfaces that a type implements? Guru is great with things like that but the switch to modules broke it and it doesn't look like it's ever going to be updated.
> For example, does lsp for Go in Emacs allow searching for the implementers of an interface?
This one is supported - lsp-find-implementations
The other one I am not sure (I am not a go user). If it make sense it will be added to the server.
This one is supported - lsp-find-implementations
The other one I am not sure (I am not a go user). If it make sense it will be added to the server.
I had a similar experience with Emacs LSP earlier, but I revisited last week and things have significantly improved for C/C++. lsp-mode and ccls work great, even with cross-compiling. Just two small use-package additions to init.el and "it just works". I will also say I tried VSCode this week using the same compile_commands.json, and it is impressive.
now, one just need to install lsp/eglot and clangd. Done!
> Emacs does not require constant tweaking and wasting time on configuration.
Unless you are using org-mode, in which case updating org-mode may cause issues that require reading up on the breaking changes that were introduced between org-mode versions.
(This is meant as a heads up for newcomers using org-mode, since it's pretty popular at this point.)
Unless you are using org-mode, in which case updating org-mode may cause issues that require reading up on the breaking changes that were introduced between org-mode versions.
(This is meant as a heads up for newcomers using org-mode, since it's pretty popular at this point.)
Don't upgrade org mode if you don't have to. I only update org when I move to a new major emacs version and it comes with a new org bundled.
Upgrading org-mode should count as tweaking the config. Is there any part of org-mode that stopped working suddenly?
I've been using org-mode for about a decade now, and while I know there were changes made, I don't think there was even a single thing that just stopped working under me during the upgrade. I have a somewhat nontrivial amount of org setup, and there was never a case I'd have to fix anything in it after upgrade.
Export to HTML had some non-trivial changes in output.
Same here.
Emacs for me was always a poor replacement for my Borland and SlickEdit developer experience.
Actually during my UNIX phase, I rather used XEmacs, as it provided much more friendly tooling than Emacs.
Nowadays Emacs really fails short from what Java and .NET environments offer out of the box, specially in graphical tooling. Including mixed language development with C++.
It is also interesting that James Gosling nowadays prefers IDEs as any UNIX editor, as stated in several interviews.
Actually during my UNIX phase, I rather used XEmacs, as it provided much more friendly tooling than Emacs.
Nowadays Emacs really fails short from what Java and .NET environments offer out of the box, specially in graphical tooling. Including mixed language development with C++.
It is also interesting that James Gosling nowadays prefers IDEs as any UNIX editor, as stated in several interviews.
No it's not a poor replacement of Borland or SlickEdit used both and still went back to emacs.
Personally I use emacs over vscode due to following reasons,
1. it does not waste CPU cycle in rendering html, we have browsers for it.
2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles,
3. and last but not the least does one thing very well which is processing and rendering text and by virtue became the most customizable editor in the world (not necessary to use customization all the time as it provides a very good out of box experience as well).
Emacs inspired me to take on and understand functional language. Rust still feels an incremental improvement with memory safety over C, not a radical improvement or a paradigm shift.
I believe C is unfairly criticised. C has it’s own drawbacks but it is one of the language which really gave me power to tinker with hardware directly and it was refreshing. Rust may be a great language in design but didn’t generate that feeling of directly able to work with hardware as I had when I used basic peek and poke and later C. Simplicity of C is still far superior to Rust.
If org-mode, text processing and lisp stays with emacs it will continue to survive for next 40 years. Yes it needs constant evolution but I do not agree with the list like renedering html, working with slack will enable it to stay relevant with modern generation Z programmers.
Personally I use emacs over vscode due to following reasons,
1. it does not waste CPU cycle in rendering html, we have browsers for it.
2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles,
3. and last but not the least does one thing very well which is processing and rendering text and by virtue became the most customizable editor in the world (not necessary to use customization all the time as it provides a very good out of box experience as well).
Emacs inspired me to take on and understand functional language. Rust still feels an incremental improvement with memory safety over C, not a radical improvement or a paradigm shift.
I believe C is unfairly criticised. C has it’s own drawbacks but it is one of the language which really gave me power to tinker with hardware directly and it was refreshing. Rust may be a great language in design but didn’t generate that feeling of directly able to work with hardware as I had when I used basic peek and poke and later C. Simplicity of C is still far superior to Rust.
If org-mode, text processing and lisp stays with emacs it will continue to survive for next 40 years. Yes it needs constant evolution but I do not agree with the list like renedering html, working with slack will enable it to stay relevant with modern generation Z programmers.
It doesn't do any kind of graphical tooling.
IDEs also don't waste CPU cycles displaying HTML.
C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.
IDEs also don't waste CPU cycles displaying HTML.
C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.
In spite of all your arguments even today most important software powering modern computing are written in C, this speaks volume about its simplicity.
I am sure there will still be critical software powered by C 40 years later. Rust will take another decade or two to reach that level of simplicity and ease of use still not sure if it will cross the threshold to replace C, when an average developer needs to spend years just understanding basic syntax, use of language and its traits.
C is like English, Hindi or simplified Chinese not very pure with flaws and ambiguity, still became lingua Franca of the majority world due to simplicity.
I am sure there will still be critical software powered by C 40 years later. Rust will take another decade or two to reach that level of simplicity and ease of use still not sure if it will cross the threshold to replace C, when an average developer needs to spend years just understanding basic syntax, use of language and its traits.
C is like English, Hindi or simplified Chinese not very pure with flaws and ambiguity, still became lingua Franca of the majority world due to simplicity.
Yet Google, Apple, Microsoft are driving C's replacement for better alternatives, go figure.
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
https://security.googleblog.com/2019/08/adopting-arm-memory-...
https://android-developers.googleblog.com/2019/10/introducin...
https://developer.apple.com/swift/#fast
English only became the lingua Franca after the two big wars, and even then, good luck trying to make use of English in some world regions.
I recommend reading a bit about the history of lingua francas since the beginning of mankind.
"The Last Lingua Franca: English Until the Return of Babel"
https://www.amazon.com/Last-Lingua-Franca-English-Return/dp/...
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
https://security.googleblog.com/2019/08/adopting-arm-memory-...
https://android-developers.googleblog.com/2019/10/introducin...
https://developer.apple.com/swift/#fast
English only became the lingua Franca after the two big wars, and even then, good luck trying to make use of English in some world regions.
I recommend reading a bit about the history of lingua francas since the beginning of mankind.
"The Last Lingua Franca: English Until the Return of Babel"
https://www.amazon.com/Last-Lingua-Franca-English-Return/dp/...
> even today most important software powering modern computing are written in C, this speaks volume about its simplicity.
C code is simple in the sense that it closely matches the simple binary interfaces of the compiled code: plain symbols with simple calling conventions. Anything more complicated than this presents a seemingly insurmountable barrier to code reuse thats leads people to rewrite stuff in C.
The current situation is any code that's meant to be reused will be written in C so that every other language has access to the resulting functionality. The higher level languages either have much more complicated binary interfaces or are completely virtualized so code reuse is extremely difficult. C++ and Rust can export C interfaces but the benefits of those languages are not available to the users of the code because the interface has been reduced to C.
C code is simple in the sense that it closely matches the simple binary interfaces of the compiled code: plain symbols with simple calling conventions. Anything more complicated than this presents a seemingly insurmountable barrier to code reuse thats leads people to rewrite stuff in C.
The current situation is any code that's meant to be reused will be written in C so that every other language has access to the resulting functionality. The higher level languages either have much more complicated binary interfaces or are completely virtualized so code reuse is extremely difficult. C++ and Rust can export C interfaces but the benefits of those languages are not available to the users of the code because the interface has been reduced to C.
> this speaks volume about its simplicity.
No, it's just an indication of how many existing C code already exists that you have to conform to.
No, it's just an indication of how many existing C code already exists that you have to conform to.
Not having graphical tooling is a net positive in my experience. I’m a programmer, not a graphic designer.
Also the UI while visually clunky is neat and free of distractions.
The only IDE I use these days in IntelliJ for Java - because Java is one of those few languages that really benefits from integrated development. Great as it is, I do find myself having to relearn a few things every year or so, and often having to readjust to changes in look and feel, and for what?
Also the UI while visually clunky is neat and free of distractions.
The only IDE I use these days in IntelliJ for Java - because Java is one of those few languages that really benefits from integrated development. Great as it is, I do find myself having to relearn a few things every year or so, and often having to readjust to changes in look and feel, and for what?
I happen to be a programmer that also does graphics, GUIs and GPGPU debugging, graphical display of data structures.
Then there are those architecture design documents, DB tooling integration, bug ticket/source control/task management.
Then there are those architecture design documents, DB tooling integration, bug ticket/source control/task management.
Sounds like fairly specialised tools for that stuff.
I typically use a document editor, to you know, write documents ...
I typically use a document editor, to you know, write documents ...
Sorry I thought we were talking about development tools here.
Text editors
And how they lack features to match what IDEs are capable of.
Given that James Gosling created XEmacs, my go-to editor back in the day, I think you will find this interview interesting, although most certainly it won't change your opinion.
https://thenewstack.io/a-conversation-with-the-creators-behi...
Given that James Gosling created XEmacs, my go-to editor back in the day, I think you will find this interview interesting, although most certainly it won't change your opinion.
https://thenewstack.io/a-conversation-with-the-creators-behi...
Thanks for this, nothing jumps out at me vis-a-vis our exchange here but since you took the time to post it I will take the time to read it.
It's not so much that I have strongly held beliefs so much as a combination of experiences that have led me to the juncture where I see most codebases as being quite unstructured, and I appreciate the benefits of a more unstructured tool for dealing with them.
The baseband for nearly everything I work with is text, pretty much all of Latin form (ASCII, UTF-8, ISO-8859-x etc). When it comes to having to switch context between various languages and codebases, all of many and varying levels of hygene, I've come to a conclusion that I have "a particular tool" that is more suitable than most others.
Of course, when I have the luxury of working with "more structured" code, I will use the appropriate tools, but quite often the tools don't work as effectively once the code deviates from more idiomatic structure (Eclips is notably robust in this sense - but I find it can be quite clunky).
But if I have the time to learn the tools, and the tools can make the code more "fluid" to work with then I'm all for it.
In particular "Java" (which is I presume why you're linking Gosling) lends itself to this, and I did make this point above. The language itself is so robust, and the development culture seems to value best practices well enough that making the investment to learn these tools is worthwhile (EDIT - exactly in the sense that Gosling describes in TFA).
Another example in recent times has been Apple XCode when doing IOS development. The tool-chain is far too complex for me to get a "bottom up" appreciation of how it works, and the IDE in that case works just fine for me.
But these are exceptions in my 20 years or so of experience. More often than not I've a big mess to be dealing with that demands a powerful text editor.
As a younger guy I used to spend hours trying to set up my IDE and get projects to work with my tools, but I've got kids to feed now and have other stuff to do.
EDIT - read it now. Still unclear of what point you are making, unless you are erroneously assigning me to the "real men use vi" camp ... vi (or vim) has it's place, but I wouldn't really put it in the same category as Emacs, except for the fact that maybe Emacs has a terminal mode of operation. vi to me is more like windows notepad. It's always there when I need to quickly edit a configuration file.
It's not so much that I have strongly held beliefs so much as a combination of experiences that have led me to the juncture where I see most codebases as being quite unstructured, and I appreciate the benefits of a more unstructured tool for dealing with them.
The baseband for nearly everything I work with is text, pretty much all of Latin form (ASCII, UTF-8, ISO-8859-x etc). When it comes to having to switch context between various languages and codebases, all of many and varying levels of hygene, I've come to a conclusion that I have "a particular tool" that is more suitable than most others.
Of course, when I have the luxury of working with "more structured" code, I will use the appropriate tools, but quite often the tools don't work as effectively once the code deviates from more idiomatic structure (Eclips is notably robust in this sense - but I find it can be quite clunky).
But if I have the time to learn the tools, and the tools can make the code more "fluid" to work with then I'm all for it.
In particular "Java" (which is I presume why you're linking Gosling) lends itself to this, and I did make this point above. The language itself is so robust, and the development culture seems to value best practices well enough that making the investment to learn these tools is worthwhile (EDIT - exactly in the sense that Gosling describes in TFA).
Another example in recent times has been Apple XCode when doing IOS development. The tool-chain is far too complex for me to get a "bottom up" appreciation of how it works, and the IDE in that case works just fine for me.
But these are exceptions in my 20 years or so of experience. More often than not I've a big mess to be dealing with that demands a powerful text editor.
As a younger guy I used to spend hours trying to set up my IDE and get projects to work with my tools, but I've got kids to feed now and have other stuff to do.
EDIT - read it now. Still unclear of what point you are making, unless you are erroneously assigning me to the "real men use vi" camp ... vi (or vim) has it's place, but I wouldn't really put it in the same category as Emacs, except for the fact that maybe Emacs has a terminal mode of operation. vi to me is more like windows notepad. It's always there when I need to quickly edit a configuration file.
[deleted]
What you list here basically means you prefer terminal to GUI, not specific to emacs. Swap emacs for vim and most still apply. :)
For all its merits, I would never use VIM as a development environment, and I would never fire up emacs just for the sake of quickly editing a file ...
I use vim too besides emacs, still prefer to work with emacs due to org-mode and lisp. Also now I got more used to emacs key bindings compared to vim.
"Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration."
This is true, to an extent. I have not touched my current Emacs configuration in about 6 months now, but it took years of tweaking and probably hundreds of hours to get it to a state where Emacs was mostly the way I wanted it... though it'll never really be complete, as there are still a lot of things I'd like it to do that it doesn't yet but could, and there are always new things I could do that would be interesting or new, more efficient ways to do what I'm already doing.
So, overall, it has the potential to be a great time suck, and certainly was for me when I first started.
How much time it'll take for you really depends on your needs, and how much you're willing to live with the defaults that Emacs and its various modes and packages provide, and how much tweaking and customization you want to do. I needed and wanted quite a lot myself.
This is true, to an extent. I have not touched my current Emacs configuration in about 6 months now, but it took years of tweaking and probably hundreds of hours to get it to a state where Emacs was mostly the way I wanted it... though it'll never really be complete, as there are still a lot of things I'd like it to do that it doesn't yet but could, and there are always new things I could do that would be interesting or new, more efficient ways to do what I'm already doing.
So, overall, it has the potential to be a great time suck, and certainly was for me when I first started.
How much time it'll take for you really depends on your needs, and how much you're willing to live with the defaults that Emacs and its various modes and packages provide, and how much tweaking and customization you want to do. I needed and wanted quite a lot myself.
> So, overall, it has the potential to be a great time suck
The most important productivity step is to launch your editor.
Unfortunately if every time you launch your editor, you get distracted by the editor itself... Well, your init.el will be well maintained. :)
The most important productivity step is to launch your editor.
Unfortunately if every time you launch your editor, you get distracted by the editor itself... Well, your init.el will be well maintained. :)
I have lines in my .emacs that go back to when I used gosmacs.
I constantly add to my setup, mostly for email handling, though. I have a filtering system built in CL on top of MH-E on top of nmh.
I constantly add to my setup, mostly for email handling, though. I have a filtering system built in CL on top of MH-E on top of nmh.
I largely agree, though to be fair, I did spend quite a bit of time tweaking my config and learning elisp during the first two years. At the time I was a PhD student and could afford it, but today? not sure. It was quite an investment of time but since I spend my days mostly processing text (code and prose) it paid off spectacularly well. Side note: Emacs is massively underappreciated as a tool for writing prose. So many wonderful tools that make writing more effective and pleasant.
Curious, would you care to elaborate about the prose-writing tools? I only ever see things relating to coding in emacs.
Emacs turns disjoint environments, languages, and activities into a (mostly) streamlined system of workflows and idioms.
Explaining just how powerful that is to people who don't use Emacs is difficult. People need to sit with you for an hour or so and watch you work to truly appreciate just what that means.
Explaining just how powerful that is to people who don't use Emacs is difficult. People need to sit with you for an hour or so and watch you work to truly appreciate just what that means.
There's a certain class of programmers tool that requires constant tweaking, like a road bike used in the city - and typically the users suffer from OCD or stockholm syndrome, because they won't stop evangelizing.
I thought emacs was one of THOSE types of tools and the initial experience does nothing to disabuse that. On my 4th or 5th attempt to start using emacs I finally decided to get over the hump even if it took weeks of being slow.
I'm sure it's the same story for every emacs user - I literally never turned back. And I don't think I've touched my dotfiles in 2 years. But I get why it looks so esoteric from the outside.
I thought emacs was one of THOSE types of tools and the initial experience does nothing to disabuse that. On my 4th or 5th attempt to start using emacs I finally decided to get over the hump even if it took weeks of being slow.
I'm sure it's the same story for every emacs user - I literally never turned back. And I don't think I've touched my dotfiles in 2 years. But I get why it looks so esoteric from the outside.
The more I use Clojure at work, the more I tolerate the elisp side of things. I've written a couple little major modes (though not to any great standard of quality) and elisp is indeed pretty crap, but usually adequate. I think the ideal Emacs lisp successor would be a Clojure derivative, with the buffer represented as a persistent trie datastructure like other things are in Clojure. Maybe the buffers could be disjointed from the presentation a bit, and we could have strictly AST-driven major modes, rather than the (admittedly quite usable) hack that is paredit.
> Maybe the buffers could be disjointed from the presentation a bit, and we could have strictly AST-driven major modes
Yes, good point, agree that would be a very positive direction.
> elisp is indeed pretty crap
Ah, I've been enjoying it a lot recently :) But I don't have an excuse to write clojure and I certainly recognize that that's a much more sophisticated thing.
What are your biggest criticisms of elisp? Mine is basically that the naming of functions in the standard library is terrible.
Also: I'm still a bit confused about whether I should be using lexical binding (probably my fault for not thinking about it hard enough); the situation with threading is a little obscure; on the face of it threads in now exist in the elisp API, but are they not fully featured in some aspect?
Yes, good point, agree that would be a very positive direction.
> elisp is indeed pretty crap
Ah, I've been enjoying it a lot recently :) But I don't have an excuse to write clojure and I certainly recognize that that's a much more sophisticated thing.
What are your biggest criticisms of elisp? Mine is basically that the naming of functions in the standard library is terrible.
Also: I'm still a bit confused about whether I should be using lexical binding (probably my fault for not thinking about it hard enough); the situation with threading is a little obscure; on the face of it threads in now exist in the elisp API, but are they not fully featured in some aspect?
My main gripe with elisp is the default to dynamic binding, which is in most systems almost never what you want. In Emacs, the dynamic bindings are used for more productive reasons than in generalized programs, but they should still be a conscious choice.
When it comes to threads, the elisp datastructures are inadequate because they are mutable. It is possible to write functioning threaded programs with shared mutable state, but for the most part, it is going to introduce the kinds of bugs that people solve one of per week on a six figure salary.
When it comes to threads, the elisp datastructures are inadequate because they are mutable. It is possible to write functioning threaded programs with shared mutable state, but for the most part, it is going to introduce the kinds of bugs that people solve one of per week on a six figure salary.
Use dash/s/f/ . seq is fine too but dash is pretty much clojure port.
Dash is a very cool library! Though it only really does seq. The Clojure persistent vectors, hash maps, and hash sets are all very powerful. CHAMP is often an improvement on HAMT.
I think the text buffer as a persistent vector of extended grapheme clusters is an interesting thought.
I think the text buffer as a persistent vector of extended grapheme clusters is an interesting thought.
Emacs is almost infinitely tweakable, but it's also very stable, so your tweaks tend to have long-term value. This seems to go against the grain of most nontechnical software, like Firefox or Microsoft Windows, where there is no stable UI and new versions typically break customizations with no recourse.
Curious, can you identify what anything specific that changed the your thinking that it was THAT type of tool?
i believe lists of its obsessively chiseled, unique, world-class features would only get contrasted with its pardonable shortcomings as an editor.
so, that question is a no go because the thing has a transcendent dimension, it puts you at the heart of the storm, the center of computing where you commune with the gods of our field in perfect calm.
once you slay the dragons. best of luck!
so, that question is a no go because the thing has a transcendent dimension, it puts you at the heart of the storm, the center of computing where you commune with the gods of our field in perfect calm.
once you slay the dragons. best of luck!
tramp mode really helps span environments.
I used XEmacs during about 10 years, after a teacher in the classroom notice how poorly we were using it, and instead of spending an hour talking about programming in Pascal, it spent the hour teaching Emacs tips and tricks.
However, it is no match for modern IDEs tooling.
However, it is no match for modern IDEs tooling.
Emacs has really undergone a renaissance in the past decade - magit, LSP, ivy, spacemacs, doom emacs - there have been so many novel new packages and frameworks written by elisp hackers.
For such an old editor, the development scene feels incredibly alive.
For such an old editor, the development scene feels incredibly alive.
I'd agree that LSP has been a huge boon to the ecosystem. Spacemacs I feel has had the opposite effect. It hasn't had an "official" release since Jan 2018, and there are TONS of lame and fixed bugs that persist in the mainline. I actively recommend people NOT to use spacemacs because of how broken the release process is. It really feels like the maintainer(s) simply does not have the time to devote and it has vastly outgrown what I think is reasonable.
After quitting spacemacs, it was refreshing. I do not believe a "meta package" system is correct. Each individual maintainer should be able to update and release their plugins with an independent cadence. Imagine if VSCode extension releases were all gated by a single point of failure... Nobody would use it (and rightfully so).
After quitting spacemacs, it was refreshing. I do not believe a "meta package" system is correct. Each individual maintainer should be able to update and release their plugins with an independent cadence. Imagine if VSCode extension releases were all gated by a single point of failure... Nobody would use it (and rightfully so).
Spacemacs isn't a meta-package. Its just a config file and some of its own packages. All package it uses get updated through melpa at their own independent cadence.
I'd recommend just switching to the develop branch. Honestly they should just make it master.
I'd recommend just switching to the develop branch. Honestly they should just make it master.
There may be much going on with emacs, but so far it fails to move ahead. The project is just improving the old strenghts, but not fixing the old fails. And as time moves, they start to hurt more and more and more until they break.
What are some old fails that need fixed?
One thing I notice: too many things cause unresponsiveness. 8 cores in my laptop and I can't install a package in the background, and semantic parsing interrupts typing. There doesn't seem to be any concurrency at all, things I do every day like eval'ing forms to REPL cause stutters.
I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.
I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.
Personally I don't see performance as a major issue, though some things can be a bit annoying. But note that the concurrency problem has been recognized by the devs and a recent version of Emacs introduced some kind of threads. So I think we can expext progress in the next coming years.
https://github.com/Malabarba/paradox lets you install packages async, by the way.
That looks like an interactive ui--I can't declare use-package forms in my init.el, and have the initial install and any updates be async and concurrent.
The big ones, to me:
- No support for threads or any other concurrency model. Any I/O and the entire UI freezes, no matter how many cores you have idling.
- Even on a single thread, the runtime is generally several times slower than comparable modern scripting languages. The GC is not so great, either.
- The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".
- Elisp is the worst Lisp dialect I've ever used. No packages or namespaces. No bignums. Weak regexes, using a syntax completely incompatible with any other. It's improving but very slowly. It finally got support for lexical scoping a few years ago.
Except for the generous contribution of Unicode support, it feels like a system whose technical attributes were not even terribly impressive for the 1980's. Emacs is truly greater than the sum of its parts. It has to be, because each part is worst-of-breed.
- No support for threads or any other concurrency model. Any I/O and the entire UI freezes, no matter how many cores you have idling.
- Even on a single thread, the runtime is generally several times slower than comparable modern scripting languages. The GC is not so great, either.
- The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".
- Elisp is the worst Lisp dialect I've ever used. No packages or namespaces. No bignums. Weak regexes, using a syntax completely incompatible with any other. It's improving but very slowly. It finally got support for lexical scoping a few years ago.
Except for the generous contribution of Unicode support, it feels like a system whose technical attributes were not even terribly impressive for the 1980's. Emacs is truly greater than the sum of its parts. It has to be, because each part is worst-of-breed.
> The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".
It has pros and cons.
The pro is clearly that in Emacs everything is text, and can be processed as text, by using the same commands, keys and macros you use for everything else.
No other editor has this, and I cannot understate how handicapped I feel in those editors where some things are "off limites" and cannot be copied, because it's a designated "GUI" of some sort, instead just... text.
Taking that away from Emcas would IMO be a major loss.
It has pros and cons.
The pro is clearly that in Emacs everything is text, and can be processed as text, by using the same commands, keys and macros you use for everything else.
No other editor has this, and I cannot understate how handicapped I feel in those editors where some things are "off limites" and cannot be copied, because it's a designated "GUI" of some sort, instead just... text.
Taking that away from Emcas would IMO be a major loss.
Are you an emacs hacker and have the knowledge/power to fix the problems that prevent it from catching up to, say, a mediocre editor like Kdevelop?
https://news.ycombinator.com/item?id=17178246
https://news.ycombinator.com/item?id=17178246
No, I'm just a guy who's pretty content with emacs and wants to know what others perceive to be the major failings
The most core inards of Emacs are subject to bitrot. It doesn't play well with any Windowing system.
And as an editor it is quite slow/sluggish.
And as an editor it is quite slow/sluggish.
Hmm. I think it plays really well with macOS's windowing system. What am I missing?
I use emacs in my OSX Terminal windows without issue. When I've tried using it in Windows with vagrant ubuntu vm's, it does wonky things on screen redraws and clears but does not redraw - probably something fixable but I could not figure it out and just moved to Visual Studio Code for now on Windows. I speculate it's a Windows specific issue for running in a command prompt, for instance there's weird key combo for using cut and paste to/from the Windows/command prompt that is unnecessary when going back and forth from OSX/Terminal.
Also when using ssh to a web server over my slow connection I can run emacs but it's obviously redrawing the screen when I change the buffer, vi is much more responsive.
Also when using ssh to a web server over my slow connection I can run emacs but it's obviously redrawing the screen when I change the buffer, vi is much more responsive.
Hey I suggest you try installing it on WSL (Windows Subsystem for Linux). I tried it just last week to do some hacking different from my usual C#/Visual Studio development and was pleasantly surprised it mostly worked out of the box. To render more nicely I had to install X Window for Windows (can't remember the exact name of the library) but it was pretty much a very good experience. Only limitation I can think is you should not access linux files from Windows, but the other way around has no problem.
Also (may be different from your use case), using tramp-mode has mostly eliminated the need to run the emacs inside the server, I run it locally and fetches files using ssh.
Also (may be different from your use case), using tramp-mode has mostly eliminated the need to run the emacs inside the server, I run it locally and fetches files using ssh.
Just to clarify this: You tried to use emacs on Windows in Ubuntu VMs and are asking it to compare to native performance of tools like VS Code? Have you considered running a native Emacs build too and see if that performs better?
It's quite speedy, unlike IDEs, and it's very well-integrated with good windowing systems.
(from the slides)
>I learned Emacs in September, 1983
>It is now November, 2019
>...that’s over thirty six years!
>An amazingly long time.
Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it.
I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental improvement. I'm sorry but I think we are still in the Bronze Age of programming.
>I learned Emacs in September, 1983
>It is now November, 2019
>...that’s over thirty six years!
>An amazingly long time.
Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it.
I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental improvement. I'm sorry but I think we are still in the Bronze Age of programming.
No, productivity has increased massively, but not due to better editors or IDEs. Those have shown only marginal improvements, if any. (Is any modern environment more productive than a Lisp Machine or Smalltalk?)
But some of the main productivity drivers are distributed version control systems, dependency management libraries, and sites like GitHub for sharing code and libraries.
Being able to automatically generate a project from a template, and pull in any open source library written by anyone on the planet with a single line in a config file, is amazing.
Also, remote hosting and cloud provisioning to quickly deploy any code to be used by anyone in the world with a web browser. Arguably even app stores by eliminating the need to figure out distribution and payments on your own. (The stuff maybe not everyone considers "development", but is key to the overall productivity of any software project.)
But some of the main productivity drivers are distributed version control systems, dependency management libraries, and sites like GitHub for sharing code and libraries.
Being able to automatically generate a project from a template, and pull in any open source library written by anyone on the planet with a single line in a config file, is amazing.
Also, remote hosting and cloud provisioning to quickly deploy any code to be used by anyone in the world with a web browser. Arguably even app stores by eliminating the need to figure out distribution and payments on your own. (The stuff maybe not everyone considers "development", but is key to the overall productivity of any software project.)
Massive increase in personal computer power (cloud or physical).
Internet and resources like stack overflow.
Back in the days, I remember the isolation.
First from the domain, we could only run part of the application or use unnaturally tiny dataset meaning that the application behaviour in prod was an abstract concept. Hell, we could not even build the app at all on large application.
Second from knowledge. If you didn't know something, you needed to pick a book and read or find someone who knew. Nowadays, with a few hours on the net, you can build enough of a working knowledge of a tech to at least know if it is worth the investment.
Internet and resources like stack overflow.
Back in the days, I remember the isolation.
First from the domain, we could only run part of the application or use unnaturally tiny dataset meaning that the application behaviour in prod was an abstract concept. Hell, we could not even build the app at all on large application.
Second from knowledge. If you didn't know something, you needed to pick a book and read or find someone who knew. Nowadays, with a few hours on the net, you can build enough of a working knowledge of a tech to at least know if it is worth the investment.
The main reason I quit Emacs was the lack of context and semantically aware code completion and re-factoring tools. Such tools are invaluable productivity boosts for me. I have never gotten that to work in Emacs to a satisfactory degree.
The creation of the Language Server Protocol has changed this kind of thing considerably. Any editor now is able to use goto definition, goto reference, rename, etc for a variety of languages (assuming they have a plugin LSP client). I've been using one in NeoVim for a while for JavaScript and it works pretty good.
OTOH hlmost many modern IDEs can't even open two copies of the same file and display it side by side or record arbitrarily complex macros and play them back any number of times.
Completion and refactoring are much more important than these.
When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually.
When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool.
Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.
When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually.
When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool.
Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.
The sad part is that text based representations of programs are holding back programmer productivity by raising the bar for these refactoring tools unreasonably. If programs were represented and edited directly as syntax trees, 80 to 90 percent of the complexity of refactoring tools would go away.
On the other hand, when writing new code it is quite efficient to simply type, supported with proper completion.
It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree.
So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes.
An efficient text editor with completion + powerful refactoring. This is the winning combination.
It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree.
So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes.
An efficient text editor with completion + powerful refactoring. This is the winning combination.
You're jumping to conclusions when you're associating a syntax tree based program representation with the forced use of a mouse or cumbersome navigation for editing. Nothing could be further from the truth. A completely usable and fast keyboard based editing method for such a program representation is entirely possible. The only downside is that it's harder to create a minimal working version of such a tool compared to a text editor.
It may be possible, but I haven't seen such a tool. I have seen tools where you edited the syntax tree via a GUI and it was terrible for writing code. It may work better for tree modifications.
Text programs are pretty efficent when writing, editing code, because you can access a large number of elements quickly with the syntax.
E.g. writing let a = 3 can be much quicker than starting some command palette from the keyboard, choosing the "declare variable" action and then fill some dialog with the name and value of the variable.
I have doubts it can be made as efficient as typing, otherwise we would have seen such prototypes already. Have you?
Text programs are pretty efficent when writing, editing code, because you can access a large number of elements quickly with the syntax.
E.g. writing let a = 3 can be much quicker than starting some command palette from the keyboard, choosing the "declare variable" action and then fill some dialog with the name and value of the variable.
I have doubts it can be made as efficient as typing, otherwise we would have seen such prototypes already. Have you?
I am working on one.
Don't know about the second, but displaying two copies of the same file side by side is pretty common in my experience, e.g.:
PyCharm: Yes
VS Code: Yes
Eclipse: Yes
PyCharm: Yes
VS Code: Yes
Eclipse: Yes
Vs code can't open two windows properly though..
I'm curious what you mean, as I've not had any issues thus far. I'm only an occasional VS Code user however.
Only one os-level window per workspace is supported AFICT. It's possible to tile editors within this window, bit you can't detach an editor.
Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because it's a common interface used by all editors, there is a lot of interest in and work on the language backends.
I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549
The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
Interesting angle.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
I started using Emacs about a year ago and I love it!!
The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you!
I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination.
I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode.
The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.
The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you!
I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination.
I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode.
The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.
Thanks for that link. I confess I have my own prejudices against LSP. This view just strengthened it some.
Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
This is true for me too.
I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors.
Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.
I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors.
Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.
I've seen posts about how to set up vim as a frontend for a headless Eclipse server, but it always looked to me like the payoff wasn't worth the effort.
Coincidentally, I quit java for almost the same reason.
Really? What languages have better IDE support than Java? I guess C#?
It was more abandonding languages that are a slog to write without somewhat advanced IDE tooling. Committing thousands of lines per PR was common for the typical Java project, and much of had to be aided by IDE tooling to keep your sanity. I'm sure there's some amount of plugins I can throw at emacs or vim to get good-enough Java assistance or I can use languages with a higher productivity-to-lines of code ratio.
"the Brone Age of programming."
And that's being generous.
And that's being generous.
I'm new to Emacs, but enjoying it very much. Just got mu4e working with Gmail XOAUTH2 (for a G Suite account that the administrators have implemented their own "delightful login experience"). Would there be any interest in reading a writeup?
Definitely. I approached the set up mu4e + offlineimap over multiple accounts (including a GMail one) many times, and I've never been fully satisfied with it. I'd really want to get it to work flawlessly, so I'd love to be able to learn from your experience.
What doesn't not fully satisfied mean for you? I might just have lower standards...
By no means a mu4e expert here. If of help, some of the mu4e bits I've picked along the way:
http://xenodium.com/trying-out-mu4e-and-offlineimap
http://xenodium.com/adding-mu4e-maildirs-extension
http://xenodium.com/trying-out-mu4e-with-mbsync
http://xenodium.com/faster-junk-mail-deletion-with-mu4e
http://xenodium.com/emailing-pdfs-to-kindle-from-mu4e
http://xenodium.com/building-mumu4e-on-macos
http://xenodium.com/mu4e-as-macos-mail-composer
edited: formatting
http://xenodium.com/trying-out-mu4e-and-offlineimap
http://xenodium.com/adding-mu4e-maildirs-extension
http://xenodium.com/trying-out-mu4e-with-mbsync
http://xenodium.com/faster-junk-mail-deletion-with-mu4e
http://xenodium.com/emailing-pdfs-to-kindle-from-mu4e
http://xenodium.com/building-mumu4e-on-macos
http://xenodium.com/mu4e-as-macos-mail-composer
edited: formatting
Thank you, your blog posts are really informative and clear. I am guessing from the last two you have working SMTP, and that's the step I'm stuck on. Any advice?
I have additional config for SMTP. Added to http://xenodium.com/trying-out-mu4e-and-offlineimap
Here's the diff https://github.com/xenodium/xenodium.github.io/commit/73a27f...
Here's the diff https://github.com/xenodium/xenodium.github.io/commit/73a27f...
That appears to use password Auth and not oauth?
Correct Authinfo used for storing encrypted password in config (instead of plaintext). No OAuth in my setup (also not using Gmail).
ps. You may want to look at the GMail/SMTP parts of this post https://github.com/redguardtoo/mastering-emacs-in-one-year-g...
ps. You may want to look at the GMail/SMTP parts of this post https://github.com/redguardtoo/mastering-emacs-in-one-year-g...
Absolutely. I've been wanting to try that, but haven't put all the pieces together yet.
Hell yeah.
Yes please!
Absolutely yes
I hope you excuse me for a shameless plug, but it seems like a relevant enough thread to share my podcast about Emacs: https://emacscast.org/
While it might seem strange to discuss a text editor in the audio format, I've been getting positive feedback on this project as I try to talk more about underlying philosophy and mindset, not specific details or settings.
While it might seem strange to discuss a text editor in the audio format, I've been getting positive feedback on this project as I try to talk more about underlying philosophy and mindset, not specific details or settings.
My feedback for you is you need to give listeners a reason to keep listening to your podcast right away, you simply can not go on a meandering personal discussion about yourself for the first 10 minutes of a podcast and expect to retain my attention.
Thank you, I think this is fair.
I assume you've started listening to the latest episode: it was released after a long break and I guess in my mind it was geared towards existing listeners, with whom I've developed a relationship of sorts. Based on their feedback, it made sense to meander and focus on personal feelings and experience. I find it hard to balance between being insider-friendly and being attractive to new audiences. Perhaps, one of the earlier episodes could be better suited, but all of them contain personal stories.
Your comment was quite a sharp revelation tbh, it got me thinking. For now, I chose to define my project as a weird, personal journal rather than anything else, and try to further evolve the relationship with its existing listeners.
I assume you've started listening to the latest episode: it was released after a long break and I guess in my mind it was geared towards existing listeners, with whom I've developed a relationship of sorts. Based on their feedback, it made sense to meander and focus on personal feelings and experience. I find it hard to balance between being insider-friendly and being attractive to new audiences. Perhaps, one of the earlier episodes could be better suited, but all of them contain personal stories.
Your comment was quite a sharp revelation tbh, it got me thinking. For now, I chose to define my project as a weird, personal journal rather than anything else, and try to further evolve the relationship with its existing listeners.
Sheesh, give a person a chance. I'll give their podcast a listen based on the episode titles alone.
Well, that wouldn't be much different from the pervasive habit of many authors of YouTube videos to stick their own faces in the frame in one or the other ridiculous fashion. This is unsurprising, because it is self-advertisement that is the true goal of such podcasts and videos.
I routinely follow one podcast (Software Engineering Daily) and one You Tube channel (3blue1brown). Neither fit your characterisation. Perhaps you should consider being a little more selective in your consumption of YouTube :)
I'd be more inclined to believe that has more to do with ScreenFlow's (a popular screencasting program) defaults rather than people's inherent narcissism.
It's nice to see you plug your podcast! I've been listening for a while, keep up the good work!
Thank you! Let me know if you have ideas or suggestions for future episodes (email in profile).
So the slides say...
> Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system.
Is that really true? I've really enjoyed concurrency in D.
http://jordi.inversethought.com/blog/advent-of-d/#day18
How much better can it be? And yes, D's concurrency is also based around types.
> Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system.
Is that really true? I've really enjoyed concurrency in D.
http://jordi.inversethought.com/blog/advent-of-d/#day18
How much better can it be? And yes, D's concurrency is also based around types.
"So far, only Rust has a good story on concurrency thanks to its type system."
In the strongest sense of that phrase, Erlang and Haskell also have extremely strong concurrency stories, in that each in their own way, they forbid the most common mistakes. It's hard to compare which of these is "better" or "stronger" though since they all differ so much in how they approach the matter.
There are a number of other languages that can make claims to having a reasonable "concurrency story" if you combine the language with certain practices, which permits writing concurrent code in a reasonable fashion (i.e., not a disaster of locks), but that technically aren't necessarily better than C. D may fit in there. It may sound vacuous to say this, because you could always just port those practices back to an older language, and indeed, you can, but the community default matters because of the resulting library support. (Prime case study: Twisted and Python, with the way Twisted required essentially its own version of many significant bits of Python functionality to work in its environment; it could never completely take off because it was at such variance with what the community did by default.)
This class of languages is a more populated area, since it turns out while concurrent programming is never going to be completely trivial IMHO, the exponential complexity explosion of pure mutex-based systems that was such a disaster in the 1990s and early 2000s is more a problem of the primitives used to address the problem than the languages themselves. Mutexes are an invaluable tool, but not suitable as the "base" abstraction that programmers actually use.
In the strongest sense of that phrase, Erlang and Haskell also have extremely strong concurrency stories, in that each in their own way, they forbid the most common mistakes. It's hard to compare which of these is "better" or "stronger" though since they all differ so much in how they approach the matter.
There are a number of other languages that can make claims to having a reasonable "concurrency story" if you combine the language with certain practices, which permits writing concurrent code in a reasonable fashion (i.e., not a disaster of locks), but that technically aren't necessarily better than C. D may fit in there. It may sound vacuous to say this, because you could always just port those practices back to an older language, and indeed, you can, but the community default matters because of the resulting library support. (Prime case study: Twisted and Python, with the way Twisted required essentially its own version of many significant bits of Python functionality to work in its environment; it could never completely take off because it was at such variance with what the community did by default.)
This class of languages is a more populated area, since it turns out while concurrent programming is never going to be completely trivial IMHO, the exponential complexity explosion of pure mutex-based systems that was such a disaster in the 1990s and early 2000s is more a problem of the primitives used to address the problem than the languages themselves. Mutexes are an invaluable tool, but not suitable as the "base" abstraction that programmers actually use.
> How much better can it be?
Rust guarantees that a data-race is a compilation error.
D.. does not guarantee anything.. a data-race won't even give you a run-time error..
So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better.
FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g. Java doesn't guarantee that either).
Rust guarantees that a data-race is a compilation error.
D.. does not guarantee anything.. a data-race won't even give you a run-time error..
So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better.
FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g. Java doesn't guarantee that either).
There's a lot more to correct concurrency than data races, although they are a big factor. I think it's more fare to say that going from D to Rust is going from zero to some guarantees. Still technically infinitely better.
Based on that description (haven't used D), it seems to cover similar grounds. But Rust's move semantics means that for message passing in particular you can protect against "use after send" issues.
https://doc.rust-lang.org/book/ch16-02-message-passing.html
https://doc.rust-lang.org/book/ch16-02-message-passing.html
Doesn't Clojure have a pretty good concurrency story as well? (Which I find particularly relevant since it is a Lisp.)
Yes it does. Writing concurrent code in Clojure out of the box is a blast, and for the more advanced use cases there's core.async.
Frankly, not that much. Rust can primarily protect against memory usage race conditions, it can't catch most kinds of deadlocks or other concurrency issues.
Notice that Rust locks support dead-lock detection at run-time. You just need to enable the detection manually because it adds a run-time cost.
There is an amazing project of converting Emacs into the more modern language - Rust (the C parts of it). It is called REmacs[1]. It is sad that the port of Emacs to Guile[2] didn't work out. And for the people who want to convert their C code to Rust, I quite recommend trying c2rust[3] transpiler and refactoring tool.
[1] https://github.com/remacs/remacs
[2] https://www.emacswiki.org/emacs/GuileEmacs
[3] https://github.com/immunant/c2rust/
[1] https://github.com/remacs/remacs
[2] https://www.emacswiki.org/emacs/GuileEmacs
[3] https://github.com/immunant/c2rust/
I'll be honest, I feel like such a project is a waste of time, in a similar vein to many such "port to Rust" projects. Even the project page itself gives vague and rather suspect motivation for why such a project should exist.
I could appreciate it if there were legitimate architectural concerns that need to be addressed (see, for example, neovim).
I could appreciate it if there were legitimate architectural concerns that need to be addressed (see, for example, neovim).
reading the GuileEmacs thing it sounds like the project was a success? Is there pushback against using this upstream?
Guile is supposed to be the GNU extension language, which meant there was a political incentive for guile Emacs, but it was never asked for by the Emacs people. Considering the amount of bikeshedding going on for faaaar less intrusive changes to Emacs, I have doubted guile Emacs success for a long time.
Guile now runs elisp, although there is a lot of low hanging fruit left when it comes to optimization. Guile is shaping up to become a very neat little VM, with proper threading, JIT compilation, and delimited continuations.
I think the idea of elisp running outside of Emacs, with access to all of the gory glory of Emacs libraries sounds fantastic. Imagine org-mode and a (emacs PKG org-mode) library you can use outside of Emacs with a sub 0.1s startup :)
Guile now runs elisp, although there is a lot of low hanging fruit left when it comes to optimization. Guile is shaping up to become a very neat little VM, with proper threading, JIT compilation, and delimited continuations.
I think the idea of elisp running outside of Emacs, with access to all of the gory glory of Emacs libraries sounds fantastic. Imagine org-mode and a (emacs PKG org-mode) library you can use outside of Emacs with a sub 0.1s startup :)
It was working, but not good enough, indeed.
I've been writing Clojure lately but I'm a greybeard (literally) Vi/Vim user. vim-fireplace is nice but I can't help wonder if I'm losing something by not using Emacs. At the same time, Clojure is so wonderfully different from the other languages I know that I don't feel like I have the cycles to learn a new editor at the same time I'm learning a new language. Then again, maybe that's the best time to learn Emacs?
I've never used Fireplace, so I can't speak to the comparison. But CIDER (the Emacs Clojure IDE) is an utter joy to use - I can't recommend it enough. If you do try it out, I would be interested to hear how it compares to Fireplace.
I learned Clojure and Emacs at the same time, and I have to say that it tested my patience. You need to reset your mind to expect to move slowly for a week or two. With that said, I'm really happy with my current setup, except for days when emacs pinky comes. You can mitigate that with Key Chords [0] and mapping Caps Lock to Control. Emacs' CIDER is the de-facto Clojure(Script) dev environment.
[0] - https://www.emacswiki.org/emacs/KeyChord
[0] - https://www.emacswiki.org/emacs/KeyChord
Also a Vim (NeoVim) user. I've been curious about Clojure and I've learned that there's a plugin called Conjure that's suppose to be pretty good. I've yet to try it myself but, might be something to look into. https://github.com/Olical/conjure
If Emacs is to be "the" editor for the next forty years, I really hope it can better combat random hangs. As someone who uses Emacs as a daily driver and loves it to death for its extensibility paradigm it's painful when it maxes out the CPU, I have to restart and have no idea what it could have been.
But then again scripting languages don't really have these interruption features by design. I'm developing something with a scripting layer and occasionally come across accidental infinite loops myself. I wonder what e.g. Factorio or Minecraft do if a mod enters an infinite loop. If the answer is "program more carefully" and "don't use badly coded mods" then I guess it can't be helped.
Proper concurrency in elisp can't come fast enough. At least then we could have a task manager to kill hung threads with.
But then again scripting languages don't really have these interruption features by design. I'm developing something with a scripting layer and occasionally come across accidental infinite loops myself. I wonder what e.g. Factorio or Minecraft do if a mod enters an infinite loop. If the answer is "program more carefully" and "don't use badly coded mods" then I guess it can't be helped.
Proper concurrency in elisp can't come fast enough. At least then we could have a task manager to kill hung threads with.
(setq-default garbage-collection-messages t) ??
pkill -SIGUSR2 emacs
I've noticed that (almost?) any talk about any editor in the last few years: emacs, vim, sublime, atom etc always brings up how good VS Code is.
It's a huge endorsement of VS code.
It's a huge endorsement of VS code.
I'm a diehard Emacs (+evil) user, and I tried VS Code for a few months. It really is quite good. Here are the few detractors that brought me back to Emacs as my primary editor.
Lousy macro support from the Vim emulator. Evil is still leaps-and-bounds above anything else (possibly Vim itself).
Flexibility of split windows. I like to view multiple files side-by-side. From my experience, Emacs and Vim have the best support for split panes; whereas VS Code and JetBrains editors have the worst.
VS Code has nothing like Magit. In my time with VS Code, I would keep Emacs open in another space for git.
Lousy macro support from the Vim emulator. Evil is still leaps-and-bounds above anything else (possibly Vim itself).
Flexibility of split windows. I like to view multiple files side-by-side. From my experience, Emacs and Vim have the best support for split panes; whereas VS Code and JetBrains editors have the worst.
VS Code has nothing like Magit. In my time with VS Code, I would keep Emacs open in another space for git.
VS Code also doesn't support Macros in the same way Emacs and vi do.
In fact its not even remotely close.
In fact its not even remotely close.
I think users of VI or emacs has different ways of defining "good" here. Personally, I would never use VS Code, or any other chromium editor.
Is this due to some notion of it being slow? VSCode is fast, native-fast. With a fantastic plugin ecosystem
I've been a full-time Vim user for the past decade (now NeoVim) but I've seriously considered switching, VSCode with vim mode turned on is truly fantastic, it's just not portable enough for my needs.
I've been a full-time Vim user for the past decade (now NeoVim) but I've seriously considered switching, VSCode with vim mode turned on is truly fantastic, it's just not portable enough for my needs.
> VSCode is fast, native-fast.
Not when starting up…
Not when starting up…
I'd consider startup time the least important metric for measuring speed of a text editor - as long as it's not ridiculous.
Important speed metrics for me are: Switching between buffers
Scrolling up/down a page (vim used to be terrible for me before i switched terminals to Kitty)
Substitutions
Search
Important speed metrics for me are: Switching between buffers
Scrolling up/down a page (vim used to be terrible for me before i switched terminals to Kitty)
Substitutions
Search
I keep trying to use VSCode because there are aspects of it that work better than vim. I always end up back with vim. I think that is because an editor that sits on top of a CLI is much more useful than an editor with a CLI on top of it, at least for my work.
Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs).
In the years since first picking up Emacs, I have probably spent 100 hours or more configuring it, reconfiguring it, refactoring my configuration, and other things that wasted my time I'm not going to make the world a better place by configuring my editor. I'm going to do it by shipping code.
I'm a recovering terminal junkie. I had a problem. I was bored with my work so I wanted to challenge myself. Maybe I even enjoyed procrastinating a little.
In the years since first picking up Emacs, I have probably spent 100 hours or more configuring it, reconfiguring it, refactoring my configuration, and other things that wasted my time I'm not going to make the world a better place by configuring my editor. I'm going to do it by shipping code.
I'm a recovering terminal junkie. I had a problem. I was bored with my work so I wanted to challenge myself. Maybe I even enjoyed procrastinating a little.
So if you’re not making the world a better place you’re wasting your time?
Play is supremely important in almost any activity. Not only is there incredible work insight to be found in activity without goals, but play is fun and good for you.
Play is supremely important in almost any activity. Not only is there incredible work insight to be found in activity without goals, but play is fun and good for you.
On the importance of "play"—
From one of the books I'm currently reading (Blueprint, The evolutionary Origins of a Good Society, by Nicholas Christakis — itself a great read), I learnt of an interesting book reference: Homo Ludens: A Study of the Play-Element in Culture (1938).
The abstract sounds promising:
"[...] With cross-cultural examples from the humanities, business, and politics, Huizinga examines play in all its diverse guises—as it relates to language, law, war, knowledge, poetry, myth, philosophy, art, and much more. As he writes, “Civilization is, in its earliest phases, played. It does not come from play like a baby detaching itself from the womb: it arises in and as play, and never leaves it.” [...] Starting with Plato, Huizinga traces the contribution of “man the player” through the Middle Ages, the Renaissance, and early modern world. [...]"
[*] https://www.amazon.com/Homo-Ludens-Study-Play-Element-Cultur...
From one of the books I'm currently reading (Blueprint, The evolutionary Origins of a Good Society, by Nicholas Christakis — itself a great read), I learnt of an interesting book reference: Homo Ludens: A Study of the Play-Element in Culture (1938).
The abstract sounds promising:
"[...] With cross-cultural examples from the humanities, business, and politics, Huizinga examines play in all its diverse guises—as it relates to language, law, war, knowledge, poetry, myth, philosophy, art, and much more. As he writes, “Civilization is, in its earliest phases, played. It does not come from play like a baby detaching itself from the womb: it arises in and as play, and never leaves it.” [...] Starting with Plato, Huizinga traces the contribution of “man the player” through the Middle Ages, the Renaissance, and early modern world. [...]"
[*] https://www.amazon.com/Homo-Ludens-Study-Play-Element-Cultur...
Is tweaking your emacs config play? Or is it work?
When I was younger, it felt more like play. In my late 20's it became work.
When I was younger, it felt more like play. In my late 20's it became work.
This is a very important idea that doesn't get enough attention.
Spending time on your tools instead of your work is not a sign that you need to change your tools - it's a sign that your work sucks.
Yeah, I don't understand this theory that if your tools are at all configurable or learnable you'll be compelled to waste time yak-shaving them. I think you're right that the problem is with the stuff you're NOT doing. I use emacs every day, but there's a ton of stuff I don't use emacs for because the investment to become proficient in the emacs solution won't pay off in my circumstances. There's a middle way between writing code in nano and getting lost trying to program emacs to do your job for you.
As with everything (programming languages, build tools, optimization, etc.) there are people who go much further into the rabbit hole of text editors than you could practically justify in your own work, but 1) they might be doing it for some intrinsic satisfaction rather than out of delusion, and 2) thank goodness for people like that, because they build and improve a lot of the software we benefit from.
As with everything (programming languages, build tools, optimization, etc.) there are people who go much further into the rabbit hole of text editors than you could practically justify in your own work, but 1) they might be doing it for some intrinsic satisfaction rather than out of delusion, and 2) thank goodness for people like that, because they build and improve a lot of the software we benefit from.
Or that your tools (as currently configured) are insufficient to the task of doing your work.
If you wonder why a woodworker hasn't finished the chair, a completely valid answer is "all the edged tools you gave me were dull".
If you wonder why a woodworker hasn't finished the chair, a completely valid answer is "all the edged tools you gave me were dull".
I've been using Emacs for 40 years.
My .emacs file is 59 lines long.
Most of the customizations turn off features have been added (menu bars and so forth), or that disable "helpful brain damage" that simply got in the way. I've spent 2-3 hours over the last decade tweaking things.
My .emacs file is 59 lines long.
Most of the customizations turn off features have been added (menu bars and so forth), or that disable "helpful brain damage" that simply got in the way. I've spent 2-3 hours over the last decade tweaking things.
Same. It's a bit like Dvorak. Yes, in theory you could make your life 10% better by carefully customizing, but there's also great value in just sticking with the default for the most part. You can sit down anywhere and everything just works.
At the risk of adding to your 2-3 hours, you might want to check out Key Chord [0] (if you don't use it already) for some low-hanging fruit.
[0] - https://www.emacswiki.org/emacs/KeyChord
[0] - https://www.emacswiki.org/emacs/KeyChord
> I'm not going to make the world a better place by configuring my editor
I think this covers work of most programmers. Doesn't matter if time is spent writing editor config or production code...
I think this covers work of most programmers. Doesn't matter if time is spent writing editor config or production code...
My .emacs on this machine is almost literally this:
(custom-set-variables
'(indent-tabs-mode nil)
'(inhibit-startup-screen t)
'(menu-bar-mode nil)
'(show-paren-mode t)
'(tool-bar-mode nil))
But I mean, that's not Emacs fault?
It very well could be. Attempting to either adapt yourself to emacs, or emacs to you, can take a long time, and may also fail.
Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.
Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.
> The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.
This can happen just as easily by installing a buggy plugin in any other IDE. I love IntelliJ, but have definitely lost time trying to figure out how to make something work or configure it to my liking.
This can happen just as easily by installing a buggy plugin in any other IDE. I love IntelliJ, but have definitely lost time trying to figure out how to make something work or configure it to my liking.
It can. The thing I like about some of the other IDEs though is that it doesn't tear down the entire process; the plugins are sandboxed. Is this possible in Emacs? I'd be shocked if the answer is no. But most major modes I've personally interacted with are not.
> I'm a recovering terminal junkie. I had a problem.
Maybe you went too far, but I think there's also a widespread problem with people not going far enough. I know smart people who have been working in the industry for over a decade who don't bother learning basic text manipulation tools because they look down on the shell and assume they're going to have to switch text editors every few years anyway. Sublime Text, BBEdit, Atom, VSCode -- you only get two or three years with each one, so there's no point learning more than delete, copy, paste, search/replace in file, jump to file, jump to symbol, and if you're really fancy, search/replace in multiple files.
But you can't get past how much of everything we work on is text, no matter how lofty the abstractions it encodes. Munging text takes an inordinate amount of our time. I have seen senior engineers spend an hour writing and debugging scripts to make changes in a big file that they could have made in minutes by using regex-replace or recording a keyboard macro in their editor. Same with basic sed and awk usage. If they can do it by hand in under ten minutes they'll do it that way; otherwise they'll file a ticket and write a script.
I have seen senior engineers painstaking picking through multi-kB json blobs adding line breaks in strategic places to make them readable. ("I used to use this one web site that reformatted JSON for you, but then it shut down, and I always felt nervous about posting internal data to random web sites anyway.") That's an extreme case, but I've seen it more than once, and it's tragic.
I agree it's hard to know ahead of time where to invest your time. One of the best engineers I ever worked with once told me, "The best thing that ever happened to me was that in undergrad I was working for a professor who had all these crazy awk scripts. I spent a whole semester using awk basically every day, even though I hated it." That impressed me —- this was a guy of very impressive theoretical background and incredible ability to design complex systems that worked in simple, reliable ways, and he was talking to me about awk? But it didn't impress me enough, because it was another five years before it sunk in that over the course of my career I had scrolled past an awful lot of simple one or two line awk solutions (on, e.g., Stack Overflow) to get to the solutions I could comprehend -- which were always much more complicated.
When considering how to spend your time, I don't think you should worry about the pits you might fall into. I think you should look at the positive possibilities, the positive possibilities, and try to achieve them. It's possible to be very productive in the terminal and in your editor or IDE without going down too many rabbit holes.
Maybe you went too far, but I think there's also a widespread problem with people not going far enough. I know smart people who have been working in the industry for over a decade who don't bother learning basic text manipulation tools because they look down on the shell and assume they're going to have to switch text editors every few years anyway. Sublime Text, BBEdit, Atom, VSCode -- you only get two or three years with each one, so there's no point learning more than delete, copy, paste, search/replace in file, jump to file, jump to symbol, and if you're really fancy, search/replace in multiple files.
But you can't get past how much of everything we work on is text, no matter how lofty the abstractions it encodes. Munging text takes an inordinate amount of our time. I have seen senior engineers spend an hour writing and debugging scripts to make changes in a big file that they could have made in minutes by using regex-replace or recording a keyboard macro in their editor. Same with basic sed and awk usage. If they can do it by hand in under ten minutes they'll do it that way; otherwise they'll file a ticket and write a script.
I have seen senior engineers painstaking picking through multi-kB json blobs adding line breaks in strategic places to make them readable. ("I used to use this one web site that reformatted JSON for you, but then it shut down, and I always felt nervous about posting internal data to random web sites anyway.") That's an extreme case, but I've seen it more than once, and it's tragic.
I agree it's hard to know ahead of time where to invest your time. One of the best engineers I ever worked with once told me, "The best thing that ever happened to me was that in undergrad I was working for a professor who had all these crazy awk scripts. I spent a whole semester using awk basically every day, even though I hated it." That impressed me —- this was a guy of very impressive theoretical background and incredible ability to design complex systems that worked in simple, reliable ways, and he was talking to me about awk? But it didn't impress me enough, because it was another five years before it sunk in that over the course of my career I had scrolled past an awful lot of simple one or two line awk solutions (on, e.g., Stack Overflow) to get to the solutions I could comprehend -- which were always much more complicated.
When considering how to spend your time, I don't think you should worry about the pits you might fall into. I think you should look at the positive possibilities, the positive possibilities, and try to achieve them. It's possible to be very productive in the terminal and in your editor or IDE without going down too many rabbit holes.
I have been using Emacs for about 20 years, and I love that you can use it on Windows and Linux and character mode and GUI. Love the programmability and the keyboard shortcuts.
Where it sucks though is programming language smarts such as "intellisense" completion. Even something basic such as syntax coloring doesn't work reliably--depends on the mode implementation and most of them are buggy.
I get by in other editors such as Visual Studio and VSCode by downloading emacs emulators.
Where it sucks though is programming language smarts such as "intellisense" completion. Even something basic such as syntax coloring doesn't work reliably--depends on the mode implementation and most of them are buggy.
I get by in other editors such as Visual Studio and VSCode by downloading emacs emulators.
I am not sure what languages you are working with but have you tried Language Support Protocol lsp-mode?
https://langserver.org/
https://langserver.org/
Intellisense was something I was missing for years. I contribute to a large C#/netcore project and it was a pain to use emacs until I discovered OmniSharp-Roslyn[0].
Auto code completion works pretty much flawlessly for me now.
[0] - https://github.com/OmniSharp/omnisharp-emacs
Auto code completion works pretty much flawlessly for me now.
[0] - https://github.com/OmniSharp/omnisharp-emacs
I have never got omnisharp to work reliably- spent quite a bit of time on it, too. I'm wondering if I should try again or just give up...
The reason I use emacs over vscode is due to the reason, that it does not waste cycle in rendering html, use irc instead of slack and discord, and does one thing very well which is processing and rendering text.
Emacs inspired me to take on and understand functional language. Rust still feels an incremental improvement with memory safety over C.
I believe C is unfairly criticised. C has it’s own drawbacks but it is one of the language which really gave me power to tinker with hardware directly and it was refreshing. Rust may be a great language in design but didn’t generate that feeling of directly able to work with hardware as I had when I used basic peek and poke and later C.
If org-mode, text processing and lisp stays with emacs it will continue to survive for next 40 years. Yes it needs constant evolution but I do not agree with the list like renedering html, working with slack.
Emacs inspired me to take on and understand functional language. Rust still feels an incremental improvement with memory safety over C.
I believe C is unfairly criticised. C has it’s own drawbacks but it is one of the language which really gave me power to tinker with hardware directly and it was refreshing. Rust may be a great language in design but didn’t generate that feeling of directly able to work with hardware as I had when I used basic peek and poke and later C.
If org-mode, text processing and lisp stays with emacs it will continue to survive for next 40 years. Yes it needs constant evolution but I do not agree with the list like renedering html, working with slack.
Fabric Bellard’s ema s port (QEmacs): https://bellard.org/qemacs/
It’s amazing how fast it is. Unfortunately it is not fully compatible and missing many features.
It doesn't have an emacs lisp interpreter right? It's funny, for me, emacs is emacs lisp. I sort of don't understand why one would emulate emacs without a lisp interpreter (given it's Bellard I'll probably find out I'm wrong and it does have a complete emacs lisp interpreter).
that's 150kb! and already addresses html/css which the author was complaining about...
People who use Racket on Emacs might appreciate Racket Mode, which I only recently discovered:
https://github.com/greghendershott/racket-mode
https://github.com/greghendershott/racket-mode
As an emacs user I like the little rant about keyboards towards the end (54:27). It's stupid hard to find a laptop with good keys, good layout, good internals, and good battery.
I'm partial to the Emacs keybindings, but you you're so right about the laptop keyboards. Mine doesn't have an End key (Home, PgDn, PgUp, Power).
The benefit of Emacs's keybindings is that they're the default keys used by GNU readline (though it also supports Vi-style keys.)
That means when you know that Ctrl+E and Ctrl+A (`C-e' / `C-a') goes to the end or beginnings of a line in Emacs, you know it'll also work in your bash shell (or indeed any tool that uses GNU readline.)
That means when you know that Ctrl+E and Ctrl+A (`C-e' / `C-a') goes to the end or beginnings of a line in Emacs, you know it'll also work in your bash shell (or indeed any tool that uses GNU readline.)
That's what I'm using while coding, but it's not friendly to all software (e.g. browsers or other programs that don't have configurable keyboard shortcuts).
This is one of the things I like about Mac OS: text fields, by default, have the readline keybindings. In the box where I'm typing this comment in Firefox, I can use control-{a,e,n,p,f,b,d,h,k} just like I can in the shell. This is one of the reasons I haven't tried harder to use a Linux desktop.
Get a Thinkpad, remap the keys in software and never look down again.
Emacs (and may be Vim) - Not sure, but seems like it got support for all the programming languages under sun.
Thanks to all those awesome people who put effort over the years.
Thanks to all those awesome people who put effort over the years.
My killer feature is when you want to streamline your workflow. Adding a new test runner on VSCode for your favourite language? Possible but takes a lot of effort to get right. Adding one in emacs? I can inspect the source code or my language bindings and add/change the command it’s running. In a few dozen lines of elisp I can add shortcuts to all my daily tasks and even combine them. Search for an error message I get in my tests on Honeybadger? Check. Run code snippets in org mode against my local machine and export the whole document as PDF or markdown to our wiki? Saves me a few minutes here and there
Could TeXmacs solve some of the problems mentioned in the slides?
http://www.texmacs.org
TeXmacs is based on Guile and there is apparently already a Guile-based implementation of Emacs that is near feature complete.
Perhaps a Guile-based Emacs could somehow be embedded as an elisp-compatible interpreter "back-end" inside TeXmacs, much like how Mathematica is separated into a kernel (for computation) and a front-end (for input and rendering) that communicate with each other over a protocol called MathLink.
There is also DomTerm from Per Bothner, who perhaps coincidentally has also worked hard to produce his own Scheme-based version of Emacs (by way of the JVM).
https://domterm.org
One of the downsides of TeXmacs is the significant keystroke input latency caused by the extensive amount of page redrawing that is often required when editing "rich text." It's one of the main reasons that many still prefer latex-preview mode inside Emacs instead. Maybe latency would be less of an issue inside a graphics-aware terminal emulator like DomTerm.
http://www.texmacs.org
TeXmacs is based on Guile and there is apparently already a Guile-based implementation of Emacs that is near feature complete.
Perhaps a Guile-based Emacs could somehow be embedded as an elisp-compatible interpreter "back-end" inside TeXmacs, much like how Mathematica is separated into a kernel (for computation) and a front-end (for input and rendering) that communicate with each other over a protocol called MathLink.
There is also DomTerm from Per Bothner, who perhaps coincidentally has also worked hard to produce his own Scheme-based version of Emacs (by way of the JVM).
https://domterm.org
One of the downsides of TeXmacs is the significant keystroke input latency caused by the extensive amount of page redrawing that is often required when editing "rich text." It's one of the main reasons that many still prefer latex-preview mode inside Emacs instead. Maybe latency would be less of an issue inside a graphics-aware terminal emulator like DomTerm.
I really started to get lost when he started talking about never wanting to leave his text editor, wanting to read his emails in Emacs, browse the web in Emacs, have slack and discord in Emacs, etc.
Serious question: Why? Is it that hard to alt+tab? Especially, why would you want such distracting features inside your editor, while you are trying to focus and work?
Serious question: Why? Is it that hard to alt+tab? Especially, why would you want such distracting features inside your editor, while you are trying to focus and work?
You need to change the way you frame this phenomenon. Don't think of Emacs as an editor, but as a fully-introspectable and runtime-modifiable OS built on the "plaintext is king, but 2D" paradigm, that has a high-level language runtime (elisp), and comes with a set of default applications, one of which happens to be a text editor.
The desire to never leave Emacs isn't about making it slightly easier to view e-mails next to code. It's about making it possible to use the same autocomplete, same syntax highlighting, same recursive regex search, same multicursor editing, same whatever "magle this thing and put it in your calendar" hack you wrote the other day, on anything that's made of mostly text - e-mail, chats, code, prose, process lists, directory listing.
You'd probably have to experience it to believe it, or at least see some Emacs-as-OS user live, but this unification of all computing under a sane, end-user programmable, highly ergonomic interface can boost your productivity and experience in a way that isn't seen anywhere else today, not even during regular Linux use.
The desire to never leave Emacs isn't about making it slightly easier to view e-mails next to code. It's about making it possible to use the same autocomplete, same syntax highlighting, same recursive regex search, same multicursor editing, same whatever "magle this thing and put it in your calendar" hack you wrote the other day, on anything that's made of mostly text - e-mail, chats, code, prose, process lists, directory listing.
You'd probably have to experience it to believe it, or at least see some Emacs-as-OS user live, but this unification of all computing under a sane, end-user programmable, highly ergonomic interface can boost your productivity and experience in a way that isn't seen anywhere else today, not even during regular Linux use.
And even for applications that try to emulate Emacs, they all emulate default Emacs, not your Emacs setup.
It helps if you reframe your question. Emacs facilitates working outside of silos. If you're using Outlook for e-mail, for example, there are some built-in mini-silos you can interoperate with (decent calendaring, decent contacts database, fairly simplistic task management, etc.), but if you want to take notes about an e-mail you received, you might end up alt-tabbing to OneNote and then pasting some text, then writing a deadline down there and then alt-tabbing to Outlook to set up a reminder (there is separate reminder functionality in OneNote but it's rudimentary), then alt-tabbing to Slack and maybe adding a comment there related to the e-mail. The promise of Emacs is working in a single environment for all of this. One more-or-less consistent interface on top of everything.
And, I would add, in an entirely keyboard-driven way. I appreciate, as an Emacs user, how much I can get done without using the mouse.
> Is it that hard to alt+tab?
incidentally, alt+tab is broken on MacOs. It cycles between programs, not windows - so if you have mutiple terminal windows open, you're screwed. You can use the alternative alt+` to cycle between windows of the same app, but that doesn't go to the least recently used window, but cycles through them in order - which is also useless when having many terminals open. Then you can pay like 15$ to get a tool like witch (just to get basic OS functionality), but that tool is slow and broken.
So on a Mac it can be pretty hard to alt+tab.
incidentally, alt+tab is broken on MacOs. It cycles between programs, not windows - so if you have mutiple terminal windows open, you're screwed. You can use the alternative alt+` to cycle between windows of the same app, but that doesn't go to the least recently used window, but cycles through them in order - which is also useless when having many terminals open. Then you can pay like 15$ to get a tool like witch (just to get basic OS functionality), but that tool is slow and broken.
So on a Mac it can be pretty hard to alt+tab.
Not exactly what your asked for, but this is what I do:
System Preferences -> Keyboard -> Shortcuts -> Mission Control:
Set "Move left a space" to: Control + 9
Set "Move right a space" to: Control + 0
System Preferences -> Keyboard -> Keyboard -> Modifier Keys...
Set "Caps Lock" key to: Control
System Preferences -> Keyboard -> Shortcuts -> Mission Control:
Set "Move left a space" to: Control + 9
Set "Move right a space" to: Control + 0
System Preferences -> Keyboard -> Keyboard -> Modifier Keys...
Set "Caps Lock" key to: Control
Trackpad + 4 finger swipe works wonders for this problem.
I’ll agree it’s not as immediate as a good alt+tab, but it allows you to directly choose a different window from the same application.
I’ll agree it’s not as immediate as a good alt+tab, but it allows you to directly choose a different window from the same application.
I don't get where that is broken.
On other operating systems, alt+tab goes to through the list of least recently used windows. So when working between two windows, one hotkey switches between them. On Mac, that's not possible if the two windows are part of the same app (or also when windows are distributed across multiple work spaces).
Being able to switch between apps, windows, and tabs is different from just windows and tabs. I prefer the former because the hierarchy allows you to find arbitrary things with fewer keypresses overall (as opposed to mashing alt-tab through a long flat list).
Except there's no such capability.
It takes mental effort. Imagine your coworker asks you which version of your app is running on staging and if the latest modification runs without throwing an error. Sure, alt-tab to your terminal and 5 commands later you’re in your app‘s repl to answer that but by then you had to switch your context. Opening your custom helm search for your servers which then displays a new window with your docker instances on staging plus pressing enter to dial into a repl session there is not only convenient, it reduces mental effort
I've been using Emacs for 15 years or so.
I recommend Emacs to anyone who thinks it would be fun to use Lisp to configure a text editor, even if just a bit. However, that is an "if and only if".
If you choose to go beyond using emacs lisp for configuration, then I would say that emacs-lisp is an extremely fun and productive environment to work in: many programming languages give you a good standard library and package ecosystem, but with Emacs lisp you not only get that, but from the outset your project will be born into a mature and extremely fully-featured text editing environment. It's possible to create useful projects with a very good feel, with relatively few lines of code. If you don't have another excuse to use a lisp in your life, this is a very good one.
I would like it if Emacs would stop distributing itself with the ridiculous splash screen and 1990s menu icons.
I recommend Emacs to anyone who thinks it would be fun to use Lisp to configure a text editor, even if just a bit. However, that is an "if and only if".
If you choose to go beyond using emacs lisp for configuration, then I would say that emacs-lisp is an extremely fun and productive environment to work in: many programming languages give you a good standard library and package ecosystem, but with Emacs lisp you not only get that, but from the outset your project will be born into a mature and extremely fully-featured text editing environment. It's possible to create useful projects with a very good feel, with relatively few lines of code. If you don't have another excuse to use a lisp in your life, this is a very good one.
I would like it if Emacs would stop distributing itself with the ridiculous splash screen and 1990s menu icons.
I struggled a lot with my Emacs setup, and developing for clients and languages. But I was able to puzzle my pieces together with https://emacs.zeef.com , it is your friend
A question for Emacs user: Do you use the GUI version or the terminal version? I found the terminal version next to unworkable because I couldn't find any terminal that didn't capture some keystrokes that were meant for Emacs.
GUI. Why should I use the terminal version if I work at a GUI. If you have SSH then you do not even have to log in to sites, to run emacs. Just use Tramp.
Terminal support is the only reason I use Emacs. Remote editing is a must. Emacs is the most feature-complete editor available on terminals.
The alternatives are: run VNC or RDP to get a remote graphical environment for an IDE or use VS Code's proprietary remote extension. Neither of these get me excited for many reasons.
The trick for terminal Emacs is to run Emacs as a daemon and spawn Emacs with the `emacsclient` command.
The alternatives are: run VNC or RDP to get a remote graphical environment for an IDE or use VS Code's proprietary remote extension. Neither of these get me excited for many reasons.
The trick for terminal Emacs is to run Emacs as a daemon and spawn Emacs with the `emacsclient` command.
alias e='emacsclient -nw -a "" -c "$@"'
I use the terminal version of Emacs. I've used a number of terminals and currently use Kitty[1]. It had some keybindings that conflicted with Emacs, but the config file has a really handy "unset everything" command. So, I only have keybindings for things I actually use.
1: https://sw.kovidgoyal.net/kitty/
1: https://sw.kovidgoyal.net/kitty/
Both. Roughly 2/3 of the time I use the GUI version on my desktop; remaining 1/3 of the time I use a terminal frame over SSH, connecting from my "sidearm" to that desktop.
If you use a 256-color-enabled terminal, the terminal version can look almost identical to the GUI version, which is very nice.
If you use a 256-color-enabled terminal, the terminal version can look almost identical to the GUI version, which is very nice.
Terminal. I started using Emacs in the terminal because I wanted to train myself to use its keybindings rather than menus and icons. I haven't looked back because running it in a window is just one more window to manage (rather than being slot 0 in my tmux session).
I've found GUI plays pretty well with macOS.
On the note in the video about irc, I think there is room to update irc but keep it going. Right now as an in between I'm leaning towards a mumble/irc setup. The only other two things that really catch my eye are matrix and mattermost (which has a jitsi integration).
I hate the trend to proprietary chat apps so much. After years of ventrillo and teamspeak, around 2009 I discovered mumble and was using it for years, but in the last ~1year or so everyone started switching to freaking Discord and it drives me crazy.
I hate the trend to proprietary chat apps so much. After years of ventrillo and teamspeak, around 2009 I discovered mumble and was using it for years, but in the last ~1year or so everyone started switching to freaking Discord and it drives me crazy.
Emacs is an extensible editor ... It just need to be adaptive now to programming language evolution.
If Lisp have make the job from a while it should be nice to keep that solution, but, to had more flexibility for next generations.
A simple example, I works with it every days, IRC, mail, web, source code ... but on Ycombinator, I need to load an html browser to vote ... But yes I works out of Xorg ... and that is an important value that most of editor just don't understand.
Thanks for GNU Emacs, I really love it.
If Lisp have make the job from a while it should be nice to keep that solution, but, to had more flexibility for next generations.
A simple example, I works with it every days, IRC, mail, web, source code ... but on Ycombinator, I need to load an html browser to vote ... But yes I works out of Xorg ... and that is an important value that most of editor just don't understand.
Thanks for GNU Emacs, I really love it.
I've never seen the need to use anything other than vim.
I used to say that for 20 years but more and more I've found it wanting and in the last week have been giving Spacemacs a go.
I'm sure it's not what I'll end on (very likely to try doom or vanilla emacs), but emacs + vim keybindings is the best of both worlds.
I'm sure it's not what I'll end on (very likely to try doom or vanilla emacs), but emacs + vim keybindings is the best of both worlds.
Same here. I've tried getting into Emacs for a couple days but gave up. It would mean a lot of effort just to achieve a similar proficiency, for little gain(better syntax highlighting, a few small features).
I think the deeper you're already in one of the ecosystems the harder it becomes to switch and the returns diminish further. In my case I'm very comfortable with Vim combined with a tiling window manager and terminal buffers, and I can't stand Emacs' control scheme. So at this point it's simply not worth it.
I think the deeper you're already in one of the ecosystems the harder it becomes to switch and the returns diminish further. In my case I'm very comfortable with Vim combined with a tiling window manager and terminal buffers, and I can't stand Emacs' control scheme. So at this point it's simply not worth it.
Emacs has recently been seeing a lot of growth from vim users who are migrating to emacs "distros" (like spacemacs and doom) that are pre-configured with emacs' vim-emulation.
I found this video[0] a pretty interesting perspective from a die-hard vim user who switched.
[0]: https://www.youtube.com/watch?v=JWD1Fpdd4Pc
I found this video[0] a pretty interesting perspective from a die-hard vim user who switched.
[0]: https://www.youtube.com/watch?v=JWD1Fpdd4Pc
I've tried those already. Evil, Spacemacs, Doom. All except Doom have a misbehaving Escape key, Spacemacs needs as long to start up as one of the Electron-based editors.
In the end it comes down to this: I don't need Emacs. I've tried to find a feature that I really want and that's worth it to switch for(yes, I also tried org mode). But I'm comfortable with my Vim setup, I don't need an email client or web browser in the text editor.
In the end it comes down to this: I don't need Emacs. I've tried to find a feature that I really want and that's worth it to switch for(yes, I also tried org mode). But I'm comfortable with my Vim setup, I don't need an email client or web browser in the text editor.
I'm on 20 years now, can easily see it going 40 more.
I am considering buying Intellij IDEA ultimate. Been testing pycharm Pro, and docker integration for specific OS settings, remote debugging, refactoring tools such as method extraction, package conversion, and terraform integration is a breeze.
Any way I could set such an environment up in emacs?
Any way I could set such an environment up in emacs?
JetBrains editors are superbly good at refactoring, IMO that's their one only advantage.
Consider working primarily in an editor with LSP support (such as Emacs) and use JetBrains on the side solely for refactoring. Wean yourself off of JetBrains, as LSP improves.
Consider working primarily in an editor with LSP support (such as Emacs) and use JetBrains on the side solely for refactoring. Wean yourself off of JetBrains, as LSP improves.
i think it's fair that for big projects, you'll be fine with the IDE. I spend my days in emacs, Intelli-J/Rider, and VSCode...
I don't do a lot of code editing in emacs, except for usually dotfiles and other single file operations. I do do a lot of code reading in it, though. Rip-grepping through multiple projects, opening the interesting looking files in Emacs....and then when I think i have what I want, I'll usually open the parent project in VSCode or Rider to do some editing.
I don't do a lot of code editing in emacs, except for usually dotfiles and other single file operations. I do do a lot of code reading in it, though. Rip-grepping through multiple projects, opening the interesting looking files in Emacs....and then when I think i have what I want, I'll usually open the parent project in VSCode or Rider to do some editing.
> Emacs support is on by default in MacOS.
Given that the author is siding with the usability of macOS with something like Emacs over using it in a GNU/Linux distro is somewhat a surprising discovery and perhaps an insight into the falsehood of having a 'consistent' Linux Desktop; even for power-users like the author.
If one has to go through a maze of settings and config files to configure Emacs shortcuts to work 'consistently' on either a GNOME or KDE desktop even for a typical developer, then I would at first question myself if such an endeavour is 'worth it' for something as arcane as Emacs.
While it was a great spectacle to watch the Vi/Emacs wars, I'm afraid that I would favour getting my work done on my MacBook, thank you very much rather than messing around with something that could be easily mistaken as the editor for the prehistoric years.
Given that the author is siding with the usability of macOS with something like Emacs over using it in a GNU/Linux distro is somewhat a surprising discovery and perhaps an insight into the falsehood of having a 'consistent' Linux Desktop; even for power-users like the author.
If one has to go through a maze of settings and config files to configure Emacs shortcuts to work 'consistently' on either a GNOME or KDE desktop even for a typical developer, then I would at first question myself if such an endeavour is 'worth it' for something as arcane as Emacs.
While it was a great spectacle to watch the Vi/Emacs wars, I'm afraid that I would favour getting my work done on my MacBook, thank you very much rather than messing around with something that could be easily mistaken as the editor for the prehistoric years.
I use the railwaycat port of emacs, which is frankly what any macos-based emacs user should use. I provides smooth scrolling, an interface with applescript, touch bar support, and lets you use os-native hotkeys including Command-as-Meta.
I agree that the Mitsuharu version of emacs is pretty great on the Mac, but the lack[0] of multi-tty[1] support is a deal breaker for me. I like emacs-plus[2], which while not quite as nice as the railwaycat/mitsuharu version, allows me to run text frames and GUI frames on the same server process.
[0]: https://bitbucket.org/mituharu/emacs-mac/pull-requests/2/add...
[1]: https://www.emacswiki.org/emacs/MultiTTYSupport
[2]: https://github.com/d12frosted/homebrew-emacs-plus
[0]: https://bitbucket.org/mituharu/emacs-mac/pull-requests/2/add...
[1]: https://www.emacswiki.org/emacs/MultiTTYSupport
[2]: https://github.com/d12frosted/homebrew-emacs-plus
I changed Emacs for Sublime and now VScode - my main reason to change IIRC was that my fingers/wrist hurt from using chords so much :(
You should have simply switched to sticky keys, so you don't have to press keys simultaneously: https://en.wikipedia.org/wiki/Sticky_keys
Also, you can change the keybindings.
Also, you can change the keybindings.
I tried a few times, but could not go from "pressing at the same time" to "presssing in a sequence". I just "chorded"...
How does Sublime or VSCode help with that? Emacs has evil mode which enables a vi style interface.
For once, they help because you don't feel like playing with the editor so much... Emacs was a timesink.
Like, where now I use https://insomnia.rest/ to interact with APIs, when I used emacs that could/would be solved with elisp files filled with elisp functions to run those calls interactively...
Like, where now I use https://insomnia.rest/ to interact with APIs, when I used emacs that could/would be solved with elisp files filled with elisp functions to run those calls interactively...
The idea of Emacs will survive, that's quite sure. The editor, I wouldn't bet on this one.
authors seems to not know melpa and is away from emacs news.
eglot is about to ship into emacs core, emasc has pdf reader for decades and remacs is a rewritten of emacs in rust, that had contributiuon from emacs core devs too.
and guile is ready to use into emacs as a alternative to elisp
eglot is about to ship into emacs core, emasc has pdf reader for decades and remacs is a rewritten of emacs in rust, that had contributiuon from emacs core devs too.
and guile is ready to use into emacs as a alternative to elisp
With emacs it feels like I can do almost anything.
Emacs - the editor that STILL doesn't have a simple way to duplicate the current line?
I don't think it's that hard to do C-a, C-k then C-y as many times as you want.
If you want to bind it to a key you could record that as a macro for e.g., but I find that sequence is simple enough that I don't think hard about it
If you want to bind it to a key you could record that as a macro for e.g., but I find that sequence is simple enough that I don't think hard about it
For the equivalent of vi's 'yyp', you must do C-a C-k C-k C-y C-y, or more likely 'C-akkyy'.
The first C-k only kills to end-of-line, to capture the line ending (\n) you need another C-k. The first C-y only puts back what you killed, so that needs to be doubled also to actually change the buffer in the desired way.
Subsequent C-y commands will add more copies of the line, but I find that 99% of the time it's only a single duplicate of a line that I want.
C-S-Backspace C-yy does the same thing, btw.
The first C-k only kills to end-of-line, to capture the line ending (\n) you need another C-k. The first C-y only puts back what you killed, so that needs to be doubled also to actually change the buffer in the desired way.
Subsequent C-y commands will add more copies of the line, but I find that 99% of the time it's only a single duplicate of a line that I want.
C-S-Backspace C-yy does the same thing, btw.
I think the germane point about Emacs here is that some people like writing Lisp and some people hate it. If you hate it Emacs is likely not going to be your best environment, and that’s fine.
I really like writing Lisp so Emacs has a simple way of doing anything I want, but it’s not for everyone.
I really like writing Lisp so Emacs has a simple way of doing anything I want, but it’s not for everyone.
I love writing Lisp and do it for a living, but I can’t even remember the last time I had to write a single line of elisp to use Emacs (unless you count things like adding or removing a layer in my .spacemacs file as writing Lisp).
Really? Emacs is the opposite for me, I've used it for 15 years and really only recommend it to those for whom writing a little bit of emacs lisp sounds like fun. You write lisp for a living, sounds like in Emacs, so I assume you use paredit-mode. Don't you have to do little things like ensure that paredit-mode is turned on in your mode hook for clojure or common lisp or whatever?
I have changed the values of dotspacemacs-smartparens-strict-mode and dotspacemacs-smart-closing-parenthesis from the default nil to t in my .spacemacs file. As far as I can remember, that's the only paredit-ish customisations I have done. And by the way, I use smartparens everywhere, not just in Lisp modes.
Generally, the Spacemacs defaults work really well for me, and for many others. Elisp hacking was more relevant in the past. These days, with Spacemacs and other similar community efforts that deliver sane and well thought out settings, not much tinkering is required.
Generally, the Spacemacs defaults work really well for me, and for many others. Elisp hacking was more relevant in the past. These days, with Spacemacs and other similar community efforts that deliver sane and well thought out settings, not much tinkering is required.
OK, I feel like I'm missing something with smartparens. I do the same as you -- but I use paredit everywhere, not just in lisp modes. When I've tried smartparens it seemed much less attractive (powerful?) than paredit.
I think this is a larger problem with Emacs. Duplicating a line is something that should be easy to do out of the box.
And if it's a situation where you really need to make the user define a keyboard shortcut, don't make them do C-c followed by the actual shortcut, let them define single keystroke shortcuts to do what they want. Multiple keystroke shortcuts are so damn annoying.
And if it's a situation where you really need to make the user define a keyboard shortcut, don't make them do C-c followed by the actual shortcut, let them define single keystroke shortcuts to do what they want. Multiple keystroke shortcuts are so damn annoying.
Why? I can't think of any time when I've wanted to duplicate a line.
Well, there are a lot of things I don't want to do, but that doesn't mean others don't want to do them. As these things go, it's a fairly common operation.
I don't hate or like lisp. It's just another programming language which does the job.
My emacs would have that feature in a few seconds if I thought it would be useful. But I don't happen to think it is so it (probably) doesn't.
Simple, given the Emacs defn of "simple" :-)
It is simple. What other editor lets you take anything from here:
https://www.emacswiki.org/emacs/CopyingWholeLines#toc3
and then just eval it to get new functionality? And the various implementations I linked to here are trivial to figure out and write yourself with even the most passing familiarity with Emacs Lisp. Even if you're a complete newcomer to the language, Emacs is self-documenting and can teach you everything from inside the editor.
https://www.emacswiki.org/emacs/CopyingWholeLines#toc3
and then just eval it to get new functionality? And the various implementations I linked to here are trivial to figure out and write yourself with even the most passing familiarity with Emacs Lisp. Even if you're a complete newcomer to the language, Emacs is self-documenting and can teach you everything from inside the editor.
C-S-backspace C-y C-y
That's simple by Emacs standards. :-)
If you need it simpler, write and save a keyboard macro.
That's simple by Emacs standards. :-)
If you need it simpler, write and save a keyboard macro.
Different editors have different patterns of usage. I find I roughly speaking never duplicate lines, so why would this be a problem?
I constantly find myself duplicate lines in vim (shift+y). You've never had to edit a line that's really similar to another?
Or when debugging, I don't want to change the old code, so I copy the line, comment it out, and work with the duplicated line.
You've never had to do that?
Or when debugging, I don't want to change the old code, so I copy the line, comment it out, and work with the duplicated line.
You've never had to do that?
Well, everyone edits things in different ways.
The Emacs way of solving a workflow problem is instructing Emacs how to solve it for you. For instance, you mention:
1. Copy the line the cursor (point) is on;
2. Insert the copied line below/above point;
3. Commenting out the line you copied;
By the sound of things you do 1 and 2 with a command in Vim and the 3rd option with another command. In Emacs, I would simply program a function to do all 3 and bind it to a key.
The Emacs way of solving a workflow problem is instructing Emacs how to solve it for you. For instance, you mention:
1. Copy the line the cursor (point) is on;
2. Insert the copied line below/above point;
3. Commenting out the line you copied;
By the sound of things you do 1 and 2 with a command in Vim and the 3rd option with another command. In Emacs, I would simply program a function to do all 3 and bind it to a key.
The point is that "duplicating a line" is a very fundamental building block to other operations, and it should be supported natively. For instance, lets say you have to do several different function calls with only minor differences, you might write it out once and then duplicate a few times, then go in and edit them.
"Writing a function for the full change" is simply not a tenable thing to do. "Duplicate a line" is fundamental in the same way that "go to start of line" or "indent this line one more tabstop" is.
As someone who has spent years using both Emacs in "Emacs mode", and vim/evil-mode, there's no question to me that the modal vim-style editing is superior to Emacs's. That's not to say that "Emacs mode" is bad: it's far superior to most editing styles. Just not evil/vim :)
Don't get me wrong: I adore Emacs, and I use it for hours and hours every day. But if it weren't for evil-mode, I would go back to Vim in a heartbeat.
"Writing a function for the full change" is simply not a tenable thing to do. "Duplicate a line" is fundamental in the same way that "go to start of line" or "indent this line one more tabstop" is.
As someone who has spent years using both Emacs in "Emacs mode", and vim/evil-mode, there's no question to me that the modal vim-style editing is superior to Emacs's. That's not to say that "Emacs mode" is bad: it's far superior to most editing styles. Just not evil/vim :)
Don't get me wrong: I adore Emacs, and I use it for hours and hours every day. But if it weren't for evil-mode, I would go back to Vim in a heartbeat.
> "Writing a function for the full change" is simply not a tenable thing to do. "Duplicate a line" is fundamental in the same way that "go to start of line" or "indent this line one more tabstop" is.
So write a function for "duplicate line" and use it from now on. It's very easy to do. Just as it's easy to write function for a full edit.
A general algorithm to get one started:
1) Execute the edit you want to reuse.
2) Press C-h l, or M-x view-lossage, to see all the keypresses you made recently, along with elisp commands they executed.
3) You now know all the operations you did. Most of the time, you can recreate the edit by just wrapping them in parens, and then wrapping the whole block with (progn).
4) You're now ready to turn it into a function. Read up on 'defun and 'interactive forms. For best results, check out the documentation for each command you used during edit, via C-h f - some commands are meant for direct usage, and have a (faster, better) variant meant for use from within code; this is usually documented.
5) Tweak your function to make it more general along the dimensions you need, bind it to a key, and now you've just implemented what elsewhere would take a large plugin.
So write a function for "duplicate line" and use it from now on. It's very easy to do. Just as it's easy to write function for a full edit.
A general algorithm to get one started:
1) Execute the edit you want to reuse.
2) Press C-h l, or M-x view-lossage, to see all the keypresses you made recently, along with elisp commands they executed.
3) You now know all the operations you did. Most of the time, you can recreate the edit by just wrapping them in parens, and then wrapping the whole block with (progn).
4) You're now ready to turn it into a function. Read up on 'defun and 'interactive forms. For best results, check out the documentation for each command you used during edit, via C-h f - some commands are meant for direct usage, and have a (faster, better) variant meant for use from within code; this is usually documented.
5) Tweak your function to make it more general along the dimensions you need, bind it to a key, and now you've just implemented what elsewhere would take a large plugin.
I love view-lossage. How often do You use C-x <esc> <esc> which shows elisp for what ya just did? Eg, switch buffer then try it.
Oh, I didn't even know about that! That's great!
Also, it reads straight from command-history variable (another thing I didn't know about). You can preview and browse it via C-h v command-history. Or, write your own elisp operating on it (perhaps interactively, by IELM - the elisp REPL).
Also, it reads straight from command-history variable (another thing I didn't know about). You can preview and browse it via C-h v command-history. Or, write your own elisp operating on it (perhaps interactively, by IELM - the elisp REPL).
You do it because it's so easy :)
I say that as a Vim user that duplicates lines constantly. Vim definitely changes your coding patterns; for better or worse because it can be soo frictionless.
I say that as a Vim user that duplicates lines constantly. Vim definitely changes your coding patterns; for better or worse because it can be soo frictionless.
millions of times. but with magit and a complete disregard for commit messages you can cure yourself of the crud-making habit in an afternoon!
If that's something you do a lot, you could write a ~3-line function and bind it to a key.
If you care about such things then don't use vanilla emacs. Use spacemacs instead where I suspect you'll have this out of the box. It's not an obscure port. Indeed in the long run it wouldn't surprise me if we end up with more spacemacs users than vanilla emacs. I've even run across some pages with emacs tips where they take it as a given that you're using spacemacs (the tips only work on spacemacs and the page never qualifies this).
And even with vanilla emacs it's probably a one liner in your config to get vi bindings.
And even with vanilla emacs it's probably a one liner in your config to get vi bindings.
I know this isn't as simple as what you're looking for, but this is what I go to macros for. Kill the line, paste it twice, move to the first one, comment it out, move down one.
Once you create a macro like that you can run it, name it, save it to your config, bind it to a key, whatever suits your workflow.
I never really thought of how much I do this manually, so I just set it up for myself right now. I'll probably rewrite it as an elisp function though.
Once you create a macro like that you can run it, name it, save it to your config, bind it to a key, whatever suits your workflow.
I never really thought of how much I do this manually, so I just set it up for myself right now. I'll probably rewrite it as an elisp function though.
Triple click the line, then middle click somewhere.
Or ctrl a ctrl k ctrl k ctrl y (move) ctrl y.
Is it really something that’s so common that it needs a command?
Or ctrl a ctrl k ctrl k ctrl y (move) ctrl y.
Is it really something that’s so common that it needs a command?
duplicate function declaration or code chunk; comment out old and modify new; leave old inline until you're happy with new and verified existing functionality isn't lost. Super useful working pattern I think that I use constantly. If it was more than `V p` Maybe i wouldn't work like that; but I do because it is so frictionless.
The more I use Git the more I've been committing/diffing for similar effect; but it's still much more overhead for smaller checks.
The more I use Git the more I've been committing/diffing for similar effect; but it's still much more overhead for smaller checks.
I find git a much better use case for that sort of thing, especially since it's about as many keystrokes.
If you've got a vim setup that works for you, great.
If you've got a vim setup that works for you, great.
(list-packages) and install move-dup.el to gain four variations on that theme..
Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration. I revisit my setup every couple of years or so, and I always find it is time well spent, as my productivity goes up as a result.
I do not know of a better environment for multi-language programming, and I often look around and try different things to see if they match up.