From: vincent.belaiche@gmail.com (Vincent Belaïche)
To: Philipp Stephani <p.stephani2@gmail.com>, 27391@debbugs.gnu.org
Cc: "Vincent Belaïche" <vincent.belaiche@gmail.com>
Subject: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file
Date: Tue, 27 Jun 2017 08:05:05 +0200 [thread overview]
Message-ID: <8460fi7ypa.fsf@gmail.com> (raw)
In-Reply-To: <CAArVCkQmFcwDQ0hzTLuUa1yxNsrYLuGCcHc3MF-be-kMj5p73Q@mail.gmail.com>
My answers inserted below.
Le 26/06/2017 à 13:39, Philipp Stephani a écrit :
>
>
> Vincent Belaïche <vincent.belaiche@gmail.com> schrieb am Mo., 19. Juni 2017 um 12:51 Uhr:
>
>
> Concerning factorization, couldn't one use [\n\r] in all cases
> rather than a switch based on some input argument ?
>
>
> It should be possible, but it slightly changes the behavior of
> file-local variables. I wouldn't expect anything to break though.
>
>
Sorry, I can't understand why there should be any slight change in the
current behaviour. BTW, as in the doit function given below what I had
in mind was some "\\(\r\n?\\|\n\\)" construct rather than a plain
"[\r\n]", so it consistently matches CR (as one some Apple computers),
CR-LF (as on MSW) and LF.
>
> I was also wondering whether it is not possible to have a single regexp
> for the whole Local Variable section. The following `doit' function is a
> trial to do so. `M-x doit' will seach forward the whole Local Variables
> section and display "ok" if found, "nak" otherwise.
>
> (defun doit ()
> (interactive)
> (let* ((eol "\\(\r\n?\\|\n\\)")
> (eol-again "\\1")
> (space-maybe "[ \t]*")
> ;; suffix may be the empty string
> (suffix "\\([^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\|\\)")
> (prefix "\\([ \t]*[^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\)")
> (prefix-again "\\2")
> (suffix-again "\\3")
> (symbol: "\\(?:\\(?:[^][()'\" \t\r\n]\\|\\\\[][()'\" \t]\\)+[ \t]*:\\)")
> (sexp (concat "\\(?:" (substring prefix 2))))
>
> (message (if (and (re-search-forward
> (concat eol
> prefix space-maybe "Local Variables:" space-maybe suffix space-maybe eol-again
> "\\(?:" prefix space-maybe symbol: sexp space-maybe suffix-again space-maybe eol-again "\\)*"
> prefix space-maybe "End:" space-maybe suffix space-maybe "\\(" eol-again "\\)?"
> )
> nil t)
> ;; when the tailing eol is not there we must be at EOB.
> (or (match-string 3) (eobp)))
> "ok" "nak"))))
>
>
>
> Looks good. Consider using `rx' for complex regexes, in my experiences it increases readability a lot.
On second thought the regexp considered above has some limitation : it
would fail if the sexp is multiline. For instance the following would
fail.
--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
/* Local Variables: */
/* multiline-sexp: ( "first line"
"second line" ) */
/* End: */
--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----
This is a regression as I think that the current code allows multiline
--- well I am not 100% sure of that, I presume this just from my reading
the current code.
I don't know if multiline sexps in file local variables is a desirable
feature, personally I have never used them.
And I am not even sure either that making a regexp that matches an Elisp
sexp is feasible, or sensible. It is not sensible in my opinion because
any change in the Elisp reader --- like supporting bignums as we had
discussed quite some day ago with Jay Belanger, maintainer of Calc ---
would imply some change in this regexp.
And regpexps do not support either any [:elisp-sexp:] construct that
would do the job with some `read' call under the hood.
Vincent.
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
next prev parent reply other threads:[~2017-06-27 6:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-16 10:00 bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Vincent Belaïche
2017-06-16 12:59 ` Eli Zaretskii
2017-06-16 14:08 ` Vincent Belaïche
2017-06-16 14:10 ` Vincent Belaïche
2017-06-16 18:38 ` Eli Zaretskii
2017-06-16 19:08 ` Vincent Belaïche
2017-06-16 19:15 ` Vincent Belaïche
2017-06-16 19:31 ` Andreas Schwab
2017-06-16 19:37 ` Vincent Belaïche
2017-06-16 21:27 ` Vincent Belaïche
2017-06-16 21:34 ` Philipp Stephani
2017-06-16 21:39 ` Philipp Stephani
2017-06-16 21:52 ` Philipp Stephani
2017-06-16 22:09 ` Vincent Belaïche
2017-06-16 22:23 ` Vincent Belaïche
2017-06-17 5:45 ` Vincent Belaïche
2017-06-17 14:30 ` Philipp Stephani
2017-06-19 10:51 ` Vincent Belaïche
2017-06-26 11:39 ` Philipp Stephani
2017-06-27 6:05 ` Vincent Belaïche [this message]
2017-06-17 14:15 ` Philipp Stephani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8460fi7ypa.fsf@gmail.com \
--to=vincent.belaiche@gmail.com \
--cc=27391@debbugs.gnu.org \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).