“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.
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.
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.