0

I was debugging some of my elisp code and realized that, in a tex-mode buffer, the newline character at end of line did not match [[:space:]]. In most other textmodes or progmodes, ie, the few I tested before posting :-), newline does match [[:space:]].

The above situation breaks a lot of my old pattern-matching code and raises two questions:

What is the rationale for this design?

In case I want to change the status of ?\n so that it matches [[:space:]], are there hidden inconvenients to using (modify-syntax-entry ?\n " " st) ?

2

describe-char tells us that the newline has syntax:

                   (...)
            character: C-j (displayed as C-j) (codepoint 10, #o12, #xa)
                   (...)
               syntax: >    which means: endcomment
                   (...)

It counts as a whitespace in fundamental-mode, but not in emacs-lisp-mode, and, I suspect, not in any progmode for a language having a comment syntax starting with a character and ending with a newline.

Changing the syntax value of the character could break some comments-related features of latex modes. Now, given how latex modes like to handle stuff without using general emacs facilities, it may still work fine, so you can always try it.

Note that it may also matter for your regexps, given the following *tex idiom:

this is not a word%
boundary
  • Thanks for the explanation. I'll use [[:space:]\n] or [[:blank:]\n] rather than expect newline to be whitespace. – phs Mar 6 '17 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.