adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-11-03 17:12:21 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Automatic DateTime Updates are Triggered Twice When File Doesn't Have Trailing Newline #175

New Issue
Closed
opened 2026-10-05 02:31:21 +02:00 by adam · 10 comments
adam commented 2026-10-05 02:31:21 +02:00
Owner
Copy link
Copy source

Describe the bug
When frontMatter.content.autoUpdateDate is enabled and editing a document that doesn't have a trailing newline, the automatic date updates are triggered twice. This doesn't happen when the file does have a trailing new line. For example, after it updates twice (the newline is added for you), subsequent updates happen only once.

To Reproduce
Steps to reproduce the behavior:

  1. Ensure frontMatter.content.autoUpdateDate is enabled.
  2. Try to update a markdown (or MDX) file and wait for the debounce to trigger the autoupdate.
  3. Observe that the lastmod field is updated twice.

Expected behavior
I'd expect the lastmod field to be updated only once.

Screenshots
A gif which demonstrates the behavior:
example

VS Code Version

Version: 1.63.2 (Universal)
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:37:28.172Z (2 wks ago)
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin arm64 21.2.0

Extension Version
v5.9.0

Additional context
This is likely due to the autoupdate logic defined here: https://github.com/estruyf/vscode-front-matter/blob/4d38a0881a9d43a4c1b4432c368618fa4590b844/src/commands/Article.ts#L243-L265

One way to solve this might be to adjust the change detection logic, but this may introduce new bugs.

Another possible solution would be to do away with change detection entirely-- moving away from vscode.workspace.onDidChangeTextDocument to onWillSaveTextDocument: https://code.visualstudio.com/api/references/vscode-api#3591 . This would move auto-updates to the pre-save lifecycle which would prevent the extension from updating the lastmod timestamp while the user is actively editing the document.

**Describe the bug** When `frontMatter.content.autoUpdateDate` is enabled and editing a document that doesn't have a trailing newline, the automatic date updates are triggered twice. This doesn't happen when the file does have a trailing new line. For example, after it updates twice (the newline is added for you), subsequent updates happen only once. **To Reproduce** Steps to reproduce the behavior: 1. Ensure `frontMatter.content.autoUpdateDate` is enabled. 2. Try to update a markdown (or MDX) file and wait for the debounce to trigger the autoupdate. 3. Observe that the lastmod field is updated twice. **Expected behavior** I'd expect the lastmod field to be updated only once. **Screenshots** A gif which demonstrates the behavior: ![example](https://user-images.githubusercontent.com/5827236/148272641-bfb469ca-4db7-4ccc-b44e-7df01a3a49fc.gif) **VS Code Version** ``` Version: 1.63.2 (Universal) Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3 Date: 2021-12-15T09:37:28.172Z (2 wks ago) Electron: 13.5.2 Chromium: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin arm64 21.2.0 ``` **Extension Version** `v5.9.0` **Additional context** This is likely due to the autoupdate logic defined here: https://github.com/estruyf/vscode-front-matter/blob/4d38a0881a9d43a4c1b4432c368618fa4590b844/src/commands/Article.ts#L243-L265 One way to solve this might be to adjust the change detection logic, but this may introduce new bugs. Another possible solution would be to do away with change detection entirely-- moving away from `vscode.workspace.onDidChangeTextDocument` to `onWillSaveTextDocument`: https://code.visualstudio.com/api/references/vscode-api#3591 . This would move auto-updates to the pre-save lifecycle which would prevent the extension from updating the lastmod timestamp while the user is actively editing the document. <!-- github-sync-id:1094662412 -->
adam closed this issue 2026-10-05 02:31:21 +02:00
adam commented 2026-10-05 02:31:22 +02:00
Author
Owner
Copy link
Copy source

The trailing line is something I think VS Code adds for you in this case, so it will indeed trigger an update when you added your content, and VS Code adds the new line, which triggers it again.

onWillSaveTextDocument means that the user has to save the file, but could be a solution. As I think the new line will be added by VS Code just before saving it.

Another way would be to disable the new line setting for markdown files.

The trailing line is something I think VS Code adds for you in this case, so it will indeed trigger an update when you added your content, and VS Code adds the new line, which triggers it again. `onWillSaveTextDocument` means that the user has to save the file, but could be a solution. As I think the new line will be added by VS Code just before saving it. Another way would be to disable the new line setting for markdown files. <!-- github-comment-id:1006047888 -->
adam commented 2026-10-05 02:31:23 +02:00
Author
Owner
Copy link
Copy source

Yeah, the newline being appended by VS Code makes total sense.

My concern, albeit minor, was that the newline being appended is being triggered by the extension, even if indirectly. Any change to the document triggers another onDidChangeTextDocument (including the frontMatter one), which I believe is causing the change detection logic to detect another change, triggering another update.

If this isn't a concern, since it's certainly an edge case, I'm happy to close the issue.

It's worth some thought, though, about whether or not onDidChangeTextDocument is a solid event for the intent behind the feature. I ask this (very not sarcastically 😁 ): Does updating the field any time prior to save provide any value?

Yeah, the newline being appended by VS Code makes total sense. My concern, albeit minor, was that the newline being appended is being triggered by the extension, even if indirectly. Any change to the document triggers another `onDidChangeTextDocument` (including the frontMatter one), which I believe is causing the change detection logic to detect another change, triggering another update. If this isn't a concern, since it's certainly an edge case, I'm happy to close the issue. It's worth some thought, though, about whether or not `onDidChangeTextDocument` is a solid event for the intent behind the feature. I ask this (very not sarcastically 😁 ): Does updating the field any time prior to save provide any value? <!-- github-comment-id:1006743352 -->
adam commented 2026-10-05 02:31:23 +02:00
Author
Owner
Copy link
Copy source

@farmerau we could certainly try to update it to the onWillSaveTextDocument, I'm very much open to changing anything that doesn't make sense or can be improved in any way.

I do not use this functionality myself, so never ran against this issue, but I can see what could go wrong if there are multiple extensions listening to changes. Although, this might be the same for the save event.

@farmerau we could certainly try to update it to the `onWillSaveTextDocument`, I'm very much open to changing anything that doesn't make sense or can be improved in any way. I do not use this functionality myself, so never ran against this issue, but I can see what could go wrong if there are multiple extensions listening to changes. Although, this might be the same for the save event. <!-- github-comment-id:1006749246 -->
adam commented 2026-10-05 02:31:24 +02:00
Author
Owner
Copy link
Copy source

Another related consequence that I see: If I type a sentence out and save it immediately (a common behavior of mine) the lastmod property is not updated:
on-save

Another related consequence that I see: If I type a sentence out and save it immediately (a common behavior of mine) the lastmod property is not updated: ![on-save](https://user-images.githubusercontent.com/5827236/148421123-759c2032-fb84-4bcf-af8e-582d58c48234.gif) <!-- github-comment-id:1006751603 -->
adam commented 2026-10-05 02:31:25 +02:00
Author
Owner
Copy link
Copy source

@farmerau we could certainly try to update it to the onWillSaveTextDocument, I'm very much open to changing anything that doesn't make sense or can be improved in any way.

I do not use this functionality myself, so never ran against this issue, but I can see what could go wrong if there are multiple extensions listening to changes. Although, this might be the same for the save event.

Sure, that makes sense! I don't think the onWillSaveTextDocument can cause a loop in the same way but I can think of ways that the behavior could conflict with other extensions like Prettier (which runs first on the event, for example)

> @farmerau we could certainly try to update it to the `onWillSaveTextDocument`, I'm very much open to changing anything that doesn't make sense or can be improved in any way. > > I do not use this functionality myself, so never ran against this issue, but I can see what could go wrong if there are multiple extensions listening to changes. Although, this might be the same for the save event. Sure, that makes sense! I don't _think_ the `onWillSaveTextDocument` can cause a loop in the same way but I can think of ways that the behavior could conflict with other extensions like Prettier (which runs first on the event, for example) <!-- github-comment-id:1006754669 -->
adam commented 2026-10-05 02:31:25 +02:00
Author
Owner
Copy link
Copy source

Let us give it a try!

Let us give it a try! <!-- github-comment-id:1006754979 -->
adam commented 2026-10-05 02:31:26 +02:00
Author
Owner
Copy link
Copy source

Cheers! I'll get a PR out!

Cheers! I'll get a PR out! <!-- github-comment-id:1006755781 -->
adam commented 2026-10-05 02:31:27 +02:00
Author
Owner
Copy link
Copy source

After doing some debugging, I learned that the newline is actually coming from gray-matter:

  • Calling document.GetText() returns the text without a newline character
  • Evaluating newMarkdown (value returned from this.stringifyFrontMatter) includes a newline character at the end.

This would mean that there are no controls from VS Code that could prevent the newline from being appended, meaning that there would be no way for a user to prevent the double updates in the current state.

I've opened a PR to run on save instead of on-change.

After doing some debugging, I learned that the newline is actually coming from gray-matter: * Calling `document.GetText()` returns the text without a newline character * Evaluating `newMarkdown` (value returned from `this.stringifyFrontMatter`) includes a newline character at the end. This would mean that there are no controls from VS Code that could prevent the newline from being appended, meaning that there would be no way for a user to prevent the double updates in the current state. I've opened a PR to run on save instead of on-change. <!-- github-comment-id:1006923292 -->
adam commented 2026-10-05 02:31:27 +02:00
Author
Owner
Copy link
Copy source

I've merged your PR @farmerau, thanks again for the help on this one! 🙏

Included a check for the gray-matter new line as well. When the content does not contain a newline before the stringify function, it will remove it when included. Combined with your change, I think this will complete the issue.

I've merged your PR @farmerau, thanks again for the help on this one! 🙏 Included a check for the gray-matter new line as well. When the content does not contain a newline before the stringify function, it will remove it when included. Combined with your change, I think this will complete the issue. <!-- github-comment-id:1007355562 -->
adam commented 2026-10-05 02:31:28 +02:00
Author
Owner
Copy link
Copy source

Released in v5.10.0

Released in `v5.10.0` <!-- github-comment-id:1008808011 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#175