bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file

[Vincent Belaïche]

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