Ignoring file local-variables in patches?

Ignoring file local-variables in patches?

[drkm]

  Hello

  One of the patches I had when working on Ediff is this one:

*** ediff-diff.el.old	Thu Dec 23 07:01:56 2004
--- ediff-diff.el	Thu Dec 30 08:24:14 2004
***************
*** 1338,1343 ****
--- 1338,1350 ----
   		(append ediff-cmp-options (list f1 f2)))))
      (and (numberp res) (eq res 0))))
  
+ (defun ediff-same-file-contents-3 (f1 f2 &optional f3)
+   "Return t if F1, F2 and F3 (if applicable) have identical contents."
+   (and (ediff-same-file-contents file1 file2)
+        (or (null file3)
+            (and (ediff-same-file-contents file1 file3)
+                 (ediff-same-file-contents file2 file3)))))
+ 
  
  ;;; Local Variables:
  ;;; eval: (put 'ediff-defvar-local 'lisp-indent-hook 'defun)

  You can see it ends by a incomplete local variables list.  When I
open it, I have the error:

    File local-variables error: (error "Local variables list is not
    properly terminated")

  I think that these lists doesn't have to be processed for such
files, it isn't?  However, I guess a bootsrap issue: local variables
have to be processed to know the major mode, and how know to discard
this processing without knowing the major mode?

  Is the current behaviour a bug or a feature?

--drkm

Re: Ignoring file local-variables in patches?

[Miles Bader]

Heh, good point...

I often am annoyed by a similar (but more minor, and probably easier
to fix) problem:  I have `copyright-update' on a save-file hook
somewhere, and it often gets confused by patches, asking if I want to
update the copyright in a patch that updates the copyright!

-Miles

Re: Ignoring file local-variables in patches?

[Simon Josefsson]

Miles Bader <snogglethorpe@gmail.com> writes:

> Heh, good point...
>
> I often am annoyed by a similar (but more minor, and probably easier
> to fix) problem:  I have `copyright-update' on a save-file hook
> somewhere, and it often gets confused by patches, asking if I want to
> update the copyright in a patch that updates the copyright!

That reminds me: copyright-update try to update the first copyright
message in a file, but it is frequently the last one the is the
current one.  For example:

Copyright 1995  Foo Bar
Copyright 1996, 1999, 2003  Simon Josefsson

When I save a file that contain the above, copyright-update try to add
2005 to the first copyright line.

In some projects, I have solved this by moving my copyright line
first, as in:

Copyright 1996, 1999, 2003  Simon Josefsson
Copyright 1995  Foo Bar

but this is slightly disrespectful, I think.

Proposed solution: Have copyright-update search the next 10 lines
after the first found copyright line, to see if it can find more
current copyright headers to update.

What do people think?  Is this a poor idea for some reason?

Re: Ignoring file local-variables in patches?

[Miles Bader]

> Proposed solution: Have copyright-update search the next 10 lines
> after the first found copyright line, to see if it can find more
> current copyright headers to update.

Sounds good to me.  I think there are probably quite a few
improvements that could be made to copyright.el's heuristics, but it's
a bit daunting to tweak (hairy regexps and all).

Some other examples:

  * It seems to not really deal well with some of the current
    Emacs copyright lines that use two-digit year abbreviations
    (maybe it has "19" hardwired somewhere?)

  * Sometimes the current year gets wrapped onto a line
    following the word "copyright", which copyright.el apparently
    doesn't handle.

-Miles

Re: Ignoring file local-variables in patches?

[Stefan Monnier]

> Proposed solution: Have copyright-update search the next 10 lines
> after the first found copyright line, to see if it can find more
> current copyright headers to update.

No, it should simply look for a copyright that correspond to you.
If such a line is not found, add one.


        Stefan

Re: Ignoring file local-variables in patches?

[Richard Stallman]

    Proposed solution: Have copyright-update search the next 10 lines
    after the first found copyright line, to see if it can find more
    current copyright headers to update.

It sounds like a good idea to me.