12:33 p.m.
Yoshiki Hayashi [yoshiki(a)xemacs.org]:
"Wedler, Christoph" <christoph.wedler(a)sap.com>
writes:
> >> 1. Use the above appended list
> >> 2. Open a new file foo.txt with two line of "ab".
> >> 3. You see the modeline is still "ISO8" (and
> >> `buffer-file-coding-system' is iso-2208-8), but this would be
> >> acceptable, although not nice (since I also see ISO8 for Unix
> >> endings and ISO8:T for dos)
> >> 4. Save the buffer, the length is 6 bytes (i.e., Unix endings)
> >> 5. Kill the buffer, re-read it.
> >> 6. Modeline ISO8:T, and `buffer-file-coding-system' is
#<coding_system
> >> iso-2022-8-dos> -- huh?
> >> 7. delete your entry from file-coding-system-alist
> >> 8. Kill the buffer, re-read it.
> >> 9. Modeline ISO8, and `buffer-file-coding-system' is #<coding_system
iso-2022-8-unix>
>
> > Did you try this?
> > (setq-default default-buffer-file-coding-system 'iso-8859-1-dos)
>
> Yes, it's better that it really write files with dos endings (i.e, 4
> above is OK now), but when reading files with unix eol type, the buffer
> has a coding system with dos eol type (i.e., 6 is still strange).
Then you found a bug in file-coding XEmacs.
Well, it doesn't contradict the docstring of
default-buffer-file-coding-system:
Default value of `buffer-file-coding-system' for buffers that do not
override it. This is the same as (default-value
'buffer-file-coding-system). This value is used both for buffers
without associated files and for buffers whose files do not have any
apparent coding system.
If you set `default-buffer-file-coding-system' to `iso-2022-8-dos' and
visit a Unix file with ASCII-only characters, this file doesn't probably
have a "apparent coding system", that's why the corresponding is
`#<coding_system iso-2022-8-dos>'.
The eol type of the file is apparent, but not the whole coding system.
If the two properties "base" and "eol type" should be considered
independently, this should be mentioned in the docstring, and the
current behaviour of XEmacs should be considered wrong as you've said.
It does work with MULE XEmacs.
Maybe XEmacs-21.5.X, but not on the following:
./configure '--with-png=no' '--site-includes=/sapmnt/hw1020/a/include'
'--site-libraries=/sapmnt/hw1020/a/lib' '--with-mule'
XEmacs 21.4.5 "Civil Service" configured for `hppa1.1-hp-hpux11.00'.
> [...] eol type nil means:
> (1) when reading: XEmacs tries to guess the correct eol type
> (2) when writing: XEmacs uses its internal eol type which is unix' one.
>
> I definitely want to have (1), that is, no, I don't want to set a
> variable which uses a specific eol type to read a file.
>
> But there is no auto-guess functionality when saving the buffer. That
> is I want to say that eol type nil can also mean dos or mac when writing
> the file.
XEmacs should not attempt to auto-guess EOL when saving buffer and
should never be. It uses whatever the value of
buffer-file-coding-system. EOL type nil is not auto-guess in this
case but means LF for new file.
Err, yes... The wording in my previous message wasn't good: I just
wanted to say (in the section starting with "But there is no..." and in
earlier messages) that it would be useful to be able to customize that
eol type nil when saving can mean CRLF (or CR) instead of LF.
If it is not a new file, you can't have EOL type nil in that
buffer.
Exactly. That's why I always talked about new files when arguing why
toggling from eol type nil is useful...
I thought we are talking about your proposal of future enhancement.
Except for the above mentioned variable ("able to customize"), I didn't
mention any others.
I'm not specifically talking about your patch.
Well, this is exactly my problem. Toggling from eol type nil in a
buffer is specific to that patch, people vetoed that feature and when I
asked "why?", people start talking about something else (if there was an
answer at all).
That's why I got annoyed. Sorry that it sounded like I was specific
annoyed with your answer.
I think no one has commented on your patch so far.
Err, some people vetoed the feature "toggling from eol type nil in a
buffer"[1] and some agreed with the veto. Before sending a patch, it
would be useful to get a reason for that or that they take the veto back
(otherwise I put work in a patch which will be vetoed).
[1] To which one should be customizable (I already agreed on that)
- Christoph
1:08 p.m.
New subject: [Proposed Patch] button2 on ISO8:T in modeline toggles eol ty pe
>>>> "Christoph" == Christoph Wedler
<Wedler> writes:
Christoph> Err, some people vetoed
I did. Specifically for 21.4, which is what you submitted that patch
against.
I don't have an objection to applying it "as is" in 21.5 (nor am I
willing to approve it yet, I'm currently in "conservative maintainer
mode"). But 21.4 is feature frozen, and definitely not appropriate
for "try it and see" patches. That's one of the things 21.5 is for.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
8:37 a.m.
New subject: [Proposed Patch] button2 on ISO8:T in modeline toggles eol ty pe
"Wedler, Christoph" <christoph.wedler(a)sap.com> writes:
Well, it doesn't contradict the docstring of
default-buffer-file-coding-system:
Default value of `buffer-file-coding-system' for buffers that do not
override it. This is the same as (default-value
'buffer-file-coding-system). This value is used both for buffers
without associated files and for buffers whose files do not have any
apparent coding system.
If you set `default-buffer-file-coding-system' to `iso-2022-8-dos' and
visit a Unix file with ASCII-only characters, this file doesn't probably
have a "apparent coding system", that's why the corresponding is
`#<coding_system iso-2022-8-dos>'.
You mean there's no LF in that file? If a file does
not have EOL, XEmacs has no way to autodetect it. So in
that case, you are seeing the correct behavior.
Err, yes... The wording in my previous message wasn't good: I
just
wanted to say (in the section starting with "But there is no..." and in
earlier messages) that it would be useful to be able to customize that
eol type nil when saving can mean CRLF (or CR) instead of LF.
OK, so we have been talking about different things. No
wonder we don't agree.
It might better if you said "allow toggling of EOL type in
new files" instead in original message. Your original
proposal sounded like you want to add different feature for
toggle-buffer-coding-system.
I still think chaning default-buffer-file will solve most of
the cases but I have no objection to applying your patch.
--
Yoshiki Hayashi
8157
days inactive
8159
days old
2 comments
3 participants
participants (3)
-
Stephen J. Turnbull -
Wedler, Christoph -
Yoshiki Hayashi