Re: Mixed EOL characters causes improper font locking and often wisi parser hangs

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> brownt.fully@aleeas.com writes:
>
>> I've encountered situations where there are multiple developers and
>> sometimes (likely due to merging), we will end up with source files
>> that contain both CRLF and LF line endings on different lines of the
>> source file.  Ideally, these should be cleaned up and only a single
>> line ending should be used for a file, however it is a reality which
>> likely will not be immediately solved.
>
> Ok.
>
>> When files with mixed line endings are encountered in ada-mode, I've
>> seen a couple different problems. The least severe is that the font
>> locking ends up being skewed and certain characters are colored in the
>> wrong font.
>
> Yes; emacs treats the extra CR as characters in the file, but the lexer
> treats them as part of the new_line sequence, so the character positions
> differ.
>
> It should be possible to tell the lexer to work the way Emacs does; I'll
> put that on my list. I doubt the change will be simple enough to provide
> a patch for wisi 3.1.1.

I've looked into this more; it has nothing to do with the lexer.

The problem is in process-send-string; it always does a "coding"
conversion, which normalizes the line ends, stripping the extra CR. So
the byte count that the calling code computes from the buffer is
different from the byte count actually sent, and the protocol relies on
the byte count being accurate.

There's no easy fix for this in ada-mode; your method of cleaning up the
file is the best workaround.

-- 
-- Stephe