You are viewing archived messages.
Go here to search the history.

Kartik Agaram 2024-07-11 01:07:01

I've been slowly reading "The Nature of Order" by Christopher Alexander and slowly thinking about how to make my editor for text and line drawings more timeless. (And mostly sleeping a lot, if I'm honest.) Today the combination of the two led me to draw this shape for the line-wrapping algorithm.

Until now I've been developing the editor the "usual" way, which for me consists of needing some computation, figuring out the most convenient place to perform the computation, then squirreling away the result somewhere it's available when needed. In an effort to get myself out of the rut of the inevitable problems of indirection and cache invalidation that result, I've been trying to replace all my ad hoc data structures with on-demand computation based on the base state of the program. And what I've been ending up with is umpteen variations of this pictured algorithm, just with different code stuck on to the protrusions.

There may be an abstraction that comes out of all this, but I don't see it yet. And as CA says, a flower isn't made up of identical petals. Each one evolves uniquely as a part of the whole.

20240710_175623.jpg

Kartik Agaram 2024-07-11 01:15:43

Here's the Lua code skeleton corresponding to that drawing. The ellipses are the protrusions:

for line_index, line in array.each(State.lines, State.screen_top.line) do

    if line.mode == 'text' then

        local initpos = 1

        if line_index == State.screen_top.line then

            -- top screen line

            initpos = State.screen_top.pos

        end

        for pos, char in utf8chars(line.data, initpos) do

            if char:match('%s') then

                if line_wrap_at_word_boundary(State) then

                    ...

                else

                    ...

                end

            else

                if x+w > State.right then

                    ...

                else

                    ...

                end

            end

        end

    else  -- drawing

        ...

    end

end
Tom Lieber 2024-07-11 02:00:56

That shape doesn’t mean anything to me yet, but I love that it means something to you and that if we were to talk about it, it would probably become a useful artifact for us both to refer to as we forget the details…

I think there’s potential for semantics to be layered onto a diagram like that, in a way that can be maintained as the design evolves. It reminds me of tinlizzie.org/dbjr/high_contrast.html

Kartik Agaram 2024-07-12 02:17:22

Quick and dirty prototype of the above algo/shape/code using Vim syntax highlighting.

The code in the screenshot is a function to convert a mouse click (mx, my) into the location (line_index, pos) of the character at that point on the screen.

The problem is much of this function is boilerplate shared with several other places, such as the code to draw text on screen, compute the height of a wrapped line, etc. The boilerplate makes it difficult to see the business logic unique to this particular function, and so creates pressure to prematurely create an abstraction to "DRY things out". Highlighting the shape of the boilerplate in pink helps the eye to focus to the unique business logic in the protrusions, and so counters the pressure to hide the boilerplate before I've figured out the best way to do so.

linewrap-vim.png

Kartik Agaram 2024-07-12 02:20:48

As an aside, this is an example of what I think of as "programmer-configured highlighting". We've gotten used to our editors deciding what to highlight for us, and we just pick the colors. One little tool I use everyday is the ability to highlight specific identifiers which flips this around: I pick a word, and the editor picks a color at random to highlight it with. And the highlight persists across sessions. The color of the State variable in the screenshot was selected in this manner.

Eli Mellen 2024-07-12 03:15:28

I love this!

Maikel van de Lisdonk 2024-07-14 14:04:41

Some updates on my visual programming project codeflowcanvas this week: In this video youtu.be/U8SB2hXBKs0 I show some work I did for the open-canvas working group (ocwg for short): if you go to demo.codeflowcanvas.io/ocwg you can see a window floating in the bottom right, this shows the current flow in the current ocwg draft spec.

I've build the export mechanism using a strategy pattern so that I can also easily support other formats if needed (a basic export to tldraw is already one of them). I hope this helps in developing the new open canvas spec that the ocwg is working on via bi-weekly meetings and a github repo (see various links on canvasprotocol.org).

Lately I am focussing more on embedding and/or integrating codeflowcanvas with other tools and technologies so that it is not running in a silo of its own, and this feature helps with that I think.

This week I also send in a submission to liveprog.org.

🎥 exporting from codeflowcanvas to open-canvas draft spec

exporting from codeflowcanvas to open-canvas draft spec

📝 Open Canvas Working Group | OCWG

Working group for establishing interoperability between different infinite canvas tools.