Zettlr: Strike-through in links & image/table previews [Feature Request]

Created on 11 Jan 2019 · 8Comments · Source: Zettlr/Zettlr

Hello, just discovered this app today.

Love the folding headers. A boon to long documents. So is the TOC feature. Thank you for the hard work.

Possible bugs?

Strike-through ~~ doesn't work with links. [~~text~~](https://text.text) comes out as ~~text~~.
No visible changes to inline code blocks (`text`) or code blocks(```). It all looks like a single wall of text.
No markdown table styling/preview.
No images preview.
# for headings pop up tag list

Feature Request

Html tag support. Can be useful with <br> or per document css.
==text== or <mark> highlight support
Custom font support maybe?

UX enhancement

Source

subi54

Most helpful comment

Yes, it will! I'm currently waiting for the build toolchain to come back online, and then I'll get to building!

I've been solving some final issues today, so it should only be a matter of days!

nathanlesage on 1 Feb 2019

🎉1 👍1

All 8 comments

Heya!

Puh, this is quite a list, and difficult to maintain as a group. Maybe we should split this up into at least two issues, but first let's get this sorted out!

Concerning the strike-through: The problem is that internally Zettlr only searches for such links and renders them as a simple <a>-tag. This means there is no inside-links markdown conversion, and I'm hesitant in implementing it. (After all, it's thought as a preview). But now that you mention it … hm.

But after all: It's not a bug, but it's not a feature either. (i.e. it should be a feature request!)

Concerning the styling of inline-comments: The font is indeed rendered as monospace-font (see image below), so I'm not quite sure I understand what you mean by this! Could you elaborate on this further?

The Markdown Tables are also not bugs, but non-implemented features. I have been thinking about this for some time now, because it annoys me as well. This should definitely be an individual issue/feature request.

No images preview? It's one of the most visible features of Zettlr, so maybe there's something wrong with the detection of images? Because normally this should work fine! Can you explain how it happens that you can't see image previews? Is the respective option ticked in the preferences?

This is something unavoidable, because just as headings, tags can pop up at the beginning of a line. Also, I don't want to change the character used for tags (#), because it's extremely common and therefore reduces the friction people experiencing when writing tags. It's somewhat "universal" since Twitter started it a decade ago. (Holy, I just realised that Twitter is a decade old, and Facebook is even older!)

Concerning your feature requests: The HTML-tag support is something I've been thinking about implementing since Typora has announced to support this (actually, I think Zettlr is in some kind of unannounced competition with Typora in who can implement the most features, because many features of Zettlr are implemented in Typora some weeks later. But I'm not sure if this is not only a simple coincidence.)

What do you mean with ===text=== or <mark> highlight support? Do you mean certain modes that I should enable in the multiplexer, such as javascript syntax highlighting? If so, please open up an individual issue asking for this and provide the mode names!

The font request has reached me multiple times now, but I'm still convinced that first some theme support would be nice (I plan to implement three themes: the current one using sans-serif font, a serif-font-theme and one minimalistic with monospace font). Thoughts?

nathanlesage on 11 Jan 2019

👍1

Hey,

Thank you for the swift reply and sorry for dumping it all into one.

Strike-through, I don't really get the science behind it but what you are saying is that the render-er is searching for <a>. Then, can't the render-er do something like <s><a></a></s> where <s> is ~~text~~?
Inline comments. You are right, there is a difference though it is subtle for me. Personal preference I suppose but it could be solved by customized fonts.
Markdown tables is kind of basic now, even Simplenote supports it. It is useful, it also diversifies your user base.
I played around with images and the problem was spaces before and after links. I had two on each end. Will have to edit somethings but this was my bad. Apologies.
Tags on # is universal now and indeed unavoidable. You could have it detected when # is the first thing in the line but some people like to add tags in a separate lines at the top or end of the document.
HTML-tag is necessary to a few ends. It opens up <style>. Put it in a document and you can do CSS per document basis. Also opens up <img src>. I am not aware of Typora's features, last I checked it out, found it clunky, slow. I do love joplin though.
I meant neon yellow text background. Some markdown apps support ==text== as highlighted text like <mark> does for HTML. You see something important, highlight it.
Themes: you have a night and day mode, basics covered. And the UI is intuitive. You could maybe try customized font size first maybe. Try Menlo and IBM Plex Mono fonts, might like them.

subi54 on 11 Jan 2019

Alright, thanks for the clarification!

Concerning the markup inside rendered links, I'll check with the CommonMark specification to add support for the inline tags allowed within Markdown links!

Concernong the inline comments: Do you have any recommendation on how to make it more distinguishable? Requirements: Inline comments should not have a background color, and should be monospaced at all cost.

Concerning the images: I'll again check with CommonMark specifications and see whether or not spaces may be permitted, in which case I will adapt the renderer to respect this!

Concerning the tags: Well, as you said, there's not going to be any change …

Concerning HTML-tags: I see your point and will do some research into how to best accomplish this!

Concerning the marking: I now get what you mean! I'll look into it!

nathanlesage on 12 Jan 2019

👍1

Hey, thanks for getting back.

Yes, I think I have seen rendered links with strike-through both as [~~text~~](text.text) & ~~[text](text.text)~~. [~~text~~](text.text) in GitHub comes out as ~~text~~.

Inline code: Monospace is a must, of course. Why not a bg color though? Usually its just enough difference to distinguish the main bg from the inline code one. Like #FFFFFF bg to #F8F6F7 code. Or just like here on GitHub, a bit of silver-greyish tint.

subi54 on 12 Jan 2019

Inner inline elements are now supported in rendered links.