Hacker News new | ask | show | jobs
by w4rh4wk5 1597 days ago
For what it's worth, I keep a file in my home folder containing some box drawing characters. It's not super fast to draw by copy-paste but the result usually looks quite nice.

    ─  │  ┌ ┬ ┐
    ┄  ┆  ├ ┼ ┤ ╲ ╱
    ┈  ┊  └ ┴ ┘

    ━  ┃  ┏ ┳ ┓ ┏ ┯ ┓ ┏ ┳ ┓ ┏ ┯ ┓
    ┅  ┇  ┣ ╋ ┫ ┣ ┿ ┫ ┠ ╂ ┨ ┠ ┼ ┨
    ┉  ┋  ┗ ┻ ┛ ┗ ┷ ┛ ┗ ┻ ┛ ┗ ┷ ┛
6 comments

Vim has digraphs for all of these characters, which I like to use. e.g. you can get ┌ with <C-K>dr (d = down, r = right), and ┨ with <C-K>Vl (V = heavy vertical, l = left). To find the mappings, :digraphs shows the whole list, or copy this block of text and put the cursor over any of the characters in normal mode and type ga and it’ll echo things like “<┠> 9504, Hex 2520, Oct 22440, Digr Vr”.

(I use a Compose key for almost all character composition, with plenty of custom mappings in my ~/.XCompose, but box drawing specifically I have skipped and use Vim digraphs, and so drop into Vim any time I want to write any.)

I know, I've used them in the past. However, I get annoyed by having to remember the exact sequence for the character I want. And often, when drawing a line, I'll just copy some characters that are already there anyway.

Also, I tend to jump a lot between editors/IDEs nowadays so I prefer workflows that don't depend on a specific tool.

Wikipedia has a good page that also includes shading

[1] https://en.wikipedia.org/wiki/Box-drawing_character

For those on macOS/iOS, using custom text expansions [0] also helps to do this without having to leave the doc you’re editing. I’ve built up tons of these over the years for things like ⌘ (“commandkey”) → (“rightarrow”) (╯°□°)╯︵ ┻━┻ (“tableflip”) and of course, a party parrot wave for Slack (“parrotwave” → :parrotwave1::parrotwave2::parrotwave3::parrotwave4::parrotwave5::parrotwave6::parrotwave7:). They can sync over iCloud and you can export/import them with plists.

I now want to add table characters like these, just need to come up with a good naming convention…

[0]: https://support.apple.com/en-gb/guide/mac-help/mh35735/12.0/...

Did you override the hotkey to go to the end of a line for an emoticon? Or are those 3 different examples?
They’re different examples.
Do you have an example context in which you'd use these? I've never thought to do this and am curious about the possibilities and use cases.
Sure, last time I used them I documented some file format I needed to reverse engineer.

Here an excerpt. Of course, it's not _necessary_ to do it like that. It's just flavor.

    ┏━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━┳┅┅
    ┃ Chunk 1 Header │ Chunk 1 Body ┃ Chunk 2 Header │ Chunk 2 Body ┃
    ┗━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┻┅┅

    Chunk Header:
    ┌───────────┬─────────────────┐
    │ Magic Nr. │ Chunk Body Size │
    │   4 Byte  │          4 Byte │
    └───────────┴─────────────────┘
Biggest problem is with mobile / low horizontal resolution displays. I don't mind scrolling left and right, but in some cases the wrapping is forced (as on the HN phone app I'm using, Materialistic) and it becomes a mess. I've longed for some kind of markup system that allows for textual data to be formatted in tabular fashion irrespective of the character size of the contents, like ummmmmm HTML
It's fabulous in cases where there's a "big important business logic" or a "big important test" with tough to eliminate complexity, where you feel a diagram is so important that it's worth putting in comments beside said code. I do recommend that you be careful with this though; in places where it's not common to put ASCII art diagrams in code you'll probably receive pushback (it is afterall very large and distracting compared to said code). Be ready to save an in-code diagram for the 1-to-3 places in the business where they'll be a godsend.
It's also extremely useful for bit-mapped registers in embedded code.

EG the TI bq25155[1] battery charge controller PCHRGCTRL register (page 52) is divided into 3 fields. It can be quite helpful to show the layout before code to set the range.

   /*
    * ┌───────────────┬──────────┬─────────┐
    * │ ICHARGE_RANGE │ RESERVED │ IPRECHG │
    * │      7        │   6-5    |   4-0   |
    * └───────────────┴──────────┴─────────┘
    * This function sets the precharge current
    *  and fast-charge current step size the
    *  nearest 1.25mA (<= 318.75mA) or 
    *  2.5mA (<= 500mA).
    */
etc, etc.

[1] https://www.ti.com/lit/ds/symlink/bq25155.pdf

Basically I use the same kind of philosophy as RFCs, and document things using ascii art where some kind of diagram makes sense. For example, see the TCP RFC https://datatracker.ietf.org/doc/html/rfc793 where they use it for packet layout, flow diagrams, block diagrams, etc. It makes the whole thing self contained, you can copy paste diagrams to almost anywhere, easy to modify. Disadvantage is in some more complex diagrams it can get noisy
RFCs are now allowed to contain SVGs though.
Similar here, I use snippets for some of these things as well. As long as you're using a monospace font, I find it nice to take advantage of things like grid layouts in the extra column space for splitting up concepts into groups for example.
I usually copy from wikipedia but that's that's a good idea. In fact, since I have a "cols" command that just prints an ansi-colour table, I've just added "box" to do this.
can you share the contents of your cols script/function/alias?