vscode-journal interprets pipe characters | as table delimiters?

[Andy Gimblett]

Overview

It seems that while this extension is enabled, anywhere a pipe symbol — i.e. | — is present, it's being seen as somehow marking a table column, so a table appears in the rendered (or at least previewed) HTML.

This is problematic in a number of cases; in particular I've been bitten by the following, but I bet there are others:

• Many web pages contain pipe symbols in their titles, and markdown links containing those tables are thus rendered incorrectly. I have hundreds of these in my notes, all of which are now affected.
• If rendering maths inside markdown we often use pipe symbols.

AFAICS this is undocumented behaviour; there is some mention in the docs of syntax highlighting modifications but none of that seems related to this (e.g. if I delete those settings this problem persists); it really looks to me like the extension is altering how markdown is rendered to HTML, which I don't see mentioned anywhere in the docs.

What I like about this extension — and what I use it for — is that it allows me to easily manage journal-type documents within my markdown notes. I have plenty of other extensions, styles, etc. handling how those notes are rendered, and honestly I would prefer that this extension left all of that unchanged (or at least gave me the option to disable whatever it does). For now I have to leave this extension disabled, and only re-enable it when I want to create a new journal entry, which rather defeats the purpose as it's no longer quick and easy to do!

Tables in VSCode

VSCode supports GFM tables by default (via the markdown-it library); the GFM rules say:

A table is an arrangement of data with rows and columns, consisting of a single header row, a delimiter row separating the header from the data, and zero or more data rows.

This extension breaks that contract in an unexpected way. Please can we fix that?

How to reproduce

1. Make a fresh install of VSCode
2. Open the attached example.md for editing
3. Open a preview window (e.g. command "Markdown: Open Preview Window")
4. See that everything renders as normal
5. Install this extension
6. Reload the window
7. See that the preview is now looking weird and wrong.

Screenshots

Without vscode-journal extension

Here's how it looks on a completely fresh VSCode install, with no extensions whatsoever; as you can see, the only table rendered is the properly-formed GFM table at the end, and anywhere else that the | symbol appears, it's just rendered normally (including interpreting it properly in the maths context).

With vscode-journal extension

And here's how that looks when we install the vscode-journal extension; as you can see, suddenly we've got tables appearing where we have no desire for tables.

(I've just noticed that the code example is rendering OK in both versions, which is interesting because in my "full installation" that gets affected too, and disabling the extension fixes it — but for some reason the problem isn't showing up for me in this minimal setting. shrug — here's how it looks in my "real" VSCode (different CSS of course):

So the pipe symbol is still present but you can see it thinks it's a table: it's centred and has horizontal lines at top and bottom, which is how I have tables rendering in the preview — and as illustrated by the $|x|$ example also seen in the screenshot.)

System Information

• vscode-journal v0.11.2

• VSCode:

  • Version: 1.62.3
  • Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247
  • Date: 2021-11-17T08:14:33.711Z (1 wk ago)
  • Electron: 13.5.2
  • Chrome: 91.0.4472.164
  • Node.js: 14.16.0
  • V8: 9.1.269.39-electron.0
  • OS: Darwin arm64 20.6.0

• MacOS Big Sur 11.6.1

[Andy Gimblett]

Ah. I guess it's this, in package.json:

  "dependencies": {
    "markdown-it-synapse-table": "^1.0.6",
    "markdown-it-task-checkbox": "^1.0.6",
    "markdown-it-underline": "^1.0.1",
    ...

So markdown-it-synapse-table is the culprit, right? Why are you adding markdown-it plugins that have nothing particularly to do with journalling? I don't want that plugin. I don't want the other two either, to be honest, but at least I haven't noticed any problems arising from them yet.

[Patrick M]

First of all, thanks for your very detailed bug description.

Regarding the problem: Yes, I never bothered to remove the table dependency, because it didn't work then. I tried to use it for tracking the time spent on my daily tasks.

[Andy Gimblett]

Ah, I see... so it was a helper component for a feature which never quite shipped, essentially?

I have to say, if it was about ease-of-use when working with those tables, I think VSCode has excellent support for both editing and rendering tables in the more standard GFM format, with the right extensions. E.g. I can type the following, without paying attention at all to proper layout:

| A | B | C |
|-|-|-|
|thing|     other  |

and when I hit save it automatically gets formatted nicely:

| A     | B     | C   |
| ----- | ----- | --- |
| thing | other |     |

I believe this auto-formatting is enabled by the Markdown All in One extension; then the Markdown Extended extension provides some nice commands for table manipulation (e.g. "paste as table", "add columns to left", and so on. So having a good and powerful table-editing experience isn't hard to achieve with VSCode, I think — and even without those extensions the basic GFM tables don't seem to me much worse to work with than the synapse ones (but maybe I'm missing something?).

Again, I'd see all this as an orthogonal concern to providing good journalling functionality; if you want tables for tracking stuff just use the GFM tables you get for free? Point people to the other options if they're interested? (Synapse support could even be an optional feature, perhaps?)

Anyway, thanks for getting back to me. Good to know the use case you had in mind! I've still left the journal extension disabled but if you do an update removing the synapse dependency I'll gratefully re-enable it. 😀

[Edward Delaporte]

Great update! Thanks for the work on this!

[Andy Gimblett]

Finally got round to trying this again too, and I agree, it's a great and much appreciated update! Thanks very much for your work on this! 🙏🏻