Re: [Proposed Patch] button2 on ISO8:T in modeline toggles eol type
"Wedler, Christoph" <christoph.wedler(a)sap.com> writes:
Yoshiki Hayashi wrote:
BTW, setting `default-buffer-file-coding-system' to
`iso-2022-8-dos' is
even worse when reading this file if it has CR (Mac) endings: then I get
a buffer with one line: ab^Mab^M (no line ending)
> I still think chaning default-buffer-file will solve most of the
> cases
This might be true in an environment where files have an "apparent coding
system" (probably Japanese), but not with ASCII-only files: files with
LF endings would be saved with CRLF the next time and files with CR
endings would be read as files with one line (see above)
I am one who is inconvenienced by this problem.
In file-coding.c, if any encoding formats doesn't detected, files are
treated with default-buffer-file-coding-system. If this variable has a
specific EOL type, it override file's own one.
This is a workaround patch to this problem by introducing C version of
coding-system-base . Does anyone have a idea for the real fix?
--- file-coding.c.orig Tue Dec 25 20:58:50 2001
+++ file-coding.c Tue Dec 25 20:24:54 2001
＠＠ -1729,6 +1729,26 ＠＠
}
static Lisp_Object
+coding_system_base (Lisp_Object coding_system)
+{
+ if (XCODING_SYSTEM_EOL_TYPE (coding_system) == EOL_AUTODETECT)
+ return coding_system;
+ {
+ Lisp_Object name;
+ Bytecount offset;
+ Bufbyte *new_name;
+
+ name = Fsymbol_name (XCODING_SYSTEM_NAME (coding_system));
+ offset = fast_lisp_string_match
+ (build_string ("-unix$\\|-dos$\\|-mac$"), name);
+ new_name = alloca (offset + 1);
+ memcpy (new_name, XSTRING_DATA (name), offset);
+ new_name[offset] = '\0';
+ return Ffind_coding_system (intern (new_name));
+ }
+}
+
+static Lisp_Object
coding_system_from_mask (int mask)
{
if (mask == ~0)
＠＠ -1747,6 +1767,8 ＠＠
"Invalid `default-buffer-file-coding-system', set to nil");
XBUFFER (Vbuffer_defaults)->buffer_file_coding_system = Qnil;
}
+ else
+ retval = coding_system_base (retval);
}
if (NILP (retval))
retval = Fget_coding_system (Qraw_text);