[AUCTeX-devel] Re: Process filter and coding system

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2007-07-05) writes:
>
>> Ralf Angeli <address@hidden> writes:
>>
>>> * David Kastrup (2007-07-03) writes:
>>>
>>>> Ralf Angeli <address@hidden> writes:
>>>>
>>>>> Hm, but pasting together random stuff will not be trivial.
>>>>
>>>> Would be the job of the filter routine.
>>>
>>>> Given TeX's byte-centricity,
>>>> it would have to be done even before decoding the byte stream into
>>>> characters.
>>>
>>> Is the string passed to the filter function still a byte stream?
>>
>> set-process-coding-system is a built-in function in `src/process.c'.
>> (set-process-coding-system PROCESS &optional DECODING ENCODING)
>>
>> Set coding systems of PROCESS to DECODING and ENCODING.
>> DECODING will be used to decode subprocess output and ENCODING to
>> encode subprocess input.
>>
>> [back]
>>
>> Setting DECODING to no-conversion will give byte streams to the filter
>> function.  There is the problem of how to deal with incomplete
>> characters in this case.
>
> How would the output finally be decoded?  By calling
> `detect-coding-region' and then `decode-coding-region' on the whole
> output buffer after process exit?

Why detect the coding from the region?  I'd presume that the filter
routine would keep track of the current file and errors (so that it
could highlight them as they come and fold the less interesting stuff
away), so it could usually take the coding from the file in question.
Of course, the output of \showbox would usually be encoded in T1 or
similar: at least NFSS makes it possible to guess a suitable encoding
from the font name.  Similarly for overfull/underfull hboxes.

There is a lot of potential for packing magic into the filter routine,
and likely some of it might be most efficiently done with CCL programs
even if it is more in the area of parsing rather than character
transliteration.  Which would probably rule out non-Mule XEmacsen.  I
don't think that this should keep us from considering CCL if it seems
best-suited for the task.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum