all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Glenn Morris <rgm@gnu.org>
Cc: 24452@debbugs.gnu.org
Subject: bug#24452: 25.1.50; add/delete-file-local-variable does not work as expected
Date: Mon, 19 Sep 2016 08:57:07 -0400	[thread overview]
Message-ID: <m27fa8avz0.fsf@andrew.cmu.edu> (raw)
In-Reply-To: <g0wpiazd3e.fsf@fencepost.gnu.org>

Thanks for the reply. Those are some good points I hadn't considered.

Glenn Morris writes:

> John Kitchin wrote:
>
>> In the add-file-local-variable and related functions, the local
>> variables are found with code like:
>>

See remarks below to explain these lines:

(search-forward "Local Variables:" nil t)
(search-forward "foo: bar" nil t)
(search-forward "End:" nil t)

>
> It uses the same logic as the function that actually applies file local
> variables (hack-local-variables).
>
>> This is too open I think, and leads to errors in files that contain that
>> phrase in places near the end of the file that aren't related to Local
>> Variables. For example, in code that is searching for that string, or in
>> text files that talk about Local Variables.
>
> Then you would already have had a more obvious issue when visiting the
> file in the first place.

It doesn't seem to cause any issues when visiting the file. It does
cause an issue when adding file local variables though without ^L or
obfuscation as you note below. For example, in this email I added a
local var foo with value bar, and it added the two extra search-forward
lines above. I guess this is known, expected behavior at this point.

> The format of Local Variables is too
> long-established to be changed now, and there's no point
> add-file-local-variable being stricter than hack-local-variables.

I didn't mean to suggest changing the format (I can see though that my
original suggestion suggested that). It seems it isn't too easy to make
it more strict given the broad range of situations where there are or
aren't comment syntax and where it is or isn't needed.


> The standard solution is eg to add a ^L, or obfuscate the "Local
> Variables", so it's not picked up.

This is a good tip that does resolve the issue for me. Thanks!

>
>> I think the search should be done with a regexp that considers the start
>> of a line and comment-start:
>>
>> (format "^%s+ Local Variables:" comment-start)
>
> Some files have no comment syntax. In some that do, there's no need for
> the LV section to use it (eg it could be after the "end{document}" in a
> latex file, or inside #if 0 in C). And then there's the case where
> comment-start is itself specified in the LV section.

It looks like this bug report is closeable. Thanks again for the clarifications.


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu





  reply	other threads:[~2016-09-19 12:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16 21:16 bug#24452: 25.1.50; add/delete-file-local-variable does not work as expected John Kitchin
2016-09-17 16:48 ` Glenn Morris
2016-09-19 12:57   ` John Kitchin [this message]
2020-08-12  1:48     ` Stefan Kangas

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m27fa8avz0.fsf@andrew.cmu.edu \
    --to=jkitchin@andrew.cmu.edu \
    --cc=24452@debbugs.gnu.org \
    --cc=rgm@gnu.org \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.