A community-driven port of Emacs to Rust
github.com
github.com
https://www.emacswiki.org/emacs/GuileEmacs
Emacs with a better Lisp option would be a big improvement. With a faster Lisp, perhaps less of Emacs would need to be written in C/Rust.
Emacs Lisp is getting better all the time feature-wise, is portable to all main operating systems (good luck running Guile on Windows and macOS without issues) has enormous user base and is rock solid.
https://common-lisp.net/project/phemlock/
I have never been able to get one to work, though.
MIT Scheme also has an Emacs 18 compatible editor called edwin written in Scheme.
What didn't work for you ?
On Clozure, the IDE with Hemlock only runs on OS X--I use Linux.
The one in CMUCL might work, but I haven't tried it because they only have 32 bit support for x86.
I wasn't trying to be dismissive--I would really like to run Emacs on CL!
It would probably die out soon. XEmacs is one of the longest living Emacs forks and even that is dead(ish).
Still, I'd put up some money for this.
(This post was written inside EXWM ;-)
Is this something we care about? RMS doesn't own lisp-based text editors.
[1] Not without reason since his foresight has been correct wrt privacy, civil rights, etc.
This seems really important, and crucial to preventing the project from getting stuck at the pie-in-the-sky stage. Start it going, and dog-food it as it comes!
Facebook (PHP/Hack), Firefox (whatever/Rust), and large web projects (JS/TypeScript) could only be rewritten piecemeal.
“Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit.” [1]
If this fork removes all the legacy cruft and hacks, it’s only for the better.
[1] https://m.facebook.com/notes/daniel-colascione/buttery-smoot...
With Emacs? Oh, it’s perfect!
How will it make Emacs not a text program with a GUI component?
I fear if Emacs was remade with graphics at the forefront and text as a secondary concern, we'd lose a lot of interoperability this "text program" thinking brings to the table. Being able to work with an UI in a way you would with text files - jumping, copy-pasting, editing the UI itself, all with the exact same shortcuts and conveniences you use for programming - is incredibly powerful and something not really replicated elsewhere. I mean, number one complaint against TUIs and GUIs is that the data is locked inside, and you can't easily take it out and send elsewhere. With Emacs UIs, it's not true - if need be, you can select, copy and paste the whole thing, UI included, and it looks good in a text file and can be operated on programmatically.
--
Further improving performance of elisp and enabling true multithreading/async: that would be a huge breath of fresh air in Emacs.
When a simple task of making a program not flicker (a solved, well understood and fairly trivial problem) requires quite a sizable effort, it’s no longer just an “implementation detail”.
LOL at people decrying the bloat and inefficiency of Electron apps and calling this a perfect program with just implementation details:
— start quote —
GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype. Compiling Emacs is a challenge. Adding modern rendering features to the redisplay engine is a miracle.
— end quote —
My own use is about 50:50 of each. Only a few things don't work the same way in the terminal and that's extremely valuable.
It needs a rewrite with modern tools and frameworks. And it needs to abandon the terminal (the obsolete system) altogether.
I’ll still often SSH home from a Chromebook and edit remotely. The fact that everything still works exactly the same is awesome. If you want to make an editor that doesn’t support that, you’re welcome to, but it won’t become my editor :)
--Nobody, ever
(My point being that I think abandoning the terminal would be a huge loss to many people and therefore a poor decision)
[1] http://www.gnu.org/software/emacs/manual/html_node/emacs/Rem...
I routinely SSH to my home desktop, where an instance of Emacs is always running, to work from e.g. a bus, or a queue to the doctors', etc. Since I'm normally working on my desktop, which runs GUI Emacs, when I SSH in I have all my files and processes opened as I left them, and I can pick up working via interface that's 99% indistinguishable, sans the smaller screen size.
I think it's great that the capability exists and that others find value in it; it's just not for me (or maybe vice versa). One of the great things about Emacs is that it can still work for both sets of people: folks who like TRAMP and folks who like to SSH in and run it locally.
There was a suggestion on a Reddit thread to use Dired instead: C-x d /ssh:me@remote: which I also tried. This appeared to get further but subsequently failed with the error "ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory".
So I figured I'd try launching Emacs from within a Git Bash prompt to see whether that would provide the extra commands it was looking for, and it failed to locate my dotfiles (must have a different $HOME in that context...). However, when I attempted to open a remote file it did actually prompt me for a password! ...but then the LDAP authentication failed after timing out.
I'm out of gumption for now, but hopefully that helps to illustrate why I still want to be able to SSH into a machine and launch Emacs from the terminal.
I am curious if there are specific things about elisp that you dislike.
I find python very expressive.
When I work in elisp, I seem to find it cumbersome to do many of the mundane things, like using a local variable, and if/then/else with multiple statments, loops (continue? break?), oo stuff, etc.
a contrived example:
(let ((foo))
(if cond
(progn
(setq foo 10)
(bar))
(progn
(setq foo 20)
(baz))))
if cond:
foo = 10
bar()
else:
foo = 20
baz()
mysorted = sorted(mydict, key=lambda t: t['Price'])
(if cond
(progn
(setq foo 10)
(bar))
(setq foo 20)
(baz))That's, frankly, because you don't know the language. It doesn't take much to learn it, though, and lisps tend to be similar, so you'll learn a bit of CL and Clojure at the same time :). I would similarly struggle with Python, for a short while at least, if you sat me in front of PythonMacs.
Your example could be rewritten as:
(let (foo)
(cond (condition (setq foo 10)
(bar))
(t (setq foo 20)
(baz))))
Lisp has a slightly different style of writing than in Python, which yields comparably tight and readable code... and then you can use macros, which Python doesn't have, dynamic binding, which Python doesn't have either (and while a pain most of the time, they're a life-saver in some cases, and the type of code you write for a text editor has lots of those).
Elisp isn't a bad language. It can handle all the stuff Python does and then some. I get the preference for syntax you're already familiar with, but individually, it might be worth it to just bite the bullet and learn some new syntax. If that's your first exposure to Lisp, then it'll be especially rewarding, for all the "code is data is code" and "code that writes code that writes code" enlightenment that comes with it.
Maybe I was trying too hard to use "if" as common ground in my contrived example. I generally use if for simple conditions and cond for multiple conditions (python would use elif, and has no case statement).
But in the same vein, your example doesn't look like python, at all :)
The point of my comment is not to put down elisp, but instead to say that the translation of ideas in my head to working code seems to go smoother for me using python than lisp, both reading and writing.
Not surprisingly, I have not had to maintain large blocks of elisp. I have had to deal with chunks of python from folks, and I just can't find it a language that is pleasant. Certainly not stable. Though, I am probably tainted in the whole python 3 debacle.
Maintaining someone else's code is always a challenge, no matter what the language.
The only elisp I've maintained are my startup files, ~4000 lines.
I will say that the emacs elisp/C code is really special because you're always a meta-. away from checking out every editor function.
This may have a payoff for maintainers. If they can convince enough of the core developers to join them or build a large enough community. If their theory is right it's easier to develop and maintain Rust code than C code and if it makes more people happy we may see remacs able to forge ahead with more/better features, faster than upstream emacs.
But from my experience with projects like this it's going to take them a long time to catch up and then someone down the line is going to have to make the decision about whether to break from upstream or to follow it.
This isn't a port at all. It represents a more major bifurcation than does even a traditional ‘fork’. It's very imprecise use of language.
You have a project. You want to change one thing about it, and as little else as possible. If you're porting to platforms maybe that's pretty easy these days, porting to languages is harder and you'll have to make more incidental changes along the way.
Great work!
Emacs' C is already largely written in a high-level, macro-rich style to deal with Lisp objects (tagged pointers). So Rust already gives wins there w.r.t. more explicit types and From/Into impls over macros.
And over the last couple weeks there has been discussion about replacing xml.c with a native Rust backend for XML parsing.
But I’m much more comfortable with ML than with C; What do you see that is magic?
I suppose the “Same(x)” thing caught me by surprise―dunno, though, if it's built-in magical syntax or again something OOPy: in Python, ‘Some’ would likely be a class implementing a special method ‘__match__’.
Some is an enum constructor that’s in the prelude, so it’s just automatically imported. It’s a library type, nothing specially built into the language.
The other thing is generics (Option<EmacsDouble>) which is not necessarily OOP either and the option type itself which is functional (https://en.wikipedia.org/wiki/Option_type).
"Rust has a fantastic learning curve."
EDIT: Let me say something of substance. There's a steep learning curve for getting past Rust's borrow checker. But the language documentation and compiler error messages are the best I've seen of any language. I wouldn't say that Rust is an easy language to pick up, but it's surprisingly easy to learn for what it does.
That sounds like a core part of the definition of "steep learning curve"
- Rust skips (or almost skips) some of those steps. If you can write code that compiles, you can also write code that works. It forces you to be very specific about your intentions, which isn't possible in language with less-thorough type systems and compile-time checks.
- I agree that the curve is steeper at first, but it's arguably impossible to write code that "works well and is readable" in C/C++ (which is why we have Rust in the first place). That makes the latter part of the learning curve an asymptote.
Forcing new programmers to be specific about intentions they may not even know they are supposed to have doesn't necessarily work.
> I agree that the curve is steeper at first, but it's arguably impossible to write code that "works well and is readable" in C/C++ (which is why we have Rust in the first place). That makes the latter part of the learning curve an asymptote.
I don't agree with your analysis of "works wells and is readable". It's not too to write C code that works well and is readable. Sure, your code might occasionally break–but the point is that it works most of the time. This isn't necessarily a good mindset to have as a software engineer, but with regards to the specific claim that Rust is easier than C: it's not, because it enforces better practices, which is mental overhead and complexity that C doesn't need to deal with.
Rust is not a good language for new programmers. Neither is C for that matter. You shouldn't start learning Rust before you have solid intuitions of programming concepts like ownership, scope and mutability.
It's like saying a plane is "harder to learn to fly than other planes" just because a beginner can't learn to fly it quickly.
I'd also argue though that while the learning curve for rust is initially steeper, it is shallower when you look at the curve up to the point where you want contributors to be. C/C++ has an insanely steep cliff to go from "can write reasonable looking code" to "can write reasonable correct code".
The first argument is in some sense better because it doesn't restrict me to talking about C/C++.
The ownership concept is a bit harder to grasp, it took me maybe a day to get the initial understanding and a year to really feel comfortable in all situations.
The thing is, now that I understand it it is not only very powerful, but it allows you to think about your code differently: because of the strict ownership rules you tend to be aware at all times of the impact of the code you are looking at in any given moment. Combine this with the strong type system and you really feel in control.
When I moved from python to Rust I probably wouldn’t recommend Rust to beginners. In hindsight I am not so sure about that anymore. It is hard, but it is teaching some concepts every programmer in any language could use and it is incredibly consistent.You rarely find any weird edge cases that are the way the are because of some arbitrary decision. Most language design decisions have been extremely careful considered and you can feel that. This is contrary to many traditional beginner languages, whkch are often filled to the brim with weird edge cases.
The cargo environment is incredible.I wish I had something like this for python
I feel similarly, I'm not sure it would be success, but I think it would have a good chance.
I'm very tempted to try and design a "learn programming via rust" course and then find some guinea pigs (err ... students) to see how it works. If I had infinite free time I definitely would.
The hardes thing about teaching any traditional language is probably explaining why it is mostly a command line/terminal thing without huge efforts.
Which approach is better? Not sure. But that's a different question.
In all seriousness, see https://news.ycombinator.com/item?id=14826070 and http://wiki.c2.com/?EmacsAsOperatingSystem
You're rite :). True Emacs enlightenment comes when you realize that this is not a joke - that Emacs really is a kind of OS, and that it offers a much better experience than traditional OSes for any task that's mostly about text (whether linear or 2D). Which is quite a lot of tasks, actually.
It's a shame because I like the idea of emacs, but I simply can't seem to get it anywhere near as good as vscode.
You definitely had something misconfigured then...
Not saying that's your problem, emacs could do a lot more to be friendlier to newcomers. I'm just saying, don't be so quick to judge it until you've gotten with your local emacs nerd to see what's wrong with your setup.
init.el and .spacemacs: https://github.com/komali2/Configs/tree/master/emacs
Features like helm, ivy, projectile, etc cost. Linters and autocomplete can really make emacs jank. All this stuff is configured out the gate in these distributions.
I really like spacemacs (I'd love to get back to using vi keybindings in emacs), but man is it slow. Awfully cool, though.
That's super interesting, because the main reason I don't use VSCode at all is that whenever I hold down a key, it seems like the key events happen faster than the editor can handle, and it ends up continuing moving well after I've stopped pressing it (which is most annoying when it's the delete key).
It could be some a rogue package or something with a wonky config?
Also, you should start it with emacsclient (I alias it to a shortcut). Run the emacs server/daemon in the background, and everytime you type your alias with a file name, it'll open almost instantly.
See more on the EmacsWiki page [1]
(global-display-line-numbers-mode 1)
linum mode (and the faster contrib, nlinum mode) were used prior to Emacs 26, and sometimes had some performance issues in large files.
Also, all of those are for displaying line numbers on the left margin. Jumping to a particular line in code works always.
(And if you want to go totally oldschool, use column-number-mode and line-number-mode to see the column and line numbers of your current position displayed in the modeline. Or (shameless plug) install nyan-mode ;).)
"M-x goto-line which is bound to M-g g, or M-g M-g."
Naming the function "goto-line" in full can make it easier to remember for a reader, providing a fallback for when the key-chord isn't part of muscle-memory yet, and provides an easy way to look up the binding in emacs itself:
C-h f <ctrl-h(elp)-f(unction)>
"Describe function:" goto-line
"[..] It is bound to M-g g, M-g M-g [..]"
About smoothness, maybe, but I don't have any editor to compare it with now, except vim. I remember that NetBeans, Eclipse and some JetBrains editor where not any different on my hardware last time I had to use them.
Startup time, it's a non issue for me because I start it up after boot and keep it running. I load files into it with emacsclient [1] and save the desktop to a file to pick up from where I was after a boot. Surely, with hundreds of buffers it takes a little to finish loading but I don't reboot every month.
I have used Emacs for about 10 years, and have days upon days of effort invested in my emacs config. Despite this, it took 5 minutes of setup to get a significantly superior setup for the languages I'm using currently (Elixir, Rust, ReasonML, Python). I had more features available (e.g. better highlighting and listing of current errors), and the core ones like auto-complete and go-to-definition worked much more reliably. It took an hour of tweaking some keybindings and settings to remove some UI cruft and navigate between splits and I have something that performs at least as well as Emacs in every regard. It's only been a couple of weeks, but it's promising so far.
or Escape Meta Alt Control Shift
So how does Rust play into this? Is the Rust-stack “compatible”?
For this to succeed long term they will have to get their changes mainlined, and it would be a shame if anything as petty as licensing or political over GNU/non-GNU should stop it.
For any substantial project, licensing is a matter of make it or break, for philosophical and economic reasons. If you think one's philosophy of life or economic approach is pity, you're out of your damn mind.
Any tips or recommendations are welcome :)
I've been using Vi/Vim for more than two decades now. Doom made me feel at home. I used to envy Emacs all these nice features such as Org Mode, Magit and even the ability to use Lisp to configure your environment. Now it's the best of both worlds.
I just wish Emacs' onboarding process / cohesiveness was as good as in VS Code. It would be a dream come true. ;)
PS. I've recorded a short Doom screencast for newcomers [2]
[1]: https://github.com/hlissner/doom-emacs [2]: https://www.youtube.com/watch?v=rCMh7srOqvw
Thank you for the recommendations!
Probably not. You'd be better off looking at an Emacs distribution to see what's available.
Sacha Chua's Visual Guide to Emacs is excellent. http://sachachua.com/blog/series/a-visual-guide-to-emacs/
There's also an awesome list for it. https://github.com/emacs-tw/awesome-emacs
I'd suggest looking at Magit or Org-Mode. These are often cited as "killer features"/"gateway drugs" for Emacs.
> ... what's the equivalent of vim-plug ...
I liked the discussion on straight.el's readme: https://github.com/raxod502/straight.el/blob/develop/README....
(Or in other words - if the answer is that ASLR is turned off for either initial exec or reexec, why not keep it turned off so that a third exec works?)