unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Francesco Potortì" <pot@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 27066@debbugs.gnu.org
Subject: bug#27066: 25.1; dired unsafe variables
Date: Thu, 25 May 2017 21:25:36 +0200	[thread overview]
Message-ID: <E1dDyO9-0007lN-4Z@tucano.isti.cnr.it> (raw)
In-Reply-To: <834lw8lses.fsf@gnu.org>

>> >Please suggest how to improve the existing docs.
>> 
>> The warning message should not say that risky variables are present in the
>> directory: that makes sense only if you know where to look.  When
>> reading that message, I thought about some bug somewhere.
>> 
>> The warning message should name the file where the offending variables
>> were found, instead.
>
>Patches are welcome to add the file name.  AFAICT, the function that
>actually applies the variables doesn't know on which file the
>variables were found, as there could be more than one of them, and
>they all are read to produce a list of variables, before the
>variables' values are applied.

First, sorry to say this, there is no hope I could ever create a patch
of tht kind.

Second, I already suspected that.  Unfortunately, I fear that in fact
this is important.  It makes no sense to me to know that the directory
contains some risky variables.  I personally know what are file-local
variables.  Probably a minority of Emacs users know that.  But I had no
idea that directory-local risky variables existed.

>> >Perhaps we should offer an option to ask the question you mentioned,
>> >but I think in general it will annoy too much.
>> 
>> I don't know.  It's a relatively recent innovation, and I bet very few
>> users have ever stumbled into it.
>
>Well, not too recent: it was introduced in Emacs 23.1, 8 years ago.
>Time flies...

Yes.  Time flies :)

But that is not something that you are bound to see.  You only notice it
when someone else us uses it and you download a tree where that's used.
A pretty unlikely situation, all in all.  I understand that this is a
matter of (personal?) judgement, but it is an uncommon corner case.  And
given the problem above, when you don't even know where that variables
come from, it should not be treated lightly, in my opinion.





  reply	other threads:[~2017-05-25 19:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-25 11:57 bug#27066: 25.1; dired unsafe variables Francesco Potortì
2017-05-25 15:21 ` Eli Zaretskii
2017-05-25 15:54   ` Francesco Potortì
2017-05-25 16:06     ` Eli Zaretskii
2017-05-25 16:58       ` Francesco Potortì
2017-05-25 18:09         ` Eli Zaretskii
2017-05-25 19:25           ` Francesco Potortì [this message]
2022-01-23 16:10           ` Lars Ingebrigtsen

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=E1dDyO9-0007lN-4Z@tucano.isti.cnr.it \
    --to=pot@gnu.org \
    --cc=27066@debbugs.gnu.org \
    --cc=eliz@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 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).