tex-style.el

Sorry that I have only now come across it:

custom-add-load is a compiled Lisp function in `custom'.
(custom-add-load SYMBOL LOAD)

To the custom option SYMBOL add the dependency LOAD.
LOAD should be either a library file name, or a feature name.

[back]

custom-autoload is a compiled Lisp function in `custom'.
(custom-autoload SYMBOL LOAD)

Mark SYMBOL as autoloaded custom variable and add dependency LOAD.

[back]

So it might be possible to put into tex-style.el only the information
where the real customizations are to be found.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

This ascender bug in dvipng mode...

Hi,

I now take care that the tightpage special does not show a negative
depth.  This should make sure that superscripts like $^1$ get
displayed properly.  It doesn't.  For some reason, the tightpage lower
edge, in spite of being 0, does not get registered by dvipng.  dvipng
still orients itself at the lower edge of the glyph.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Insertion of leading new line with C-c C-s

[This is a follow-up to a thread from last december, see
<URL:http://article.gmane.org/gmane.emacs.auc-tex/5093>]

Ralf Angeli <angeli <at> iwi.uni-sb.de> writes:

> * Christian Schlauer (2004-12-02) writes:
>
>> When you press `C-c C-s' to insert a section, the first thing that
>> happens is that AUCTeX inserts a new line at point in the buffer [1].
>> I don't like it for two reasons:
>>
>> 1. I sometimes accidentally press `C-c C-s', and then `C-g' is not
>>    sufficient to abort, one also has to do `C-_'.
>
> I find this annoying as well.
>
>> 2. The new line is always inserted [1], even if there is already a
>>    blank line before point. I don't want two blank lines in front of a
>>    \section, so I always have to remove it.
> [...]
>> I would prefer to remove the two lines, but bundling the modification
>> of the buffer in `LaTeX-section-section' and thus delaying the
>> insertion of the new line would be better than the current state, too.
>> But in the second case, I would prefer a smarter mechanism that
>> doesn't add a new line if there is already a new line before point.
>
> I like this last suggestion.  One could check if the return value of
> `(save-excursion (skip-chars-backward "\n\f"))' is less than -1.  (Not
> sure if "\f" is needed, but IIRC there were problems with XEmacs if it
> wasn't included.)

Re: Insertion of leading new line with C-c C-s

Oh, I forgot the patch 

--

-- 
Christian Schlauer

_______________________________________________
auctex-devel mailing list
auctex-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/auctex-devel

Re: tex-style.el

* David Kastrup (2005-04-03) writes:

> Sorry that I have only now come across it:

You don't have to be sorry, because you came across it before, see
link below. (c:

> custom-add-load is a compiled Lisp function in `custom'.
> (custom-add-load SYMBOL LOAD)
[...]
> custom-autoload is a compiled Lisp function in `custom'.
> (custom-autoload SYMBOL LOAD)
[...]
> So it might be possible to put into tex-style.el only the information
> where the real customizations are to be found.

I wrote about some problems with this approach in
<URL:http://article.gmane.org/gmane.emacs.auc-tex/5999>.

--

-- 
Ralf

Re: Re: preview-latex 0.9.1 and AUCTeX 11.whatever

Jan-Åke Larsson <jalar <at> mai.liu.se> writes:

> David Kastrup wrote:
>> The question really is what it would buy us.  "call it from
>> aclocal.m4" does not exactly like a recipe that would save Windows
>> users from installing MSYS.  We still need all components, though
>> we'd pass the threshold between them at fewer times.  So the basic
>> complaint seems to be "David, we hate the EMACS_LISP macro".
>
> Not really. What I am saying, at least, is that I see an increased
> complexity each time we get a bug report.

Actually, I try collecting the complexity in fewer places.  I have to
agree that I might be less than successful.  Part of the complexity is
simply that we are dealing with non-trivial problems, part of the
complexity might be my inability to come up with good design.

>>  One problem is that the autoconf framework relies on a lot of
>> shell variables that are not necessarily exported.
>
> I suppose we could use a verbatim "export" (the limitations of
> "export" in Solaris 2.5, IRIX 6.3, IRIX 5.2, AIX 4.1.5, and Digital
> UNIX 4.0 are of no consequence in this case).

We still would need to know just _what_ to export.  autoconf has a lot
of internal variables.  Probably not many of them occur in the
expressions we have to deal with, but exporting something like
"prefix" in general seems like asking for trouble.

>> At the current point of time, we need the kind of glue that

Re: Re: Insertion of leading new line with C-c C-s

* Christian Schlauer (2005-04-03) writes:

> [This is a follow-up to a thread from last december, see
> <URL:http://article.gmane.org/gmane.emacs.auc-tex/5093>]
[...]
> I attach a patch that does the right thing: it inserts a new line only
> if the previous line is not empty or does not start with `[possible
> whitespace]\begin'. The latter is to avoid things like
>
> \begin{some-environment}
>
>   \section{blah}
>
> where a blank line between the beginning of the environment and the
> section is not wanted.

Why isn't it wanted in this case?

> I couldn't use `skip-chars-backward' as suggested by Ralf because that
> didn't work when the section is already indented, for example when the
> section is within a `multicols' environment. Try to insert sections in
> the following document, and you will see that the code `does the right
> thing':

The code fails to insert a newline in the following case:

text text text

text text text-!-

Suggested feature...

For macro insertion like \usepackage, it would make sense to check
whether we are
a) in the master file
b) outside of the document environment properly.

If we aren't, it would be nice to
a) change to the master file if not there already, just before
   \begin{document} and announce that C-c ^ can be used for returning
b) Push the mark at the previous location and announce that C-u C-SPC
   can be used for returning.

This means that AUCTeX would need to have an idea about what commands
are preamble-only.  This can be automatically guessed when parsing,
since such commands usually are marked with

\ <at> onlypreamble\usepackage

and similar.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggested feature...

* David Kastrup (2005-04-03) writes:

> This means that AUCTeX would need to have an idea about what commands
> are preamble-only.  This can be automatically guessed when parsing,
> since such commands usually are marked with
>
> \ <at> onlypreamble\usepackage
>
> and similar.

The more such reqirements for features pop up, the more I get the
impression it would be a good idea to build some sort of macro
database for the various modes.  One entry would carry information
about

  * the command name,

  * the insertion mechanism (optional and mandatory arguments,
    functions to be called, where to leave point; basically what we
    have now),

  * structure of the macro (e.g. "[{{"; maybe somehow encoded in the
    insertion mechanism but should be easily accessible by folding and
    fontification code),

  * faces to be applied by fontification (font-latex currently is only
    able to fontify three parts of a macro, the macro name, optional
    arguments and mandatory arguments; and all of these have to be
    adjacent.  So you cannot have \magenta[orange]{blue}[yellow]{green}.
    But this might change in the future.),

Re: This ascender bug in dvipng mode...

David Kastrup wrote:
> I now take care that the tightpage special does not show a negative
> depth.  This should make sure that superscripts like $^1$ get
> displayed properly.  It doesn't.  For some reason, the tightpage lower
> edge, in spite of being 0, does not get registered by dvipng.  dvipng
> still orients itself at the lower edge of the glyph.

I knew I should have looked into this more thouroghly. I coded the
tightpage code in dvipng to do exactly the same thing as your Postscript
snippet, so it does do everything you want. You can just as well revert
that last change, sorry for that extra work. The _real_ problem is that
'tightpage' is identified by looking at the postscript header at the
beginning of the DVI and that changed in revision 1.65 of preview.dtx
(before 0.7.3) with the innocent-looking log entry "Code cosmetics". In
a preview-latex run there is now an ignored PS header in the DVI and no
message "Preview-latex tightpage option detected". dvipng simply reverts
to the default behaviour.

Since this code may change again, may I suggest a -T tightpage option to
dvipng?
/JÅ