sheremetyev

I'm running Codex/Claude in native macOS sandbox with access just to the project folder (plus read-only access to Git repo), and expand to other folders if necessary - https://github.com/sheremetyev/sandfence

Linux VM doesn't run native macOS toolchain and requires copying files back and forth

> I don't want to give it "dangerous" access to my entire mac

I'm running Claude/Codex inside native macOS sandbox, configured with a simple script - https://github.com/sheremetyev/sandfence

always in "bypass permissions" mode - it works until task is solved, sometime 1 hour or more (which includes running tests etc)

I've built multi-agent workflow on JJ workspaces - independent from specific agent. You can run Codex, Claude or anything else - https://www.visualjj.com/learn/parallel-ai-agents

You can use VisualJJ to rebase via drag & drop, split interactively etc.

https://www.visualjj.com - I'm building it and would appreciate any feedback!

JJ is great - we actually build on it! Branching uses JJ for commit-graph storage, then layers live-sync and automatic conflict resolution on top. It started life as the VisualJJ extension for VS Code and Cursor and is now available as a standalone app as well, so any editor can benefit.

Branching continuously synchronises your Git repository with GitHub and automatically resolves conflicts on rebase - removing manual pull/push, management of branches, and conflict resolution. The exact merge strategy is evolving - we are starting with deterministic "take incoming" and testing structural and AI-assisted options. The guiding principle: automate the routine merges, leave full control in developer's hands when it matters.

You are right that some situations do require careful inspection of changes to avoid "garbage". In others cases you might not care about internals if behaviour looks correct, e.g. for a prototype.

Our "progressive depth" approach in Branching aims to serve both cases - default automatic behaviour, and the option to do Git operations manually when you need to - including editing conflicts manually or with tools like Mergiraf. That way the busy path stays fast, and the careful path is still just plain Git.

by default snapshotting happens on each jj command

additionally you can enable automatic snapshots when files in the working copy are updated: https://martinvonz.github.io/jj/latest/config/#watchman

for me important argument in favour of JJ over Sapling was "first-class conflicts" - JJ stores conflicts in the history and allows you to resolve them later, while Sapling forces you to resolve conflicts at the point when they happen

https://martinvonz.github.io/jj/latest/sapling-comparison/

You are not alone :) For Microsoft Word you might find Writage plugin useful (https://www.writage.com) - supports all basic Markdown syntax, tables etc. and recently added support for math formulas.

Hey! This resonates :) My friends and I are trying to make it less hard - with a UX tailored to workflow at big tech companies (trunk-based development): https://www.trunkflow.com/ - would appreciated any feedback!

Texts is single-window, WYSIWYM (“what you see is what you mean”).

Texts (http://texts.io) is a WYSIWYM editor for Markdown.

Have a look at tests.js, another shell testing framework that works on Windows, OS X and Linux.

https://github.com/sheremetyev/tests.js

It is possible to create EPUB via pandoc (http://johnmacfarlane.net/pandoc/epub.html).

Not sure but it's probably because the .msi is not signed and the web site is relatively new.

You are right, WYSIWYM is more correct term. Formatting in the editor shows document structure and not exact rendering.

Thanks! I'll fix that. For now you could open .md files using "Open with..." in Finder.

I think it's fixable. Thanks for reporting!

I'm planning to open source most of the parsing/formatting/API code. Making everything open source would not make it sustainable. Sorry.

Thanks!

1) Tab/Shift+Tab change the level of header.

2) Yeah, it's "not implemented yet" :) Actually, there are many ways to publish from Markdown, including services like scriptogr.am. So I'm not sure that compiling PDF is the most important feature.

The idea was to make Markdown accessible for those who don't want to learn the syntax.

But switching code block style (Cmd+3 on Mac or Ctrl+3 on Windows) on and off maintains inline syntax. So you can type raw Markdown into a code block and then switch it into plain text paragraph with formatting.

Yes, most likely after releasing Windows and Mac versions. May be after a version for iPad. It depends on the feedback.

Thanks! Do you mean that menu options like "View as HTML", "View as PDF" etc. should process the current file with pandoc and display the resulting file?