nvim icon indicating copy to clipboard operation
nvim copied to clipboard

feat: Add support for `OXY2DEV/markview.nvim`

Open OXY2DEV opened this issue 1 year ago • 7 comments

Is your feature request related to a problem? Please describe. Hi, Is it possible to add colorscheme support for my plugin markview.nvim?

Describe the solution you'd like It would be great if the colorscheme came with the highlight groups for the plugin.

You can check all the highlight groups used by the plugin here.

Describe alternatives you've considered By default, the plugin will generate highlight groups based on the colorscheme. So, currently it looks like this.

Screenshot_2024-08-25-15-15-50-439_com termux-edit Catppuccin frappe

Screenshot_2024-08-25-15-17-46-846_com termux-edit Catppuccin latte

Screenshot_2024-08-25-15-18-34-970_com termux-edit Catppuccin macchiato

Screenshot_2024-08-25-15-19-20-983_com termux-edit Catppuccin mocha

Additional context Not provided

OXY2DEV avatar Aug 25 '24 09:08 OXY2DEV

This plugin is amazing. +1 support for this

barcell1 avatar Oct 07 '24 16:10 barcell1

I believe the current maintainers of this repository are not active at the moment so this would most likely need to be PR'd in. However, I'm unsure if this should be accepted as https://github.com/catppuccin/nvim/pull/740 was already merged before this issue was raised.

https://github.com/MeanderingProgrammer/render-markdown.nvim seems to provide pretty much the same functionality and I'd imagine they can't both be enabled at the same time?

sgoudham avatar Oct 07 '24 22:10 sgoudham

https://github.com/MeanderingProgrammer/render-markdown.nvim seems to provide pretty much the same functionality and I'd imagine they can't both be enabled at the same time?

markview.nvim is the king, better than render-markdown.nvim (although is a great plugin also)

barcell1 avatar Oct 08 '24 13:10 barcell1

I looked through our existing integrations list and it does look like we are okay with allowing multiple plugins that overlap in functionality / featuresets so I'd be happy to accept a PR for it.

I think it makes sense to set it false by default, however, I'm currently unsure of prior precendent on how we decide to set integrations to true or false. Maybe @vollowx or @mrtnvgr have some insights here?

sgoudham avatar Oct 08 '24 14:10 sgoudham

Unless there is any significant change in what currently is used and the integration, there is no need to set it to true.

The plugin uses tree-sitter highlight groups so it shouldn't be too far off from what the document itself looks like.

I am a bit on a fence wether to request plugin support to other colorschemes. Since,

  1. It's more work for you, it's more work for the end-user(having to open a PR/request integration) and it's more work for me(as I will have to notify colorscheme authors when changes occur).
  2. It limits development as now I have a finite number of set groups(as I am sure nobody will like having to update the integrations constantly).
  3. Previews should retain the original highlight groups(either from the syntax files or tree-sitter). So, there shouldn't be any immediate need to manually add support.
  4. Due to hardware limitations I can't test colorscheme support(especially transparency) so, I can't make PRs for mot colorschemes.

But you guys are more smarter than me, so I will leave it in your hands.

OXY2DEV avatar Oct 08 '24 14:10 OXY2DEV

@sgoudham Also, there has been significant changes to highlight groups. So the original comment is outdated.

https://github.com/user-attachments/assets/ae3d2912-65d4-4dd7-a8bb-614c4406c4e3

OXY2DEV avatar Oct 08 '24 14:10 OXY2DEV

Happy new year ! Any update on this? @sgoudham

MuntasirSZN avatar Jan 08 '25 10:01 MuntasirSZN

+1 for this!

xfzv avatar Jan 25 '25 09:01 xfzv