Magit treats .el files like binary files

[Thorsten Jolitz]

Hi List,

I posted this on emacs.help, but should have posted it here probably,
so I'm sorry for the double posting.

Lately I see this using (ma)git on (uncompiled) emacs-lisp files (.el
extension):

,----
| Local: trunk ~/git/foo/
| Head: 0173df1 Reorganize utility functions.
|
| Unstaged changes:
| Modified src/foo.el
| diff --git a/src/foo.el b/src/foo.el
| index 4fd4832..92baf7a 100644
| Binary files a/src/foo.el and b/src/foo.el differ
`----

For some reason they are treated as binary files.
Any hints what is going on there and how to fix it?

PS

#+BEGIN_SRC emacs-lisp
(emacs-version)
#+END_SRC

#+results:
: GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
: of 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc


#+BEGIN_SRC emacs-lisp
(magit-version)
#+END_SRC

#+results:
: 20140118.1540

,----
| git version 2.1.0
`----

--
cheers,
Thorsten

[Noam Postavsky]

Sorry, hit reply instead of reply-all; resending to list.

On Fri, Aug 22, 2014 at 10:10 AM, Thorsten Jolitz <tjo...@gmail.com> wrote:
>
> Lately I see this using (ma)git on (uncompiled) emacs-lisp files (.el
> extension):

To be clear, this happens with git from the command line, not just
magit? Do you have any NUL characters in your file? I think adding

*.el diff

to your ~/.gitattributes file should avoid the problem. Or even better

*.el diff=lisp

and add this to your ~/.gitconfig:

[diff "lisp"]
xfuncname = "^\\(.*$"


That way you get nicer headers for your lisp diffs.

See http://git-scm.com/docs/gitattributes for details.

[Thorsten Jolitz]

Noam Postavsky <npos...@gmail.com>
writes:

> Sorry, hit reply instead of reply-all; resending to list.
>
> On Fri, Aug 22, 2014 at 10:10 AM, Thorsten Jolitz
> <tjo...@gmail.com> wrote:
>>
>> Lately I see this using (ma)git on (uncompiled) emacs-lisp files (.el
>> extension):
>
> To be clear, this happens with git from the command line, not just
> magit?

,----
| [tj@arch foo]$ git diff
| diff --git a/src/foo.el b/src/foo.el
| index 4fd4832..600937e 100644

| Binary files a/src/foo.el and b/src/foo.el differ
`----

> Do you have any NUL characters in your file?

Ah, I think thats it!

foo.el and other libraries of mine contains regexps with a technique I
stole from the Org developers: match every possible char with

,----
| "[^^@]+"
`----

with ^@ being the NULL character entered with C-q. I've seen other
variations of this, but this one works really reliably for me. At a
cost, it seems ...

> I think adding
>
> *.el diff
>
> to your ~/.gitattributes file should avoid the problem. Or even better
>
> *.el diff=lisp
>
> and add this to your ~/.gitconfig:
>
> [diff "lisp"]
> xfuncname = "^\\(.*$"
> That way you get nicer headers for your lisp diffs.

ok, done, guess I should restart emacs now.

> See http://git-scm.com/docs/gitattributes for details.

Thanks for your tips!

--
cheers,
Thorsten

[Noam Postavsky]

On Fri, Aug 22, 2014 at 12:21 PM, Thorsten Jolitz <tjo...@gmail.com> wrote:
>
> ok, done, guess I should restart emacs now.

This all git config stuff, so you don't need to anything in emacs.

[Noam Postavsky]

On Fri, Aug 22, 2014 at 12:21 PM, Thorsten Jolitz <tjo...@gmail.com> wrote:

> foo.el and other libraries of mine contains regexps with a technique I
> stole from the Org developers: match every possible char with
>
> ,----
> | "[^^@]+"
> `----
>
> with ^@ being the NULL character entered with C-q.

By the way, you should be able to use lisp string escape syntax
instead of a literal NUL: "[^\0]+".

Also, wouldn't this fail to match NUL chars? (rx (1+ anything)) gives
"\\(?:.\\|\n\\)+", seems like that would be better...

[Thorsten Jolitz]

Noam Postavsky <npos...@gmail.com>
writes:

> On Fri, Aug 22, 2014 at 12:21 PM, Thorsten Jolitz
> <tjo...@gmail.com> wrote:
>> foo.el and other libraries of mine contains regexps with a technique I
>> stole from the Org developers: match every possible char with
>>
>> ,----
>> | "[^^@]+"
>> `----
>>
>> with ^@ being the NULL character entered with C-q.
>
> By the way, you should be able to use lisp string escape syntax
> instead of a literal NUL: "[^\0]+".

in org-mode they write it like "[^\000]+", and it should work really,
but I tried it and it failed sometimes, while the literal NUL was 100pc
reliable. I will try it again.

> Also, wouldn't this fail to match NUL chars? (rx (1+ anything)) gives
> "\\(?:.\\|\n\\)+", seems like that would be better...

isn't the whole idea based on the fact that NUL chars should not appear
ever in non-binary files (ok, I just proved the contrary with my regexps
...)?


This looks like a nice alternative, however I'm struggling a bit to make
it a regexp subgroup

#+BEGIN_SRC emacs-lisp
(string-match "\\(\\(.\\|\n\\)+?\\)\\(world\\)" "hello \nworld")
(match-string 0 "hello \nworld")
#+END_SRC

#+results:
: hello
: world


#+BEGIN_SRC emacs-lisp
(string-match "\\(\\(.\\|\n\\)+?\\)\\(world\\)" "hello \nworld")
(match-string 1 "hello \nworld")
#+END_SRC

#+results:
: hello

#+BEGIN_SRC emacs-lisp
(string-match "\\(\\(.\\|\n\\)+?\\)\\(world\\)" "hello \nworld")
(match-string 2 "hello \nworld")
#+END_SRC

#+BEGIN_SRC emacs-lisp
(string-match "\\(\\(:?.\\|\n\\)+?\\)\\(world\\)" "hello \nworld")
(match-string 2 "hello \nworld")
#+END_SRC

#+results:
:

#+BEGIN_SRC emacs-lisp
(string-match "\\(\\(.\\|\n\\)+?\\)\\(world\\)" "hello \nworld")
(match-string 3 "hello \nworld")
#+END_SRC

#+results:
: world

--
cheers,
Thorsten

[Noam Postavsky]

On Fri, Aug 22, 2014 at 6:01 PM, Thorsten Jolitz <tjo...@gmail.com> wrote:
> isn't the whole idea based on the fact that NUL chars should not appear
> ever in non-binary files (ok, I just proved the contrary with my regexps

Yeah, exactly. They shouldn't but they might anyway.

> #+BEGIN_SRC emacs-lisp
> (string-match "\\(\\(:?.\\|\n\\)+?\\)\\(world\\)" "hello \nworld")
> (match-string 2 "hello \nworld")
> #+END_SRC

You have the ":?" flipped around, it should be "?:".

[Thorsten Jolitz]

Noam Postavsky <npos...@gmail.com>
writes:

ups, of course, that was noise ...

But - why is this not working as expected?

#+BEGIN_SRC emacs-lisp
(string-match "\\(.\\|\n\\)+?\\(world\\)" "hello \nworld")

(match-string 1 "hello \nworld")
#+END_SRC

#+results:
:

#+BEGIN_SRC emacs-lisp
(string-match "\\(.\\|\n\\)+?\\(world\\)" "hello \nworld")

(match-string 2 "hello \nworld")
#+END_SRC

#+results:
: world

Either the regexp alternative isn't a group, then "world" should be
subgroup 1 like here

#+BEGIN_SRC emacs-lisp
(string-match "\\(?:.\\|\n\\)+?\\(world\\)" "hello \nworld")

(match-string 1 "hello \nworld")
#+END_SRC

#+results:

: world

or it is one, than it should have match data - or I'm overlooking
something obvious?

--
cheers,
Thorsten

[Noam Postavsky]

On Fri, Aug 22, 2014 at 6:30 PM, Thorsten Jolitz <tjo...@gmail.com> wrote:
>
> But - why is this not working as expected?
>
> #+BEGIN_SRC emacs-lisp
> (string-match "\\(.\\|\n\\)+?\\(world\\)" "hello \nworld")
> (match-string 1 "hello \nworld")
> #+END_SRC
>
> #+results:
> :
>

> or it is one, than it should have match data

It does have have match data, "\n". It's only one character long
because "\\(.|\n\\)" only matches a single character. You need to
include the "+?" in the group if you want more.

[Thorsten Jolitz]

Noam Postavsky <npos...@gmail.com>
writes:

Ah, ok, I see ... thx!

--
cheers,
Thorsten