Advanced Tables Plugin

[aleksandrk]

Thanks a lot for your quick reply. The formula you gave works. Seeing as the answer is so obvious I started looking at why I had problems. I was trying to multiply by a decimal number, like 1.1, and I am not able to do it. Is there something to take into considerations with decimals? Here is the formula I am setting up:

<!-- $>=(($4 * 0.8)+($5 * 1.2)) -->

[tgrosinger]

Ah, it looks like you have found a bug. Thank you for reporting it. I have filed an issue here: Algebra with decimals cannot be parsed in formulas · Issue #18 · tgrosinger/md-advanced-tables · GitHub

I haven’t been working on that project for a bit though, so I’m not sure when I’ll be able to get back to that one. But when I do I’ll be sure to fix that

[aleksandrk]

Thanks. I hope you get to it and that the plugin continues growing. Your implementation of tables is very helpful and before it I did not use tables in Obsidian. I realize that formulas are a bit of an advanced use case here though.

Have you considered monetizing development? I mean in the sense of allowing people to vote/support bugs/features with their money. This type of system has been on my mind for ages, but I don’t actually know whether it’s been implemented, so I my suggestion may not even possible.

[tgrosinger]

@aleksandrk

Have you considered monetizing development?

There are some links to ways you can support me in the plugin settings page and in the Github sidebar. But of course the contributions are completely voluntary.

[Grey]

Is there a way to put to do items in a table? The usual formatting of - [ ] doesn’t render correctly.

[tgrosinger]

Hey @Grey, unfortunately I do not believe that there is. Advanced Tables only has an effect on table editing, not how they are rendered in preview mode. This might be something you could post about in the feature request section though to see if the Obsidian developers could work on it. You’re definitely not the first to ask.

Here’s an similar question.

[chchen]

The Advanced Tables Plugin finally resolved the pain of having to calculate the sum outside of the markdown file. Thank you!

I have a problem on my macOS (Big Sur 11.5.1) that I do not know how to fix. The -- > at the end of the formula is rendered as -->. Even in this post, I had to put a space in between -- and > otherwise it will render as an arrow. Interestingly, Obsidian can still process the formula correctly.

I know it’s not a problem with the plugin, but could not figure out how to turn it off.

[tgrosinger]

@chchen

The -- > at the end of the formula is rendered as →

@chchen, this is just Obsidian trying to be helpful with displaying those characters together as an arrow. If you open the file in textEdit you’ll see that it is still the expected --> . I don’t think this is something can be turned off, but it also isn’t causing a problem.

This syntax is used because it is an HTML comment, which prevents the formula from being rendered in preview mode.

[chchen]

Thanks for the explanation. When I first tested f(x) and it was not working, I thought the errors were caused by the automatic arrow thing and had to open another editor to be sure.

A suggestion: maybe you can make the HTML comment also monospaced? That will clear the confusion for new comers.

[MrTunio]

Tables dont work in preview mode (it just remove all spaces, breaks width and view of the table), also tables menu (align, move column etc) dont work. Why?

[chchen]

I use Obsidian and Typora interchangeably, and noticed that the Advanced Tables Plugin somehow knows that edits have been made outside of Obsidian. Formulas no longer work after outside edits, e.g. a row deletion in Typora. This behavior took me a while to figure out as I thought markdown files are plain text and are blind to platforms. Is there a fundamental limit or is it a fixable bug?

By the way, I just found out that the Advanced Tables Plugin can carry out algebra with units in the table. Although it basically ignores the units, it is still better than Excel, which refuses to proceed when numbers are mixed with units. Great job!

[Klaas]

@chchen : good point. I also use both, and I use Typora mostly for my journal, which is table-rich. The tables in Edit mode in Obsidian drive me nuts, so I am using Typora while eagerly awaiting the WYSIWYG feature in Obsidian before I transfer them all.

In other words, I had not picked up this issue …… yet …… and hope Tony can fix it.

[chchen]

OK, I think I figured out what was going on. Every time when I do some edits in Typora, the formula line (html comment) is automatically reformatted by Typora as the bottom row of the Table. So all that is needed is to delete a few “|” on the formula line. Occasionally, Obsidian (or Advanced Tables) is so confused by the editing that a relaunch is needed, but it’s really not a bug of Advanced Tables.

Like I suggested above, it will help to get rid of the automatic conversion of -- > to an arrow. This unnecessary conversion confuses the formatting of the formula/comment line and makes debugging so much harder.

[Klaas]

@chchen

Like I suggested above, it will help to get rid of the automatic conversion of -- > to an arrow.

That can be due to a ligatures-supporting font, like e.g. Obsidian’s default Inter font, or to the Smart Typography plug-in.

[chchen]

@Klaas Thanks for the suggestions. I did not have Smart Typography installed, but installed it after seeing your message. It did not help the automatic arrow conversion with all the options I could try.

Not sure if ligature is the cause but I cannot find the default css (it is quite easy to locate in Typora), so I do not know how to change it.

[Klaas]

@chchen Smart Typography will convert -> into an arrow.

Don’t change the default Obsidian CSS, use a snippet instead in which you define a different font if that’s what you want.

[chchen]

Thanks for the tip. I played briefly with css snippets. Because of the arrow conversion, the second half of the formula is no longer taken as part of the HTML comment. For now, the best I can do is to match the comment color with that of the normal text. It’s not ideal, but still easier to notice when table boarders are inadvertently added around the comment. Here is the snippet:

/* html comments in editor */
.cm-s-obsidian span.cm-comment {
  color: var(--text-normal);
}

@Klaas: thanks for putting together the useful snippet collection on GitHub.

[Klaas]

@chchen I am not sure I understand your 1^st paragraph. Going back to your original comment, though, I understand that ligatures, esp. the -> one, pose a problem.

If that is still the case, why not change the font altogether? Obsidian’s default font is Inter, which supports ligatures. If you change the font to a non-supporting one with a snippet, you’re done.

[chchen]

@Klaas, I changed the body font to Menlo, and this indeed solves the artificial arrow conversion. However, the formula line is still messed up in terms of formatting.

@tgrosinger, please pay attention to this screenshot. It looks like the complex formula (not the arrow conversion) is confusing the parsing of html comment, and this is probably fixable within the Advanced Tables Plugin.

Notes added: It’s the $ sign that messes up the comment parsing. Compare the two screenshots, one with $, the other without $:

[Klaas]

@chchen Menlo is a very nice monospace font. In fact, recently I came to realize that I find monospace font much easier to read because the letters are relatively widely spaced. So, because I emulate the WYSIWYG feature with various CSS bits and pieces, I am using monospace font in bothe Edit and Preview modes.

My favourites are Monaco and Space Mono. Furthermore, I like dark modes, so in my browser I use the Dark Reader extension, which also allows me to set the font for webpages. The font I use there: Monaco.

Sorry for my off-topic rant, I just thought it might be useful to share.