[HN Gopher] Using Guile for Emacs
___________________________________________________________________
Using Guile for Emacs
Author : todsacerdoti
Score : 101 points
Date : 2024-12-16 15:37 UTC (7 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| klik99 wrote:
| For people who are more involved in this world than me: What're
| the chances of actually getting a supported full feature parity
| version of guile emacs? Like not anytime soon but, say, in the
| next 10 years.
|
| It's my understanding it would be a significant speed improvement
| but the amount of work and the - ahem - stallman factor are big
| roadblocks.
| hollerith wrote:
| Although I think I understand Stallman and his role in Emacs
| pretty well, I cannot guess as to what "Stallman factor" refers
| to in this context.
| klik99 wrote:
| I don't so it was a genuine question, checking if my
| understanding was correct. I guess it's more about the CL
| aspect.
|
| From the article "Richard Stallman is not a fan of Common
| Lisp; rewriting Emacs using it is not likely to go far." My
| understanding is his preferences have a strong influence on
| emacs direction, which of course is well deserved, but he can
| be stubborn about things. I used "stallman factor" because
| it's not easy to sum up, as his strong opinions and influence
| on the project are both not bad things (even when I disagree
| with him I feel it's important to have someone like him) but
| they do prevent some avenues for improvement. Happy to be
| wrong about this.
| davexunit wrote:
| My recollection of past guile-emacs stuff is that rms is not a
| blocker here.
| lloda wrote:
| The biggest roadblocks are 1) lack of continued effort and 2)
| reticence on the Emacs side. I'd say 1) is the most important
| by far.
| blihp wrote:
| What's your rush, sonny? You say 'not anytime soon' but then
| you say 'next 10 years'. In the world of GNU software, to say
| 'glacial pace' is basically asking 'what's your hurry?' Fine
| wine, fine wine... give it at least 30-40 years...
| rollcat wrote:
| I've been a "casual" Emacs user for 20ish years. I've never
| written a full-blown package, but went thru several cycles of
| init.el bankruptcy.
|
| In my opinion and from my POV, Elisp is completely fine - no need
| to amend or replace it. The last thing I'd like is to mix yet
| another language into my config (already have to call out to
| shell _and_ AppleScript).
|
| Now I don't know how annoying Elisp is for package authors, or
| maybe there's a Guile/Scheme library somewhere out there that
| Emacs could desperately use.
|
| The problems are IMHO elsewhere, and the main one is that Emacs
| feels antiquated next to literally any text editor conceived in
| the past 30+ years. The defaults are awful - most of my config is
| just fixing papercuts, like adding support for light/dark mode,
| finding a reasonable font and applying text size consistently,
| locating the correct LSP executable, or following platform
| conventions for copy/paste (all across Linux, OpenBSD, and
| macOS).
|
| I would really like it if Magit was a standalone program, rather
| than an Emacs package, so that I could just switch to a more
| reasonable editor.
| vfclists wrote:
| This is not about replacing Emacs Lisp with Guile. It is more
| about replacing the interpreter and the parts written in C with
| Guile. Emacs Lisp will still be the language for scripting and
| the code for the plugins shouldn't change much.
| pavon wrote:
| I don't think there is any plan to replace or even supplement
| ELisp with Guile Scheme. Guile is a language, but it is also a
| compiler and runtime. The later two have been intentionally
| designed such that different language front ends can be written
| to use them. The plan here is to use a new Elisp front end for
| the Guile compiler and runtime to replace Emacs' custom Elisp
| interpreter. Extensions and internal implementations will still
| be written in Elisp.
| rbanffy wrote:
| Wasn't someone porting Emacs to run on Common Lisp? Or was
| just the C part of Emacs and building an eLisp on top of CL?
| simendsjo wrote:
| You might be thinking of https://lem-project.github.io/
| klik99 wrote:
| Yeah defaults suck, but Starter kits have existed for a while:
| http://xahlee.info/emacs/misc/list_of_emacs_starter_kits.htm...
|
| For me at least it took a few weeks initially to get a set up I
| liked but then have barely touched it in ~15 years. I suspect
| "better defaults" won't happen because it's not a continuing
| problem users have - like maybe you think about it when you're
| in the initial setup, but then it becomes less important to any
| developers.
|
| It's an advanced tool, and typically advanced tools don't come
| out of the box ready to go.
| ska wrote:
| > I suspect "better defaults" won't happen because it's not a
| continuing problem users have
|
| As the plethora of startup kits and re-configurations show,
| it's also not something people can agree what the right thing
| (TM) is.
| Kototama wrote:
| You can always make magit behave as a standalone program if you
| wish. For example https://github.com/gizmomogwai/magit
| ajross wrote:
| 33 years here, and that's *exactly* where I am. Emacs... is
| fine. I mean, there are new features occasionally that are
| worth using. There are new paradigms it would be nice for it to
| support. But major architectural changes just seem silly. It's
| *done*. How many pieces of software ever get to say that? How
| many of those are entering their _fifth_ decade of popular use?
|
| Just leave elisp alone. I see nothing but grief and churn in
| this direction.
| pton_xd wrote:
| Agreed. Having gone through it several times myself, I don't
| even mind init.el bankruptcy once every 5-10 years. It's kind
| of rejuvinating to clean house and start anew. And these days
| the "starter kits" like Doom make it easy to setup sane
| defaults for 95% of what you want to do.
|
| What really bothers me is the sluggish performance, especially
| when handling large numbers of buffers or even searching large
| files. Pretty sure fussing with Elisp is not going to fix that.
| tcoff91 wrote:
| I switched from vim to spacemacs back in 2017, (before recently
| switching to neovim). Emacs just seemed to have far superior
| packages compared to vim plugins (circa 2017), and with EViL
| mode honestly emacs just seemed like a better vim than vim for
| my use case. The performance though was never very good, but
| the feature set was amazing. I agree that Magit is hands down
| the best way to use git that's ever been created.
|
| With my recent switch to neovim, I'd say that neovim is a lot
| better than emacs for me. I used kickstart.nvim as a launching
| point to base my config off of, and it's incredible! Neogit is
| a port of magit to neovim and while it's not quite as feature
| complete as magit, it's close enough when combined with
| DiffView.nvim and gitsigns.
|
| Lua is a game changer versus vimscript and I'd say now that the
| gap in packages has been narrowed greatly and you can turn
| neovim into a pretty equivalently powerful dev environment to
| Emacs, while having vastly better performance.
| dingnuts wrote:
| > The performance though was never very good,
|
| to be honest mostly this is Spacemacs' fault. I left
| Spacemacs around the time you adopted it and I was shocked at
| how much more performant Emacs was without all the crap in
| Spacemacs' layers system
|
| I haven't declared init.el bankruptcy since then, either.
|
| > would really like it if Magit was a standalone program
|
| check out lazygit
| forty wrote:
| You should try Doom emacs if you find spacemacs performances
| not good enough.
| reddit_clone wrote:
| >I would really like it if Magit was a standalone program,
| rather than an Emacs package, so that I could just switch to a
| more reasonable editor.
|
| Magit (for me) has so much value _because_ it is part of Emacs
| , where I edit all my code.
| TacticalCoder wrote:
| > Magit (for me) has so much value _because_ it is part of
| Emacs , where I edit all my code.
|
| Same. I'll never ever understand people saying _" I use Emacs
| but only because of org-mode"_ or _" I use Emacs but only
| because of Magit"_.
|
| I use for Emacs for many things, hence org-mode and Magit
| have a lot of value to me. But they're not _that_ amazing in
| themselves as to put up with Emacs only for one of these two.
|
| Emacs is quite something: I don't think it's reasonable to
| use if only for either org-mode or Magit. You risk feeling
| bitter about it like GP.
| robenkleene wrote:
| > I would really like it if Magit was a standalone program,
| rather than an Emacs package, so that I could just switch to a
| more reasonable editor.
|
| Always curious with folks who request this whether they've
| tried `tig` (https://jonas.github.io/tig/)?
|
| Not sure what part of Magit you're looking for, but the basic
| workflow of jumping to changes and interactive staging works
| just as well to me in `tig` (with Vim) as Magit.
| Quekid5 wrote:
| Tig does about 10% of what Magit does, alas.
|
| EDIT: It does the things it does well, but it's not even
| close.
| tmtvl wrote:
| > _maybe there 's a Guile/Scheme library somewhere out there
| that Emacs could desperately use._
|
| It isn't the reason for Guile Emacs, but there is in fact a
| library Emacs could quite desperately use: fibers
| (<https://github.com/wingo/fibers>). The Emacs concurrency
| story is about as bad as you could expect from a 40+ year old
| application.
| NeutralForest wrote:
| I feel like this as well sometimes. I have a pretty good setup
| there's been instances where things like activating the correct
| Python environment, have the LSP work properly or understand
| some arcane docs has been an issue. I don't see how Guile fixes
| any of this and it also suffers anemic docs imo.
| sourcepluck wrote:
| I would be in favour of the defaults being "prettified" or
| "modernised" a bit, but I don't agree that it's that big of an
| issue.
|
| Actually, I'm not sure if there are any "major" issues...
| Development has been phenomenally good the last few years, the
| maintainers have been brilliant. There's a steady stream of
| contributors, new cool stuff (LSP support, native compilation,
| etc), improvements are happening regularly.
|
| In summary, Emacs seems to be rock solid, and the quaint little
| splash screen when you run it for the first time does not seem
| close to keeping people away! Maybe we need to uglify it :)
|
| But sure, yeah, prettier defaults, why not. I'm not convinced
| it'd suddenly get more people using Emacs, though, as Doom
| Emacs already exists, and that's very pretty and well-
| documented and modern-looking and so on.
| sourcepluck wrote:
| Oh, also, for new users who want to quickly smooth over a few
| papercuts, there's:
|
| https://protesilaos.com/codelog/2024-11-28-basic-emacs-confi...
|
| Also, a small point, you'll be thrilled to hear that an
| excellent "light/dark mode" is included in stock emacs since
| the modus-themes were beamed up into the mothership, which was
| several years ago at this stage.
| hatmatrix wrote:
| I understand native multithreading would be one of the key
| advantages of Guile Emacs.
| hibbelig wrote:
| I use lazygit as a ui. I like it. I think magit can do way
| more.
| n_sd wrote:
| Was it just me who read this as "User Guide for Emacs"
| armitron wrote:
| Given that Guile is unstable and full of rough edges on Unix and
| nearly unusable on Windows, I don't see that taking place any
| time soon. Even if they improve stability, the Emacs C VM (which
| is rock solid) is much more performant so they'd still need to
| climb that hill. And for what benefit? The ability to script
| Emacs in Javascript and Scheme? No thanks.
|
| Advice to Robin: Find something else to spend your time on
| because this isn't going anywhere.
| davexunit wrote:
| This is both rude and wrong. Congrats!
| PaulDavisThe1st wrote:
| Can anyone tell me (a GNU Emacs user for 35+ years) something
| that I can't do in elisp but would be able to do if Guile was
| used instead?
| systems wrote:
| there is a presentation on youtube (a new one)
|
| https://www.youtube.com/watch?v=yjC162DnsKI&t=594s
|
| for me the most interesting point, guile will allow emacs to be
| more lispy, replace c code with guile code and integrate with
| CLISP and CLISP libraries
| davexunit wrote:
| One example that comes to mind is the delimited continuation
| primitive (what Guile calls a "prompt" [0]) that would allow
| for lightweight concurrency in elisp code, something that elisp
| is not good at today.
|
| [0]
| https://www.gnu.org/software/guile/manual/html_node/Prompts....
___________________________________________________________________
(page generated 2024-12-16 23:00 UTC)