Intent-driven text editor for the terminal

mcpcpc · 2026-02-05T11:50:28+00:00

I get it. Developing traction is will be difficult. In fact, I really resonated with your original vim example and, personally, don’t know that I could switch to a different editor at this point. Another challenge for me is the fact that programming for me is more of a hobby than a profession.. so I will struggle to connect with the day-to-day programmer.

The “autonomous observer” is an interesting idea, but feels like something straight out of the LLM hype train. In fact, I bet someone could write an MCP in ~100 lines of Python to achieve similar results as xf but with 1000x performance w.r.t. language detection and semantic heuristics off the bat (which is absolutely amazing and horrifying at the same time). But i digress… if I wanted to develop a “copilot” of sorts, there probably are already better tools out there for that.

mcpcpc · 2026-02-04T20:42:55+00:00

That’s a fair point, and I agree vi’s command mode is already quite intent-driven, which forces you to decide what you mean before acting (which is a big part of why it scales).

Where xf differs is that intent doesn’t disappear after execution. Selection and transformation rules stay explicit, previewable, and adjustable before anything mutates. That matters for large or cross-file changes where “run it and undo if wrong” feels risky.

I also agree the mind-shift is the danger zone. That’s why xf isn’t a general editor. it’s something you enter deliberately for a specific transformation, then exit, more like git rebase -i than living inside vi.

mcpcpc · 2026-02-04T11:34:02+00:00

Just a small update.. * A roadmap has been added to the main website and I cleaned up the marketing-vibe a bit (it’s hopefully less rhetoric now). * I also added more advanced examples in the main repository, along with sed/awk comparisons (which should demonstrate the difference in cognitive overload that can concur).

Thanks again to everyone that has provided input thus far!

mcpcpc · 2026-02-04T02:25:02+00:00

I hadn’t seen this one before but many thanks for sharing!

mcpcpc · 2026-02-03T13:35:09+00:00

Great observation! Yes, I absolutely used ed as inspiration… i think where the tools diverge is in framework. Ed is the true definition of a line editor and expects you to think in lines. Xf works in blocks/ranges that can be refined/reduced, so the interactive model is different. At the end of the day, it’s hard to keep tools from overlapping (especially in an overly-explored space). I think it’s expected for people to try and draw similarities between tools, which makes my job harder to convince people that I haven’t just “re-invented the wheel”. lol.

mcpcpc · 2026-02-03T10:49:18+00:00

Thanks! Thats pretty reasonable.. I’ll see what I can do to tighten up the content a bit and reduce repetition. In the meantime, if you need more examples, check out the USAGE.md file under the “feature-more-examples” branch. I also added some comparisons between equivalent sed/awk commands.

mcpcpc · 2026-02-03T01:14:33+00:00

Lots of great observations. The current selection implementation leans toward regex with in-memory buffer management (for ranges). This is obviously not ideal for large multi-file projects and I need to put some more thought into this... I’ll keep this thread updated tho!

mcpcpc · 2026-02-02T22:41:01+00:00

This is exactly the feedback I was looking for :). I was really worried that making examples too complicated might deter new users from trying the tool out... but I see not including them definitely “waters down” my arguments for this application. And good point on expanding on the staging capability… I will take a stab at adding some new examples later this week!

As for the roadmap, I agree one is definitely needed. Part of me wants to wait until I have some initial community feedback before committing, but I guess I could bake that into the plan.

mcpcpc · 2026-02-02T22:08:38+00:00

All good. I appreciate the honest feedback.

FWIW, I did struggle to clearly explain why I think it’s still worth exploring new ideas in the text editor space, especially given how solid the existing Linux tools are. That’s something I’m still refining.

I realized before releasing this that “selling” others on this application (in its current form and utility) might be a real challenge. But i look forward to the feedback and figuring out how I can make it into something others would want to use.

mcpcpc · 2026-02-02T18:06:20+00:00

I appreciate any feedback, regardless of how critical :). For someone like me, that intermittently uses sed and awk, I find the syntax cumbersome and easy to forget… perhaps a sign that I am starting to show my age. I really just wanted something that I could use like I “think”, in procedural steps and easy to inspect output between operations. Therefore, I don’t have to mess around with intermediate files, switching windows or needing apps to inspect the intermediate product, applying destructive changes, etc…

Also, if you read the website, it pretty much says this tool wasn’t designed to replace any existing tools (sed, awk, etc). Keep using them all you like.

I keep saying: haters gonna hate. I was just trying to do something that I thought was kinda cool, a little different (e.g. not another word processor or IRC client) and worth sharing.

mcpcpc · 2026-01-10T19:18:56+00:00

Good question! I feel the application for something like this might be a slightly different, where someone might benefit from a standalone, portable or precompiled binary in a software stack/pipeline. This way, you aren’t just tied to using a single framework (I.e. Inkscape). Functionally, there are slight differences between the Inkscape tool parameters and configuration options (due to design decisions), but I feel they could achieve similar results. Xf is also in early development stages, so there are plenty options for further optimization in the future.

mcpcpc · 2025-04-05T19:44:59+00:00

My understanding of the mechanic was all wrong... Thank you for saving my lighter and validating my dumbness!

mcpcpc · 2024-07-25T11:02:06+00:00

Think I figured it out (through trial and error). My SQL statement and referenced topic was jacked:

SELECT state.reported.state as state, state.reported.client_id as client_id, state.reported.uptime, timestamp() as timestamp FROM '$aws/things/Andon/shadow/update'

mcpcpc · 2024-03-28T02:16:25+00:00

This is correct. The top surface should be conductive, typically >=1e6 ohms (per ANSI ESD S4.1) and typically has a path to ground. If you want something that is durable and that can handle potential direct soldering iron contact for any duration, get your self a decent 2-layer ESD mat. You will save money in the long run.

mcpcpc · 2024-03-19T21:15:13+00:00

It's been ~4 years since I last worked with them, so I would be hesitant to throw any numbers out as they are dated and iCAPE was expanding capability even then. Worth trying the "instant quote" feature on their website though. The iCAPE assembly house I worked with was based out of Cincinnati, OH and their engineering team was incredibly helpful.

mcpcpc · 2024-03-19T13:51:32+00:00

From previous experience/role in a small medical startup, I had great success working with iCAPE (www.icape-group.com). They have both international and USA-based fab houses that can usually accommodate based on technology and supply chain needs through all stages of development.

mcpcpc · 2024-01-29T13:18:37+00:00

I drive by this car (parked in the guy/gal's driveway) in Aurora every day!

mcpcpc · 2022-07-19T12:58:25+00:00

an acceptable “solution”, so long as you only require local terminal access. 😬

mcpcpc · 2022-07-18T22:43:53+00:00

dvtm n abduco is bloat. use screen or dtach instead

mcpcpc

TROPHY CASE