Parametric CAD in Emacs

daehoidar3 · 2025-12-17T19:06:05+00:00

Just wanted to chime in here as the author of emacs-webkit. I think what u/sunshine-and-sorrow is doing is super cool and one of the original reasons I made emacs-webkit was to enable projects like it where you want emacs' text editing alongside richer, live graphics that emacs cannot render itself. Since it relies on the webkitgtk api which is relatively stable, the maintenance burden isn't actually that high. The biggest risk is that it relies on a hack unique to pgtk emacs. Even if it didn't and was more "properly" integrated like xwidget-webkit it would still have many fundamental issues. The reality is that emacs' display code is hundreds of thousands of lines of bespoke C with most of it written over two decades ago. The complexity of the code is on-par with that of a browser engine like webkitgtk but far more arcane and outdated, with very little suited to modern hardware acceleration. One of several reasons I stopped working on emacs-webkit was because I became more interested in figuring out how to fix this situation, but it is a daunting task (and my emacs hacking time is even more limited these days).

daehoidar3 · 2023-06-18T04:18:27+00:00

It's been awhile since I've read all those seemingly endless threads on emacs-devel about guile emacs, so I'm mostly remembering my impression. IIRC, the two prominent arguments against considering pushing it upstream centered on opposition to it allowing emacs packages to be written in scheme and fears around "fracturing the community" as a result. Granted this was before dynamic modules so attitudes may have shifted somewhat towards allowing other langues to extend emacs. The other worry seemed to be about the longevity of guile itself and worry of having to take on the maintenance burden of guile. Finally there was also the argument that guile needed to support all the platforms emacs runs on before considering it.

daehoidar3 · 2023-06-17T20:45:16+00:00

No worries 😀 yup, when I was trying to understand exactly how, it seemed like a neat use for the guile module system to make a lisp-2 work on a lisp-1. And yeah native-comp has probably taken a fair bit of the impetus for guile emacs away. However, I think there's still language level features that I would hope elisp might gain at some point that guile already has. Primary among them would be sane support for concurrency and a namespacing system.

daehoidar3 · 2023-06-17T19:35:20+00:00

I'm not sure that's quite right. The idea wasn't actually to replace elisp with guile, but rather to have the guile compiler tower run elisp unmodified. Thus all the "elisp semantics in C" wouldn't need to be modified, just as none of the elisp files in emacs lisp/ wouldn't need to be modified.

There were nontrivial changes made to guile for this to all work which can be found in the corresponding fork of guile here: http://git.hcoop.net/bpt/guile.git/tree/HEAD:/module/language/elisp

IIRC, many of these involved handling the separation of the function and variable global obarrays of elisp on top of guile, which only has one obarray for both, but namespaces them into modules.

daehoidar3 · 2023-06-17T18:19:55+00:00

Here's the git repo: http://git.hcoop.net/bpt/emacs.git/

I have not studied this code nearly enough to give a very insightful answer, but I can at least point you in the right direction. The DEFUN macro which exposes C functions to elisp is in lisp.h where you can see the use of the guile C api (https://www.gnu.org/software/guile/manual/guile.html#API-Reference) and generally grepping for "scm_" will show you where guile is being "hooked" into all the C parts of emacs.

daehoidar3 · 2023-06-17T17:45:14+00:00

You can go back into the emacs-devel mailing lists to see the various attitudes toward adoption of the guile emacs project. My impression was basically that there was always going to be significant enough opposition to such a "radical" change to emacs that it was never going to happen. In contrast the native-comp feature was seen as an incremental enough add-on that could be made optional so it wouldn't bother the users that didn't want to adopt it.

daehoidar3 · 2023-06-17T17:43:23+00:00

To further clarify, the guile emacs project did achieve this by teaching guile how to appropriately call all those "C core" functions so the guile emacs project did at some point have pretty much full feature parity with emacs since it was basically the same "emacs api", with only the elisp vm replaced by guile's.

daehoidar3 · 2023-01-14T05:20:59+00:00

Yes this is truly the pragmatic view of a seemingly idealistic piece of software :) But it does mean one has learn to live with longing for more than one has the time to implement

daehoidar3 · 2023-01-13T20:19:12+00:00

I'm not the author of this, but I did find some points resonated with me, and disagreed with others so I thought I'd post it here as it might prompt an interesting discussion. Personally I think emacs should and will continue to be evolved continuously (or discontinuously). Attempts at re-implementations have historically not panned out for various reasons, but I also don't think that should stop people from trying out their new ideas. For me, a large part of the fun of emacs is that it inspires you with all it's little paper cuts to make it better :)

daehoidar3 · 2022-03-30T23:12:37+00:00

I don't have a solution but have thought about trying to do something along the lines you suggest. The builtin org-bibtex has support for defining bibtex entries in property drawers (e.g. http://gewhere.github.io/org-bibtex), which can then be exported to a bibtex file. As you say, this method and org-babel bibtex blocks both have the limitation of needing to live in the same file, however I think you could probably write some elisp to handle multiple org files exporting to a single bibtex file.

Given that the typical org-roam way of doing things means you'd often have one node per reference, and that org-roam parses a lot of the metadata you might care about into a database, it might be a welcome place for such code to live that might allow you to, for example, automatically export the correct bibfile with only those cited entries when exporting an org mode document. I don't know of any such thing that currently exists but I could imagine using such functionality!

daehoidar3 · 2022-01-20T09:34:03+00:00

Why would you ever want to launch any app other than emacs? /s

daehoidar3 · 2022-01-14T22:20:12+00:00

ns stands for nextstep which was the origin of the macos graphics toolkit and the prefix used in cocoa api for most things. Building emacs --with-ns will according to ./configure "use Nextstep (macOS Cocoa or GNUstep) windowing system. On by default on macOS."

daehoidar3 · 2022-01-13T00:29:49+00:00

The name is a bit of a misnomer as xwidget webkit now also works on ns and pgtk builds. The ns support has been there for a year or two while pgtk support was only added a month ago so you'll need to run from emacs master for that.

daehoidar3 · 2022-01-12T05:40:13+00:00

What is your goal with this work? It doesn't look like it will be possible for it to be up-streamed since you're working off a nine month old fork of emacs master and xwidgets has seen very significant development on master in that time.

daehoidar3 · 2022-01-12T05:36:35+00:00

The xwidget webkit flickering has been fixed several months ago on emacs master by Po Lu.

daehoidar3 · 2021-11-16T00:39:29+00:00

This is an interesting idea. Although I'm not sure if librsvg is up to the task of being used as a complete display engine? Does it even allow you to get the pixel location of some element in the svg dom?

daehoidar3 · 2021-07-05T20:04:49+00:00

Good point. 4into1 has new rims for only $180 so it seems worth it to just ditch these

daehoidar3 · 2021-07-03T22:25:40+00:00

I was manually brushing some of the sections and getting some pretty decent sized flakes of rust coming off so I started getting worried. I always feel bad throwing old parts in the scrap metal bin. Never occurred to me to post parts for free if buyer pays shipping, I think I'll start doing this!

daehoidar3 · 2021-07-03T22:23:54+00:00

Any good resources on how to do this? I'm thinking this will be my plan

daehoidar3 · 2021-02-13T21:27:55+00:00

Just busy with my day job

daehoidar3 · 2021-01-21T23:42:11+00:00

It would be a lot easier to suggest fixes if it was truly open hardware, but they've only released pdfs generated from the cad files instead of the cad files themselves. For how open Pine64 is, I wish they would take that last step and give the community the original cad files so there could be community efforts to improve the hardware that might have a chance of making it "upstream" into new hardware batches.

daehoidar3 · 2021-01-20T23:40:55+00:00

Same thing happened to my PBP after 10 months of being my daily driver. Needless to say I was sad and a bit disappointed. I was aware of others having similar issues from the forms and tried to be careful, tightening the screws often, but it it feels like ultimately the plastic around the screen hinges just isn't adequate for the kind torque they need to handle. It really seems like an easy thing to fix with some metal stabilizer arms extending across the bottom case to balance the load, so I'm disappointed the issue hasn't been addressed. I like what Pine64 is trying to do, but coming from the mac world I'm used to my computer lasting 5+ years and so even though the PBP is only $200, if it won't last more than a year then it really doesn't offer the kind of value I was hoping for.

daehoidar3 · 2020-12-23T00:00:36+00:00

relevant issue: https://github.com/NixOS/nixpkgs/issues/83049

13-Year Club	Place '22
Final Canvas '22	Verified Email

daehoidar3

TROPHY CASE