By default this plugin does not style the note (beyond a few small helpful changes). The plugin focuses on function, namely clickable links and images.
I go into more detail (including describing how to get that style) in a comment on GitHub. I do plan on adding some extra styles by default, but it's not a priority for me.
Hi, I'm wondering if there could be CSS code to hide the ID part of a linked file/linked note in a note? The part in red here:
Thank you!
UPD: the link goes to the right manual now
@graphit0 I don't see a reference to that element in the extra CSS section? There is something about reference links not being supported yet but I'm not sure if that is what this element is.
Could you try
span.cm-url {
display: none;
}
inside userchrome.css? It worked for my minimal test case.
In most cases, the corresponding HTML elements can be found by using the developer tools (Help -> Toggle development tools -> Click on the mouse arrow at the top left and hover over the element).
Great plugin!
One question from this newbie though. The custom CSS classes dont' seem to be compatible with the Jira plugin. If I put the JIRA inline on top of the note, the effects of the css are gone. I'm pretty sure this is a mistake in that Jira plugin, but how can I debug? It seems like some of you can see the resulting html and classes within the editor. Is there an easy way to see that?
If you can't add wrapping elements due to CM limitations, is it possible to put classes on existing wrapper elements? Or does CM literally only let you touch a single line at a time?
I've found another case where I want wrapping: lines that are just a single long link. But I don't think I can do this without being able to target a parent element. These parent elements lack a "has-link" class or something to that effect, and Chrome doesn't support :has() until v105 vs. Joplin's v93!
Could you add such a class or am I out of luck until Joplin updates its Chromium version? Thanks!
You can add css that applies to any wrapper element if that's what you mean? But CM breaks the document up into lines, so even if you add scrolling to a code block, you'll get one scroll bar per line.
It's definitely possible to add a class for this, but I suspect the horizontal scrollbar will be a show-stopper for CM. CodeMirror has an internal state of where it thinks characters are, and moves the cursor and adjusts edits based on that state. If we add horizontal scrollbars using CSS, I think the editor will break pretty bad (I haven't tested this).
You can add css that applies to any wrapper element if that's what you mean?
I was wondering if your plugin could add classes to a wrapping element based on its contents -- specifically doing something like going back up to the pre to add .cm-rm-has-link or something like that to it. But it sounds like CM's "one line at a time" setup may make that impossible. And if so, Chromium v93's lack of :has() means I can't do what I want. :c
I think the editor will break pretty bad
I already experience this since I hide URLs in links when the line isn't active. CM seems to get confused about how many characters are in the line and makes cursor navigation a pain until it updates the count. But I'm used to it, and the pros of cleaning up links, one of the worst parts of Markdown in terms of readability (IMO), is worth the cons.
Hello,
Is there a solution ?
I think that I will have the same problem.
Thank you !
really awesome update, thank you @CalebJohn !
one minor thing about the Stylish theme that I noticed, is that the strike-through style no longer strikes through inline code blocks.
Stylish theme
No theme and just using this recommended snippet from the TIPS.
EDIT: when I added the snippet to my userchrome.css it fixed the issue even then the Stylish theme (and token hiding) was being used.
Thanks @shikuz ! When setting up the theme I was tweaking css and accidentally left some of the necessary specifiers out. I've just pushed v0.13.1 which fixes this
!!!) and for the line the tokens are on, but not the in-between lines.@CalebJohn I'm really liking the new updates! I have a few questions/possible bugs though.
"Highlight the background of the current line" option doesn't seem to work anymore?
When I enable the "Stylish" theme, I find it difficult to select the # portion with my cursor. Is there a fix for this?
Should the == characters also be highlighted (stylish theme disabled)? I think it would match better with what is done for the other things if it wasn't.
In dark themes == is barely visible because it is black on a dark background. Also, when used in a list, the text within is not legible since it is gray on yellow.
It still works, but not if you're using focus mode or the hide-markdown option. They end up overwriting the css because of the way they work. It can be added back in your userchrome.css
No fix, most of this advanced styling stuff is just css hacks, so the editor isn't going to be perfect. I tried to find a happy balance.
By default in Joplin the tokens are highlighted for other stylings. The highlight token is designed to match
But I see your point, the background is a bit loud on the tokens. I'll remove the background in the next update.
Thanks for catching that, I'll fix it for the next update.
I've updated that tip now with some extra css that will correct that colouring.
Thanks @shbach for identifying these issues, I've just pushed 0.13.2 which fixes the issues that I was able to fix!
Thanks so much! It looks a lot better/legible.
I tried adding it back using the highlight the active line code but it's just a gray color which I don't think looks as good. Is there a way to modify this so that it does the color scheme the plugin does? i.e. light blue in light theme and black in dark theme?
Understood. Unfortunately, I think the unindent portion is too much of a hack for me. I also noticed that it cuts off the # symbols once I get down far enough.
Which is a shame because I actually really like how it looks.
You can specify for which colour scheme the styling should apply, setting whichever colour you like.
This is good or bad depending on the user, for me the # tokens are completely hidden when the split view is open. It's bad to hide them, but it's nice for readability (it looks pretty cool!). The design intentions around this plugin are focused on the editor full-width use case which hopefully means this won't be an issue for most users, but it's definitely a tradeoff,
This might be beyond me unfortunately. I basically want to reimplement what your plugin does which is different colors for the selected line based on theme and also light/dark. The current code for adding to userchrome.css is only for selecting one color that is used for everything. I'm not sure how to extend that to do what your plugin does which seems a lot more complicated.
Fair enough. I don't think I'm quite ready to shift from split view to using the editor full-width because there are plugins I use such as mermaid graphs that don't display in editor view.
@CalebJohn I think with a recent update, the fix to correct strikethrough colouration no longer fully works. Indented items don't have color.
This is what I see now:
While this is what I see without the fix:
