Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

[João Távora]

Hi Sam,

I was going through Flymake in master to perform some refactorings when
I came across this change:

   commit 934a72c7e4a506a36697fdb98f837cea989e70e1
   Author: Sam Steingold <sds@gnu.org>
   Date:   Wed Nov 1 09:36:41 2017 -0400
    
       User can specify files never subject to flymake.

There was some discussion around it

   https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00054.html

but I believe we later agreed (though off-list for some reason) that
using a file or dir-local value of nil for
`flymake-diagnostic-functions' is a much better alternative in Emacs
26.1 onwards. In the case of your "mini-scratch" Python files, just add:

# Local Variables:
# flymake-diagnostic-functions: nil
# End:

So, do you mind if I revert the patch?  I'm asking because new
user-visible complexity in a file I'm trying to refactor is
counterproductive to that task.

João

Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Tue, 05 Jun 2018 00:59:27 +0100
> Cc: emacs-devel@gnu.org
> 
> I was going through Flymake in master to perform some refactorings when
> I came across this change:
> 
>    commit 934a72c7e4a506a36697fdb98f837cea989e70e1
>    Author: Sam Steingold <sds@gnu.org>
>    Date:   Wed Nov 1 09:36:41 2017 -0400
>     
>        User can specify files never subject to flymake.
> 
> There was some discussion around it
> 
>    https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00054.html
> 
> but I believe we later agreed (though off-list for some reason) that
> using a file or dir-local value of nil for
> `flymake-diagnostic-functions' is a much better alternative in Emacs
> 26.1 onwards. In the case of your "mini-scratch" Python files, just add:
> 
> # Local Variables:
> # flymake-diagnostic-functions: nil
> # End:
> 
> So, do you mind if I revert the patch?  I'm asking because new
> user-visible complexity in a file I'm trying to refactor is
> counterproductive to that task.

So we introduced a defcustom in Emacs 26.1 just to remove it in Emacs
27.1?  Isn't there a nicer way out of this, one that doesn't remove an
existing feature?

Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

> So we introduced a defcustom in Emacs 26.1 just to remove it in Emacs
> 27.1?  Isn't there a nicer way out of this, one that doesn't remove an
> existing feature?

Well, it's not in NEWS :-)

And it wasn't really agreed to by consensus...  Sam pushed it, some
discussion ensued, and then Sam and I agreed off-list (which was
probably my common mistake of hitting "reply" instead of "reply to all")
that the file-local variable was the best way.  This was also the
opinion of more people.

Yesterday, when cleaning up I noticed the commit.  I guess you're right,
we might as well live with it, ...sigh.  If the plan is to obsolete
flymake-proc.el anyway, maybe this has little influence.

In a similar cleanup, I just pushed to master an obsoletion of a
variable introduced in 26.1 (but here with full backward compatibility
and a better alternative).  Do you think this can make it into 26.2?

João

Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: sds@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 05 Jun 2018 16:11:29 +0100
> 
> Yesterday, when cleaning up I noticed the commit.  I guess you're right,
> we might as well live with it, ...sigh.  If the plan is to obsolete
> flymake-proc.el anyway, maybe this has little influence.

OK, thanks.

> In a similar cleanup, I just pushed to master an obsoletion of a
> variable introduced in 26.1 (but here with full backward compatibility
> and a better alternative).  Do you think this can make it into 26.2?

Yes, I think so.

Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> In a similar cleanup, I just pushed to master an obsoletion of a
>> variable introduced in 26.1 (but here with full backward compatibility
>> and a better alternative).  Do you think this can make it into 26.2?
>
> Yes, I think so.

By git cherry-picking into the emacs-26 branch or something else?

João

Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: sds@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 05 Jun 2018 16:53:58 +0100
> 
> >> In a similar cleanup, I just pushed to master an obsoletion of a
> >> variable introduced in 26.1 (but here with full backward compatibility
> >> and a better alternative).  Do you think this can make it into 26.2?
> >
> > Yes, I think so.
> 
> By git cherry-picking into the emacs-26 branch or something else?

I usually do "git cherry-pick -x", so that the notice of the fact gets
placed in the commit log message.

Re: [Emacs-diffs] master 934a72c: User can specify files never subject t

[Sam Steingold]

Hi,
yes, I actually thought you reverted the patch long ago.
Thanks

On Mon, Jun 4, 2018 at 7:59 PM, João Távora <joaotavora@gmail.com> wrote:
> Hi Sam,
>
> I was going through Flymake in master to perform some refactorings when
> I came across this change:
>
>    commit 934a72c7e4a506a36697fdb98f837cea989e70e1
>    Author: Sam Steingold <sds@gnu.org>
>    Date:   Wed Nov 1 09:36:41 2017 -0400
>
>        User can specify files never subject to flymake.
>
> There was some discussion around it
>
>    https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00054.html
>
> but I believe we later agreed (though off-list for some reason) that
> using a file or dir-local value of nil for
> `flymake-diagnostic-functions' is a much better alternative in Emacs
> 26.1 onwards. In the case of your "mini-scratch" Python files, just add:
>
> # Local Variables:
> # flymake-diagnostic-functions: nil
> # End:
>
> So, do you mind if I revert the patch?  I'm asking because new
> user-visible complexity in a file I'm trying to refactor is
> counterproductive to that task.
>
> João
>
>



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net>
<http://steingoldpsychology.com>