Show HN: ASCII Tree Editor
26 points
18 hours ago
| 5 comments
| asciitree.reorx.com
| HN
Show HN: ASCII Tree Editor

I've created a web-based editor for ASCII file directory trees called asciitreeman. It's designed to make it easier to edit and reorganize the output of the tree command.

You can try it out here: https://reorx.github.io/asciitreeman/

And the source code is on GitHub: https://github.com/reorx/asciitreeman

Some of the key features include visual tree editing with drag-and-drop-like operations, real-time sync where changes are immediately reflected in the ASCII output, keyboard shortcuts for navigation (J/K or arrow keys), and auto-saving your work to local storage.

What's interesting is that I used Claude Code to "vibe-code" this project in a very short amount of time. It was a fun experiment in AI-assisted development. For those curious about the process, I've included the prompts and specifications I used in the source code. You can check them out in the spec.md and CLAUDE.md files in the repository.

Hop you find it useful!

chrismorgan
14 hours ago
[-]
I’m sure lots of people will think this, so I’ll say it—

Box-drawing characters (U+2500–U+257F) are not ASCII (U+0000–U+007F).

There, got it out of my system. :-)

(I know, “ASCII art” colloquially means more than just the ASCII range.)

reply
Gormo
50 minutes ago
[-]
> (I know, “ASCII art” colloquially means more than just the ASCII range.)

I recall "ASCII art" always referring to art made with the 7-bit character set, and art made with the extended CP437 characters (and including color, etc.) always being called "ANSI art".

reply
guidedlight
11 hours ago
[-]
They sort of are.

I think the confusion arises because the IBM PC ASCII (code page 437) included comprehensive box-drawing characters between hexidecimal character positions B3 and DA. These weren't adopted into Unicode in the same character positions, but the box-drawing characters were definitely part of the commonly understood ASCII character set.

But I think that this ASCII tree editor should have a toggle option for basic vs extended ASCII, by utilising +, -, and | characters.

reply
chrismorgan
11 hours ago
[-]
ASCII is a 7-bit encoding. That’s it.

Honestly I’m not even convinced it’s entirely fair to call code page 437 a superset of ASCII, with how it repurposes the control codes 0x01–0x1F and 0x7F. (Superset of printable ASCII, definitely. It just feels not quite right to call it a superset of ASCII as a whole, though it is generally considered so.)

(And I can’t find any references to code page 437 being called “IBM PC ASCII”.)

reply
novoreorx
7 hours ago
[-]
My understanding of ASCII was influenced by tools like ASCIIDraw and ASCIIFlow, which I used them like almost 10 years ago. Inside my mind there's a voice with the same opinion of yours, but I still quite used to call plain-text drawings as "ASCII". LOL
reply
Timwi
13 hours ago
[-]
Indeed! I was disinclined to even look at this project because it said ASCII when the box-drawing characters are obviously a lot more suitable. It should say “text-only” or “plain-text” or similar instead.
reply
ycombiredd
15 hours ago
[-]
You might find this a useful companion to your tool.

https://github.com/scottvr/retree

reply
novoreorx
15 hours ago
[-]
That's pretty neat! My motivation is to manipulate tree structures to provide them to LLM. Retree does the opposite, taking tree text as input to create a real file system hierarchy. Next time I want to create a new project based on the tree I edited through ASCII Tree Editor, I can use retree to do this.
reply
adi_hn07
14 hours ago
[-]
Seems like a cool project !! Can you implement auto-parse as soon as the tree is pasted? Right now we can use arrow keys to reorder files, would love drag and drop ability for that too.

Would love to have ASCII Tree Editor on https://www.superlaun.ch

reply
novoreorx
7 hours ago
[-]
Thank you, I'm glad you find it useful! The reason I didn't implement auto-parsing in the text editor is that I want it to avoid affecting the tree component on the left side. Sometimes, I like to write something before copying the tree. It's like a scratchpad for me to finalize the text I want. Also, since it's auto-generated, if it were also auto-parsed, it could cause an infinite loop whenever anything is changed.

Drag-and-drop functionality was actually the first thing I considered. However, I want to keep the code clean and avoid involving too many third-party libraries. So, I came up with this method to make reordering easy while keeping it simple to implement.

I will submit it to Superlaunch, although I feel that it might not be valuable enough to be considered a product :)

reply
Timwi
13 hours ago
[-]
Both your link, and the “Live Demo” link in the GitHub readme, are dead links.
reply
novoreorx
8 hours ago
[-]
Thank you for bringing this issue to my attention. I forgot to publish it to GitHub Pages, which caused the reorx.github.io/asciitreeman link to be inactive (I've just fixed that). However, the main link for this news should be working, as it is deployed on Cloudflare. If you cannot see it, it is likely an edge CDN problem with Cloudflare.
reply
deadbabe
11 hours ago
[-]
If you vibe code a project, just share your prompts and the output they produce, no one should really care about what your specific code looks like because the prompts should generate a fully custom version of the same app from scratch.

Otherwise, it’s like showing assembly code for some program you wrote. No one cares about the machine code, just give the highest level language.

reply
novoreorx
7 hours ago
[-]
Totally agree and I've already mentioned that in the post, the prompts are in CLAUDE.md and spec.md, actually, my purpose of providing the repo url is for anyone interested to check the prompt, not the source code.

For your convenient, here's the link (it's written in Chinese, that what I really forget about): https://github.com/reorx/asciitreeman/blob/master/spec.md

reply
deadbabe
6 hours ago
[-]
Thank you, it’s promptware
reply