Re: rel-0-9; Some inline math is shown at the beginning of the line

David Kastrup wrote:

> Sebastian Schubert <[email protected]> writes:
> 
>> Sebastian Schubert wrote:
>>
>>> David Kastrup wrote:
>>>>> When I run preview-latex, some of my inline formulas are shown
>>>>> correctly (first two in the example below), some are shown at the
>>>>> beginning of the line while the code is still visible (the others).
>>>>> Actually, I can't say exactly when it happens.
>>>>>
>>>>> \documentclass{article}
>>>>> \begin{document}
>>>>> Eine Punktladung $Q$ befinde sich im Koordinatenursprung, deren
>>>>> Ladungsdichte lautet dann $\rho(\vec{x})=Q\delta(\vec x)$.  Wenn auf
>>>>> beiden Seiten über eine Kugel $K$ mit dem Radius $r$ und
>>>>> \end{document}
>>>> 
>>>> Well, I can.  When international characters are in the same line, in
>>>> particular before the formulas.

[..]
 
> I'd like the output of
> 
> C-h C
> 
> (capital C) both from the run buffer (the one you get with C-c C-l)

Emacs showed "Describe coding system (default, current choices):", I just
pressed RET. It gives me then:

Coding system for saving this buffer:
  Not set locally, use the default.
Default coding system (for new files):
  u -- mule-utf-8 (alias: utf-8)
Coding system for keyboard input:
  nil
Coding system for terminal output:
  u -- mule-utf-8 (alias: utf-8)
Defaults for subprocess I/O:
  decoding: u -- mule-utf-8 (alias: utf-8)
  encoding: u -- mule-utf-8 (alias: utf-8)

Priority order for recognizing coding systems when reading files:
  1. mule-utf-8 (alias: utf-8)
  2. iso-latin-1 (alias: iso-8859-1 latin-1)
  3. iso-2022-jp (alias: junet)
  4. iso-2022-7bit 
  5. iso-2022-7bit-lock (alias: iso-2022-int-1)
  6. iso-2022-8bit-ss2 
  7. emacs-mule 
  8. raw-text 
  9. japanese-shift-jis (alias: shift_jis sjis)
  10. chinese-big5 (alias: big5 cn-big5)
  11. no-conversion (alias: binary)

  Other coding systems cannot be distinguished automatically
  from these, and therefore cannot be recognized automatically
  with the present coding system priorities.

  The followings are decoded correctly but recognized as iso-2022-7bit-lock:
    iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext
iso-2022-jp-2 iso-2022-kr

Particular coding systems specified for certain file names:

  OPERATION     TARGET PATTERN          CODING SYSTEM(s)
  ---------     --------------          ----------------
  File I/O      "\\.elc\\'"             (emacs-mule . emacs-mule)
                "\\(\\`\\|/\\)loaddefs.el\\'"
                                        (raw-text . raw-text-unix)
                "\\.tar\\'"             (no-conversion . no-conversion)
                ""                      (undecided)
  Process I/O   nothing specified
  Network I/O   nothing specified





> and the source file in question.


Coding system for saving this buffer:
  u -- mule-utf-8-unix
Default coding system (for new files):
  u -- mule-utf-8 (alias: utf-8)
Coding system for keyboard input:
  nil
Coding system for terminal output:
  u -- mule-utf-8 (alias: utf-8)
Defaults for subprocess I/O:
  decoding: u -- mule-utf-8 (alias: utf-8)
  encoding: u -- mule-utf-8 (alias: utf-8)

Priority order for recognizing coding systems when reading files:
  1. mule-utf-8 (alias: utf-8)
  2. iso-latin-1 (alias: iso-8859-1 latin-1)
  3. iso-2022-jp (alias: junet)
  4. iso-2022-7bit 
  5. iso-2022-7bit-lock (alias: iso-2022-int-1)
  6. iso-2022-8bit-ss2 
  7. emacs-mule 
  8. raw-text 
  9. japanese-shift-jis (alias: shift_jis sjis)
  10. chinese-big5 (alias: big5 cn-big5)
  11. no-conversion (alias: binary)

  Other coding systems cannot be distinguished automatically
  from these, and therefore cannot be recognized automatically
  with the present coding system priorities.

  The followings are decoded correctly but recognized as iso-2022-7bit-lock:
    iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext
iso-2022-jp-2 iso-2022-kr

Particular coding systems specified for certain file names:

  OPERATION     TARGET PATTERN          CODING SYSTEM(s)
  ---------     --------------          ----------------
  File I/O      "\\.elc\\'"             (emacs-mule . emacs-mule)
                "\\(\\`\\|/\\)loaddefs.el\\'"
                                        (raw-text . raw-text-unix)
                "\\.tar\\'"             (no-conversion . no-conversion)
                ""                      (undecided)
  Process I/O   nothing specified
  Network I/O   nothing specified




> Also the output of 
> 
> M-! locale RET

LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=



> It would appear that your run buffer does not contain any "^^" string
> sequences.  Is that correct?

You mean doing preview, then C-c C-l, then changing in the new buffer and
C-s ^^ or C-r ^^? Yes, there isn't any "^^", even any "^". 

I found another strange thing. "Generate previews" ... "at point", "for
environment", "for section" and "for buffer" don't show any previews in my
document posted above. I can see in the minibuffer that there was a
compilation and I can look at it (by C-c C-l) but no previews in the
document buffer. "for document" works (with my problems).

When I try circ.tex (the one that came with preview latex) it is even
stranger. On the one hand, "Generate previews for document" does everything
perfectly. Even inline math near ä,ö,ü works and \section{Einführung} gives
Einführung. On the other hand, "... at point" or "...for buffer" don't do
anything and "for section" shows the problem with non-English letters (eg
\section{Einführung} becomes EinfÄ1/4hrung).

Somehow, I hope I don't do anything really stupid. :)

Thanks for your work,
Sebastian