[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40148: 26.3; Custom package header checked out from GIT in Windows w

From: Noam Postavsky
Subject: bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
Date: Fri, 20 Mar 2020 15:47:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Noam Postavsky <address@hidden>
>> Cc: Michael Angelozzi <address@hidden>,  address@hidden
>> Date: Fri, 20 Mar 2020 10:25:11 -0400
>> Eli Zaretskii <address@hidden> writes:
>> > It may be the case that package.el should be more tolerant in this
>> > case, but that's just the tip of an iceberg, because there are files
>> > out there where LF to CR-LF conversions are a no-no (just one example:
>> > Unix shell scripts).  Just say no to this "feature", and Bob's your
>> > uncle.
>> The problem happens without git conversion as well (because Emacs
>> defaults to "dos" encoding on windows-nt systems):
> You are saying that creating a package (or a new file in a package)
> should leave the EOL format of the Lisp files at "dos", and distribute
> the package's files like that via the elpa's?

My message above says only what does happen, not what should happen (for
the latter, see below).

But I'm not sure exactly what you mean by "create a package".  I don't
think Emacs has a particular action/command which corresponds to that.
Distribution via repos is mostly outside the responsibility of Emacs'
code (there are some upload functions in package-x.el, but none of the
existing repos make use of them, as far as I know).

About what should happen: I think detecting and giving a specific error
about CRLF from package-buffer-info could be a satisfactory solution to
this bug.  Or perhaps package-install-file could be more lenient.
Actually, if I'm reading the code right, it's already more lenient in
case of installing from a .tar file containing CRLF elisp files.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]