Kind of, but I wouldn't rely on any of that. In general I would avoid calling this plugin from yours, realistically that's going to make things more complicated and fragile.

What I would suggest is simply setting the filetype of your buffer to markdown. From there if users have this plugin installed it'll get rendered like any other markdown buffer.

Then if you have some suggested configuration that you think works really well for your plugin you can suggest users use some specific set of options for my plugin to get results like in your screenshots.

I don't think adding a way to force a configuration for specific buffers is a good idea, at least that's my initial impression. If you can provide a specific example, like here's the options I think users should get and here's why they're generally speaking always better, then I'll try to think of some way to accomplish what you're looking for.

@MeanderingProgrammer thanks for the answer!
My use case - i have 'tabish' kinda data like following:

and currently i keep that visual structure myself, with space paddings.

what i would like to do - is to delegate all that ui madness to something else, that could do a better job than me.

nuance of mine here - is that i want content to be aligned like its inside the table, but not having table borders and separators, and thats one custom configuration i want ( now the only one ), and i also don't want all of my users to remove those just because they have my plugin installed...

here is link to repo if you want to look around - https://github.com/alex-popov-tech/store.nvim

nuance of mine here - is that i want content to be aligned like its inside the table, but not having table borders and separators

Do you create the table as a valid markdown table? My plugin relies on tree-sitter to interact with tables, meaning find the rows / columns, etc. So if the table in the text isn't in markdown table syntax this plugin won't be able to render it at all.

i render buffer on screen as plain text, but it would be much easier to render them like a valid markdown table, and not make all these counts of spaces here and there

Ah, gotcha, that makes sense, it is definitely more convoluted then you would think to track all the widths.

If your plugin is changed to output a markdown table this plugin will render it, but based on your original question, the rendering will not look quite how you want.

I do think the loss of direct control in the output is going to happen if you make this kind of a change, and in this case it's reasonable IMO. You provide the content to render and my plugin renders it based on the user's configuration. If user's don't like exactly how the output looks they can configure table rendering settings through this plugin. I imagine the way they want tables to look in the context of your plugin is the same as how they want tables to look in other markdown files, but I could be wrong here.

I'm unsure if it makes sense for other plugins to be able to modify the rendering settings of my plugin for specific buffers. I can kind of see both sides here, but I generally prefer to use what users specify they want when possible. It also seems like we could end up in a place where you add options to modify the options you send to this plugin, when we could just let the user configure this plugin.

What do you think?

I imagine the way they want tables to look in the context of your plugin is the same as how they want tables to look in other markdown files, but I could be wrong here.

welll...no? :D
tables look like tables and its fine, my use case is not like 'i have a table to render', but 'i have dataset, which consists of rows and columns, and would be nice to have even alignment for all these to have pretty visual representation'. so its not 100% case like table in excel, but its more like just me trying to arrange data nicely on screen

I did not plan to allow users any modifications on ui ( actually i do have them already - they can control columns shown and their order, but no visual things like separators ), i just want my data to look pretty and readable, thats all. consider my initial version for comparison:
image

thats why i was asking about separate instance - i do think that users want to see tables how your plugin renders them right now, they are pretty as they are. so for my case i want to use your whole engine with custom config just for this one buffer.

by the way, on the last screenshot you can see readme preview to the right of 'list' buffer, and its an actual real readme of some plugin, and it can contain tables, and in that buffer tables should just render as tables, no changes to their borders and separators. i note that to express an example of few buffers nearby being need to setup a bit differently for different use cases

I'm following along, and think I understand what you're looking for. I think there are 2 separate things needed:

1. A way to render tables "like a dataset"

By this I mean a set of options that if configured on this plugin tables will look the way your plugin shows them. This means some way to hide separators, maybe not showing the header / delimiter rows.

Some of these might be possible with existing options, others will likely require new options to be added. I just have to have a really good idea of this markdown should render like this, will require some and forth with you.

2. A way to use that rendering for your plugin's buffers

I'm not sure exactly how I'll end up doing this but here are 2 ways I can think of:

1. Using a custom filetype based override. This plugin already allows custom configurations to be used based on the filetype value. Rather than using markdown as your filetype you can use a custom value like store. You can then set the language associated with the filetype to markdown using vim.treesitter.language.register('markdown', 'store'). Then I can set a default override for store. This does mean to change the default behavior you'd need to send a PR to this repo, but it also means I'll handle breaking changes and it will allow users to change this behavior if they really want to (could be a good or bad thing).
2. An API that lets you modify configurations however you want. It'll be up to you to you to do something like oh this is a buffer from my plugin, set these options, as well as potentially handling breaking configuration changes in the future if options ever change on my end. This will also let you decided what users have control over.

thanks for such a passionate response!
2.1. This one looks quite hacky, as it requires me to stick to non-existing filetype, and you to have something in your plugin code to handle non-existing filetype for one plugin in the universe ( what if new guy came in and asks some other customisations? )
2.2. that might be something generic on your side ( so new guy will be able to do its thing on its own ). the way i did this is - https://github.com/alex-popov-tech/store.nvim/blob/main/lua/store/init.lua#L8 - is i built whole plugin as an instance, not a global thing. the only global state is on very high level on init.lua, to prevent re-creating objects ( as we only really need one ). but technically we can create two 'store modal's. so my initial question was about that, is there sometrhing similar on your engine side :)

is i built whole plugin as an instance, not a global thing

Unfortunately not really, at least if I understand what you mean correctly. Since I do not own / create / update the buffers users are interacting with the concept of an "instance" is a little different. This plugin is more built around "listening" and responding to changes to buffers.

I'm also not sure if it would help in this case. By that I mean if this plugin did the equivalent of creating an "instance" per markdown buffer then by default this plugin will automatically attach to the store.nvim buffers since they're markdown. If you were then to manually create a second "instance" in your plugin we would just end up with 2 things trying to render the same buffer with different configurations.

The configuration to use for rendering is computed once per buffer and re-used on all subsequent render calls. So the only hook you need is a way to modify the configuration for buffers created by your plugin.

as it requires me to stick to non-existing filetype, and you to have something in your plugin code to handle non-existing filetype

It can seem hacky for sure, but it's a pretty common pattern for neovim plugins. It's essentially a way that allows the source of a buffer to be easily identified and to handle it differently based on that. Some example:

• avante.nvim: https://github.com/yetone/avante.nvim/blob/70a73d4f981c1e4e09fba2ed96da5244cf9d1897/lua/avante/init.lua#L313
• codecompanion.nvim: https://github.com/olimorris/codecompanion.nvim/blob/638b643a17a656a34d15c884e1fd059d0992d660/plugin/codecompanion.lua#L83

okay, no worries!
i also has this option to explore - OXY2DEV/markview.nvim#371 - i will give it a shot, don't want to bother you to change whole thing just because i don't want table borders in on buffer on earth :D