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

Minor Issue With Org-mode Font Locking #40

Open
sdubinsky opened this issue Jun 16, 2021 · 4 comments
Open

Minor Issue With Org-mode Font Locking #40

sdubinsky opened this issue Jun 16, 2021 · 4 comments

Comments

@sdubinsky
Copy link

When ethan-wspace cleans a buffer, it removes all trailing whitespace. This breaks org-mode font locking for outlines. In org-mode, header lines are color-coded according to their depth, based on the number of leading asterisks (or at least, that's what I use). But that requires a space after the last asterisk, and if there's nothing else on the line ethan-wspace will delete that space and break the font-locking

A file like

* Header
** header 2
*** 

will have the space character at the end of the third line removed, and show up as white characters.

@glasserc
Copy link
Owner

Hi, sorry for the delayed response. While I use org-mode myself, I typically put text on each header line so this hasn't really been a problem for me. Can you tell me a little bit more about how you use org-mode and what you think correct behavior would be? One option would be to stop considering whitespace-at-eol an error type, which you could do by customizing ethan-wspace-errors from org-mode-hook.

@sdubinsky
Copy link
Author

Hi, thanks for the response! My specific use-case here is an org-capture-template that I use to populate a notes file. The template has several header lines for info I know I'm going to need, but haven't added yet.

I also add the new templates to the top of the file, so whitespace-at-eol won't work.

@glasserc
Copy link
Owner

glasserc commented Jul 4, 2022

Thanks for the additional context. What do you think correct behavior should be? It sounds to me like the "DWIM-iest" thing would be for ethan-wspace to know that whitespace after header lines is not an error, but only in org-mode buffers. I'd be open to patches but I don't tihnk it's straightforward to implement: First, there's no infrastructure in ethan-wspace to support different interpretations of errors according to the buffer's major mode, so we'd have to implement something reasonable there, and I don't know what that would look like exactly; second, we'd have to essentially implement a new whitespace-at-EOL mode. Unlike other whitespace types, eol is implemented with show-trailing-whitespace, which is implemented in C source. The nice thing about show-trailing-whitespace is that it doesn't consider trailing whitespace behind point to be an error, so you don't get flickering red spaces as you type. We'd probably want to support something like this but in elisp and that might be a little trickier than e.g. just fontifying tabs.

I still think the easiest solution for you is to remove eol as an error type when working in org-mode. Something like this should work:

(defun org-eol-is-ok ()
  (setq ethan-wspace-errors (remq 'eol ethan-wspace-errors)))

(add-to-list 'org-mode-hook 'org-eol-is-ok)

@sdubinsky
Copy link
Author

I do rely on the package fairly heavily in the normal course of my day, including in org-mode, so disabling it for the whole mode is a no-go.

I had vague ideas of an optional "disable for lines that only contain symbols", but other than that I don't have a good solution. Like I said, it's a minor issue - if you can't think of anything good either, then we'll close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants