treeblah

Claims about “what comes after git” aside, I really like the idea of virtual branches. Worktrees have a pitfall IMO that they don’t allow you to test changes in a running local env, meaning I need to commit the changes, close the worktree, and checkout the branch on my primary workspace to verify.

Gitbutler virtual branches OTOH appear to provide branch independence for agents/commits, while simultaneously allowing me to locally verify all branches together in a single local env. This seems quite a bit nicer than checking out worktree branches in the primary workspace for verification, or trying to re-run local setup in each worktree.

https://mgmarlow.com

I had a near identical approach for my blog but I recently moved to a headless CMS. The bugbear being that it wasn't easy to publish if I wasn't at my desktop. With a headless CMS, I auth through Github via my phone, which also serves as the draft/publish step since posts in the CMS manifest as pull requests. It's been working great so far, with the caveat that the writing experience isn't as nice as Obsidian.

FWIW the CMS is Decap CMS and I have it configured likewise with Cloudflare Pages (since Pages supports functions that are needed for the auth/callback cycle).

Emacs 29 made getting started a lot easier IMO, my from-scratch configuration is pretty minimal and I use it everyday. To plug my own project, I built a "kickstart" equivalent (https://github.com/mgmarlow/start-emacs) that sets up some recommended defaults and packages with lots of comments so you can easily extend it.

I don't think so. I just think right now Vercel is very good at marketing and lots of new programmers and hopping on the NextJS train. There are tons of materials out there for building apps quickly and it's very appealing for newer developers, particularly the bits where getting a site deployed is as easy as running a couple commands w/ the Vercel CLI.

For larger applications, I don't see meta-frameworks eating up a significant chunk of the world since they're very expensive to run in certain situations. Especially so if you use the default deployment options and rely entirely on serverless functions for your infrastructure or a database-as-a-service like Firebase/Supabase. I think it's inevitable that people will carve bits and pieces off of their meta-frameworks into different types of applications as they scale, just in the same way that people carve up their Rails applications of yore.

I generally think that the meta-framework obsession will also help propel backend SSR + HTMX, since thinking in server-side components is easier to translate to traditional backend SSR than SPA -> backend.

I found this snippet in one of Mickey's earlier tree-sitter posts that works great. It does require searching through the tree-sitter repo to make sure your paths are correct:

  (setq treesit-language-source-alist
      '((typescript "https://github.com/tree-sitter/tree-sitter-typescript" "master" "typescript/src")
        (tsx "https://github.com/tree-sitter/tree-sitter-typescript" "master" "tsx/src")))

  (mapc #'treesit-install-language-grammar (mapcar #'car treesit-language-source-alist))

Hm, what's your `(emacs-version)`? `package-vc-install' is only available in Emacs 29+.

Really happy to see this. I've been using Emacs 29+ for the past while and have enjoyed simplifying my configuration now that use-package is OOTB. I think now is a really excellent time to try Emacs if you haven't already.

I put together a simple tool to generate a starter Emacs config from a few configurable options, which I can now update to point at a proper release channel instead of a prerelease:

https://emacs-config-generator.fly.dev/

https://mgmarlow.com

Tons of Emacs posts recently since that's been top of mind for the last six months.

Grammarly posted an article a couple years ago about using Common Lisp: https://www.grammarly.com/blog/engineering/running-lisp-in-p...

I use web-mode + typescript-language-server for React+TSX. Whether or not you choose to use eglot or lsp-mode, I'd still recommend following the lsp-mode performance guide: https://emacs-lsp.github.io/lsp-mode/page/performance/. Those tips are useful for all setups.

  (use-package web-mode
    :ensure t
    :mode (("\\.ts\\'" . web-mode)
           ("\\.js\\'" . web-mode)
           ("\\.mjs\\'" . web-mode)
           ("\\.tsx\\'" . web-mode)
           ("\\.jsx\\'" . web-mode))
    :config
    (setq web-mode-content-types-alist
   '(("jsx" . "\\.js[x]?\\'"))))

  (use-package eglot
    :ensure t
    :hook (web-mode . eglot-ensure))

For me its been the questionable stewardship of vscode (https://github.com/omnisharp/omnisharp-vscode/issues/5276) driving me away from vscode and the Emacs from Scratch videos from the System Crafters youtube channel driving me towards Emacs. When I was looking for alternatives I stumbled on those videos and they blew me away.

Also Emacs 28/29 has been way more welcoming and easy to get started with than when I first tried 8 or so years ago.

As far as out-of-the-box support, I think it works great. Much easier to configure than lsp-mode.

However, for my uses with a Ruby/React+TSX setup the performance was lacking on a large codebase. I swapped back to lsp-mode and the experience felt smoother.

IIRC the author's stance on previous discussions around multiple language servers was to rely on flymake instead, since the previous discussion centered around ESLint + TypeScript. Tailwind is a bit of an issue in the ecosystem right now, but you may want to try https://github.com/merrickluo/lsp-tailwindcss.

There's no direct PDF, you have to build it yourself w/ TeX by cloning the repo:

  git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
  cd c-intro-and-ref/
  make c.pdf