tony

I made a tmux source reference, doxygen-inspired. It links C symbols to CLI commands, options, hooks, formats and libtmux APIs (including alpha ports to new languages like TypeScript, Rust, Go).

Disclaimer: I used LLMs extensively to build this. I have intersection with building documentation systems and tmux. Also, I didn't create tmux itself, just a wrapper called libtmux and session manager for it.

tmux is created by Nicholas Marriott, its official site is at https://github.com/tmux/tmux. I and others are very thankful to be able to use his program daily, and that it's still being well-maintained!

P.S. there are PRs for introducing Sixel / Kitty-based terminal graphics in the pipe: https://github.com/tmux/tmux/pull/5445#issuecomment-61802179.... Very big stuff on the way. https://github.com/tmux/tmux/issues/5406

Location: RGV, TX, USA (US citizen) Remote: Yes

Willing to relocate: No

Technologies: Python, TypeScript, React, AWS, Sentry, Terraform, GraphQL, Flask, Django, py.test, ruff, uv, biome, vite, vitest, asyncio

Résumé/CV: https://tony.cv (PDF: https://tony.cv/cv.pdf)

Email: tony [at] git-pull [dot] com

Hi, I'm Tony — a senior software engineer (2× YC companies, 2 acquihires).

I'm the open-source author of `tmuxp` and `libtmux`, both packaged across major Linux distros, FreeBSD, and Homebrew.

I work well on teams of any size and prefer startups using Python.

Available for roles aligned to U.S. or E.U. time zones.

Location: RGV, TX, USA (US citizen)

Remote: Yes

Willing to relocate: No

Technologies: Python, TypeScript, React, AWS, Sentry, Terraform, GraphQL, py.test, ruff, uv, biome, vite, vitest, asyncio

Résumé/CV: https://tony.cv (PDF: https://tony.cv/cv.pdf)

Email: tony [at] git-pull [dot] com

Hi, I'm Tony, a Senior+ engineer — 2× YC, 2 acquihires. OSS creator and maintainer of tmuxp/libtmux (packaged in major Linux distros, FreeBSD, Homebrew).

Location: RGV, TX, USA (US citizen)

Remote: Yes

Willing to relocate: No

Technologies: Python, TypeScript, React, AWS, Datadog, Sentry, LLMs (ChatGPT/Claude/Gemini)

Résumé/CV: https://tony.cv (PDF: https://tony.cv/cv.pdf)

Email: tony [at] git-pull [dot] com

Senior+ engineer — 2× YC, 2 acquihires. OSS maintainer of tmuxp/libtmux (packaged in major Linux distros, FreeBSD, Homebrew). Interested in AI/product work.

Location: RGV, Texas, USA (US Citizen)

Remote: Yes

Willing to Relocate: No

Technologies: Python, TypeScript, AWS, Datadog, Sentry, React, AI LLMs (ChatGPT, Claude, Gemini)

Résumé/CV: https://tony.cv, https://tony.cv/cv.pdf

Email: tony [at] git-pull [dot] com

Interested in AI oppurtunities, shoot me an email and let's say hi! Mission-oriented, senior+ software engineer. Veteran of 2 YC startups, 2 acquihires.

I've contributed to over 100 open source projects. Find my packages tmuxp and libtmux in major Linux distros, FreeBSD, and brew.

Chris Lattner also has a very good episode on Lex Fridman (Episode 381, June 2nd, 2023):

- https://www.youtube.com/watch?v=pdJQ8iVTwj8

- https://open.spotify.com/episode/6flH0XxwdIbayoXTHOgAfI

- https://podcasts.apple.com/us/podcast/381-chris-lattner-futu...

He has two other episodes on the show:

- https://www.youtube.com/watch?v=nWTvXbQHwWs (Episode 131, October 18th, 2020)

- https://www.youtube.com/watch?v=yCd3CzGSte8 (Episode 21, May 13th, 2019)

Location: RGV, Texas, USA (US Citizen)

Remote: Yes

Willing to Relocate: No

Technologies: Python, TypeScript, Any

Résumé/CV: https://tony.cv

Email: <hn_username> @ git-pull.com

Mission-oriented, accomplished software engineer. Veteran of 2 YC startups, 2 acquihires.

I've contributed to over 100 open source projects. Find my software packaged in major Linux distros, FreeBSD, and brew.

Look, at the end of the day, folks might initially give a `.so` or `.sh` the side-eye, questioning its credibility. But if you nail your branding and put real effort into building your reputation, that perception quickly fades away. Once people trust you and your offering, nobody’s going to care about the TLD - just look at Notion.so: everyone links to them, uses them internally, and doesn't bat an eye. In fact, they eventually upgraded to .com - so that door always remains open.

Remember, with any new domain, you're starting from zero anyway; you'll have to build trust from scratch, whether it's a fancy `.com` or a `.so`. Going with something like `.so` or `.sh` just means more choices when the usual suspects are already taken.

Keep files <1000 lines. If you can.

Keep chats <30 minutes, ideally 20-minute continuous segments.

Use a `notes/TODO.md` file to main a checklist of objectives between chats. You can have claude update it.

Commit to version control often, for code you supervised that _does_ look good. Squash later.

This glitch often begins to happen around the time you'd be seeing "Start a new chat for better results - New chat" on the bottom right.

If you don't supervise, you will get snagged, and if you miss it and continue, it'll continue writing code under the assumption the deletion was fine: potentially losing the very coverage you'd hope to have gained.

If it does happen, try to scroll up to the chat before it happened and "Restore checkpoint"

claude-3.7-sonnet-thinking, Cursor 1.96.2

   Location: Rio Grande Valley, TX
   Remote: Yes
   Willing to relocate: No
   Technologies: Python and TypeScript
   Résumé/CV: https://tony.cv
   Email: <hn_username> at git-pull.com

Experienced IC (Python backend/TypeScript frontend). Active open source contributor—always happy to network over coffee.

Good article. This was 2015 (!)

A few years later, I released The Tao of tmux, available for free online: https://leanpub.com/the-tao-of-tmux/read.

Random: this is a lean, cross-platform program I've used in the status line for ages: https://github.com/thewtex/tmux-mem-cpu-load

tmux has been getting steady updates throughout the years: https://github.com/tmux/tmux/blob/master/CHANGES.

It's nice to see a program that does one thing well and gets such quality attention.

> I can‘t summarize it better right now. I have learned the portuguese word „saudade“. That feeling, i believe i know. It seems somehow related, to what I am trying to describe.

I've found "theories of personality" textbooks to be delightful in expanding repertoire to describe feelings better. One of note I found is An Introduction to Theories of Personality by Robert B Ewen.

I found it to be beginner friendly and showcase a variety of competing theories in a very objective and proportional way, without pushing a conclusion onto the reader, it just laid out their strengths and let me make up my mind.

If you're open to reading I have more resources on personality theories.

I've done this during COVID. Zoom groups. I want to share my experience:

Participants in the zoom crowd are great folks.

Occasionally, these zoom events could get amped up on internet banter - this could disappoint the original poster's goal of broadening their horizons.

The zooms aren't a random sampling of a professional or academic field. I'll leave it at that.

Also, if we're there, we're also part of that statistic: we needed the internet to socialize - which is OK - but that puts us with other people who were also frustrated in real life and needed to go online to connect with others.

These sessions had highly talented presenters from around the world. Despite that, they often weren't places where everyone gets work gets done - which may surprise people used to Gitlab/GitHub/etc and doing open source. If you want to chat, OK - if you like to accomplish things, nothing happens. This really was what struck me the most.

I haven't used pydantic yet. I'm conservative when adding (non-dev) dependencies since I am maintaining library packages. For other projects, it's a possibility.

> if I mark a field as an int, and pass in a str, I want an error -- is that weird of me

That is perfectly fine. And the question is why don't TypedDict, NamedTuple, dataclass raise during construction - since if they don't - we have to play it safe and do isinstance checking since we can't trust the field's types at runtime.

I suppose the idea the `typing` module [1] is to be unobtrusive: not to be involved in runtime checks.

What I want is something that does what pydantic does in standard library. I think it's a sensible request and would be indispensable for anyone wrangling data.

[1] https://docs.python.org/3/library/typing.html

Painpoint with type annotations: not being able to reuse "shapes" of data, e.g. struct-like fields such as TypedDict, NamedTuple, dataclasses.dataclass, and soon *kwargs (PEP 692 [1]) via TypedDict.

Right now, there isn't a way to load up a JSON / YAML / TOML into a dictionary, upcast it via a `TypedGuard`, and pass it into a TypedDict / NamedTuple / dataclass.

dataclasses.asdict() or dataclasses.astuple() return naïve / untyped tuples and dicts. Also the factory functions will not work with TypedDict or NamedTuple, respectively, even if you duplicate the fields by hand [2].

Standard library doesn't have runtime validation (e.g. pydantic [3]). If I make a typed NamedTuple/TypedDict/dataclass with `apples: int`, nothing is raised in runtime when a string is passed.

Other issues you may run into using mypy:

- pytest fixtures are hard. It's repetitious needing to re-annotate them every test.

- Django is hard. PEP 681 [4] may not be a saving grace either [5]. Projects like django-stubs don't give you completions, it'd be a dream to see reverse relations in django models.

- Some projects out there have very odd packaging and metaprogramming that make typing and completions impossible: faker, FactoryBoy.

[1] https://peps.python.org/pep-0692/ [2] https://github.com/python/typeshed/issues/8580 [3] https://github.com/pydantic/pydantic [4] https://peps.python.org/pep-0681/ [5] https://github.com/microsoft/pyright/blob/8a1932b/specs/data...

I am moving all my open source projects to `mypy --strict`. Here's the diff of adding basic / --strict mypy types:

libvcs: https://github.com/vcs-python/libvcs/pull/362/files, https://github.com/vcs-python/libvcs/pull/390/files

libtmux: https://github.com/tmux-python/libtmux/pull/382/files, https://github.com/tmux-python/libtmux/pull/383/files

unihan-etl: https://github.com/cihai/unihan-etl/pull/255/files, https://github.com/cihai/unihan-etl/pull/257/files

Perks:

- code completions (through annotating)

- typings can be used downstream (since the above are all now typed python libraries)

- maintainability, bug finding + Easy to wire into CI and run locally

Longterm, unsure of the return on investment. I do promise to report back if I find it's not worth the effort.

How does carbon have any intersection with Google Chrome / Chromium development? Some earlier posts:

- https://chromium.googlesource.com/chromium/src/+/refs/heads/...

- https://security.googleblog.com/2021/09/an-update-on-memory-...

Would carbon be a variation of "making C++ safer" mentioned in that blog post?

Appreciated these examples, thank you!

Delighted to see the developers at AWS incorporating react w/ TypeScript.

I hope this project stays active and the framework keeps a low overhead: I've spent some time ripping out chakra-ui from my sites due to its complexity making it hard to diagnose styling bugs between styled-system, emotion, etc. Mix that with a monorepo of UX components where packages depend on each other, and them being prebuilt. I could never find out why certain style rules wouldn't apply.

It looks like this project has an interesting thing: style-dictionary (https://github.com/cloudscape-design/components/tree/7433543...)

I'd be interested in reading a dev blog post on the architectural decisions (and lessons learned). Is there any decisions from other major UI frameworks that were trying to be avoided?

One more thing I've never seen before in a framework's documentation: Patterns (very practical and case-specific examples), https://cloudscape.design/patterns/patterns/overview/

Good job to the AWS team on this, will be studying it!

> responsible for taking Go Language, Docker and MongoDB from niche technologies to widespread mainstream enterprise adoption.

In terms of proliferating Go I think that statement is fair. spf13 is like brand name in open source.

I recall years back on GitHub, spf13 was like a name you were guaranteed to come across if you were sinking your teeth into Go. I ended up using cast / viper: https://github.com/tony/vcsync/commit/a76681b. (Not that I'm anything special at golang)

I contribute to open source projects as well - in various capacities - and it's fine for a maintainer of a huge project to use that wording.

He pushed hugo and viper in 2013-2014: https://github.com/gohugoio/hugo/commits/v0.7, viper: https://github.com/spf13/viper/commit/98be071

Steve is a very accomplished programmer, with what hugo / viper became in the go ecosystem by itself. In my view, the projects also jumpstarted a lot of new users who were trying out golang who weren't sold on it yet. I didn't really notice his leadership or advisory roles until now, that's just icing on the cake.

Thanks for your contributions, Steve!

Edit: If it's really big ecosystem, _indirect_ contributions also matter. e.g. in python, even if you're not writing CPython patches or PEPs, community based projects do a lot to shape best practices and even bubble up into standard library.

Good that you are on HN now and thanks for this message.

I ended up fetching git 2.37 (from whatever the default Ubuntu impish is at, I believe 2.32)

(I don't know any benchmarking tools for `git(1)`, if your or anyone else does I'm all ears).

I opened up `tig(1)` and `gitui(1)` in a large repo, stuff feels snappier. It could be a placebo. When trying to track where it could be coming from, I have trouble pinning it down:

- 2.33.0: https://github.com/git/git/blob/v2.33.0/Documentation/RelNot...

- 2.34.0: https://github.com/git/git/blob/v2.34.0/Documentation/RelNot...

- 2.35.0: https://github.com/git/git/blob/v2.35.0/Documentation/RelNot...

- 2.36.0: https://github.com/git/git/blob/v2.36.0/Documentation/RelNot...

- 2.37.0: https://github.com/git/git/blob/v2.37.0/Documentation/RelNot...

This is a VCS that's getting a lot of care given to it.

Nice, thanks for linking this

Wow. I wasn't expecting anything like a filesystem monitor in git(1) itself.

They post says Jeff Hostetler, the author of the patches, will make a blog post delving into it. So it's worth bookmarking that post and swinging back. It's bound to be an interesting one!

Apparently git 2.16 had a fsmonitor hook for external filewatcher like watchman (it got passed me): https://github.com/git/git/commit/def4376711f607914bfb784f8d...

This kind of change needs to be tailored to the platform, it says just Mac (FSEvents?) and Windows (ReadDirectoryChangesW?) for now. So can we expect Linux (inotify?) and BSD (kqueue*) in the future?

Anyway, I hope this venture is fruitful. The premise of having cross-platform file watching without needing an extra application is delightful.

Thank you Jeff!

* I believe one area that may be tricky is kqueue, I believe it has limits in watching directories, needing a file descriptor for each file.

P.S. I would like to drop a link to entr(1), a lightweight cross platform file watcher: https://eradman.com/entrproject/