problem with system_eol_type

I've got several complaints about the change I made a few
months ago regarding the handling of the default eol-type.

Previously, when a coding system without explicit eol-type
(e.g. iso-latin-1) was specified for encoding, Unix-like
eol-type is selected on any platform.

The change I made was to use an eol-type set to
system_eol_type (CRLF on Windows, LF otherwise) in such a
case.  To me, that change was just a bug fix.

But, the bug-reports say that there are many codes that
assumes the previous behaviour, and some of them now don't
work well on Windows.

I think that it is cleaner to ask a program to specify the
eol-type explicitly if it requires a specific eol-type on
encoding.  But, as long as the behavior is clearly
documented, it seems that the previous behaviour is also not
that bad.

What do people think?

---
Kenichi Handa
handam17n.org

PS.  I included mule-ja maining list in CC:.  Mule-ja
subscribers please write in English if you want to reply to
this mail.


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

On Mon, Jul 31 2006, Kenichi Handa wrote:

> I've got several complaints about the change I made a
few
> months ago regarding the handling of the default
eol-type.
>
> Previously, when a coding system without explicit
eol-type
> (e.g. iso-latin-1) was specified for encoding,
Unix-like
> eol-type is selected on any platform.
>
> The change I made was to use an eol-type set to
> system_eol_type (CRLF on Windows, LF otherwise) in such
a
> case.  To me, that change was just a bug fix.
>
> But, the bug-reports say that there are many codes that
> assumes the previous behaviour, and some of them now
don't
> work well on Windows.

FWIW, two examples in Gnus where that doubled newlines
appeared in
mail messages and NOV (overview) files weren't read/written
correctly
anymore, see this discussion on the Gnus list:
<http://thread.gmane.org/gmane.emacs.gnus.g
eneral/63496/focus=63502>

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages
.de/


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

>>>>> "Reiner" == Reiner Steib
<reinersteib+gmaneimap.cc> writes:

> On Mon, Jul 31 2006, Kenichi Handa wrote:
>> I've got several complaints about the change I
made a few
>> months ago regarding the handling of the default
eol-type.
>> 
>> Previously, when a coding system without explicit
eol-type
>> (e.g. iso-latin-1) was specified for encoding,
Unix-like
>> eol-type is selected on any platform.
>> 
>> The change I made was to use an eol-type set to
>> system_eol_type (CRLF on Windows, LF otherwise) in
such a
>> case.  To me, that change was just a bug fix.
>> 
>> But, the bug-reports say that there are many codes
that
>> assumes the previous behaviour, and some of them
now don't
>> work well on Windows.

I'd argue that those pieces of code had bugs: if your code
depends on a Unix
style EOL, it should say so explicitly.

> FWIW, two examples in Gnus where that doubled newlines
appeared in
> mail messages and NOV (overview) files weren't
read/written correctly
> anymore, see this discussion on the Gnus list:
> <http://thread.gmane.org/gmane.emacs.gnus.g
eneral/63496/focus=63502>

Is there any good reason why Gnus uses coding systems of the
form `foo'
rather than `foo-unix'?

This said, there's clearly a problem of backward
compatibility since the
"buggy" code worked in Emacs-21.


        Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

> From: Kenichi Handa <handam17n.org>
> Date: Mon, 31 Jul 2006 15:04:59 +0900
> Cc: mule-jam17n.org
> 
> But, the bug-reports say that there are many codes that
> assumes the previous behaviour, and some of them now
don't
> work well on Windows.

What other packages, besides Gnus, were broken by this
change?

> I think that it is cleaner to ask a program to specify
the
> eol-type explicitly if it requires a specific eol-type
on
> encoding.

I agree.


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

    Previously, when a coding system without explicit
eol-type
    (e.g. iso-latin-1) was specified for encoding, Unix-like
    eol-type is selected on any platform.

    The change I made was to use an eol-type set to
    system_eol_type (CRLF on Windows, LF otherwise) in such
a
    case.  To me, that change was just a bug fix.

This is clearly The Right Thing, at the user level.

    But, the bug-reports say that there are many codes that
    assumes the previous behaviour, and some of them now
don't
    work well on Windows.

Thus, what's good at the UI level is not good at the API
level.
Programs would usually like to get uniform results.

I see two possible approaches to this:

1. Fix those programs to specify `-unix'.  That way, they
should get
LF eol behavior in all Emacs versions on all systems.

2. Take out your old change, and implement something at the
UI level,
perhaps in a function that reads a coding system name.

#1 is clearly easier.  Is there any strong argument against
it?


Is there a way 


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel