Closed samarulmeu closed 2 years ago
Hello @samarulmeu, I don't think I really need to do anything here, you can define your own syntax highlighting groups which load only for markdown files for exactly these kinds of use cases. Additionally, you can link your highlight groups to groups provided by mkdx so that they are highlighted the same way.
For me to implement this wouldn't be that difficult, but it seems a bit niche to me and I don't want to add say another option because some users may not want this "by default" for example, which in turn will require me to add more documentation.
I would probably start looking at :h highlight
to learn how to create groups and :h highlight-link
to learn how to link them. To learn about the highlight groups mkdx uses internally, you can use :h mkdx-highlighting
. You'll probably want to put these groups in a file which only loads for markdown as well which requires looking into :h after-directory
(superuser on vim highlighting for specific filetypes).
It's a ton of info for sure but tinkering with Vim like this is what makes it so awesome amongst a vast amount of other things which also make Vim awesome of course :)
In any case, cheers for the suggestion but in this case I am going to close it, if you disagree I'm open to listen to reason 👍
Hello @SidOfc!
I can understand your point in seeing my request/suggestion as a bit niche and in a way you are right. Although :grin:, I looked into the "official" markdown specification and, although not specifically stated, all the examples show headers starting always with a space after #
.
Now it is common to consider that #tag
is actually a tag and not a header and some problem appears also on folding. What I am showing you now was annoying me from a long time. You can see how in a piece of code starting #
messes up with the folding, not with the highlighting I must admit.
I did not reopened the issue, but maybe it will be nice to have an option to turn on/off for this? :grin:
So this issue actually has a different underlying reason if I understand correctly. Is mkdx folding enabled which is causing this issue for example?
Additionally, this is one feature coming from "just" one user, but it requires adding "yet another" option. Adding options requires documenting them, requires keeping into account everything else that has to interact with them.
It's barely ever simply "just an option". As I mentioned in my previous post this plugin already supports nearly 50 customization options, at some point I feel like I have to stop bending over backwards for the really niche stuff because this plugin's code is already a bit of a monster 😅
I understand your frustration and that you've sat on this for some time but I would strongly advise to disable mkdx folding if enabled and to use something else which will do it properly instead.
I apologize for not wanting to implement this, but I do hope you can understand why I am reluctant to do so from a "plugin author" perspective.
So this issue actually has a different underlying reason if I understand correctly.
More or less. I still think that in an markdown file only lines starting with #
should be considered as Heading 1, and lines that start like #some_word
not be considered Heading 1.
Is mkdx folding enabled which is causing this issue for example?
Actually the folding is working as expected in mkdx, but, as mkdx supports only fence and toc, I have some other function for folding. Maybe I should improve that.
I understand your frustration and that you've sat on this for some time but I would strongly advise to disable mkdx folding if enabled and to use something else which will do it properly instead.
I apologize for not wanting to implement this, but I do hope you can understand why I am reluctant to do so from a "plugin author" perspective.
It is OK. No problem. I understand your approach.
Hi @samarulmeu, I actually had the great idea to just "try" #some_word
in the very editor we use to write comments, turns out I'm just ignoring the spec for some reason because:
does not look like a H1 to me. This also means your thoughts are actual "fact" 😅
Since this is the case I feel like I can't "break" anything actually. That said, this also means no option is required which in turn should make this easier to implement. Don't know why I didn't think of this sooner, but I suppose it's better late then never.
With the above in mind I apologize for the naive stance, please disregard my last comment. I'm reopening this and will try to make quick work of it.
I ended up doing the "inverse" by creating mkdxTag
instead of overwriting markdownH1
as that would require me to keep it up to date with the original implementation used in Vim. This will make sure that #nonwhitespace
will be highlighted as mkdxTag
.
I'm not sure if you have the ability to close this issue, but I'll let you confirm if this works for you regardless.
Hi @SidOfc ! Thank you so much! Now I think it is as it is supposed to be. There is still a small issue and for the moment I can not check it: now the heading 2 and heading 3 do not seem to highlight differently, they are just tags. Maybe eliminate #
that it is followed by one or more #
from mkdxTag
, so that markdown headings are not affected.
Now the picture I attached above looks like this:
Again thank you! :rocket:
@samarulmeu should be fixed too now, cheers for the suggestion, I've checked and they all look good now 👍
Will re-close this but if it's still broken for you then feel free to respond here of course :)
Yes. All good. Thanks again! 🎉
No problem, thanks for your patience and understanding as well, much appreciated :)
Enjoy!
Hello again!
I am trying to enter the world of Zettelkasten using vim. More or less the workflow is working and I can generate tags and navigate them. There is something a little bit annoying in the way that a tag (like
#tag1
in the picture below) is displayed. I am wandering if it not possible to be displayed the way#tag2
is. So if we have#space
be considered a heading and#character
be considered a tag.Hope I was clear enough and there is a solution for this.
All the best!