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

Don't fill code blocks #169

Closed
vermiculus opened this issue Sep 26, 2016 · 8 comments
Closed

Don't fill code blocks #169

vermiculus opened this issue Sep 26, 2016 · 8 comments

Comments

@vermiculus
Copy link
Contributor

Code is usually line-sensitive – it's inappropriate to fill them with fill-paragraph.

@syohex
Copy link
Collaborator

syohex commented Sep 26, 2016

Could you show us example code which reproduces your issue ?

@vermiculus
Copy link
Contributor Author

(insert "```
hello
world
```")
(fill-region 0 (point-max))

@xiongtx
Copy link
Contributor

xiongtx commented Oct 12, 2016

This actually seems like a hard problem.

It's easy to modify paragraph-start to stop filling code blocks formed by lines that begin with 4 or more spaces with the regexp " .*".

The trickier part is recognizing code blocks between two sets of triple tick marks. The paragraph-start and paragraph-separate regexps only apply to a single line, so in the following situation (where | indicates point):

```
|foo
bar
```

you have no way of knowing that you're in a code block and not a regular paragraph.

GitHub also stupidly chose start and end delimiters to be the same, so regexp-based solutions are in for a world of pain. The syntax was clearly designed for parsing, not text matching.

@vermiculus
Copy link
Contributor Author

Yep – I encountered the same complications when I tried to implement. I think the solution is going to have to re-implement commands like fill-paragraph entirely.

@jrblevin
Copy link
Owner

I was able to fix this without reimplementing fill-paragraph entirely. Instead, a custom fill-paragraph-function blocks filling when in a code block. There is a test case, but bet me know if you see any problems.

@jrblevin
Copy link
Owner

jrblevin commented May 11, 2017

Actually, I just realized that the original report was about fill-region not fill-paragraph. This only fixes the latter. Oddly, fill-region seems to work on its own, via fill-region-as-paragraph, without calling out to fill-paragraph.

Even in emacs-lisp-mode, if one uses fill-region it fills code as paragraphs. For example, start with this in the buffer:

(defun markdown-show-version ()
  "Show the version number in the minibuffer."
  (interactive)
  (message "markdown-mode, version %s" markdown-mode-version))

Then issue (fill-region (point-min) (point-max)) and you're left with a jumbled mess:

(defun markdown-show-version () "Show the version number in the
minibuffer."  (interactive) (message "markdown-mode, version %s"
markdown-mode-version))

@vermiculus
Copy link
Contributor Author

I would've thought fill-region would be based on fill-paragraph (or perhaps vice-versa). Should this be reported as an Emacs bug?

@jrblevin
Copy link
Owner

I agree--I'm surprised too. It does seem to be a common issue, so maybe a bug report is warranted. For example, I checked latex-mode. It rightly won't fill a verbatim environment when fill-paragraph (M-q) is called directly, but fill-region doesn't respect verbatim.

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

No branches or pull requests

4 participants