Observations on Live Editing

I wanted to share some observations and pain points around the current state of live editing in query results, linked mentions, and other renderings. I’m coming from Logseq and as another poster says, live editing is an extremely useful part of one’s PKM workflow.

What Works Today (in a limited way)

There is a very rudimentary step toward live editing:
When a query renders task items, the checkbox is linked via an anchor to the original task line. Toggling the checkbox correctly updates the source task. This is a good start.

Limitations

  1. Anchors break on document edits
    If a query is rendered and then the underlying document changes (e.g. inserting a line above a task or moving content), the anchor can become invalid.
    The UI still makes it appear as though the checkbox interaction worked, but it silently fails because the anchor no longer points to the correct line.

  2. No true live editing of rendered results
    A very common workflow for me (and I suspect, others) is:

    • Render a list of tasks via a query
    • Relatively prioritize them (e.g. add or adjust a prio attribute)
    • And/or relatively change their scheduled/deadlines

    In Logseq, this is trivial because the rendered task is fully editable in place.

    In SilverBullet, the flow is:

    • Click the anchor
    • Navigate to the original task line → this results in a mental context shift
    • Edit the priority
    • Navigate back to the query result → one more mental context shift
    • Manually refresh the page

    Until refresh, the query results are stale — and it’s easy to forget this step. Also, the mental context shifts can break one’s workflow.

To summarize, live editing can be a very helpful feature in a PKM, and given @zef is one person and his time is limited, I’m wondering if:

  • there are fundamental limitations in the architecture or stack that would make this a challenge now or in the future
  • if there are other (baby) steps that can be taken towards live editing
  • if @zef is open to contributors helping with these steps
1 Like

Instead of rendering the default table, you could construct one yourself using widgets. If you add, say, a drop-down to set priority (or perhaps make the widget support drag and drop even) you could handle it setting the attributes in Lua, and then refresh the widget.

Could be a bit of work, and not very generalizable, but could at least be done once and then distributed via a library.

2 Likes

Thank you @thepaperpilot, great ideas in terms of bringing a livr edit feel to a specific case, and a bunch of these might bridge the gap for folks’ most common workflows. I’ll keep this in mind, this might even help me make the jump to SB possibly.

On an alternate approach, I’m wondering if live edit could be Incorporated in a much more fundamental way. So the rendering is the same as the original line, and there are no restrictions. Logseq and a few others offer this. I’m not familiar enough with a text tag to evaluate this.

1 Like