Closed zanodor closed 11 months ago
Hey @zanodor . I am sorry to hear that you hit problems around the Linter. That functionality currently requires code changes and should be feasible once #392 gets added.
In the meantime, could you provide your data.json
and a sample file to see what may have happened?
Hey there,
From your response I gather that what's happening should not happen?
My data.json:
{
"ruleConfigs": {
"escape-yaml-special-characters": {
"enabled": false,
"try-to-escape-single-line-arrays": false
},
"force-yaml-escape": {
"enabled": false,
"force-yaml-escape-keys": ""
},
"format-tags-in-yaml": {
"enabled": true
},
"format-yaml-array": {
"enabled": true,
"alias-key": true,
"tag-key": true,
"default-array-style": "multi-line",
"default-array-keys": true,
"force-single-line-array-style": "",
"force-multi-line-array-style": "aliases\nalias2\nalias3\ntags\ntopic\nparent_topic\nchild_topic\ntopic_alternative\nrelated_topic"
},
"insert-yaml-attributes": {
"enabled": false,
"text-to-insert": "aliases: \ntags: \nstatus:\npriority:\nclass:"
},
"move-tags-to-yaml": {
"enabled": false,
"how-to-handle-existing-tags": "Nothing",
"tags-to-ignore": ""
},
"remove-yaml-keys": {
"enabled": true,
"yaml-keys-to-remove": "stitched on"
},
"yaml-key-sort": {
"enabled": true,
"yaml-key-priority-sort-order": "obsidianUIMode\ntitle\naliases\nalias2\nalias3\ntype\nstatus\npriority\ntags\ncssclasses\nbanner\nbanner_x\nbanner_y\nshare\ndg-home\ndg-publish\ndg-created\ndg-updated\ndg_upload_status\nclass\ntopic\ntopic_alternative\nparent_topic\nchild_topic\nrelated_topic\nheads-up\nrenamed\ncomment\ndate created\ndate modified",
"priority-keys-at-start-of-yaml": true,
"yaml-sort-order-for-other-keys": "None"
},
"yaml-timestamp": {
"enabled": true,
"date-created": true,
"date-created-key": "date created",
"force-retention-of-create-value": false,
"date-modified": true,
"date-modified-key": "date modified",
"format": "YYYY-MM-DD"
},
"yaml-title": {
"enabled": false,
"title-key": "title",
"mode": "filename"
},
"yaml-title-alias": {
"enabled": false,
"preserve-existing-alias-section-style": true,
"keep-alias-that-matches-the-filename": false,
"use-yaml-key-to-keep-track-of-old-filename-or-heading": false
},
"capitalize-headings": {
"enabled": false,
"style": "Title Case",
"ignore-case-words": true,
"ignore-words": "macOS, iOS, iPhone, iPad, JavaScript, TypeScript, AppleScript, I",
"lowercase-words": "via, a, an, the, and, or, but, for, nor, so, yet, at, by, in, of, on, to, up, as, is, if, it, for, to, with, without, into, onto, per"
},
"file-name-heading": {
"enabled": false
},
"header-increment": {
"enabled": false,
"start-at-h2": false
},
"headings-start-line": {
"enabled": false
},
"remove-trailing-punctuation-in-heading": {
"enabled": false,
"punctuation-to-remove": ".,;:!。,;:!"
},
"footnote-after-punctuation": {
"enabled": false
},
"move-footnotes-to-the-bottom": {
"enabled": false
},
"re-index-footnotes": {
"enabled": false
},
"auto-correct-common-misspellings": {
"enabled": false,
"ignore-words": ""
},
"convert-bullet-list-markers": {
"enabled": false
},
"emphasis-style": {
"enabled": false,
"style": "consistent"
},
"no-bare-urls": {
"enabled": false
},
"ordered-list-style": {
"enabled": false,
"number-style": "ascending",
"list-end-style": "."
},
"proper-ellipsis": {
"enabled": false
},
"remove-consecutive-list-markers": {
"enabled": false
},
"remove-empty-list-markers": {
"enabled": false
},
"remove-hyphenated-line-breaks": {
"enabled": false
},
"remove-multiple-spaces": {
"enabled": true
},
"strong-style": {
"enabled": false,
"style": "consistent"
},
"two-spaces-between-lines-with-content": {
"enabled": false
},
"unordered-list-style": {
"enabled": false,
"list-style": "consistent"
},
"compact-yaml": {
"enabled": true,
"inner-new-lines": false
},
"consecutive-blank-lines": {
"enabled": true
},
"convert-spaces-to-tabs": {
"enabled": false,
"tabsize": "2"
},
"empty-line-around-blockquotes": {
"enabled": false
},
"empty-line-around-code-fences": {
"enabled": false
},
"empty-line-around-math-blocks": {
"enabled": false
},
"empty-line-around-tables": {
"enabled": true
},
"heading-blank-lines": {
"enabled": false,
"bottom": false,
"empty-line-after-yaml": false
},
"line-break-at-document-end": {
"enabled": false
},
"move-math-block-indicators-to-their-own-line": {
"enabled": false
},
"paragraph-blank-lines": {
"enabled": false
},
"remove-empty-lines-between-list-markers-and-checklists": {
"enabled": false
},
"remove-link-spacing": {
"enabled": false
},
"remove-space-around-characters": {
"enabled": false,
"include-fullwidth-forms": true,
"include-cjk-symbols-and-punctuation": true,
"include-dashes": true,
"other-symbols": ""
},
"space-after-list-markers": {
"enabled": false
},
"space-between-chinese-japanese-or-korean-and-english-or-numbers": {
"enabled": false
},
"trailing-spaces": {
"enabled": true,
"twp-space-line-break": true
},
"add-blockquote-indentation-on-paste": {
"enabled": true
},
"prevent-double-checklist-indicator-on-paste": {
"enabled": true
},
"prevent-double-list-item-indicator-on-paste": {
"enabled": true
},
"proper-ellipsis-on-paste": {
"enabled": false
},
"remove-hyphens-on-paste": {
"enabled": false
},
"remove-leading-or-trailing-whitespace-on-paste": {
"enabled": false
},
"remove-leftover-footnotes-from-quote-on-paste": {
"enabled": false
},
"remove-multiple-blank-lines-on-paste": {
"enabled": false
},
"blockquote-style": {
"enabled": false,
"style": "space"
},
"quote-style": {
"enabled": false,
"single-quote-enabled": true,
"single-quote-style": "''",
"double-quote-enabled": false,
"double-quote-style": "\"\""
},
"remove-space-before-or-after-characters": {
"enabled": false,
"characters-to-remove-space-before": ",!?;:).’”]",
"characters-to-remove-space-after": "¿¡‘“(["
}
},
"lintOnSave": true,
"recordLintOnSaveLogs": false,
"displayChanged": false,
"lintOnFileChange": true,
"displayLintOnFileChangeNotice": false,
"settingsConvertedToConfigKeyValues": true,
"foldersToIgnore": [
"assets",
"pages",
"01 notes",
"02 analysis",
"03 writing",
"04 index",
"05 tasks",
"06 archives",
"07 diary",
"08 kanban",
"meta",
"meta/templater",
"02 Home",
"10 Templates",
"01 Index",
"35 Tables",
"70 Web iFrame Sites",
"00 System",
"99 Signs and Symbols",
"80 Omnivore",
"04 Excalidraw",
"A/Templates",
"B/Templates",
"C/Templates",
"D/Templates",
"E/Templates",
"F/Templates",
"G/Templates",
"H/Templates",
"I/Templates",
"J/Templates",
"K/Templates",
"L/Templates",
"M/Templates",
"N/Templates",
"O/Templates",
"P/Templates",
"Q/Templates",
"R/Templates",
"S/Templates",
"T/Templates",
"U/Templates",
"V/Templates",
"W/Templates",
"X/Templates",
"Y/Templates",
"Z/Templates",
"assets/inlineScripts",
"support/inlineScripts"
],
"linterLocale": "system-default",
"logLevel": "ERROR",
"lintCommands": [],
"customRegexes": [
{
"find": "õ",
"replace": "ő",
"flags": "gm"
},
{
"find": "Õ",
"replace": "Ő",
"flags": "gm"
},
{
"find": ",,",
"replace": "\"",
"flags": "gm"
},
{
"find": "„",
"replace": "\"",
"flags": "gm"
},
{
"label": "MAY NOT BE NEEDED remove superfluous YAML dashes from MetaEdit plugin issue",
"find": "(date.*mod.*\\n)|(---\\n---\\n)",
"replace": "",
"flags": "gm"
},
{
"label": "Delete parent folder when or if using AlanG embed script - uses [[A-Z/note]] format",
"find": "(!\\[\\[)[A-Z]\\/(.*?[#]\\^[0-9a-z]{4,10}\\]\\])",
"replace": "$1$2",
"flags": "gm"
},
{
"label": "Remove inline queries",
"find": "\\n\\n^%%\\n```query[\\d\\D]*?^%%",
"replace": "",
"flags": "gm"
}
],
"commonStyles": {
"aliasArrayStyle": "multi-line",
"tagArrayStyle": "multi-line",
"minimumNumberOfDollarSignsToBeAMathBlock": 2,
"escapeCharacter": "\""
}
}
A typical file with typical YAML:
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-10-25
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
On no changes made to the file, date is modified next time I enter it:
Whether or not it should be happening is based on whether or not a rule has made a change. I probably should change the modification check to just happen right before running the date logic, but it checks after each rule runs right now.
I will have to take a closer look to say anything for sure.
For that small file it is easy to check there was no rule that could or should have made a change. As for the rest of the files, they were batch-linted multiple times recently to comply with the changes introduced with the Properties update(s). So basically there should at this point in time no rule triggering a change, unless I make a change myself by typing or inserting my queries with the Templater script (which when exiting the file will be removed by Linter through the custom regex).
Sorry about the delay on getting to look at this issue. I will have to take a look and see if this is happening for me with the file and data.json
provided.
I do want to clarify that there are a couple of conditions that will update the date modified value:
If none of these is happening and the Linter is still updating, it likely is a bug that I will need to address.
For that small file it is easy to check there was no rule that could or should have made a change. As for the rest of the files, they were batch-linted multiple times recently to comply with the changes introduced with the Properties update(s). So basically there should at this point in time no rule triggering a change, unless I make a change myself by typing or inserting my queries with the Templater script (which when exiting the file will be removed by Linter through the custom regex).
I am not sure if this was before the fix was added for this, but there was a bug for a little while where regardless of change being made, the file was saved for any process that was not running on the active file. So maybe that caused the issue you are seeing.
I am not able to reproduce the issue you are seeing in a test vault. Is this issue still happening for you @zanodor ? If so, does it happen when you create and test a new file?
- The date format in the YAML for the date modified key is not the same format as the format specified in the settings
I have always used YYYY-MM-DD
for simplicity and because it is what I've been familiar with from childhood.
Not sure if it is the Properties behind the trigger as I think the Properties pane is just an UI above YAML; there it is month-day-year format but in the underlying frontmatter, I do have YYYY-MM-DD format as in the settings. Before I started using 'File on Change', there's never been an issue.
Just tried a few different files now.
When the tags was empty, Linter or Obsidian Properties put in an empty array ([]
) with the tag, so there I can understand the modification. I have GH Desktop and I could see this change (changes, if I count in the date modified change).
But on another file, there was no change shown on GH Desktop, apart from the file modified date. No date format had to be overriden, nothing.
So for me the problem persists. At this point I don't know how else I can be of assistance.
The only thing I can think of doing thay might help better understand this situation would be if I create a custom version of the plugin with logging just for what is going on in the function.
Would that be something you would be interested in trying?
The only thing I can think of doing thay might help better understand this situation would be if I create a custom version of the plugin with logging just for what is going on in the function.
Would that be something you would be interested in trying?
Sure, if it serves a bigger purpose than satisfying my own needs. Instruct on how to proceed.
I will need to create a custom main.zip
for you to install and run locally. You will then need to copy the contents from the console from the developer tools (ctrl+shift+i on windows and cmd+shift+i on mac) on a linter run that creates the issue. If you post the contents in this thread, it should give me a better idea of what is going on.
Hey @zanodor . Here is the main.zip that you should be able to install and get the logs for it from the console log. That should give me some info to work with. I may need to do this a couple times to get a clearer picture, but I think this one should give me a decent bit of info to look at for now.
Thanks!
I may need to add an extra check in the logic for the difference in time check, but the main.zip
in the previous comment should make that clear if that is the case.
Well, on every file I tried:
date created key exists
plugin:obsidian-linter-test:2460 date creation updated?:false
plugin:obsidian-linter-test:2480 missing date modified key
Not only do I have date modified
with a field value, I have linted all my files at least 3 times in the last 6 months in batch and all my files should have been changed for date modified as well had I had any issues with those fields.
Obsidian Properties panel says on my file modified field that my property type is date.
All settings are the same as give above (I am of course testing Lint on Change here).
Data.json part:
"yaml-timestamp": {
"enabled": true,
"date-created": true,
"date-created-key": "date created",
"force-retention-of-create-value": true,
"date-modified": true,
"date-modified-key": "date modified",
"format": "YYYY-MM-DD"
},
Undo the completed bit, please -- I hit some key or icon wrong.
Well, on every file I tried:
date created key exists plugin:obsidian-linter-test:2460 date creation updated?:false plugin:obsidian-linter-test:2480 missing date modified key
Not only do I have
date modified
with a field value, I have linted all my files at least 3 times in the last 6 months in batch and all my files should have been changed for date modified as well had I had any issues with those fields.Obsidian Properties panel says on my file modified field that my property type is date. All settings are the same as give above (I am of course testing Lint on Change here). Data.json part:
"yaml-timestamp": { "enabled": true, "date-created": true, "date-created-key": "date created", "force-retention-of-create-value": true, "date-modified": true, "date-modified-key": "date modified", "format": "YYYY-MM-DD" },
Undo the completed bit, please -- I hit some key or icon wrong.
Could you provide all of the console logs provided for one file lint? I am not able to get a full picture of the problem with those 3 logs (there should be around a dozen of them).
Well, on every file I tried:
date created key exists plugin:obsidian-linter-test:2460 date creation updated?:false plugin:obsidian-linter-test:2480 missing date modified key
Not only do I have
date modified
with a field value, I have linted all my files at least 3 times in the last 6 months in batch and all my files should have been changed for date modified as well had I had any issues with those fields. Obsidian Properties panel says on my file modified field that my property type is date. All settings are the same as give above (I am of course testing Lint on Change here). Data.json part:"yaml-timestamp": { "enabled": true, "date-created": true, "date-created-key": "date created", "force-retention-of-create-value": true, "date-modified": true, "date-modified-key": "date modified", "format": "YYYY-MM-DD" },
Undo the completed bit, please -- I hit some key or icon wrong.
Could you provide all of the console logs provided for one file lint? I am not able to get a full picture of the problem with those 3 logs (there should be around a dozen of them).
Sure, I just didn't want to copy here long .md file contents and such.
plugin:obsidian-linter-test:2460 created time: 2023-01-18T01:43:13+01:00 plugin:obsidian-linter-test:2460 modified time: 2023-12-14T03:32:41+01:00 plugin:obsidian-linter-test:2460 format: "YYYY-MM-DD" plugin:obsidian-linter-test:2460 locale: en-us plugin:obsidian-linter-test:2460 current time: 2023-12-14T03:32:43+01:00 plugin:obsidian-linter-test:2460 text: --- title: Behest aliases:
File content....
plugin:obsidian-linter-test:2467 date created key exists plugin:obsidian-linter-test:2460 date creation updated?:false plugin:obsidian-linter-test:2480 missing date modified key
Indeed, the date modified key is missing from here. What the heck.
Is there another file that is having the issue?
Is there another file that is having the issue?
I think all are like this. All modified date keys are missing from the console output.
I used to use the two plugins that update date modified but I didn't like them triggering those annoying files automatically merged pop-ups and I disabled them.
Is there another file that is having the issue?
I think all are like this. All modified date keys are missing from the console output.
To clarify, are you saying that the files do not have the date modified key?
Also, are they getting added by the Linter?
Is there another file that is having the issue?
I think all are like this. All modified date keys are missing from the console output.
To clarify, are you saying that the files do not have the date modified key?
Also, are they getting added by the Linter?
I am saying they are physically in the files but Linter doesn't pick them up for some reason. There is no interference with other plugins and YAML checks out with Properties as well.
If it makes any difference, I created the date modfied keys and values in batch with regex in Notepad++ a year ago or so.
But as I said there was plenty of time for Linter to update them if they were wrong in the last 5-6 when I linted each of my folders in preparation for the Properties update.
I linted all files 2-3 times as I was trying to find a good order of keys as well to suit other plugins like the Linked Data Vocabularies, Breadcrumbs, etc.
As one of my Dataview queries is riding on the date modified value and I have 10k+ files, it will be impossible to update them one by one.
Interesting thing would be to go into the same files changed just now tomorrow and see what their status is -- I mean whether they'd be updated for the new day as well without a key pressed in the editor still.
This is a bit odd. Could you upload the file that you posted the logs for?
I ask because the YAML from the logs does not indicate that a date modified key is present:
title: Behest
aliases:
- behest
status: formatted
tags:
- titleandheadingonedontmatch
- multipleentries
- stitched
share: true
dg-publish: true
dg_upload_status: down
date created: 2022-12-14
It may also help to go to the Linter's debug tab and change the log level to trace. You will also want to enable collecting logs on save. Then run the Linter by running the obsidian command to lint the current file. From there, you can go go back to the Linter debug tab which should be able to describe what the file looked like after each rule ran. Uploading or copying the contents of that would help show whether the Linter has a rule that removed the date modified key or if something else is going on.
This is a bit odd. Could you upload the file that you posted the logs for?
I ask because the YAML from the logs does not indicate that a date modified key is present:
title: Behest aliases: - behest status: formatted tags: - titleandheadingonedontmatch - multipleentries - stitched share: true dg-publish: true dg_upload_status: down date created: 2022-12-14
It may also help to go to the Linter's debug tab and change the log level to trace. You will also want to enable collecting logs on save. Then run the Linter by running the obsidian command to lint the current file. From there, you can go go back to the Linter debug tab which should be able to describe what the file looked like after each rule ran. Uploading or copying the contents of that would help show whether the Linter has a rule that removed the date modified key or if something else is going on.
I can see all these things from the GH Desktop app as well as it diffs the content on file change.
More interesting is the fact that I opened and closed the same 3 files in my editor and even if Linter just modified the date (and GH Desktop shows the diff), the next time you open the file, the console again says missing date modified date
.
Linter does not see or acknowledge this property and I don't seem to be doing anything wrong.
I am guessing the culprit is
{
"label": "MAY NOT BE NEEDED remove superfluous YAML dashes from MetaEdit plugin issue",
"find": "(date.*mod.*\\n)|(---\\n---\\n)",
"replace": "",
"flags": "gm"
},
Can you try removing that custom replacement regex and see if it works? The replace value seems wrong for that custom replace.
Edit: I am not cetain what the intent is behind that regex replace,but it will remove all of the matches including date modified.
I am guessing the culprit is
{ "label": "MAY NOT BE NEEDED remove superfluous YAML dashes from MetaEdit plugin issue", "find": "(date.*mod.*\\n)|(---\\n---\\n)", "replace": "", "flags": "gm" },
Can you try removing that custom replacement regex and see if it works? The replace value seems wrong for that custom replace.
Edit: I am not cetain what the intent is behind that regex replace,but it will remove all of the matches including date modified.
Oh, would that if it had been as easy as that... That regex did not have any match. It was needed when I was using a Templater Js script with MetaEdit to add properties and I think the modified date updater was still on and it messed up the YAML so I used that to restore order.
Also, let me remind you, when opening an md file, the log already said the key was missing. And I would have notice on the GH Desktop diff as well probably. I deleted the regex replacement as I don't need it.
I think there is something wrong with how Linter interacts with the metadacache. The reason I'm saying this because I recently realized I couldn't get Templater and DataView play along nicely to update frontmatter values. The file path was not found or something. I spent almost 2 days trying to find the cause of that -- to no avail.
But Dataview picks up my modified date values nicely, mind you. So what I do now is Lint on Save witn CNTRL+S after I made some changes to the file being worked on. As I am being in the process of uploading my work to a Digital Garden, these changes are mostly to do with finalizing and I also update the date modified field with the simple search and replace in the Templater js script.
What is really hard to understand how on both of my Linux and WIndows installations I have these issues with the path problem with a DVJs script and with Linter (Lint on Chage). One I would understand (Windows), but not Linux.
So ostensibly there is some file among myriad files that somehow corrupts the index and/or the metadatacache. I don't know how I'll find the culprit.
Thanks for looking into this but I think that at this point there's nothing else we can do.
You are free to close this as another wild goose chase I've sent you on.
Regards
Hey @zanodor .Thanks for the information you have provided so far. There should be no issue with reading from cache from my understanding since we either read in the file or get the value from the active editor. However that does not completely rule it out as a metadata issue.
There is still 1 set of logs I would appreciate if you could provide as that should show which rule is removing the date modified key.
Could you do the following and either upload a file with the contents or paste the output as a comment on this issue?
The steps are as follows:
If for some reason using the Lint Current File command does not cause the issue, please let me know. I can provide another main.zip
that can output the same logs as Lint Current File for linting the previously active leaf.
Looks like I can reproduce the issue locally, The issue was not showing up due to the date modified key format being a day based value so it would not actually make an update. I will look into this and see if I can figure out what is causing the problem.
Here are the logs I was looking for:
Running linter
Running Format Tags in YAML
format-tags-in-yaml: 0.8999999999068677 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
rules before regular rules: 2.1999999997206032 ms
Running Format YAML Array
format-yaml-array: 2 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Remove YAML Keys
remove-yaml-keys: 0.900000000372529 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Remove Multiple Spaces
remove-multiple-spaces: 1.3999999999068677 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Compact YAML
compact-yaml: 0.7000000001862645 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Consecutive blank lines
consecutive-blank-lines: 1.1999999997206032 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Empty Line Around Tables
empty-line-around-tables: 0.8000000002793968 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Custom Regex
custom regex rules: 0.7000000001862645 ms
Running Trailing spaces
trailing-spaces: 1.6000000000931323 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running YAML Timestamp
yaml-timestamp: 9.100000000093132 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running YAML Key Sort
yaml-key-sort: 3.8999999999068677 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
rules after regular rules: 18.699999999720603 ms
rules running: 36.10000000009313 ms
If I am logging things correctly and correctly reading the logs then the issue is that Empty Lines Around Tables
is removing the date modified key for some reason. I need to verify this, but if that is the case, that would definitely explain why this is so confusing as a whole.
Seems it was not that. I am not logging the results of the custom regex logic, so I am going to log that and see what is happening there.
When I added logic for debugging the custom regex logs I got the following:
Running linter
Running Format Tags in YAML
format-tags-in-yaml: 1.6000000000931323 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
rules before regular rules: 3.2000000001862645 ms
Running Format YAML Array
format-yaml-array: 2.1000000000931323 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Remove YAML Keys
remove-yaml-keys: 0.6999999997206032 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Remove Multiple Spaces
remove-multiple-spaces: 1.8000000002793968 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Compact YAML
compact-yaml: 0.6999999997206032 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Consecutive blank lines
consecutive-blank-lines: 1.3999999999068677 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running Custom Regex
/õ/gm
/Õ/gm
/,,/gm
/„/gm
/(date.*mod.*\n)|(---\n---\n)/gm
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
/(!\[\[)[A-Z]\/(.*?[#]\^[0-9a-z]{4,10}\]\])/gm
/\n\n^%%\n```query[\d\D]*?^%%/gm
custom regex rules: 4.699999999720603 ms
Running Trailing spaces
trailing-spaces: 2 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running YAML Timestamp
yaml-timestamp: 6.899999999906868 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
Running YAML Key Sort
yaml-key-sort: 3.1000000000931323 ms
---
title: Csalit
aliases:
- csalit
tags:
- dg_uploaded
share: true
dg-publish: true
dg-created: 2023-10-18T08:40
dg-updated: 2023-10-25T01:12
dg_upload_status: Vercel and Netlify done
date created: 2022-12-14
date modified: 2023-12-14
---
# Csalit
[[Berek]], [[Nemeton]], [[Keremet]] és [[Tanórok|tanórok]] címnél volt szó áldozati szent helyekről.
rules after regular rules: 16.100000000093132 ms
rules running: 36.799999999813735 ms
With new logs for custom regex to show which custom regex was run and which ones modified the file, it is saying that the culprit is
{
"label": "MAY NOT BE NEEDED remove superfluous YAML dashes from MetaEdit plugin issue",
"find": "(date.*mod.*\\n)|(---\\n---\\n)",
"replace": "",
"flags": "gm"
},
I removed that regex locally and that fixes the problem for me. It no longer says that the date modified key is being updated every time I lint. However there are likely files in your vault that have a skewed date modified because of this which will only get ironed out over time.
It sounds like you are fine with this getting closed, but I will wait until I get feedback from you or Sunday the 17th arrives before closing this since it looks like that regex is the culprit.
Also, when testing the regex matches for regex stored in the config, you need to account for the fact that the regex has to be string escaped to make sure it shows up properly in the UI. That means \\
becomes \
in the UI for visibility purposes.
So (date.*mod.*\\n)|(---\\n---\\n)
becomes (date.*mod.*\n)|(---\n---\n)
. It does indeed match the date modified key in the YAML which is causing it to be removed. I just thought I would add that just in case it helps in some way in the future.
Well, first of all, I don't quite know how I mistook the regex "culprit" not to be able to match, as there is the OR operator pipe character that indeed matches my date modified line in normal circumstances. I should have just deleted that custom regex after I concluded that MetaEdit is not the way to go to update properties.
Having said that, after removing the culprit, the date modified field still gets updated when using the Lint on Change function -- with no keys pressed in the editor.
I made the logs you asked for.
First on latest normal Linter version using the debug tracker option.
LOG WITH CUSTOM REGEX CULPRIT ADDED BACK
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
A latin NUM-erus (szám) és a magyar NYOM-ni szavak is szerinte feltehetőleg metatézisek voltak.
rules after regular rules: 5 ms
rules running: 36.40000000037253 ms
Running Custom Lint Commands
2. Regex culprit removed
LOG WITH CUSTOM REGEX CULPRIT REMOVED
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
title: Metatézis aliases:
Götz László Keleten kél a Nap című könyvének 154. oldalán ír a metatézis (szótagok megfordulása) jelenségéről.
Lásd [[Mássalhangzók felcserélődése|mássalhangzók felcserélődése]].
Szól arról, melyek a nem valódi és valódi metatézisek.
[[Szótagmegfordítás]] címnél szereplő adataihoz illő gondolata: a metatézisek is elsősorban szemantikai jellegűek: részben szinonimák, részben pedig új, néha hasonló, néha azonban éppen [[Ellentétes jelentések|ellentétes jelentésű szavak]] képzésére szolgálnak.
A latin NUM-erus (szám) és a magyar NYOM-ni szavak is szerinte feltehetőleg metatézisek voltak.
rules after regular rules: 26.700000000186265 ms
rules running: 37 ms
Running Custom Lint Commands
3.
Finally, I relaunched Obsidian with the main.js file you sent me with manifest.js edited to be picked up by Obsidan as Obsidian Linter Test.
I have here the regex culprit removed and here I did not Lint Current FIle, just opened the file and closed it, then I saved the Console Log pertaining to the file (I didn't know from where to start pasting, so I added a Breadcrumbs plugin log part as well):
plugin:breadcrumbs:24277 Object plugin:obsidian-linter-test:43 [Obsidian Linter] Running Format Tags in YAML plugin:obsidian-linter-test:43 [Obsidian Linter] format-tags-in-yaml: 0.900000000372529 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] rules before regular rules: 1.800000000745058 ms plugin:obsidian-linter-test:43 [Obsidian Linter] Running Format YAML Array plugin:obsidian-linter-test:43 [Obsidian Linter] format-yaml-array: 2.300000000745058 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running Remove YAML Keys plugin:obsidian-linter-test:43 [Obsidian Linter] remove-yaml-keys: 1.5 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running Remove Multiple Spaces plugin:obsidian-linter-test:43 [Obsidian Linter] remove-multiple-spaces: 24 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running Two Spaces Between Lines with Content plugin:obsidian-linter-test:43 [Obsidian Linter] two-spaces-between-lines-with-content: 9.300000000745058 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running Compact YAML plugin:obsidian-linter-test:43 [Obsidian Linter] compact-yaml: 0.900000000372529 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running Consecutive blank lines plugin:obsidian-linter-test:43 [Obsidian Linter] consecutive-blank-lines: 2.5 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running Empty Line Around Tables plugin:obsidian-linter-test:43 [Obsidian Linter] empty-line-around-tables: 39.09999999962747 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running Custom Regex plugin:obsidian-linter-test:43 [Obsidian Linter] custom regex rules: 0.19999999925494194 ms plugin:obsidian-linter-test:43 [Obsidian Linter] Running Trailing spaces plugin:obsidian-linter-test:43 [Obsidian Linter] trailing-spaces: 1.099999999627471 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running YAML Timestamp plugin:obsidian-linter-test:2460 initial state: plugin:obsidian-linter-test:2460 already modified: false plugin:obsidian-linter-test:2460 created key: date created plugin:obsidian-linter-test:2460 created status: true plugin:obsidian-linter-test:2460 modified key: date modified plugin:obsidian-linter-test:2460 modified status: true plugin:obsidian-linter-test:2460 force retention?: true plugin:obsidian-linter-test:2460 created time: 2023-11-25T18:16:02+01:00 plugin:obsidian-linter-test:2460 modified time: 2023-12-07T01:59:30+01:00 plugin:obsidian-linter-test:2460 format: "YYYY-MM-DD" plugin:obsidian-linter-test:2460 locale: en-us plugin:obsidian-linter-test:2460 current time: 2023-12-14T16:13:50+01:00 plugin:obsidian-linter-test:2460 text: --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:2467 date created key exists plugin:obsidian-linter-test:2460 date creation updated?:false plugin:obsidian-linter-test:2478 something was triggered the normal date modified update: plugin:obsidian-linter-test:2478 Was text modified prior to this? false plugin:obsidian-linter-test:2478 modified date time is null? false plugin:obsidian-linter-test:2478 modified date time is invalid for the locale and format provided? false plugin:obsidian-linter-test:2478 modified date is more than 5 seconds from file time? true plugin:obsidian-linter-test:2478 time difference (seconds): 6138000 plugin:obsidian-linter-test:43 [Obsidian Linter] yaml-timestamp: 10.5 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] Running YAML Key Sort plugin:obsidian-linter-test:43 [Obsidian Linter] yaml-key-sort: 1.3999999985098839 ms plugin:obsidian-linter-test:43 [Obsidian Linter] --- title: Már aliases:
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin major
és olasz maggiore
párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol yet
is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán mada
^1 = még és matte
= vár szavakat összevetettem.
De volt egy japán motto
szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese plugin:obsidian-linter-test:43 [Obsidian Linter] rules after regular rules: 14.200000001117587 ms plugin:obsidian-linter-test:43 [Obsidian Linter] rules running: 104.70000000111759 ms plugin:obsidian-linter-test:43 [Obsidian Linter] Linted M/Már.md
Here's the part where the date modified value gets updated:
![Screenshot from 2023-12-14 16-41-02](https://github.com/platers/obsidian-linter/assets/110669301/4290efbe-c162-4634-a176-97064a2e80fd)
Hey @zanodor . Thanks for the logs.
For example 2, I am guessing it is the same as what I describe below for case/example 3.
Here is my understanding of the update in example 3 based on the information provided:
The logs following logs from the logs above indicate that the initial date modified for the file was 2023-12-07T01:59:30+01:00
. This means that the Linter is expecting the date modified to be within 5 seconds of 2023-12-07
. The problem is that the value is currently 2023-09-27
. This will cause the update and there is nothing the Linter can do to prevent that as the date of the last modification does not match the date in the date modified. Thus it goes ahead and adds the current time in the date modified to make sure the modification date matches the value in the file metadata (otherwise you are always updating this value on save since the file metadata will almost never match that in the file if you use the file metadata to set the value in the UI because that then updates the file metadata again).
plugin:obsidian-linter-test:43 [Obsidian Linter] Running YAML Timestamp
plugin:obsidian-linter-test:2460 initial state:
plugin:obsidian-linter-test:2460 already modified: false
plugin:obsidian-linter-test:2460 created key: date created
plugin:obsidian-linter-test:2460 created status: true
plugin:obsidian-linter-test:2460 modified key: date modified
plugin:obsidian-linter-test:2460 modified status: true
plugin:obsidian-linter-test:2460 force retention?: true
plugin:obsidian-linter-test:2460 created time: 2023-11-25T18:16:02+01:00
plugin:obsidian-linter-test:2460 modified time: 2023-12-07T01:59:30+01:00
plugin:obsidian-linter-test:2460 format: "YYYY-MM-DD"
plugin:obsidian-linter-test:2460 locale: en-us
plugin:obsidian-linter-test:2460 current time: 2023-12-14T16:13:50+01:00
plugin:obsidian-linter-test:2460 text: ---
title: Már
aliases:
- már
status: unformatted
tags:
- nyelvészet
share: true
dg-publish: true
dg_upload_status: down
topic:
- japán
date created: 2022-12-14
date modified: 2023-09-27
---
# Már
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin `major` és olasz `maggiore` párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol `yet` is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán `mada`[^1] = még és `matte` = vár szavakat összevetettem.
De volt egy japán `motto` szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
## Lábjegyzetek
[^1]: Lábjegyzet:
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese
plugin:obsidian-linter-test:2467 date created key exists
plugin:obsidian-linter-test:2460 date creation updated?:false
plugin:obsidian-linter-test:2478 something was triggered the normal date modified update:
plugin:obsidian-linter-test:2478 Was text modified prior to this? false
plugin:obsidian-linter-test:2478 modified date time is null? false
plugin:obsidian-linter-test:2478 modified date time is invalid for the locale and format provided? false
plugin:obsidian-linter-test:2478 modified date is more than 5 seconds from file time? true
plugin:obsidian-linter-test:2478 time difference (seconds): 6138000
plugin:obsidian-linter-test:43 [Obsidian Linter] yaml-timestamp: 10.5 ms
plugin:obsidian-linter-test:43 [Obsidian Linter] ---
title: Már
aliases:
- már
status: unformatted
tags:
- nyelvészet
share: true
dg-publish: true
dg_upload_status: down
topic:
- japán
date created: 2022-12-14
date modified: 2023-12-14
---
# Már
A [[Még|még]] párja, ahol már megfelel annak a [[More|more]] = több szónak, melynek latin `major` és olasz `maggiore` párjai arra a visszatér fogalmát is magában foglaló [[Magyar|magyar]] alakú szavakat mutatják meg, mely a [[Még|még]] szót is kiadhatja.
Mind a még és a már az idő körfolyamatához tartozik. Ellentétes de ugyanakkor egy jelentésűek (ahogy az angol `yet` is lehet kettős jelentésű). [[Életkör]]ben való gondolkodás lehetőségét kell itt is felfedezni.
A már és [[Marad|marad]] is összetartoznak, alakilag mindenképp. Ahogy a [[Vár|vár]] = mar-ad szavak is.
Ezekre akkor jöttem rá, amikor a japán `mada`[^1] = még és `matte` = vár szavakat összevetettem.
De volt egy japán `motto` szó is, mely a középfokú melléknév fokozással lehet kapcsolatos. Ott is a még (meg = plusz = több) értelem vehető észre. És ha már itt tartunk, a fentebb említett More is lehet Magyar/Magor vagy már szavainkra visszavezethető.
De már korábban is volt marad jelentéssel kapcsolatban olyan érzésem, hogy a másutt folytat, [[Követ|követ]], valamint visszatér jelentésű M-G-R vázú szavakhoz hasonló alak a Hunor-Magor "[[Jön és megy|jön és megy]]" rendszerhez illeszkednek. És lám Mag = Megy = még, de marad M(agya)r-d.
## Lábjegyzetek
[^1]: Lábjegyzet:
Lásd: https://www.wordsense.eu/%E3%81%BE%E3%81%A0/#Japanese
This is just speculation on my part. But if you were to relint this file, I don't believe it would have the date modified updated again according to the logs. Thus if you relint your entire vault, the remaining files with date modified file metadata and the date modified YAML keys will get ironed out. Then you likely should not see this issue anymore. If you don't want to do that, that is fine. It is just something that will pop up as the files gradually get their metadata updated to be within the Linter's set bounds for the differences in data. Hopefully this explanation helps clear up why the changes were made. If not, feel free to ask questions.
TLDR
Based on what I am seeing data-wise for example 1 and 3, I believe those 2 are working as expected given the rules run and the file metadata provided. The first is caused by the regex removing the date modified. The second is caused by the file modification metadata not being on the same day/within 5 seconds of the value in the YAML for date modified when they are both in the same format. Example 2 is likely the same as example 3, but without the console logs to prove it that is just my hunch.
Relinting your vault once should update all of this outliers when it comes to the file metadata not currently matching the file's YAML value. If you want to retain the value that is in the frontmatter instead of using what the file has currently, then your only option is to disable the date modified key until you feel satisfied that you have made changes to all files in your vault that may have this date modified key vs file metadata mismatch (I would rather just accept the file system as being correct even though it may not reflect the last time you manually edited the file due to the regex causing the file to get saved to disk and making the file metadata get updated). I hope this helps.
Unless there is an issue that is persisting around the date modified key getting updated despite the key being present and the date modified file metadata matching the date in the frontmatter, I am thinking this issue is resolved from the Linter's perspective. But if there is a scenario that is incorrectly updating the frontmatter, changes can be made to change it.
Thanks for the help on this @zanodor !
From your last response, I gather two main points that need attention:
Are we talking about Linter looking at file metadata inaccessible for me through Obsidian? Because obviously if I mass modify files with regex replacements done outside of Obsidian, the file metadata changes and can even change for file created as well. In your settings, though, forcing value retention only refers to date created though. I cannot set the same modified date that exists in the file metadata for my frontmatter fields unless I run a Python script, for instance. Which I'm pretty sure most Obsidian users will never do (and I'm hardly experienced at myself).
Linter's check on modified date metadata and counting 5 seconds (other plugins can use 10 secs) would only make sense for me if the user interacted with the content of the active leaf: typed something in, changed some formatting, or used search and replace, etc. But in my case this doesn't happen: I just peruse the file and do nothing. But of course if Linter checks the internal file modification date, it will always be different than by frontmatter value. And even linting the full folder won't do right by that, especially if I mass replace stuff again outside of Obsidian again.
For these frontmatter values, Obsidian should use the internal file metadata for file creation and modification (it saves files every 2 secs). I think there's a feature request (or just a general wish?) as well, probably for updating the modified date automatically as well. In the meantime, most people are completely oblivious of the problem. I recently got into using DV queries (I usually made my DVJs queries with Chat-GPT, among them the one that checks the modified date against another date to ascertain if I should update an uploaded copy of my note), and I saw -- to my surprise -- that the cdate and mdate variables access the internal file creation and modification dates. They are never the same for me as the field values of my frontmatter and this current situation is dire as it is. I agree though that my Obsidian files were not made in Obsidian but imported and the YAML was made with regex in Notepad++. Thus the dates will not reflect the correct metadata the files have.
From your last response, I gather two main points that need attention:
- Are we talking about Linter looking at file metadata inaccessible for me through Obsidian? Because obviously if I mass modify files with regex replacements done outside of Obsidian, the file metadata changes and can even change for file created as well. In your settings, though, forcing value retention only refers to date created though. I cannot set the same modified date that exists in the file metadata for my frontmatter fields unless I run a Python script, for instance. Which I'm pretty sure most Obsidian users will never do (and I'm hardly experienced at myself).
The Linter currently only deals with metadata from the file itself. This data is not visible in Obsidian directly. The Linter has no idea when a file is changed as it stands now. There is a feature request to change that (see #890 / #183 ). That feature is currently not being worked on due to needing to lay groundwork for it to be feasible and actually performant. I am working on the groundwork, but that will not be a fast change since it requires knowing which files were last linted by the Linter and what they looked like after they were linted (this prevents an infinite loop since changing the file would trigger the exact same logic that runs the linter on a file changing after a designated amount of time).
So as far as the Linter works, the data modified is kept as close to the file date modified as possible since doing it any other way except a manual command to do so is currently not performant or feasible. Hopefully this will change in the future, but being the only dev actively working on this plugin means it may take a while for this to get added.
- Linter's check on modified date metadata and counting 5 seconds (other plugins can use 10 secs) would only make sense for me if the user interacted with the content of the active leaf: typed something in, changed some formatting, or used search and replace, etc. But in my case this doesn't happen: I just peruse the file and do nothing. But of course if Linter checks the internal file modification date, it will always be different than by frontmatter value. And even linting the full folder won't do right by that, especially if I mass replace stuff again outside of Obsidian again.
I think the only reasons this is an issue is because the file was edited outside of Obsidian thus causing the file metadata to be out of sync with the actual file plus the issue with the regex causing other updates to files. The Linter has no way of knowing the difference between a user making a change in Obsidian and something else editing the file either inside or outside of Obsidian.
As far as the Linter is concerned, the date modified file metadata (the one from the file system and not visible in Obsidian), is the source of truth. This can change once the Linter is aware and can handle user changes to a file's contents via the Obsidian events for this, but there are still several steps that seem to me that need to be added first ( #337 , #488, then #183 ). Once those are in place it would be feasible to add a dropdown for the source of truth for the Linter's date modified value (the file metadata or when a user edits the file in Obsidian).
Hopefully this explanation gives a better understanding of how and why the date modified properties work as they do.
I see (well, I think so). I feel a little responsible for drawing this out while we should have talked about this in the first place. I guess the visual Properties feedback is a little at fault at this also. One can forget about the file metadata easily.
As I said, most people don't import files with YAML (or make regex changes) en masse and don't have this problem and maybe don't even know about the two types of dates metadata. So for that maybe the settings panel should give a line of info about that. Or at least these exchanges on this ticket will remind you to wise people up about date metadata sooner; at least this is what you can take out of all this.
I was going to add that maybe a switch to turn off file modified updates would be nice but then you'd need to explain why, etc.; or you could have the setting on by default and the user could turn it off...But I may be out of line here as this would require me to open a new ticket and I certainly don't want you to overwork yourself in exchange of nothing. Especially if the coming Obsidian changes (if we can expect anything from the core devs in this regard) would render your proposed changes useless.
I'll leave it up to you and in the meantime I decided to try not linfting the file manually. I have run three Python scripts that dealt with the date modified dates of files already uploaded to my Digital Garden, their dg_upload dates and finally changed date modified metadata fields for both file system metadata and Obsidian frontmatter. At least now I have a clean slate, although I don't know for how long?
Also, from what I understand, a day from now, if I enter a file and leave it, my frontmatter modified date field will be updated -- which is why the title Lint on File Change is misleading (the small print underneath that is closer to the truth).
Which means I cannot use this feature because I am liable to get unwanted results from my Dataview query to upload files to the net one by one.
So either I use manualy Lint current file or go back to using Alan Grainger's Update Frontmatter Modified Field plugin, which I wanted to shun for other reasons.
Anyway, thanks for your time and blessings
A last remark, if I may (without wanting to peruse feature requests and or opening a new ticket). I am on Linux and stat-ing files I open in Obsidian. If there is no key presses, Obsidian doesn't modify the file and the modified date. I'm not a programmer, but it doesn't seem to be too hard to put these dates into a variable and use them for when a File Change would be triggered (closing or leaving a tab). Of course you'd need to take all file systems into consideration, I guess.
A last remark, if I may (without wanting to peruse feature requests and or opening a new ticket). I am on Linux and stat-ing files I open in Obsidian. If there is no key presses, Obsidian doesn't modify the file and the modified date. I'm not a programmer, but it doesn't seem to be too hard to put these dates into a variable and use them for when a File Change would be triggered (closing or leaving a tab). Of course you'd need to take all file systems into consideration, I guess.
I can't say I fully follow this statement. Obsidian does provide file stats in a varable that is used by the Linter that is where date created and date modified come from.
Hello there,
I just spent the last few minutes going through and reading the contents of issues (FR's and questions) about Date Modified, after I had been playing around in the vault.
I've recently started to use the Lint on File Change feature because I find it useful to delete with regex custom command my inline queries 1. before publishing the note 2. closing the note.
My peeve with the feature is that currently, if I just go into the file to peruse the contents or enter the file mistakenly, the Modfied Date change will be triggered on Lint on File Change, which consequently will cause that file to be picked up by a DataView query as 'file was changed, update pubilshed copy`, even though there was no changes at all in the file.
My question:
Can some measure be taken to not have this happen?
I've recently stopped using this plugin (for reasons to do with...eh, long story), which has a feature that makes the date modified field change only on having had keys pressed in the file.
Would you think it a good idea to include some similar code or feature?
Cheers, Z.