emanote

emanote copied to clipboard

I notice my tags list is flooded with tags of the form #[\d+], coming from the titles of issue tracker links. Looking at the source I see the hashTagSpec follows CommonMark's allowing other inline elements in link titles, ie ital bold #hash. Still, in the case of hashtags my gut says they should be disallowed in the titles of other links (mostly because I want to be able to drop links from the browser without sanitizing the titles), also Obsidian doesn't parse them. WDYT?

Originally posted by @edrex in https://github.com/srid/emanote/discussions/166

Reading WikiLink.hs, I see that wiki links are also parsed in markdown link text. BracketedSpec disallows nesting links in the link text, but I'm not sufficiently familiar with Haskell or parsers to clearly see how to similarly disallow nesting WikiLinks and HashTags

FTR, using \ will disable parsing of that inline tag, eg: \#foo. See the commit above.

Obviously, the ideal way is to have a way to control this globally so that these \ are not required.

Maybe add a logic which parse #SomeText in the following cases:

1. It is a beginning of a new row.
2. No space between # and the text.
3. No text after the adjacent text unless it is another # (Support list of tags).

If we want to follow Obsidian Tags then no spaces in the tags as well and a tag can not be composed of digits only.

Reading WikiLink.hs, I see that wiki links are also parsed in markdown link text.

Related: #349

Note that the embedding wikilinks (at least those that embed images) should be parsed in the link text.

---

I tried implementing an workaround using a Pandoc filter that converts the tag Spans nested in link descriptions to their Inlines contents, but , but run into some obstacles, like handling of:

[see *issue #12345* on github](https://github.com/srid/emanote/12345)

The problem is that the second * is parsed as part of the hashtag.

Another nasty example:

[#abc{.someclass}](def)

On the other hand, as far as I understand, the discussion in https://github.com/jgm/commonmark-hs/issues/97 implies that this may be difficult to handle during parsing using commonmark-hs. Perhaps switching to Pandoc parser #264 is the way to go?

---

I don't think the "good first issue" tag is appropriate.