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?

Yes, please!

Thanks! UI is based on WebKit. Pandoc's license is GPL so I don't think I'll be embedding it.

As for Markdown parts – Texts 0.3 supports only blocks of plain text, headers (setext), unordered lists, code and math blocks (pandoc extension) and intervals of bold, italic, code, math and links. Only simple links (<URL>) are supported for now.

The idea is to expand syntax gradually, focusing on simplicity of user interaction. There are too many flavours of Markdown out there and several ways of writing the same structure in Gruber's Markdown is not a good thing, IMHO. There is no real need to decide between _italic_ and italic.

The object model of the text that is implemented is as simple as possible: blocks and spans (without nested spans). It shouldn't be a problem to implement essential parts of AsciiDoc and other plain text markups. When these formats get into the product depends on the interest from users. I'm planning to expose an API to allow implementation of formats as plugins.

It's an early prototype. Please let me know what you think about the approach. Thanks!

It would be interesting to have some feedback from startups as well. Have they got many hires from the first fair? What kind of hires?

My intuition is that, on one hand, most graduates do not meet expectations of startups. A startup needs exceptional people to push technology forward. On the other hand, startups presented at the fair do not meet expectations of potential employees. They are not "cool enough". (I registered for the event in May but after looking at the list of companies decided that it was not worth trouble going from Oxford to London.)