-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Title and Excerpt line breaks #46
Comments
could you post a link to the readme and a copy of the resulting output? |
Of course! This one may also be a twofer in weirdness; when targeting the Readme file in GitHub repositories, I would sometimes get the content but sometimes I would get the GitHub wrapper instead. I'll try to structure some proper repeatable tests because my quick and dirty approach was to just retry "until it worked". |
Example
Properties view wrapping does not indicate that the extra spaces or line breaks are in excerpt: Recent Log
{
{
{
{
{
"url"
"og:url"
"parsely-link"
"twitter:url"
{
"author"
"article:author"
"parsely-author"
"cXenseParse:author"
{
"og:site_name"
"page.content.source"
"application-name"
"apple-mobile-web-app-title"
"twitter:site"
{
{
"article:published_time"
"parsely-pub-date"
"datePublished"
|
When I target: when I target: Any github README seems to randomly have this issue, and sometimes just re-trying works. Whenever it "works" however, the line breaks / extra spaces issue exists if the content is more than one line long for excerpt and title. |
the github wrapper thing is a bit weird. all three of those links work for me. i'll try it a couple more times to see if i can narrow it down but tbh, i think rather than troubleshooting this it would make more sense to handle this as a preprocessing hook (see #37). ie: if github link and ends with .md, use the raw md file content rather than the parsed output. regarding the newlines, it looks like the yaml lib i'm using is adding those newlines without adding the yaml syntax for a multiline string. can you try replacing the excerpt property directly in source mode with the following and see if that fixes your issue? excerpt: >
Lists the authors of projects on the Manage Modules Window. If a url is
provided in the module.json file, it will make the version tag link to the
module url. - mouse0270/module-credits |
That doesn't help; any line breaks are parsed by other apps as separate frontmatter values. That said, it's a loose standard at best. I do think this is the least impactful / most compatible end result to have, so that's what I'm presenting, but I'm also going to poke around to see if I can reference more definative guidance on this point. Another tangent is whether maintaining formatting of the excerpt is more important/useful than it possibly clashing with Obsidian Add-Ons. I can see reasons for and against that - it's not obvious to me which answer is the best one at this moment. |
I disagree completely. Multi-line strings are well-supported by YAML in multiple ways. Obsidian specifically states that note properties are YAML-formatted and they have nothing to say on multi-line strings.
Lots of websites publish multiple paragraphs in their excerpt (eg: academic journals that put a paper's abstract into the excerpt metadata), so it's important for slurp to ensure that the YAML lib respects existing line breaks. In this case, the YAML lib is adding line breaks and that might be a behaviour I can change. Beyond that, Slurp's goal is to capture information, so it's important for Slurp to stay as true to the original content as possible. If other plugins aren't handling well-formatted YAML when processing note properties, then I'd recommend requesting proper YAML support from them. YAML is a complex specification, relying solely on regex to parse it will be a lot of work to maintain. |
I was probably unfair in the negative. I was referring to things like this: https://en.wikipedia.org/wiki/YAML#Criticism where StrictYAML and similar endevours came in response to. All that said, I'm happy to agree with you and obviously Obsidian targets YAML as a standard.
When this ticket started, I was not clear on exactly what "correct" was supposed to look like in the first place, so much of this was thinking out loud to some degree. I agree with you completely now. I went digging for some clarity over discord and the web and essentially ended where you are. At this point, I've tested in multiple YAML validators to ensure what "correct" is supposed to be and what you output is supported by that, so the behavior issue is clearly with Linter in this case. Thank you for working through that with me! |
I'm pulling some ReadMe files from GitHub and the Excerpt / Titles seem to be saved in the YAML with line breaks and extra spaces that don't show in the Properties view, but is problematic when I try to rearrange property order using Linter.
Is this part of the known bug experiences?
The text was updated successfully, but these errors were encountered: