all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* preview-latex: frob line lengths?
@ 2002-12-06 14:42 Kai Großjohann
  2002-12-10  9:33 ` David Kastrup
  0 siblings, 1 reply; 5+ messages in thread
From: Kai Großjohann @ 2002-12-06 14:42 UTC (permalink / raw)


The default setting of preview-latex is to frob inline math, too.  I
think I will like it, though after 5 minutes I'm not sure yet :-)

But if, in the source code there is a line break, like $f(x) = 1 +
2x + 3x^2 + 4x^4$, then the output will have a long line because the
formula is displayed all in one line.  This problem becomes
especially pronounced when I use macros with short names which
produce long formulas.

Ideas?

preview-latex really rocks.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: preview-latex: frob line lengths?
  2002-12-06 14:42 preview-latex: frob line lengths? Kai Großjohann
@ 2002-12-10  9:33 ` David Kastrup
  2002-12-10 11:58   ` Sven Utcke
  2002-12-13 16:08   ` Kai Großjohann
  0 siblings, 2 replies; 5+ messages in thread
From: David Kastrup @ 2002-12-10  9:33 UTC (permalink / raw)


kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> The default setting of preview-latex is to frob inline math, too.  I
> think I will like it, though after 5 minutes I'm not sure yet :-)
> 
> But if, in the source code there is a line break, like $f(x) = 1 +
> 2x + 3x^2 + 4x^4$, then the output will have a long line because the
> formula is displayed all in one line.  This problem becomes
> especially pronounced when I use macros with short names which
> produce long formulas.
> 
> Ideas?

There are basically two approaches: the insane and the sane one.  The
insane one is somewhat easier to do but will probably only work with
the Emasc port, not the XEmacs one.  The insane one would be to
"export" newlines within formulas into an after-string of "\n".  This
would make cursor movements behave _very_ strange though.

The sane solution is not to break the line in the first place.  There
are several ways for that: one is $f(x)=1+2x+3x^2+4x^4$, which
obviously does the right thing.  The best way probably would be to
add a text property to the previews that would cause AUC TeX not to
reformat inside of previews when it does paragraph formatting.  Even
better would be if this property also told AUC TeX how much space the
preview takes up.  Then AUC TeX could be told to
a) format such that the previewed source looks nice/does not wrap
b) format such that the original source looks nice/does not wrap
c) format defensively such that both previewed and original source do
   not wrap.

This would be done simply by declaring the respective width of the
resulting large character as
a) the image length
b) the source code length
c) the maximum of both.

It just happens that I am maintainer of AUC TeX also.  Contributions
in that area would be a killer feature: it is one of the things
people are constantly complaining about.  One should probably also
backport other changes in reformatting from Emacs to AUC TeX (which
has its own formatting code).

The other frequent "unreasonable" complaint (i.e., technically
infeasible and not really possible), namely that equation and section
numbers for regenerated previews should not be arbitrary, I have just
fixed in the latest CVS release: using a checkbox on
preview-required-option-list's `counters' option will fix that.

> preview-latex really rocks.

Help it rock more.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: preview-latex: frob line lengths?
  2002-12-10  9:33 ` David Kastrup
@ 2002-12-10 11:58   ` Sven Utcke
  2002-12-10 12:59     ` David Kastrup
  2002-12-13 16:08   ` Kai Großjohann
  1 sibling, 1 reply; 5+ messages in thread
From: Sven Utcke @ 2002-12-10 11:58 UTC (permalink / raw)


David Kastrup <David.Kastrup@t-online.de> writes:

> The other frequent "unreasonable" complaint (i.e., technically
> infeasible and not really possible), namely that equation and section
> numbers for regenerated previews should not be arbitrary, 

My main complaint about preview LaTeX :-)

> I have just fixed in the latest CVS release: using a checkbox on
> preview-required-option-list's `counters' option will fix that.

How is it done (or maybe it simply omits the number?)?

Sven
-- 
 _  __                     The Cognitive Systems Group
| |/ /___  __ _ ___                                       University of Hamburg
| ' </ _ \/ _` (_-<  phone:    +49 (0)40 42883-2576      Vogt-Koelln-Strasse 30
|_|\_\___/\__, /__/  fax  :    +49 (0)40 42883-2572             D-22527 Hamburg
          |___/ http://kogs-www.informatik.uni-hamburg.de/~utcke/home.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: preview-latex: frob line lengths?
  2002-12-10 11:58   ` Sven Utcke
@ 2002-12-10 12:59     ` David Kastrup
  0 siblings, 0 replies; 5+ messages in thread
From: David Kastrup @ 2002-12-10 12:59 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

Sven Utcke <utcke+news@informatik.uni-hamburg.de> writes:

> David Kastrup <David.Kastrup@t-online.de> writes:
> 
> > The other frequent "unreasonable" complaint (i.e., technically
> > infeasible and not really possible), namely that equation and section
> > numbers for regenerated previews should not be arbitrary, 
> 
> My main complaint about preview LaTeX :-)
> 
> > I have just fixed in the latest CVS release: using a checkbox on
> > preview-required-option-list's `counters' option will fix that.
> 
> How is it done (or maybe it simply omits the number?)?

The LaTeX style is called with a special "counters" option that
outputs all changes of counters (they all get registered in cl@@ckpt
or so) at "checkpoints" which in this case are the start and end of
any preview.

Here is the relevant file, somewhat shortened:

[-- Attachment #2: Extract from prcounters.def --]
[-- Type: text/plain, Size: 569 bytes --]

%%
%% This is file `prcounters.def',
%% generated with the docstrip utility.

[...]

\def\pr@eltprint#1{\expandafter\@gobble\ifnum\value{#1}=0%
  \csname pr@c@#1\endcsname\else\relax
  \space{#1}{\arabic{#1}}\fi}
\def\pr@eltdef#1{\expandafter\xdef
  \csname pr@c@#1\endcsname{\arabic{#1}}}
\def\pr@ckpt#1{{\let\@elt\pr@eltprint\edef\next{\cl@@ckpt}%
  \ifx\next\@empty\else\typeout{Preview: Counters\next#1}%
  \let\@elt\pr@eltdef\cl@@ckpt\fi}}
\g@addto@macro\pr@ship@start{\pr@ckpt:}
\g@addto@macro\pr@ship@end{\pr@ckpt.}
\endinput
%%
%% End of file `prcounters.def'.

[-- Attachment #3: Type: text/plain, Size: 1671 bytes --]


As you can see, as customary with preview-latex, a combination of a
bit of TeX trickery solves a complex problem right where it originates.

So you are likely to catch changes in those counters that would
interest you.  Those counter settings are written out to the error
log, and preview-latex records them together with its other error
analysis.  When you now preview a region, the next checkpoint starting
from the start of the region backwards is searched for, and the
counters are set to the value of this checkpoint.  This will not work
before the first preview in a buffer, so in particular it will not
work with C-c C-p C-b; maybe one should then search forward for a
checkpoint so as to be able to insert stuff at the front of a buffer
that is included not as first part in the main document.

(Ok, I'll just do that, just be patient for an hour).

This will impact the speed of the initial full-document run a bit, of
course, but since this is mostly a one-time expense and interactive
work usually mostly deals with much smaller regions, people won't mind
much, I hope.  It will also cause Emacs to exit and restart slightly
slower when you are using the desktop.el package, since then the
previews get saved and restored along with the counter information.

Anyhow, also because the next release will be mostly bugfix related,
the option is not checked by default, LaTeX does not generate the
messages, they don't lower the speed of parsing and the rest of the
operation.

It's performance impacting only if requested, the standard
preview-latex philosophy.

Should be available in 0.7.6, the next release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: preview-latex: frob line lengths?
  2002-12-10  9:33 ` David Kastrup
  2002-12-10 11:58   ` Sven Utcke
@ 2002-12-13 16:08   ` Kai Großjohann
  1 sibling, 0 replies; 5+ messages in thread
From: Kai Großjohann @ 2002-12-13 16:08 UTC (permalink / raw)


David Kastrup <David.Kastrup@t-online.de> writes:

> There are basically two approaches: the insane and the sane one.  The
> insane one is somewhat easier to do but will probably only work with
> the Emasc port, not the XEmacs one.  The insane one would be to
> "export" newlines within formulas into an after-string of "\n".  This
> would make cursor movements behave _very_ strange though.

I notice that C-p already stops in the middle of a line if the line
contains previews of inline formulas with embedded newlines.

Can it get stranger than that?  ;-)
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-12-13 16:08 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-06 14:42 preview-latex: frob line lengths? Kai Großjohann
2002-12-10  9:33 ` David Kastrup
2002-12-10 11:58   ` Sven Utcke
2002-12-10 12:59     ` David Kastrup
2002-12-13 16:08   ` Kai Großjohann

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.