Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Is Not Enough

project-mage.org

Post reply on HN
Print view View original

41–50 of 163 posts

Re: Emacs Is Not Enough

#41

Post by bradrn »

avgcorrection wrote: post #35

I never cared about structural editors because the argument always seemed to be that being able to ruin the parse (going from a state where it parses to one where it doesn’t) with your editor is bad. Because I don’t care: I want the supreme flexibility of going from state A to B through some ill-formed textual editing much more than I want to be protected from ending up in a bad parse state, since syntax errors are o…

> I want the supreme flexibility of going from state A to B through some ill-formed textual editing

Seems like the author agrees with you (albeit in a different article):

> … the traditional structural editors do tend to impose some limitations … But these are not the inherent qualities of structural editing. This is just the way someone chose to implement it. So, when I say that Rune provides seamless structural editing, what I mean is that the other kind of choices are possible: the kind where you are editing as if the structure is only apparent, but not in your face, and so, it's just like there are no seams.

— https://project-mage.org/the-power-of-structure#orgeb59167

Re: Emacs Is Not Enough

#42

Post by some-mthfka »

Syntonicles wrote: post #22
throwawayoaky wrote: post #13

Earlier quoted context omitted.

Treating a document like a 2d text buffer is the root of all evil. Treating a document like a string is even worse. Emacs does both, so does everybody else. The big idea is mapping the doc to a tree of nested structures whose schemas define constraints, which constraints define the editing and viewing semantics of the parts of the tree you're looking at. Also lisp should have won the 70s and we're not done relitigati…

I understand the argument for it, but I can't make heads or tails of the implementation article discussing constraints. How do constraints help us at all? For context, I wrote a graph-based CSP-solver and I'm still completely lost. I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.

Hey, I just wrote a general reply on structure editing here in this thread, please do check it out. Also, I have added a notice in the article to skip the Fern section, as it's, indeed, probably best left for last, in case you are interested in the platform as a whole. I should have really done that before.

As for constraints and prototype OO: I think those will simply do great for GUI building, and for flexibility. I think you need such abstractions to be able to deal with customization and complexity of embedded structures. I am basing Fern on the Garnet GUI framework [1], which had ~80 projects and was pretty fun to use judging by what people say.

[1] http://www.cs.cmu.edu/~garnet/

Re: Emacs Is Not Enough

#44

Post by avgcorrection »

bradrn wrote: post #41
avgcorrection wrote: post #35

I never cared about structural editors because the argument always seemed to be that being able to ruin the parse (going from a state where it parses to one where it doesn’t) with your editor is bad. Because I don’t care: I want the supreme flexibility of going from state A to B through some ill-formed textual editing much more than I want to be protected from ending up in a bad parse state, since syntax errors are o…

> I want the supreme flexibility of going from state A to B through some ill-formed textual editing Seems like the author agrees with you (albeit in a different article): > … the traditional structural editors do tend to impose some limitations … But these are not the inherent qualities of structural editing. This is just the way someone chose to implement it. So, when I say that Rune provides seamless structural edi…

Yup. Apparently.[1] Seems that we agree that your typical structural editor is either too gimped or to inflexible to be useful. But I believe him when he writes that it is possible to make a unified language for editing all kinds of structures. I certainly wouldn’t wanna learn a new editing mode for every little yaml/json/java/rust/yaml-superset/yaml-superset-superset.

[1] But I don’t have time right now to read that main article to find out, since Firefox claims that it is a 2 hour+ read. :p

Re: Emacs Is Not Enough

#47

Post by emj »

evrimoztamur wrote: post #34
jb1991 wrote: post #26

Earlier quoted context omitted.

Well, you're right, of course. Another obvious one is that print debugging doesn't work for your GPU kernels.

Well, not every system has a framebuffer, but here's a Carmack tweet that comes to mind: "gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins." — https://mobile.twitter.com/id_aa_carmack/status/568861553245...

He also seems to like a timing/GPU/CPU debugger called PIX from MS, I'm impressed. I wish they had started with the hands on, but the presenters in this video[0] all show why print debug will never be enough. Getting back to the OP, for me even IDE integrated debugging is worse than print debugs. You need to so much data to make it useful for me, which makes things like PIX, APM and other application tracers the thing I go for during debug.

[0] https://www.youtube.com/watch?v=UH-o5cG_QWo

Re: Emacs Is Not Enough

#48

Post by sudosysgen »

taeric wrote: post #11

I can't but reflect back on another post I made today, which is that everything fails at scale. Literally everything. They just fail in different ways and made different tradeoffs along the way. For example, this is why I find myself using "print" debugging on a process of 10^4 values. It is fun to think that, "maybe I can step debug this" on that many values, but... that is well beyond my capability to keep it in my…

There are ways to debug at scale that aren't step debugging. You can set conditional breakpoints, or breakpoints that run code, or even backwards debugging. You don't have to settle with print debugging, ever. But sometimes it's faster to use it.

Re: Emacs Is Not Enough

#49

Post by evrimoztamur »

emj wrote: post #47
evrimoztamur wrote: post #34

Earlier quoted context omitted.

Well, not every system has a framebuffer, but here's a Carmack tweet that comes to mind: "gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins." — https://mobile.twitter.com/id_aa_carmack/status/568861553245...

He also seems to like a timing/GPU/CPU debugger called PIX from MS, I'm impressed. I wish they had started with the hands on, but the presenters in this video[0] all show why print debug will never be enough. Getting back to the OP, for me even IDE integrated debugging is worse than print debugs. You need to so much data to make it useful for me, which makes things like PIX, APM and other application tracers the thin…

As a side note: While using wgpu-rs to do Rust game development, I grew very fond of RenderDoc (https://renderdoc.org/).

It has great Vulkan compatibility and it helped me greatly when building an object picking buffer by visualising everything from call trees to resource contents and metadata. I believe it should come in handy for any GPU-based project, not just 3D/2D graphics.

Re: Emacs Is Not Enough

#50

Post by msla »

maydup-nem wrote: post #33
Syntonicles wrote: post #22

Earlier quoted context omitted.

I understand the argument for it, but I can't make heads or tails of the implementation article discussing constraints. How do constraints help us at all? For context, I wrote a graph-based CSP-solver and I'm still completely lost. I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.

Seems like the argument is in the "Rune" part even more down below. I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that. The point on ambiguity localization is kind of curious too. I don't think there's an argument to be had for all structures, just that you can do it for each custom structure, and that's the point. Maybe the editors of the old…

> I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that.

Emacs modes, in other words?

Like how, in Emacs, C-n nearly always does "move to next line" but it could mean "highlight next mail message" and "Enter" nearly always does something with the current line but it could mean "open currently highlighted message" or "newline and indent as per language-specific rules" or "send this line to a subprocess" or whatever.

Post reply on HN