Adding indenttabchar, indentspacechar and spacechar options #3760

Neko-Box-Coder · 2025-05-24T22:06:55Z

This PR added the options of indentspacechar and spacechar and moved indentchar to indenttabchar to avoid confusion.

indenttabchar will display the specified character when \t is encountered.

indentspacechar will display the specified character when ' ' is encountered at tabsize locations

spacechar will display the specified character when ' ' is encountered, but indentspacechar takes precedence.

Created this PR because I wanted the feature to view files with deeply nested blocks.
Gonna merge it to my own fork https://github.com/Neko-Box-Coder/micro-dev for whoever needs it while waiting for this to be merged.

This should address long-standing requests of #2539 , #2707 and #431

I am happy to revert the prompt message of telling user indentchar is deprecated, if people/maintainer finds it controversial.

internal/config/settings.go

dmaluka · 2025-06-01T14:00:21Z

runtime/help/options.md

+    default value: ` ` (space)
+
+* `indentspacechar`: same as `indenttabchar` except for spaces that are at
+   locations that are divisible by `tabsize`.


What if tabsize doesn't match the actual indentation used in the given file (which happens more often than not)? If my detectindent plugin is used, it tries to detect the actual indentation width and adjusts tabsize accordingly, but this plugin is not even built-in.

I am not sure what the problem is here.

The user (or any plugins) can always change the tabsize and the indentspacechar will be displayed accordingly?

The problem is that the default behavior is confusing. For example, the default value of tabsize is 4, the user edits a file with 2-space indentation and doesn't bother changing the tabsize value (because it doesn't matter to him), then the user sets this indentspacechar option to highlight indentation, but only half of the indentation is highlighted.

I have no better suggestions right now, so I'm fine with it.

dmaluka · 2025-06-01T14:06:59Z

runtime/help/options.md

-   setting available in many other text editors. The color of this character is
-   determined by the `indent-char` field in the current theme rather than the
-   default text color.
+* `indenttabchar`: sets the indentation character for tabs. This will not be


What is "indentation character for tabs"? AFAICS indenttabchar does exactly what indentchar currently does, i.e. simply displays all tabs, so why not call it just tabchar?

I guess technically they are the same? Since the tab character is always (displayed) aligned to tabsize?

I can change it to tabsize, I named it this ways just (trying) to be consistent to what it was called previously.

dmaluka · 2025-06-01T14:43:12Z

Do we need to deprecate indentchar? I'd rather fix it to do something closer to what its documentation says, instead of what it does now (i.e. simply displays all tab characters regardless of indentation).

It feels that by adding that many new options we are creating even more mess and confusion.

Why not just add tabchar which simply displays all tabs (i.e. what indentchar does now), spacechar which simply displays all spaces, and repurpose indentchar, for example, to display all tabs and all spaces at the position of tabs (i.e. divisible by tabsize)? And for example let tabchar (if set to any other value than ) take precedence over indentchar, so that if you want different characters for tabs and for spaces at the position of tabs, you can set tabchar for the former and indentchar for the latter?

BTW another request in #431 (comment) was to display other non-printable characters, which is quite reasonable, so we might add another option e.g. invisiblechar for that.

Neko-Box-Coder · 2025-06-01T15:17:27Z

Do we need to deprecate indentchar? I'd rather fix it to do something closer to what its documentation says, instead of what it does now (i.e. simply displays all tab characters regardless of indentation).

It feels that by adding that many new options we are creating even more mess and confusion.

Why not just add tabchar which simply displays all tabs (i.e. what indentchar does now), spacechar which simply displays all spaces, and repurpose indentchar, for example, to display all tabs and all spaces at the position of tabs (i.e. divisible by tabsize)? And for example let tabchar (if set to any other value than ) take precedence over indentchar, so that if you want different characters for tabs and for spaces at the position of tabs, you can set tabchar for the former and indentchar for the latter?

Repurposing a setting would be confusing since the user is not expecting it unless they read the documentation.

I guess if we want to truly do what the name says, we can have a setting indenttabchar for all the tab characters before the first letter in a line and another setting tabchar for all the tabs after the first character, similar to how indentspacechar is handled.

BTW another request in #431 (comment) was to display other non-printable characters, which is quite reasonable, so we might add another option e.g. invisiblechar for that.

Okay, I will add that as well.

dmaluka · 2025-06-01T15:26:00Z

Repurposing a setting would be confusing since the user is not expecting it unless they read the documentation.

It would be "backward compatible" in a sense: tabs would be still highlighted.

Spaces at the position of tabs would become highlighted as well, but if the user changed the default value of indentchar in the first place, quite likely the user actually wants that?

I guess if we want to truly do what the name says, we can have a setting indenttabchar for all the tab characters before the first letter in a line and another setting tabchar for all the tabs after the first character, similar to how indentspacechar is handled.

Let's not overcomplicate without real need.

Neko-Box-Coder · 2025-06-01T15:45:32Z

Repurposing a setting would be confusing since the user is not expecting it unless they read the documentation.

It would be "backward compatible" in a sense: tabs would be still highlighted.

Spaces at the position of tabs would become highlighted as well, but if the user changed the default value of indentchar in the first place, quite likely the user actually wants that?

Okay, I see. But if tabchar is "overriding" indentchar while spacechar isn't, wouldn't it make more sense to call it indenttabchar? And this hidden behavior (where tabchar is "overriding" indentchar) is no longer hidden?

I am fine to do it either way tbh. Just a question.

The reason I deprecated indentchar other than clarity is because I don't need to check multiple settings for the same character (tabchar vs indentchar if both are populated) each time, makes it a bit easier to follow the logic in code as well.

Another reason is what if the user actually wants space (the default) instead of indentchar, we wouldn't be able to tell as well.

I guess if we want to truly do what the name says, we can have a setting indenttabchar for all the tab characters before the first letter in a line and another setting tabchar for all the tabs after the first character, similar to how indentspacechar is handled.

Let's not overcomplicate without real need.

Okay.

dmaluka · 2025-06-01T16:55:28Z

But if tabchar is "overriding" indentchar while spacechar isn't, wouldn't it make more sense to call it indenttabchar?

Its primary role is to simply specify which character to use to visualize tabs. It is not primarily about indentation. What do we gain by making its name more verbose?

And this hidden behavior (where tabchar is "overriding" indentchar)

It doesn't need to be hidden, it can (and probably should) be documented as well.

Neko-Box-Coder · 2025-06-01T17:48:58Z

But if tabchar is "overriding" indentchar while spacechar isn't, wouldn't it make more sense to call it indenttabchar?

Its primary role is to simply specify which character to use to visualize tabs. It is not primarily about indentation.

I know, but that's what it was called.

That's why I said maybe we could have 2 settings for tabs, 1 act like indentspacechar and the other one act like spacechar.

... What do we gain by making its name more verbose?

To be less confusing. The previous behavior of indentchar is only for tabs. The user updates to latest micro and found out indentchar is now applied to indented space as well. If they want to change or disable it, they will have to unintuitively change the tabchar option (remember, they want to change indented space now) or mistakely think spacechar is the option they are looking for.

And this hidden behavior (where tabchar is "overriding" indentchar)

It doesn't need to be hidden, it can (and probably should) be documented as well.

I would prefer the behavior to be mentioned in the name rather that requiring the user to read the documentation (although they should be to be fair).

This is gonna be my last attempt to see if we can stick to the current proposed names.
If you still disagree, I can change it.

dmaluka · 2025-06-01T18:12:54Z

Simple question: do we want an option that allows the user to simply display all tabs (no matter at the beginning, at the end or in the middle of a line)?

If the answer is yes, why not call this option tabchar? Wouldn't that be the most natural and intuitive name? If we name it indenttabchar instead, wouldn't that be confusing?

If what we want instead (or in addition) is an option that only displays tabs at the beginning of lines, then yes, it would make sense to name it indenttabchar. But that is not what your PR is implementing.

Neko-Box-Coder · 2025-06-01T18:35:41Z

Simple question: do we want an option that allows the user to simply display all tabs (no matter at the beginning, at the end or in the middle of a line)?

If the answer is yes, why not call this option tabchar? Wouldn't that be the most natural and intuitive name? If we name it indenttabchar instead, wouldn't that be confusing?

That's what it does currently, both indentchar and this PR's indenttabchar. The reason I keep the indent name is to be consistent with previous name, even though technically it acts like spacechar

If what we want instead (or in addition) is an option that only displays tabs at the beginning of lines, then yes, it would make sense to name it indenttabchar. But that is not what your PR is implementing.

That's why I was asking maybe if I should have indenttabchar act like indentspacechar and tabchar that is used for in the middle of a sentence. I can implement this instead But as you said it introduces complexity.

Actually, maybe it is better if I rename the new options to the following:

tabchar which will replace (and act like) current indentchar
indentspacechar which highlights spaces that are in tabsize at the beginning of the sentence
and spacechar for the rest of spaces
and invisiblechar for non-displayable characters (todo)

Do you think this is better?

dmaluka · 2025-06-01T21:00:32Z

The reason I keep the indent name is to be consistent with previous name

What's the point of being consistent with it if you are deprecating it?

That's why I was asking maybe if I should have indenttabchar act like indentspacechar and tabchar that is used for in the middle of a sentence. I can implement this instead But as you said it introduces complexity.

I'm not suggesting to implement it, I'm saying that if we wanted to implement it, then indenttabchar would be a suitable name for it.

Actually, maybe it is better if I rename the new options to the following:

[...]

indentspacechar which highlights spaces that are in tabsize at the beginning of the sentence

Ok, I've just noticed that you already have bloc.X < leadingwsEnd for indentspacechar...

Question (not a rhetorical one): are you going to use tabchar and indentspacechar with different values, or with the same value?

Neko-Box-Coder · 2025-06-01T21:11:10Z

Actually, maybe it is better if I rename the new options to the following:
[...]

indentspacechar which highlights spaces that are in tabsize at the beginning of the sentence

Ok, I've just noticed that you already have bloc.X < leadingwsEnd for indentspacechar...

Question (not a rhetorical one): are you going to use tabchar and indentspacechar with different values, or with the same value?

Yeah, I am, so that I can tell any hidden tabs in space-indented files.

dmaluka · 2025-06-01T21:28:21Z

so that I can tell any hidden tabs in space-indented files

For that purpose, wouldn't hltaberrors be more useful?

Neko-Box-Coder · 2025-06-01T23:32:02Z

so that I can tell any hidden tabs in space-indented files

For that purpose, wouldn't hltaberrors be more useful?

True. I should probably turn that on as well. But they will still be different values, since I use indentchar to "see" tab characters (including ones that are in the middle of a sentence in tab indented file), and indentspacechar as indented scopes.

The main thing here is we are mixing the ability to see tab character and indented blocks into a single option (indentchar), which now we are trying to separate.

If we reuse indentchar, this will certainly be confusing for people who are using indentchar just to see tab character, which now becomes tabchar.

If we are reusing indentchar, I think we should at least have a new version/breaking changes message or something when the user upgraded micro, similar to how lazygit did it when they introduced a breaking change. I really think just mentioning it in the documentation is not enough.

I think it is good to have a new version/breaking changes message anyway for future breaking changes if any.

Also if we need to account for a special case where tabchar can take precedence over indentchar when it is ' ', why not spacechar as well?

Or we can avoid all of this headache by just having 4 options, spacechar, indentspacechar, tabchar and indenttabchar, and don't need to introduce breaking/confusing changes and special cases. idk ¯\_(ツ)_/¯

dmaluka · 2025-06-02T01:45:37Z

To be clear, when I suggested reusing indentchar, I thought your intention was to extend the definition of "indentation character" to all blank characters with X % tabsize == 0, not just those with X < leadingWsEnd (because I hadn't noticed your bloc.X < leadingwsEnd for indentspacechar, and because you confusingly didn't add it for indenttabchar).

I think it is good to have a new version/breaking changes message anyway for future breaking changes if any.

This is a UI change, not an API change. The user is gonna notice it anyway.

We've done such "breaking" UI changes before. It is less breaking than #3335, for example.

Also if we need to account for a special case where tabchar can take precedence over indentchar when it is ' ', why not spacechar as well?

Because with the "extended" definition of indentation character (see my confusion above), any tab is an indent char, but not any space is...

Anyway, screw that, yes, it would be messy. Now I think it's better to let indentchar take precedence over both spacechar and tabchar. So that, tabs at the end of a line are displayed as tabchar, but tabs (and spaces) at the beginning of a line are displayed as indentchar (unless it is set to ' '). That would mean we can't set different characters for indentation tabs vs indentation spaces, but it seems there are no use cases for that?

Or we can avoid all of this headache by just having 4 options, spacechar, indentspacechar, tabchar and indenttabchar

I'm almost fine with that, but... Think of what would be the most useful and pleasant behavior for the user. The user wants to see "indentation columns", displayed with the | character, for example. It seems friendlier to let the user simply set indentchar to | for that, instead of figuring out that it needs to be set separately for tabs and for spaces?

On the other hand... I've recalled once again that it's not that simple, since tabwidth may not match the actual indentation width with spaces. So yeah... for this reason it seems better to have separate options indenttabchar and indentspacechar, and in the documentation for indentspacechar emphasize that this option is tricky and the result will only be desirable if tabwidth is set appropriately...

So, right now I'm inclined to agree that having 4 options spacechar, indentspacechar, tabchar and indenttabchar would be best...

and don't need to introduce breaking/confusing changes and special cases

It still doesn't answer what to do with indentchar.

I don't think silently removing it from the documentation (what your PR seems to be doing) is an option. It seems we should just keep it, and say in its documentation that it is just an alias for tabchar, kept for backward compatibility.

JoeKar · 2025-06-02T18:50:58Z

So, right now I'm inclined to agree that having 4 options spacechar, indentspacechar, tabchar and indenttabchar would be best...

Agree, but while we are at it...the eolchar (see: #431 (comment)), the already mentioned invchar and maybe even the wrapchar.

Andriamanitra · 2025-06-02T19:40:14Z

So, right now I'm inclined to agree that having 4 options spacechar, indentspacechar, tabchar and indenttabchar would be best...

Agree, but while we are at it...the eolchar (see: #431 (comment)), the already mentioned invchar and maybe even the wrapchar.

If we're going to keep adding more of these maybe grouping them together under one setting would be better for discoverability? Similar to what vim does with listchars.

JoeKar · 2025-06-02T19:50:57Z

Similar to what vim does with listchars.

Hm, good idea.
micro does something more "lightweight" with the divchars already, but this would be ugly to configure for more than two options.

Neko-Box-Coder · 2025-06-02T20:37:42Z

Similar to what vim does with listchars.

Hm, good idea. micro does something more "lightweight" with the divchars already, but this would be ugly to configure for more than two options.

I will need an example in order to implement grouping for the options.

I am not following how divchars are grouped?.

I did say this PR addresses the issues but doesn't mean I am solving all of them completely (for instance #431 (comment) is asking for displaying a hex code, that's not gonna be done in this PR). I am open to ideas but don't want to get feature-creeped here 😅

I will try to implement the ideas mentioned here if relatively straightforward, if not it's better to have a dedicated PR for those features.

The main goal for this PR (to me) is to have configurable indent characters for both space and tab indented files.

dmaluka · 2025-06-02T21:53:29Z

If we're going to keep adding more of these maybe grouping them together under one setting would be better for discoverability? Similar to what vim does with listchars.

Good point. Originally I was mildly opposed to doing something similar to vim's listchars (we don't need to exactly follow what vim does), but given that it would help us to avoid this "option creep", it seems attractive.

dmaluka · 2025-06-02T21:55:57Z

I will need an example in order to implement grouping for the options.

Something like tab=>,space=.,itab=|,ispace=| ?

I'm not sure what would be the name of this generic option though. listchars is definitely not the most intuitive one.

Neko-Box-Coder · 2025-06-02T22:35:19Z

I'm not sure what would be the name of this generic option though. listchars is definitely not the most intuitive one.

formatchars (welcome for any other suggestions)? Since space and tabs are used for formatting. But in this case newline (eolchar) would be in this option as well. invchar and wrapchar not so sure.

Something like tab=>,space=.,itab=|,ispace=| ?

I see. In this case, I will need to store these options as global variables (since we don't want to do string parsing in every display call) instead of getting it from the settings map.

dmaluka · 2025-06-03T00:06:02Z

since we don't want to do string parsing in every display call

Hah, you are sure it would be slower than the settings map lookup? Especially considering how many times we do the settings map lookup in every display call? :D

We are extremely wasteful there. See #3227 and #3228 (and #2970 for the background)

(Just in case, I'm not saying we should not store those parsed settings.)

Neko-Box-Coder · 2025-07-13T22:20:26Z

Shouldn't it be like this, regardless of tabstospaces?
|   |||||   |   abc

No because ispace only gets displayed at columns divisible by tabsize.

What you shown would be true if space is set to | as well.

dmaluka · 2025-07-13T23:11:02Z

So let's say I have "showchars": "ispace=|,itab=| for example to mimic scope indicator in other text editor

Hmm... this is why IIRC I was originally asking you if there are really use cases for having two separate "scope indicators" for tabs and spaces, rather than just one for both. You said you had use cases for that.

So... instead of requiring to the user to "mimic scope indicator in other text editor" by setting both ispace and itab, maybe we should, well, just provide this scope indicator? Name it e.g. indent, and make it respect tabstospaces, and then we can make ispace and itab not care about tabstospaces. So the user can just set indent=|, and then your example will be displayed as | | | abc, as we want it to. While if the user sets e.g. itab=|,ispace=:, it will be always displayed as | : | | abc, as the user probably wants it to, instead of unexpectedly hiding : or | depending on the tabstospaces value.

Andriamanitra · 2025-07-13T23:25:59Z

Shouldn't it be like this, regardless of tabstospaces?
|   |||||   |   abc
No because ispace only gets displayed at columns divisible by tabsize.

What you shown would be true if space is set to | as well.

I see, that's pretty weird (does any other editor work like that?). I had incorrectly assumed ispace would be used for showing spaces in indentation but not in the middle of the line, kind of like a less smart version of renderWhitespace: "boundary" in VS Code.

So... instead of requiring to the user to "mimic scope indicator in other text editor" by setting both ispace and itab, maybe we should, well, just provide this scope indicator? Name it e.g. indent, and make it respect tabstospaces, and then we can make ispace and itab not care about tabstospaces.

I like this idea of indent much better than having separate ispace and itab. Do we really need all 3? I don't think any other editor makes it that complicated.

Neko-Box-Coder · 2025-07-13T23:39:05Z

So let's say I have "showchars": "ispace=|,itab=| for example to mimic scope indicator in other text editor

Hmm... this is why IIRC I was originally asking you if there are really use cases for having two separate "scope indicators" for tabs and spaces, rather than just one for both. You said you had use cases for that.

Yes, I still do. My point was (when deciding to have 2 indicators or not) the user can choose if they want to differentiate tab indent or space indent.
Right now I have "showchars": "itab=▏⇥,ispace=▏,tab=⇥", but that's me personally. An user can set them to the same if he doesn't care.

My point I just gave (wrt tabstospace) was if the user choose not to differentiate the indent char between tab and space.

So... instead of requiring to the user to "mimic scope indicator in other text editor" by setting both ispace and itab, maybe we should, well, just provide this scope indicator? Name it e.g. indent, and make it respect tabstospaces, and then we can make ispace and itab not care about tabstospaces. So the user can just set indent=|, and then your example will be displayed as | | | abc, as we want it to.

You mean the other way around? If indent cares about tabstospaces it would be | | abc in your example.

But anyway, the behavior that indent respects tabstospaces but not ispace (indent space) and itab (indent tab) is weird to me.

... While if the user sets e.g. itab=|,ispace=:, it will be always displayed as | : | | abc, as the user probably wants it to, instead of unexpectedly hiding : or | depending on the tabstospaces value.

idk, the fact that the user told the editor if the file is tab indented or not and yet it can still show space indented character is weird to me since the "indent" part is explicitly said in the name.

Anyway, we are spending time dicussing this which would probably barely come up. I am fine to drop the tabstospaces check.

Neko-Box-Coder · 2025-07-13T23:44:15Z

@Andriamanitra

I like this idea of indent much better than having separate ispace and itab. Do we really need all 3? I don't think any other editor makes it that complicated.

For me, I just want to be able to see tab character without losing the scope indicator, that's why I needed 2 indent characters to do that.

VS Code is different because it can render a tab character on top of the scope line, we can't do that here since we can only render 1 character.

dmaluka · 2025-07-13T23:57:48Z

But anyway, the behavior that indent respects tabstospaces but not ispace (indent space) and itab (indent tab) is weird to me.

What's weird about it? Space indentation in a tab-indented file it still an indentation, just not a "desired" one.

the fact that the user told the editor if the file is tab indented or not

The user hardly told anything. The tabstospaces option just happens to be set to one value or the other, not necessarily because the user has set it, and even if so, not necessarily because the user realized this particular implication of it (after all, this is not the primary, documented purpose of tabstospaces).

Neko-Box-Coder · 2025-07-14T08:30:03Z

Yeah I dropped the tabstospaces check.

dmaluka · 2025-07-19T09:58:17Z

runtime/help/options.md


+* `showchars`: sets what characters to be shown to display various invisible
+   characters in the file. The characters shown will not be inserted into files.
+   (This option overrides the `indentchar` option if that exists)


Both options always exist, it's not like indentchar may cease to exist, it just may change its value?

And this statement is not quite true: 1. it is just the tab key, not the showchars option in its entirety, that overrides indentchar. 2. if the tab key is present, it overrides indentchar always, regardless of what value the indentchar itself is set to. Right?

I reworded it.

dmaluka · 2025-07-19T10:23:52Z

internal/display/bufwindow.go

+					if indenttabchars != "" {
+						indentrunes = []rune(indenttabchars)
+					} else {
+						indentrunes = []rune(tabchars)


Instead of having this else branch which duplicates the outer else branch below, we can just add indenttabchars != "" to the outer if condition?

Ditto for spacechars below.

dmaluka · 2025-07-19T10:30:49Z

internal/display/bufwindow.go

-					fg, _, _ := s.Decompose()
-					style = style.Foreground(fg)
+			case ' ':
+				if bloc.X%tabsize == 0 && bloc.X < leadingwsEnd {


Simply checking bloc.X%tabsize == 0 is buggy, since bloc.X is not necessarily the visual position of the character in the line (since there may be tab characters in the line before this space character). Try it: put some space characters after some tab characters (before the first visible character in a line) -> result: ispace is displayed at wrong locations.

We should probably use util.StringWidth().

I am using the line width (totalwidth) now, doing util.StringWidth() every time would be overkill.

dmaluka · 2025-07-19T10:32:27Z

internal/display/bufwindow.go

-					fg, _, _ := s.Decompose()
-					style = style.Foreground(fg)
-				}
+			var returnrune rune


nit: maybe drawrune instead (in line with the name used by the callers, and because the meaning of this variable is precisely: the rune to be drawn)?

internal/display/bufwindow.go

dmaluka · 2025-07-19T23:21:55Z

internal/display/bufwindow.go

 		}
 		bloc.X = bslice

+		// returns the rune to be drawn, style of it and if the bg should be preserved


What's the point of this comment?

The point of the comment is to describe the return values, otherwise you have no idea what it returns unless you read the rest of the impl/call sites.

That's what we do - look at the call sites to see how the function is actually used and what for. If we are not interested in the call sites, why would we be interested in the function itself?

If the problem is just that we don't see the names of the return values here in the function declaration, we could use named return values? Or the problem is that we don't want to use them since the line would become enormously long (which it already is)?

Anyway, I'm ok with keeping it as is.

But again, why are you doing that in this commit "Simplifying draw to be less nested" which is supposed to be just about simplifying draw() to be less nested? This comment should added in the first commit, where getRuneStyle() itself is added?

And same about renaming bgoverridable and returnrune - why do that in this commit, and why do that at all? If we agree they should be preservebg and drawrune, we should name them preservebg and drawrune from the beginning, in the first commit?

I genuinely don't get it.

It's fine, just merged to the wrong commit, have moved it to the first one. Should be good now?

Yeah, now looks good.

Except that, the commit message of the 2nd commit includes an outdated sentence?

oops, missed that. Have removed it.

dmaluka · 2025-07-19T23:30:44Z

internal/display/bufwindow.go

+				if !preservebg {
+					// syntax or hlsearch highlighting with non-default background takes precedence
+					// over cursor-line and color-column
+					preservebg = origBg != defBg


Also just realized: this can be even simpler:

// syntax or hlsearch highlighting with non-default background takes precedence // over cursor-line and color-column if !preservebg && origBg != defBg { preservebg = true }

Updated, both reads fine to me tbh.

dmaluka · 2025-07-19T23:32:58Z

internal/display/bufwindow.go


 		// returns the rune to be drawn, style of it and if the bg should be preserved
-		getRuneStyle := func(r rune, style tcell.Style, isplaceholder bool) (rune, tcell.Style, bool) {
+		getRuneStyle := func(r rune, style tcell.Style, drawoffset int, linex int, isplaceholder bool) (rune, tcell.Style, bool) {


Any reason why you renamed showoffset to drawoffset?
Neither name seems quite intuitive to me, but at least showoffset somehow relates to showchars (and showchars is the only reason for the existence of this argument, right?).

dmaluka · 2025-07-19T23:34:31Z

internal/display/bufwindow.go


 			width := 0

+			linex := totalwidth


visualx? (like in VLocFromLoc() for example)

I didn't use visiualx because it's quite easy to get mixed up with vloc.X, which is different.
vloc.X resets on wrap but this doesn't, this is x (draw/visual?) position in a line.

dmaluka · 2025-07-19T23:39:45Z

runtime/help/options.md

+
+   Here are the list of keys:
+   - `space`: space characters
+   - `tab`: tab characters, this option overrides the `indentchar` option


"this key"?
Or, cleaner, in a separate sentence: "If set, overrides the indentchar option."?

Neko-Box-Coder · 2025-08-09T10:19:48Z

Hey @JoeKar

I want to get this merged so would be nice if you can take a look at this PR and approve/merge it when you are free.

(and also I can start the next PR of adding eol, inv and wrap char options)

Thanks

internal/display/bufwindow.go

…rune in bufwindow

Neko-Box-Coder · 2025-09-06T20:53:41Z

@JoeKar
Maybe we should close #2539 and #2707 ?

Neko-Box-Coder force-pushed the MoreCharOptions branch 4 times, most recently from 22c9b6f to f2c18b2 Compare May 25, 2025 00:10

JoeKar reviewed May 26, 2025

View reviewed changes

internal/config/settings.go Outdated Show resolved Hide resolved

Neko-Box-Coder force-pushed the MoreCharOptions branch from f2c18b2 to 5acc8f4 Compare May 27, 2025 18:35

JoeKar reviewed May 27, 2025

View reviewed changes

internal/config/settings.go Outdated Show resolved Hide resolved

internal/config/settings.go Outdated Show resolved Hide resolved

Neko-Box-Coder force-pushed the MoreCharOptions branch from 5acc8f4 to 8b92972 Compare May 27, 2025 21:05

dmaluka reviewed Jun 1, 2025

View reviewed changes

Neko-Box-Coder force-pushed the MoreCharOptions branch from cb54c9a to a559fc4 Compare July 13, 2025 23:48

dmaluka reviewed Jul 19, 2025

View reviewed changes

Neko-Box-Coder force-pushed the MoreCharOptions branch from a559fc4 to e660625 Compare July 19, 2025 13:46

dmaluka reviewed Jul 19, 2025

View reviewed changes

Neko-Box-Coder force-pushed the MoreCharOptions branch 5 times, most recently from f872c3b to 814322a Compare July 20, 2025 14:34

dmaluka approved these changes Jul 20, 2025

View reviewed changes

JoeKar reviewed Aug 19, 2025

View reviewed changes

internal/display/bufwindow.go Outdated Show resolved Hide resolved

internal/display/bufwindow.go Outdated Show resolved Hide resolved

internal/display/bufwindow.go Outdated Show resolved Hide resolved

Neko-Box-Coder added 3 commits September 6, 2025 16:42

Splitting draw out to getRuneStyle in bufwindow, removing @ for wide …

7b01fe4

…rune in bufwindow

Simplifying draw to be less nested

532c315

Adding showchars option

1ef6459

Neko-Box-Coder force-pushed the MoreCharOptions branch from 814322a to 1ef6459 Compare September 6, 2025 15:48

JoeKar approved these changes Sep 6, 2025

View reviewed changes

JoeKar merged commit 45342bb into zyedidia:master Sep 6, 2025
6 checks passed

This was referenced Sep 7, 2025

Display indentation level on files using spaces (indentchar). #2539

Closed

Feature request: show tabs as dashes and spaces as dots when highlighting them #2707

Closed

Show invisibles (whitespaces, tabs, newlines...) #431

Open

ninetailedtori mentioned this pull request Dec 12, 2025

showchars option doesn't work with multiple characters, which is suggested in the options help page. #3938

Closed

Adding indenttabchar, indentspacechar and spacechar options #3760

Adding indenttabchar, indentspacechar and spacechar options #3760

Uh oh!

Conversation

Neko-Box-Coder commented May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmaluka commented Jun 1, 2025

Uh oh!

Neko-Box-Coder commented Jun 1, 2025

Uh oh!

dmaluka commented Jun 1, 2025

Uh oh!

Neko-Box-Coder commented Jun 1, 2025

Uh oh!

dmaluka commented Jun 1, 2025

Uh oh!

Neko-Box-Coder commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmaluka commented Jun 1, 2025

Uh oh!

Neko-Box-Coder commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmaluka commented Jun 1, 2025

Uh oh!

Neko-Box-Coder commented Jun 1, 2025

Uh oh!

dmaluka commented Jun 1, 2025

Uh oh!

Neko-Box-Coder commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmaluka commented Jun 2, 2025

Uh oh!

JoeKar commented Jun 2, 2025

Uh oh!

Andriamanitra commented Jun 2, 2025

Uh oh!

JoeKar commented Jun 2, 2025

Uh oh!

Neko-Box-Coder commented Jun 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmaluka commented Jun 2, 2025

Uh oh!

dmaluka commented Jun 2, 2025

Uh oh!

Neko-Box-Coder commented Jun 2, 2025

Uh oh!

dmaluka commented Jun 3, 2025

Uh oh!

Neko-Box-Coder commented Jul 13, 2025

Uh oh!

dmaluka commented Jul 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Andriamanitra commented Jul 13, 2025

Uh oh!

Neko-Box-Coder commented Jul 13, 2025

Uh oh!

Neko-Box-Coder commented Jul 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmaluka commented Jul 13, 2025

Uh oh!

Neko-Box-Coder commented May 24, 2025 •

edited

Loading

Neko-Box-Coder commented Jun 1, 2025 •

edited

Loading

Neko-Box-Coder commented Jun 1, 2025 •

edited

Loading

Neko-Box-Coder commented Jun 1, 2025 •

edited

Loading

Neko-Box-Coder commented Jun 2, 2025 •

edited

Loading

dmaluka commented Jul 13, 2025 •

edited

Loading

Neko-Box-Coder commented Jul 13, 2025 •

edited

Loading

Neko-Box-Coder Jul 20, 2025 •

edited

Loading