sobjornstad/TiddlyRemember

Ignore curly braces contained within a code block

Closed this issue · 4 comments

grooveboxunited commented

Hi Soren.

A cloze card like the following causes a sync error, presumably because of the open curly bracket:

<<remembercz "20210710114236368"
    """
        ''CSS: ID selector syntax''
        <br><br>
        {`#`}`id-name {...`
    """
>>

In my opinion TiddlyRemember should ignore curly braces contained within a code block. It seems reasonable to assume that there are many cases where a user might want include a curly bracket in a cloze card without also invoking a new cloze element.

Thanks for the great plugin.

sobjornstad commented

I agree this is tricky, although what about cases where the user does want the cloze inside a code element?

What is the sync error specifically? Mismatched braces since you don't have a } for the second pair?

Single curly braces really stink as a cloze delimiter in cases like these – Anki's double braces are much better – but double and triples are already taken in TW, and square brackets are even worse!

grooveboxunited commented

What is the sync error specifically? Mismatched braces since you don't have a } for the second pair?

Yeah: ValueError: expected '}' before end of string

I agree this is tricky, although what about cases where the user does want the cloze inside a code element?

Well the only thing I can think of is to close the code element before adding the curly braces, then open it again. This is what I tried to do in my example:

{`#`}`id-name {...`

This is obviously pretty awkward, and will only work with inline code I suppose.

I guess the choice is between not being able to use clozes on code that contains a '{', or not being able to use clozes within a code block. I'm not sure which is worse.

Maybe TiddlyRemember could ignore '{' if it doesn't find a closing bracket on the same line, rather than giving an error?

SonephetR2 commented

I agree this is tricky, although what about cases where the user does want the cloze inside a code element?

Couldn't having an escape character be a way of making sure the user's intention is clear?

In the meantime, I discovered the use of ⦃white curly brackets⦄. It's a plain workaround on the user's side, easily added to Autokey/Autokey or what not (strangely I couldn't it to work with <Multi_key> on .Xcompose as of yet). @grooveboxunited <Multi_key> <{> <{> or <Alt_gr> <{> <{> is a non-intrusive way to yield ⦃ without having to wait for an "airdrop". Maybe it'll fit your workflow as it does mine.

… Actually, maybe ⦃⦄ could even be the end result of character replacement operated by TiddlyRemember to avoid having to deal with too many real curved brackets!? Just an very roughhewn idea here :)

sobjornstad commented

In the next version, you will be able to escape braces that you don't want to become part of a cloze delimiter with \{ and \}. This might be a little irritating to write inside code blocks that are heavy on braces, but it saves the parsing code from having to understand where code blocks are, which would require a rewrite of the cloze parser since it currently selects occlusions via a simple regex and regexes aren't really capable of understanding HTML doctrees. If this proves inadequate, we can revisit the question of making it do something different in code blocks.

  • 🎉1