Skip to content

Fix #1507 (allow Emacs Lisp checker to run without a buffer-file-name)#1695

Merged
cpitclaudel merged 1 commit intomasterfrom
cpitclaudel_fix-1507
Mar 29, 2020
Merged

Fix #1507 (allow Emacs Lisp checker to run without a buffer-file-name)#1695
cpitclaudel merged 1 commit intomasterfrom
cpitclaudel_fix-1507

Conversation

@cpitclaudel
Copy link
Member

@cpitclaudel cpitclaudel commented Mar 18, 2020

CC @matthew-piziak

Closes GH-1507. This isn't perfect because org mode temporary buffers don't
have a file name at all, so we don't know which buffer they came from.

The original code said this:

Ensure that we only check buffers with a backing file. For buffers
without a backing file we cannot guarantee that file names in error
messages are properly resolved, because `byte-compile-file' emits file
names relative to the directory of the checked file instead of the
working directory. Hence our backwards-substitution will fail, because
the checker process has a different base directory to resolve relative
file names than the Flycheck code working on the buffer to check.

The problem is that we create a temp file in /tmp/, and the checker reports
errors relative to that, so we get "xyz" as a file name. This doesn't match
what we expect ($PWD/xyz). The fix here is to tell the ELisp compiler which
directory to report errors relative to.

@matthew-piziak
Copy link

Thank you so much @cpitclaudel! What workflow would you recommend for me, who has a literate init file with many source blocks? When I use flycheck on this revision I get errors now, but they're mostly of the form "the function foo is not known to be defined", and I don't want to put a bunch of require statements at the front of every source block. It feels like currently every source block is like its own package.

@cpitclaudel
Copy link
Member Author

What workflow would you recommend for me, who has a literate init file with many source blocks? It feels like currently every source block is like its own package.

It's quite tricky. Your description is exactly right.

Ideally, you'd want org to create an indirect buffer that has all your snippets in it, and narrow it to the snippet you're editing. Then Flycheck and Emacs would see the whole context.

Is there a generic way (in org-mode) to extract all snippets that a snippet depends on?

@cpitclaudel cpitclaudel force-pushed the cpitclaudel_fix-1507 branch from 3b1d955 to 33f2b01 Compare March 19, 2020 20:01
@cpitclaudel
Copy link
Member Author

I've updated the PR to make it more robust. Can you give it a new try and tell me if it still gives you errors (the update won't improve things in terms of spurious errors)

@matthew-piziak
Copy link

Ideally, you'd want org to create an indirect buffer that has all your snippets in it, and narrow it to the snippet you're editing. Then Flycheck and Emacs would see the whole context.

Is there a generic way (in org-mode) to extract all snippets that a snippet depends on?

Well there's tangling. If I jump to definition (xref-find-definition) in main.org, it jumps me to the tangled main.el file, even if the definition being jumped to is in the same snippet. If flycheck used main.el as the backing file for errors, while using the snippet buffer for error location data, then I think that would do it. Keeping them in sync is another issue though. Maybe I should look into Org Tanglesync.

I've updated the PR to make it more robust. Can you give it a new try and tell me if it still gives you errors (the update won't improve things in terms of spurious errors)

Confirmed, still works on 33f2b01.

@cpitclaudel
Copy link
Member Author

Well there's tangling

Right. Ideally, that temporary buffer that org gives you should be the full tangled file, narrowed to just the snippet that you're editing. That's a discussion that would be better taken to the org-mode list, though.

Confirmed, still works on 33f2b01.

Thanks!

@matthew-piziak
Copy link

That's a discussion that would be better taken to the org-mode list.

Quite right. Never did figure out how to use it, to be honest. If only they had a status-based bug tracker…

@cpitclaudel cpitclaudel force-pushed the cpitclaudel_fix-1507 branch from 33f2b01 to 495992b Compare March 22, 2020 16:44
Copy link
Member

@fmdkdd fmdkdd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, it's always good to be able to check buffers without files if we can.

This definitely warrants an entry in the changelog.

@cpitclaudel cpitclaudel force-pushed the cpitclaudel_fix-1507 branch 3 times, most recently from d5771e8 to 5d18e29 Compare March 29, 2020 21:21
Closes GH-1507.  This isn't perfect because org mode temporary buffers don't
have a file name at all, so we don't know which buffer they came from.

The original code said this:

> Ensure that we only check buffers with a backing file.  For buffers
> without a backing file we cannot guarantee that file names in error
> messages are properly resolved, because `byte-compile-file' emits file
> names *relative to the directory of the checked file* instead of the
> working directory.  Hence our backwards-substitution will fail, because
> the checker process has a different base directory to resolve relative
> file names than the Flycheck code working on the buffer to check.

The problem is that we create a temp file in /tmp/, and the checker reports
errors relative to that, so we get "xyz" as a file name.  This doesn't match
what we expect ($PWD/xyz).  The fix here is to tell the ELisp compiler which
directory to report errors relative to.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flycheck Emacs Lisp in Org-mode babel source blocks

3 participants