Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emacs lockfiles produce "Rendering failed" errors #2224

Open
dmoles opened this issue Oct 22, 2023 · 3 comments
Open

Emacs lockfiles produce "Rendering failed" errors #2224

dmoles opened this issue Oct 22, 2023 · 3 comments
Labels
A-Documentation Area: Documentation C-bug Category: A bug, incorrect or unintended behavior C-dependency-bug Category: A bug in a dependency Command-serve Command: serve Command-watch Command: watch S-Blocked-Upstream Status: Blocked Upstream

Comments

@dmoles
Copy link

dmoles commented Oct 22, 2023

Problem

When an Emacs buffer has been edited but not saved, Emacs generates a lock file in the form of a symlink to a nonexistent file. E.g., when editing SUMMARY.md:

lrwxrwxrwx 1 david david   35 Oct 22 12:40  .#SUMMARY.md -> [email protected]:1697969899

mdBook does not like these files:

$ mdbook build
2023-10-22 12:43:28 [INFO] (mdbook::book): Book building has started
2023-10-22 12:43:28 [INFO] (mdbook::book): Running the html backend
2023-10-22 12:43:28 [ERROR] (mdbook::utils): Error: Rendering failed
2023-10-22 12:43:28 [ERROR] (mdbook::utils):    Caused By: Failed to read "/home/david/projects/mdbook-project/src/.#SUMMARY.md"
2023-10-22 12:43:28 [ERROR] (mdbook::utils):    Caused By: No such file or directory (os error 2)

Steps

  1. In an mdBook project, open SUMMARY.md in Emacs and make a small edit, but do not save.
  2. Run mdbook build.

Expected:

  • build succeeds, perhaps with a warning

Actual:

  • build fails

Possible Solution(s)

  1. a mechanism to exclude certain file patterns from the build would allow excluding all files of the pattern .#*.md
  2. the build command (as well as watch, serve, etc.) could (optionally?) ignore broken symlinks

(N.b. I'm new to mdBook; it's possible these mechanisms exist and I'm just not finding them in the docs. In which case, it would be nice to surface them more prominently there.)

Notes

This isn't a showstopper as it's cleared up as soon as the file is saved (or in the event of a crash, as soon as the offending symlink is deleted). Still, it creates a lot of noise, particularly in watch or serve mode, and makes it hard to see legitimate warnings/errors.

Version

`mdbook v0.4.35`
@dmoles dmoles added the C-bug Category: A bug, incorrect or unintended behavior label Oct 22, 2023
@KFearsoff
Copy link
Contributor

This seems very relevant: notify-rs/notify#255

The issue seems very hard to tackle. Very often, failing is what you want to do when your symlink is broken. Emacs is a rare special case. It seems like Emacs doesn't support other forms of lockfiles either, so I fear this is unfixable.

I guess this could be better documented, or a flag might be added when notify-rs lands support for ignoring symlink failures, but for now there's not much we can do.

@KFearsoff
Copy link
Contributor

KFearsoff commented Nov 14, 2023

@rustbot label +A-Documentation +C-dependency-bug +Command-serve +Command-watch +S-Blocked-Upstream

@rustbot rustbot added A-Documentation Area: Documentation C-dependency-bug Category: A bug in a dependency Command-serve Command: serve S-Blocked-Upstream Status: Blocked Upstream Command-watch Command: watch labels Nov 14, 2023
@pnkfelix
Copy link
Member

One way we could deal with this, as pointed out to me by @ehuss , would be to first put in a change resolving #1156/#1187 (such as PR #2183). Then, once that in place, all Emacs lockfiles can be specified via a pattern matching files starting with .# in the mdbookignore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Documentation Area: Documentation C-bug Category: A bug, incorrect or unintended behavior C-dependency-bug Category: A bug in a dependency Command-serve Command: serve Command-watch Command: watch S-Blocked-Upstream Status: Blocked Upstream
Projects
None yet
Development

No branches or pull requests

4 participants