Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Hey @d12frosted, would it be possible to have it as the emacs-plus (homebrew formula) option?
    by iLemming
  • If I were you, it'd be pretty much worth it when you had a conversation with Stallman.
    by flakiness
  • This is outstanding, if I have time I'll be switching over today.

    This is the kind of thing that could drive a truly free fork of emacs forward, it's enough better on realistic desktop displays to rally around and as the parent discovered "Free Software" at this point has very little to do with the freedom to do what I want on my computer in a low friction way: an ideological position on "GPUs" as a category is bizarre even by Late Soviet FSF standards. By all means cite a vendor and a policy, but even NVIDIA is in tree now, it's got the same software freedom as ext4 and I don't hear anyone talking about chains on that.

    In the age of machine assist emacs could get a modern fast/cachable build, clean under all the sanitizers, io_uring on Linux, deterministic clang formatting, compat break with zero-use junk from the 80s, WASM compilation for polyglot extension (I like lisp but I understand why some people don't), modern networking, modern chrome, 100% vscode compatible LSP, modern theming that defaults to something that doesn't drive users away. I would love to have a ten line init.el instead of 4k of workarounds.

    Maybe this can be the nvim moment.

    I love emacs but the nvim people have so many nice things and FSF emacs has a shelf life. If someone out of their own time and resources did a cross platform, mechanically verified, dramatically accelerated at HiDPI patch to basically anything else they'd be greeted like a hero.

    Keep up the good work legend.

    by reinitctxoffset
  • Thank you! A small correction on framing though: the goal is not a fork but a patch upstream. The backend is structured precisely to minimize the diff against Emacs mainline. The "nvim moment" comparison is flattering but I would rather this be the patch that makes the FSF argument easier to win than the one that splits the community. That said, your list of modernization items is a fair read of the backlog.
    by andros
  • I agree. Nvim already takes notes out of emacs with major contributors using Funnel to use Lisp as a workaround for working with Lua. This would be a step in the right direction for the continued pioneer emacs proves to be.
    by arikrahman
  • >an ideological position on "GPUs" as a category is bizarre even by Late Soviet FSF standards.

    The FSF and the GNU project are both paralyzed by their inability to move on from Stallman. He may have been a visionary 40 years ago but now he's an obsolete dinosaur who hasn't written a line of code in decades and has absolutely no idea how modern computers work.

    He can't update his own website. He evidently doesn't seem to know how GPUs work. He does his computing in a very unorthodox and anachronistic manner, and that's great for him, but irrelevant to most people who would benefit from more free software.

    by stackghost
  • Just to clarify: the NVIDIA driver is not in-tree, and probably never will be.

    Intel and AMD are, but require proprietary firmware to work, so the freedom aspect is disputed.

    by wasting_time
  • I think a stronger basis for that is probably the Neomacs project aiming to rewrite the elisp layer and all C code in Rust, incorporating GPU rendering etc along the way, see https://github.com/eval-exec/neomacs
    by joshjob42
  • > In the age of machine assist emacs could get a modern fast/cachable build, clean under all the sanitizers, io_uring on Linux, deterministic clang formatting, compat break with zero-use junk from the 80s, WASM compilation for polyglot extension (I like lisp but I understand why some people don't), modern networking, modern chrome, 100% vscode compatible LSP, modern theming that defaults to something that doesn't drive users away. I would love to have a ten line init.el instead of 4k of workarounds.

    A lot of wishes, but no concrete solutions (unlike TFA). A good design doc with factual arguments would be better.

    by skydhash
  • In case anyone is curious, ezemtsov (EWM author) has a Skai port of Emacs [1] built for Wayland (only).

    [1]: https://codeberg.org/ezemtsov/emacs

    by stebalien
  • Also done by master incal and his faithful sidekick cognitive efti, some time ago, with industry standard methods: Elisp/C/SDL3/OpenGL/GLSL/GPU.

    https://www.reddit.com/r/lisp/comments/1rasjwf/elgpu/

    https://dataswamp.org/~incal/el-gpu/

    Big thread on devel as well also 'forgetting' to mention it eheh? Well, now then :)

    by efti
  • "That was the moment the architecture stopped being a promise and became a fact."

    The post is AI generated as well, right?

    by tomaskafka
  • it certainly has the tells... I could be charitable and say maybe since it's a bilingual blog it was generated as a type of translation from the original source, but that post itself seems only available in English
    by cml123
  • I know this type of approach was rejected at the beginning, but you can also just ask CoreGraphics to use the GPU for 2D rendering (and I'm sure there are equivalent paths in e.g. Skia or Cairo).

    On macOS/iOS, the easiest way would probably be to set the drawsAsynchronously property on a CALayer. Then, all CoreGraphics operations on the context passed back to the layer via drawInContext: will be GPU accelerated.

    Lastly, there are some pretty sharp edges to this API, so definitely don't go flipping it on for every layer/view in your view hierarchy.

    by simscitizen
  • This seems like the "obvious" solution. Why was the rejected?

    EDIT: It appears to be an objection to GPU programming entirely.

    by Conscat
  • There's a lot to discuss here, a very interesting comment. I wouldn't want to talk too much publicly about certain technical elements, and because I don't want to encourage solutions decided by LLMs, however the Skia/Cairo-GL angle is interesting but would be a heavy dependency and does not help Linux, where the same gfxterm.c policy drives the OpenGL backend. The vtable abstraction was specifically designed so the rendering logic is written once and the platform just supplies the draw primitives.
    by andros
  • could've guessed staying away from xdisp.c was a good idea, cf. the "Buttery Smooth Emacs"[0] post:

    > Keep in mind that Emacs xdisp.c tries to support five different toolkits (including two different major versions of GTK) with #ifdefs. There is no runtime abstraction. We define three or four different versions of each damn function. It’s a nightmare.

    [0] https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb7...

    by internet_points
  • "No runtime abstraction" seems the correct approach for good performance.

    Run-time abstractions should always be avoided when the problem can be solved at compile-time.

    While the conditional compilation syntax of the C/C++ preprocessor is not nice, good programming text editors can make it much more readable, by highlighting/hiding appropriate text sections.

    by adrian_b
  • Well done. Here’s hoping that a hand-written GPU backend gets developed based on this wonderful proof of concept. There’s no reason to not take advantage of the state of the art hardware when it’s available. And screens are only moving toward 4k and higher (6k or 8k).
    by drob518
  • Me too. In the meantime, I'll stick with this version :)
    by andros
  • Or that GNU updates a policy that will very rapidly go from probably net silly/mildly contestedly useful to completely ridiculous in a year or two. Not allowing LLM code will be basically turning down the work of the worlds best programmers running at 50x speed in couple years, and will functionally doom any software project that enforces such a policy.
    by joshjob42
  • Aside from the wonderful contribution to Emacs, I have the utmost respect for how straight-forward you were with the 100% LLM generated code. The enlightening conversation on GPU freedom that ensued was also informative.
    by arikrahman
  • I completely agree with you. For me, it was the best reward.
    by andros
  • I really appreciated this too. Such a contrast with a similar article from someone offended because their "honesty" caused a patch to be rejected.
    by mark_h
  • This is a way of using LLMs that doesn’t seem appreciated enough: prototyping a refactor or other new approach to see how it goes. Even if you then rewrite it from scratch, it’s a big timesaver because you’re using the new knowledge to do the “right thing” and avoid backtracking.
    by wrs
  • https://github.com/tanrax/emacs-gpu/blob/main/.github/assets...

    This massive speed-up on 4K screens makes me want to try it. The wayland pgtk version has such terrible latency I have to use the X11 build to avoid gnashing teeth during my working hours. And I think it's the X11 version that uses cairo, so the actual speedup in my case might be even larger.

    I reported the issue years ago, the pgtk maintainer confirmed, say they can't do much as they're using GTK3 which isn't hardware accelerated, so I have to wait until they migrate to GTK4 (in a decade or so). A bit disappointing, but that's open source.

    Looks like I'm not the only one suffering with a 4K screen: https://old.reddit.com/r/emacs/comments/ucv0at/awful_perform...

    by sph
  • Just switch to xlibre.

    Wayland is a dead end.

    by aboardRat4
  • I didn't notice to much performance issue switching to PGTK on an ultrawide on Niri. Are you using the daemon to render Emacs as a client?
    by arikrahman
  • My experience with Emacs, 4K and Wayland was so abysmal that I spent a weekend making my config fully compatible with a terminal.

    Not ideal, but I'll keep running it through Ghostty until it's fixed.

    by panza
  • Good news on the Wayland front: there is already a working branch (wayland-pgtk-backend) that adds a PGTK binding on top of the same EGL/GLES driver, pending merge to main. If you want to try it before that, the branch is available on the repo.
    by andros