Pretty tables using box drawing characters

[minad]

This feature is already present in the prototype https://github.com/Fuco1/org-pretty-table. Unfortunately this project seems unmaintained. Maybe the pretty table feature could find a new home here? I think the feature would fit well into the scope of the org-superstar-mode package.

[integral-dw]

Hi @minad! Interesting feature. I do see the point that it fits neatly into the general spirit of the package (providing misc. eye candy for Org), but I believe that that this feature is actually beautifully self-contained that it would likely be better from a design and maintenance perspective to split it into its own thing. That doesn't mean that I won't consider picking it up in the future (or helping someone else along to do it), though. I actually already prepared the framework of this mode as a separate package template for cases like this, I will likely have to refactor it soon due to #25, however.

[integral-dw]

Whoops, didn't mean to close it just yet!

[minad]

I believe that that this feature is actually beautifully self-contained that it would likely be better from a design and maintenance perspective to split it into its own thing.

I don't know how different the feature would be from the already present facilities in org-bullet/org-superstar. I don't think it makes sense to have too many split packages which essentially fill the same niche. I would love to see the feature here. Hopefully it can be implemented without much effort, maybe in a simpler way than the original org-pretty-table.

[dakra]

jFYI there's already https://github.com/casouri/ftable which does this.

[minad]

@dakra It seems ftable is replacing the table with a unicode version. This is not what I want. Ideally only the visualization is modified via some overlay/display property mechanism - similar to what org-bullet/superstar is doing to the bullets.

EDIT: But there is also https://github.com/casouri/valign, maybe this provides the visualization.

[integral-dw]

I don't think it makes sense to have too many split packages which essentially fill the same niche.

I get what you mean. On the one hand it would make no sense to split things that conceptually belong to one another into many packages (especially if this could either mean code repetition or packages depending on one another), on the other hand there are distinct advantages to small, narrowly scoped packages in my opinion, especially for someone like me that likes to learn about packages by just diving into the code (which gets harder the more moving parts there are, with the exception of simple flags and the like). After all, Superstar has already grown quite a bit, being close to 700 LOC. That does not mean I'm opposed to integrating this feature into Superstar, it just means that I will probably have a crack at it, get a feeling for the complexity of the task, and then judge whether making it its own thing would be justified. Something along the lines of: If my implementation of it ends up being 300LOC, and making it its own package instead adds 50 but keeps things nice and separate I'd be more incline to do that instead of pushing superstar towards 1kLOC. On the other hand, if it turns out to be much simpler, then I'd put it into Superstar. Either way, I'll likely give it a whirl sometime (though it may take a while).

[minad]

I implemented table formatting in my org-modern package.