emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: decode-coding-string gone awry?


From: Stefan Monnier
Subject: Re: decode-coding-string gone awry?
Date: Mon, 14 Feb 2005 13:12:03 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

>> instead of being processed directly from the process filter, then
>> you should also ensure that this buffer is unibyte.

> Yuk.  The problem is that this buffer is not only processed by
> preview-latex, but also by AUCTeX, and the versions that get combined
> may be different.  AUCTeX uses the source code buffer's file encoding
> by default, which is fine for basically unibyte based coding systems.

If you can't change this part, then your best bet might be to do something
like:

(defun preview-error-quote (string)
  "Turn STRING with potential ^^ sequences into a regexp.
To preserve sanity, additional ^ prefixes are matched literally,
so the character represented by ^^^ preceding extended characters
will not get matched, usually."
  (let (output case-fold-search)
    (while (string-match 
"\\^*\\(\\^\\^\\(\\(address@hidden)\\|[8-9a-f][0-9a-f]\\)\\)+"
                         string)
      (setq output
            (concat output
                    (regexp-quote (substring string 0 (match-beginning 1)))
                    (decode-coding-string
                     (preview-dequote-thingies (substring (match-beginning 1)
                                                          (match-end 0)))
                     buffer-file-coding-system))
            string (substring string (match-end 0))))
    (setq output (concat output (regexp-quote string)))
    output)))

BTW, you can use the 3rd arg to string-match to avoid consing strings for
`string'.

This way you only apply decode-coding-string to the part of the string which
is still undecoded but not to the rest.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]