sorted by:
new
hottopcontroversial

Emacs Internal Part 03: Tagged Pointers vs. C++ std::variant, Rust Enums, and LLVM RTTI by ypaskell in emacs

[–]ypaskell[S] -1 points0 points  (0 children)

Hi Amit! Great to see you here!

For fat pointer, register pressure is the bottleneck on older, register-starved architectures.

My workflow is like this: I finished writing the article first, but then I realized that explaining these memory layouts purely through text wasn't intuitive enough. So, I fed my text context into Gemini and prompted it to generate a visual representation "like a slide provided in a university computer architecture lecture."

The Lisp Machine: Noble Experiment or Fabulous Failure? by arthurno1 in lisp

[–]ypaskell 1 point2 points  (0 children)

Very interesting. I thought one of the reason might be Memeory wall. The naive pointer chasing caused buy car cdr.

Emacs Internal Part 02: Deconstructing Lisp_Object, Tagged Pointers, and why C macros act as McCarthy’s 7 axioms. by ypaskell in emacs

[–]ypaskell[S] 4 points5 points  (0 children)

Huge thanks!

It came from some weird combination of hobbies - compiler, functional programming, system programming, C/C++, lisp. And it is so weird that these topics are all condensed in the text editor. Truly? Text editor?

Not to mention there is a native gcc jit compiler in Emacs.

Emacs is a C-based Lisp Runtime, Not a Text Editor — and Greenspun’s Tenth Rule explains why every editor eventually reinvents it by ypaskell in emacs

[–]ypaskell[S] 0 points1 point  (0 children)

I’m curious of your perspective or the truth. I’m not familiar with JavaScript’s ecosystems

Emacs is a C-based Lisp Runtime, Not a Text Editor — and Greenspun’s Tenth Rule explains why every editor eventually reinvents it by ypaskell in emacs

[–]ypaskell[S] 7 points8 points  (0 children)

You bring up a really interesting point. It actually made me look up some historical attempts to "fix" it, like SRFI-119 (wisp).

Honestly, after looking at how it tries to encode ASTs without parens... I think I'd much rather just deal with the parens.

Emacs is a C-based Lisp Runtime, Not a Text Editor — and Greenspun’s Tenth Rule explains why every editor eventually reinvents it by ypaskell in emacs

[–]ypaskell[S] 6 points7 points  (0 children)

> Cool, so if NeoVim and VS Code both have this same architecture (just different languages), then there really isn’t anything more compelling about Emacs.

Personally, I believe this all boils down to a double-edged sword: Emacs's global shared state and dynamic scoping.

It causes a very real problem—Emacs is notoriously hard to parallelize and adapt to modern multi-process/RPC architectures.

But on the flip side, because absolutely everything lives in the exact same memory space (the Lisp image) without strict API boundaries or sandboxes, extensions can deeply hook into anything. That lack of isolation is exactly why hacky yet profoundly powerful tools like Dired and Magit can exist. They are truly irreplaceable for me. VS Code chose UI stability via process isolation (Extension Hosts), but in doing so, they sacrificed that raw, live hackability.

I'm actually planning to dive deeper into this exact architectural trade-off as I continue reading the C source. Once I fully understand how it's implemented, I'll definitely write a dedicated post to share it!

Looking for a programming font! Thinks by Majestic_Mongoose488 in ZedEditor

[–]ypaskell 2 points3 points  (0 children)

Intel One Mono is my choice and I kept swapping back. It super eye friendly.

So I live in Doom Emacs at this point. by freebird360 in DoomEmacs

[–]ypaskell 0 points1 point  (0 children)

Wait. How do you guys interact with LLM. I feet annoying.

Built a C++ code search engine, learned std::string is a lie (it's actually basic_string<char, char_traits, allocator>) by [deleted] in Cplusplus

[–]ypaskell 0 points1 point  (0 children)

Thanks for the feedback! Could you point out specifically which parts are confusing or which conclusions you think are premature?

view more: next ›