Skip to content

Block-based editing: selection, drag-and-drop, and actions menu - #11

Closed
jondkinney wants to merge 10 commits into
mainfrom
block-based-editing
Closed

Block-based editing: selection, drag-and-drop, and actions menu#11
jondkinney wants to merge 10 commits into
mainfrom
block-based-editing

Conversation

@jondkinney

Copy link
Copy Markdown
Member

Summary

  • Block selection via drag handle click or Cmd+click
  • Drag and drop with depth-aware drop indicators
  • Block actions menu (Cmd+/) with duplicate, delete, turn-into
  • Tab/Shift+Tab indent/outdent in block-select mode
  • Keyboard block movement (Cmd+Shift+Arrow)
  • Highlight color inheritance for block-mode operations
  • Turn-into for wrapped blocks in block-select mode

Note: This PR contains the full headwayio-customizations branch diff, including all standalone features (PRs #4-#10). Once those are refined and merged individually, this PR should be rebased to contain only the block-editing-specific changes.

Test plan

  • Click drag handle — block selected with highlight
  • Drag block to new position — drops correctly
  • Cmd+/ opens block actions menu
  • Cmd+D duplicates block
  • Tab indents selected block, Shift+Tab outdents
  • Cmd+Shift+Arrow moves block up/down
  • Highlight color cascades to children on indent/move/drop

🤖 Generated with Claude Code

@jondkinney
jondkinney force-pushed the block-based-editing branch from 00f51ac to 0e7bceb Compare March 27, 2026 20:24
Full headwayio-customizations branch including all standalone features.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@jondkinney
jondkinney force-pushed the block-based-editing branch from 0e7bceb to a610857 Compare March 27, 2026 20:32
jondkinney and others added 9 commits March 27, 2026 16:30
Fixes gem build failure: yarn install --frozen-lockfile rejects the
stale lockfile when building Lexxy from a git source in Gemfile.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Render uses Yarn Classic (v1) globally but the repo's yarn.lock is in
Yarn Berry (v4) format. Classic can't read the Berry lockfile and fails
with --frozen-lockfile. Dropping the flag lets the build succeed
regardless of which Yarn version is installed.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bundler on hosts with Yarn 1 (e.g. Render) cannot build from source
because the repo uses Yarn 4 (Berry). Committing the built assets
lets the ext/Rakefile skip the build step entirely.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The previous yarn.lock update was run with Yarn 4 (Berry) which
silently rewrote the lockfile from v1 to v8 format. Render has
Yarn 1 installed and cannot parse the v4 format. Restore the
original Yarn 1 lockfile from headwayio-customizations.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This repo uses Yarn 1 (Classic). The .yarnrc.yml with
nodeLinker: node-modules is a Yarn 4/Berry config that causes
Yarn 4 to silently rewrite the lockfile when run locally.
Removing it prevents accidental lockfile format upgrades.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
With the Yarn 1 lockfile restored and .yarnrc.yml removed, the
ext/Rakefile build step works correctly on hosts with Yarn 1.
No need to commit 1.1MB of generated JS.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Corepack on GitHub Actions and other hosts auto-downloads the latest
Yarn (v4) which cannot read Yarn 1 lockfiles. Adding packageManager
field tells Corepack to use Yarn 1.22.22.

Pre-built assets are also committed so the ext/Rakefile skips the
yarn build step entirely — no dependency on Yarn being installed at all.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The packageManager field in package.json pins Corepack to Yarn 1.22.22,
so yarn install + yarn build works correctly on all hosts. No need to
commit build artifacts — the ext/Rakefile builds from source when the
assets don't exist.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
WebKit/Safari does not support requestIdleCallback. Optional chaining
(requestIdleCallback?.()) does not prevent the ReferenceError because
it only guards property access on objects, not undeclared variables.
Use typeof check instead.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@jondkinney

Copy link
Copy Markdown
Member Author

Closing in favor of #12

@jondkinney jondkinney closed this Mar 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant