Thanks for your response and the extra context. I've been experimenting with the settings and got a style that I like.

vim.api.nvim_set_hl(0, "CustomHighlightBorder", {
 fg = "yellow",
 italic = true,
})

Omitting the "bg" so I get a transparent header border (but the bottom border is still visible). Then the following config:

 code = {
 sign = false,
 disable_background = true,
 width = "block",
 border = "thin",
 below = "─",
 highlight_border = "CustomHighlightBorder",
 },

Which looks like this:

image

I would ideally like to control the color of the bottom border, but as soon as I set a "bg" value the top thick border becomes visible.

This works for me though :)

If you remove the border value you'll get the default value which is hide. This will let you remove the bottom line entirely. Is that closer to what you were looking for?

That's awesome, LMK once it's ready!

I'm currently writing some tests to cover the different cases for the top thin border.

Let's say we have the following raw markdown:

 local lines = {
 '```rust',
 '```',
 '',
 '```rust {filename="test.rs"}',
 '```',
 '',
 '```rust',
 'println!("long line beyond header width");',
 '```',
 '',
 '```rust {filename="test.rs"}',
 'println!("long line beyond header width");',
 '```',
 }

This is how I expect the render to be for each of the following cases (I've replaced the actual icon with 'x' so it's easier to view on here):

 it('block left pad 0', function()
 code.width = 'block'
 code.position = 'left'
 code.language_pad = 0
 util.setup.text(lines, { code = code })
 util.assert_screen({
 'x rust',
 '──────',
 '',
 'x rust {filename="test.rs"}',
 '───────────────────────────',
 '',
 'x rust ───────────────────────────────────',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 '',
 'x rust {filename="test.rs"} ──────────────',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 })
 end)
 it('block left pad 2', function()
 code.width = 'block'
 code.position = 'left'
 code.language_pad = 2
 util.setup.text(lines, { code = code })
 util.assert_screen({
 '─ x rust ─',
 '──────────',
 '',
 '─ x rust {filename="test.rs"} ─',
 '───────────────────────────────',
 '',
 '─ x rust ─────────────────────────────────',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 '',
 '─ x rust {filename="test.rs"} ────────────',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 })
 end)
 it('block right pad 0', function()
 code.width = 'block'
 code.position = 'right'
 code.language_pad = 0
 util.setup.text(lines, { code = code })
 util.assert_screen({
 'x rust',
 '──────',
 '',
 '{filename="test.rs"} x rust',
 '───────────────────────────',
 '',
 '─────────────────────────────────── x rust',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 '',
 '{filename="test.rs"} ────────────── x rust',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 })
 end)
 it('block right pad 2', function()
 code.width = 'block'
 code.position = 'right'
 code.language_pad = 2
 util.setup.text(lines, { code = code })
 util.assert_screen({
 '─ x rust ─',
 '──────────',
 '',
 '─ {filename="test.rs"} x rust ─',
 '───────────────────────────────',
 '',
 '───────────────────────────────── x rust ─',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 '',
 '─ {filename="test.rs"} ────────── x rust ─',
 'println!("long line beyond header width");',
 '──────────────────────────────────────────',
 })
 end)

Note: if we have a language_pad of 1, it would just have a space without an above character. I could use the above character, but it would be squashed up next to the text and would look inconsistent. I think having the space either side of the text is important to make the header look nice. Generally, advise against using language_pad of 1, when the border is thin.

You mentioned potentially using a new tab border style, but I'm not sure if it's necessary with this approach, as the tab effect can be achieved by using thin and a language_pad. It also makes thin border work in the way I expected, with a thin border at the top as well as the bottom. Let me know your preference and I'll go with that :)

Please let me know if there's anything you would like to change on the proposed renderings.

By the way, as I've had to test a lot of edge cases for this, I came across a couple of bugs with existing functionality in some of these. I'll share the details of these later.

You mentioned potentially using a new tab border style, but I'm not sure if it's necessary with this approach, as the tab effect can be achieved by using thin and a language_pad. It also makes thin border work in the way I expected, with a thin border at the top as well as the bottom. Let me know your preference and I'll go with that :)

I get why you would expect things to work that way. The idea behind using a new style is not to change the functionality for people without opting in to something new, it can be surprising if an update causes the rendering to behave differently. For anyone that may prefer the current rendering is there a way to get the old functionality back? Depending on the results I can be okay with changing the behavior, but there should be a way to achieve the same rendering as you get currently.

Please let me know if there's anything you would like to change on the proposed renderings.

It's a little hard to tell how things look from the screen draws, those really are just for quickly being able to unit test. But other than the things I mentioned above I don't have any other concerns.

By the way, as I've had to test a lot of edge cases for this, I came across a couple of bugs with existing functionality in some of these. I'll share the details of these later.

Sweet, feel free to create simpler bug reports just configuration + things that break would be enough. All the other stuff in the template is for filtering out common issues.

I get why you would expect things to work that way. The idea behind using a new style is not to change the functionality for people without opting in to something new, it can be surprising if an update causes the rendering to behave differently. For anyone that may prefer the current rendering is there a way to get the old functionality back? Depending on the results I can be okay with changing the behavior, but there should be a way to achieve the same rendering as you get currently.

Of course, that makes perfect sense. I would say to revert back to current rendering in terms of the config, the above value would just need to be set to ' ' (or ''), indicating no top thin border is desired. Looking at the default config for above and below, these would be set to the current half height blocks. So existing users that don't have an explicit above value in their config would see this default char in the top border, even when there is a code or icon on the line (not just when these are empty).

The couple of bugs I came across trace back to a single issue. Let's say I have the following code block:

```lua {filename="demo.lua"}
vim.print('Hello, World!')
```

And the following config:

{
 win_options = {
 conceallevel = {
 default = vim.o.conceallevel,
 rendered = 0,
 },
 },
 code = {
 width = "block",
 }
}

This would render like this (trucating the header):

Actually I have a solution to completely avoid the thin_border_pad_char. For a top thin border with language, I can apply the initial thick border background as it currently does, then just apply the thin borders over the top using offsets to position them (using the thin_border_pad, or just always have this set as 1).

Would you be able to create a PR (even if it's a rough one) with whatever the current state of the change is?

It'll help me better understand what option makes sense and maybe think of other ways to approach this.

No need to fix any failing unit tests (unless you already have) mostly interested in how you actually generate the thin border extmark(s).

No problem, I've just created one it in its current state. In terms of functionality, I think it's pretty close now, and has a few unit tests testing the layout of the new rendered output.

I'm just going to tidy a few things and will push another PR, the rough one with the current state wasn't working after a couple of recent changes.

Edit: The issues seems to be related to some commits I merged in from last week, I'll take a look today and create a new PR

PR has now been updated and back to a working state post merge. It's still work in progress, but you can see the approach, etc.