bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov Date: Tue, 07 Oct 2014 13:20:03 +0000

 >>>> Yes, but what's the reason for having latin-extra-code-table in
 >>>> the first place?

 >>> I vaguely remember that it was a request from latin-1 users who
 >>> occasionally have to edit files created by Windows users, and those
 >>> files tend to contain those non-Latin-1 characters.

[…]

 >> Thus, just using the windows-1252 encoding (perhaps also as a
 >> default fallback in Latin-1 environments) looks like a cleaner
 >> solution to me.

 > Solution to what problem?

        To the problem of reading “files created by Windows users” into
        Emacs buffers.  (See above.)

 > And how do you propose to apply that solution in the case in point,

        By a chance, aren’t we now talking about different issues
        altogether?  (Emacs crashing vs. latin-extra-code-table.)

 > where Emacs is _guessing_ the encoding, as the user didn't tell how
 > to decode the file?

        Sorry, I don’t know the exact magic Emacs implements in this
        case, but couldn’t Emacs be instructed to, whenever
        (set-language-environment "Latin-1") is in effect, try to use
        the windows-1252 encoding for the files being read /iff/
        iso-8859-1 (the default in this case, I presume) fails?

        Again, I’m not an expert in the Emacs i18n support, but wouldn’t
        such an approach allow us to drop latin-extra-code-table?

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A