Non-ascii encodings are harder to program in due to the need to switch in and out of input methods.

That said, some languages like Arabic and Japanese (and possibly Korean and Hindi) lend naturally to VSO token ordering, which maps directly to LISP syntax, so it's unfortunate that there isn't a lot of interest in this. It would be lots of fun. Maybe agents will make this possible!

Here are some interesting examples.

    - https://github.com/nasser/--- (Arabic)
    - https://honoka.nukenin.jp/Introduction/Loop.html (Japanese)
    - https://github.com/wenyan-lang/wenyan (Chinese, which is SVO like English)

Comments URL: https://news.ycombinator.com/item?id=47085517

Points: 1

# Comments: 0

We could not make it funny. Also interesting was that when CoT research was getting a lot of attention, we tried a joke version of CoT, asking GPT4 to explain why a joke was funny in order to produce training set data. Most of the explanations were completely off base.

After this work, I became a lot less worried about the GAI-taking-over narrative.

Funny is very, very hard.

[1] without a dictionary, which at first seems inefficient, but this work demonstrated that GPT could perfectly reconstruct the dictionary anyway

I also pulled vui.el into the dev setup and basically instructed the agents to reach feature parity. I ran out of CC credits fast so switched to codex. Codex makes a lot of unbalanced parenthesis mistakes even in agent, although it does eventually get it right by telling it to run emacs itself. Codex wasn't able to reach feature parity though, like the background color indications (I supply a video in the readme). I didn't look too deep yet.

Jupyter is objectively more powerful from an interactivity standpoint, but the cell-based editing strategy has always fell short from a navigation and versioning standpoint. OTOH text-only interaction is sometimes too free, so after all these years, I still haven't found anything that feels just right.

Say you are writing devops documentation. Skipping the many ugly ways you can achieve this in jupyter (e.g. you need ssh logins and creds), or even slightly less ugly in atuin, in org-mode you'd use a begin_src / end_src block and eval that block. The block kind of breaks the text flow. A possibly better interaction mode would be a text "button", borrowing from GNU Hyperbole's terminology.

Continuing the button use case, say the devops document says " to check the uptimes of our servers". That button is simple enough. You can evaluate this and get a buffer, or like org-babel, insert the output into a block inline. Now we want to extend the functionality: "". We want parameterization, but without breaking flow. So here I'm thinking of injecting a disposable form at cursor. In a web-based toolkit, we'd use a popup or expandable form, but that switches focus out of the document and into a modal. Does that make sense?

I'm not sure how well it will all fit, but every now and then I feel the same itch, and it seems like in 10+ years of using different tools, Emacs is still the best for providing "structured, validated input for in-document interaction".

I haven't used it extensively, but semantic grep alone was kind of worth it.

Is there a simple way to achieve in-buffer forms? The jsf-- stuff was instructed to make the widget form read-only except for the interactive widget components (took a few iterations to work), while keeping the rest of the buffer editable. The demos seem to all mount to a new buffer. Though I could also feed vui.el into an agent and ask :-)

Thanks for the tips. I guess I can add the deps to --eval "(load 'eldev)" in manual testing.

edit: wow, I just saw your implementation at https://gist.github.com/d12frosted/51edb747167c0fa8fcce40fed...

this is awesome!

Staying vanilla reduces dependencies, which also makes testing easier during iteration. I forgot which agent (CC or codex) I used for the bulk of the code generation, but some times I manually do some one-off dialog and those get unbalanced parens.

In the agent I ask it to do `emacs -q -nw -l ...` to iterate, so it starts a bare emacs instance. This seems to have worked well when adding [Submit and Close] and [Cancel] buttons, as well as "move the cursor into the first text input widget when inserting a new array item" (the default action is to keep the cursor on the [INS] widget after inserting the list item).

The next consideration is just that I am less confident in the agent's ability to just ingest a .el library and use it correctly vs something more popular like python. Maybe it can, I just wanted results fast and not have to dig too deep myself. I had to go in and do some (setq debug-on-error t) toggles a few times while it was figuring out the json schema load into alist/hashmap differences and I didn't want to spend more time doing plumbing.

But as you probably can imagine, dynamic inline forms immediate gives us state issues, so I asked the agent to create a buffer-local alist (or hashmap?) to track the states of the form input, so it can be cleaned up on close. It's a bit unreliable now. If vui.el already has a solution I'll switch over next.

I was searching for what's the latest in emacs widgets developments because I was interested in using widgets. Emacs Customize for example, renders text-based widgets in an editable buffer, which is very uncommon nowadays. Emacs seems like the best candidate for this kind of interactivity. I'm sure it's possible in other editors, but with significantly more effort and significantly slower rendering. I also considered lem, but the barrier also seems much higher.

His post also led me to his vui.el project, but I ended up not trying it, since after understanding the tradeoffs, I pushed the widget code creation to an LLM. I still get frequent unbalanced parentheses errors so I still stay close to the defaults.

The PoC is about testing a method to render a widgets-based, json-schema-validated input form that you can embed dynamically into an emacs buffer, enter the data, then do something post-validation. If anyone's interested, here's the latest state of the LLM-generated and human-fixed code: https://gist.github.com/whacked/6875c5117b48528e619755e13e24...

Comments URL: https://news.ycombinator.com/item?id=46584864

Points: 112

# Comments: 41

[1] https://coscup.org/2025/sessions/SNHFTW

sometimes I'm grepping in /nix/store and you have (as shown earlier) a list of derivation paths like this

$ ls /nix/store | grep nodejs-2 | head | sed 's/^/ /'

    0a9kkw6mh0f80jfq1nf9767hvg5gr71k-nodejs-22.18.0.drv
    0pmximcv91ilgxcf9n11mmxivcwrczaa-nodejs-22.14.0-source.drv
    0zzxnv3kap4r4c401micrsr3nrhf87pa-nodejs-20.18.1-fish-completions.drv
    2a7y7d38x8kwa8hdj6p93izvrcl9bfga-nodejs-22.11.0-source.drv
    2gcjb0dibjw8c1pp45593ykjqzq5sknm-nodejs-20.18.1-source.drv

You might ask why are you grepping? Because it's fast and familiar and I don't know the native tooling as easily (possibly a UX problem).

Then in spack (see https://spack.readthedocs.io/en/latest/package_fundamentals....) they have

$ spack find --paths

    ==> 74 installed packages.
    -- linux-debian7-x86_64 / gcc@4.4.7 --------------------------------
        ImageMagick@6.8.9-10  ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/ImageMagick@6.8.9-10-4df950dd
        adept-utils@1.0       ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/adept-utils@1.0-5adef8da
        atk@2.14.0            ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/atk@2.14.0-3d09ac09

$ spack find --format "{name}-{version}-{hash}"

    autoconf-2.69-icynozk7ti6h4ezzgonqe6jgw5f3ulx4
    automake-1.16.1-o5v3tc77kesgonxjbmeqlwfmb5qzj7zy
    bzip2-1.0.6-syohzw57v2jfag5du2x4bowziw3m5p67
    bzip2-1.0.8-zjny4jwfyvzbx6vii3uuekoxmtu6eyuj
    cmake-3.15.1-7cf6onn52gywnddbmgp7qkil4hdoxpcb

Tradeoffs wise I think they both made the right choice. Because for nix, the packages are almost always in /nix/store, so the path length including the hash is almost always the same.

For spack you can place your packages anywhere so the base directories can be highly variable, and so it's sensible to have the package names immediately after the package directory.

Or, I'm just trying to rationalize the choices each designer made post-hoc. But after using both I appreciate the design considerations that went in. In the end, humans are inefficient. When I make name / version / hash identifiers in my own applications I end up using one or the either design.

    0009flr197p89fz2vg032g556014z7v1-libass-0.17.3.drv
    000ghm78048kh2prsfzkf93xm3803m0r-default.md
    001f6fysrshkq7gaki4lv8qkl38vjr6a-python-runtime-deps-check-hook.sh.drv
    001gp43bjqzx60cg345n2slzg7131za8-nix-nss-open-files.patch
    001im7qm8achbyh0ywil6hif6rqf284z-bootstrap-stage0-binutils-wrapper-boot.drv
    001pc0cpvpqix4hy9z296qnp0yj00f4n-zbmath-review-template.r59693.tar.xz.drv

One interesting scenario re time traveling is if we use an LLM somewhere in data derivation. Say there's a secondary processor of e.g. journal notes that yield one kind of feature extraction, but the model gets updated at some point, then the output possibilities expand very quickly. We might also allow human intervention/correction, which should take priority and resist overwrites. Assuming we're caching these data then they'll also land somewhere in the database and unless provenance is first class, they'll appear just as ground truth as any other.

Bitemporal databases look interesting but the amount of scaffolding above sqlite makes the data harder to manage.

So if I keep ground truth data as text, looks like I'm going to have an import pipeline into timelinize, and basically ensure that there's a stable pkey (almost certainly timestamp + qualifier), and always overwrite. Seems feasible, pretty exciting!

How does this handle data updating / fixing? My use case is importing data that's semi structured. Say you get data from a 3rd party provider from one dump, and it's for an event called "jog". Then they update their data dump format so "jog" becomes subdivided into "light run" vs "intense walk", and they also applied it retroactively. In this case you'd have to reimport a load of overlapping data.

I saw the FAQ and it only talks about imports not strictly additive.

I am dealing with similar use cases of evolving data and don't want to deal with SQL updating, and end up working entirely in plain text. One advantage is that you can use git to enable time traveling (for a single user it still works reasonably).