bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors

[jfbu]

Hi Mosé, (replying about 56 months later)

> 
> Le 24 oct. 2017 à 00:24, Mosè Giordano  a écrit :
> 
> 2017-10-23 18:35 GMT+02:00 jfbu :
>> 
>> Le 23 oct. 2017 à 17:09, Mosè Giordano  a écrit :
>> 
>>> 2017-10-23 14:47 GMT+02:00 jfbu :
>>>> In real life example the ``:1: `` pattern appeared farther away on the line
>>>> inside a sentence. To a human, it is obvious it is not a LaTeX error
>>>> message. I am confident the logic for recognizing such error messages
>>>> is improvable. I plan to look at it when I get time to make
>>>> concrete proposal.
>>> 
>>> The relevant regexp is at line 1507 of tex-buf.el:
>>> https://git.savannah.gnu.org/gitweb/?p=auctex.git;a=blob;f=tex-buf.el;h=f458651c2cffc110ef4af4541c6b08af976907fb;hb=HEAD#l1507
>>> Perhaps ".*" is too greedy, anyway that regexp should match anything
>>> that is a legal path.  I don't expect it to be supereasy to find a
>>> regexp matching a path but not a whole sentence ;-)
>> 
>> 
>> Indeed. But the regexp is really minimal, is there some documentation
>> about the underlying difficulties?
> 
> I don't think there is such documentation, but I'd be happy to be proven 
> wrong.
> 

about this:

> As far as I know, using exclamation mark to start an error message is
> just a widespread convention, there is nothing fundamental in it.  For


Only to point out that it is core TeX behaviour in errorstopmode:
(quoting from tex.web sources:)

> The print_err procedure supplies a ‘!’ before the official message, and makes 
> sure that the terminal is awake if a stop is going to occur. 
> 
> @ The global variable |interaction| has four settings, representing increasing
> amounts of user interaction:
> 
> @d batch_mode=0 {omits all stops and omits terminal output}
> @d nonstop_mode=1 {omits all stops}
> @d scroll_mode=2 {omits error stops}
> @d error_stop_mode=3 {stops at every opportunity to interact}
> @d print_err(#)==begin if interaction=error_stop_mode then wake_up_terminal;
>   print_nl("! "); print(#);
>   end


Any LaTeX \PackageError ultimately goes through TeX’s \errmessage and \errhelp 
mechanisms.

But the change file tex.ch implements -file-line-error option and this is 
relevant:

> @x [6.73] l.1734 - file:line:error style error messages.
>   print_nl("! "); print(#);
> @y
>   if file_line_error_style_p then print_file_line
>   else print_nl("! ");
>   print(#);
> @z


The procedure print_file_line has coding

> procedure print_file_line;
> var level: 0..max_in_open;
> begin
>   level:=in_open;
>   while (level>0) and (full_source_filename_stack[level]=0) do
> decr(level);
>   if level=0 then
> print_nl("! ")
>   else begin
> print_nl (""); print (full_source_filename_stack[level]); print (":");
> if level=in_open then print_int (line)
> else print_int (line_stack[level+1]);
> print (": ");
>   end;
> end;


Some other relevant pieces from tex.ch from web2c 

> % Plus, it's nicer just to do an exit with the appropriate status code
> % under Unix.  We call it `uexit' because there's a WEB symbol called
> % `exit' already.  We use a C macro to change `uexit' back to `exit'.


> @d do_final_end==begin
>update_terminal;
>ready_already:=0;
>if (history <> spotless) and (history <> warning_issued) then
>uexit(1)
>else
>uexit(0);
>end


and from tex.web:

> @d spotless=0 {|history| value when nothing has been amiss yet}
> @d warning_issued=1 {|history| value when |begin_diagnostic| has been called}
> @d error_message_issued=2 {|history| value when |error| has been called}
> @d fatal_error_stop=3 {|history| value when termination was premature}



which is probably related to the exit status returned by binary
in case \errmessage has been made used of

Cheers,

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors

[jfbu]

Hi Keita and Mosè,

OK with me, thanks

I noticed in 2017 I wrote


I plan to look at it when I get time to make
concrete proposal.


Obviously I never got time...

As per my original problem it had occurred in a LaTeX package of mine
and I fixed it there via avoiding using \ref with some argument
including a ":", which I replaced with a full stop "." rather.

This is why, probably, I did not bother more, sorry...


Best,

Jean-François

Le 16/06/2022 à 13:57, Ikumi Keita a écrit :

Hi Mosè and Jean,

I've forgotten this bug, but came across it just now. I expect it was
fixed recently together with bug#55065[1].

Is it OK to close this bug?

Bye,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

[1] https://lists.gnu.org/r/bug-auctex/2022-04/msg00013.html


Mosè Giordano  writes:

2017-10-23 18:35 GMT+02:00 jfbu :


Le 23 oct. 2017 à 17:09, Mosè Giordano  a écrit :


2017-10-23 14:47 GMT+02:00 jfbu :

In real life example the ``:1: `` pattern appeared farther away on the line
inside a sentence. To a human, it is obvious it is not a LaTeX error
message. I am confident the logic for recognizing such error messages
is improvable. I plan to look at it when I get time to make
concrete proposal.


The relevant regexp is at line 1507 of tex-buf.el:
https://git.savannah.gnu.org/gitweb/?p=auctex.git;a=blob;f=tex-buf.el;h=f458651c2cffc110ef4af4541c6b08af976907fb;hb=HEAD#l1507
Perhaps ".*" is too greedy, anyway that regexp should match anything
that is a legal path.  I don't expect it to be supereasy to find a
regexp matching a path but not a whole sentence ;-)



Indeed. But the regexp is really minimal, is there some documentation
about the underlying difficulties?



I don't think there is such documentation, but I'd be happy to be proven wrong.



As far as I know, using exclamation mark to start an error message is
just a widespread convention, there is nothing fundamental in it.  For
the file-line-error style, the first part should match a file path.  I
don't know if it **has** to start with "./" (or "/"), or it may change
depending on the TeX version (and for sure it depends on the platform
used).  The file may end with an extension (AUCTeX doesn't really like
files without any extension), but TeX doesn't require it at all.



Reporting that the LaTeX run had errors, and giving an Error overview
could perhaps be split.

For example if I try this

\documentclass{article}
\begin{document}
Hi
\typeout{./I/am/not/a/file:4: and this is not an error}
\typeout{}
\ERROR
\typeout{}
\typeout{! I am not an error.}

Did it go OK?
\end{document}

with Latexmk, it will only say

Collected error summary (may duplicate other messages):
latex: Command for 'latex' gave return code 1
Refer to 'temp2.log' for details

Without the \ERROR, it reports no problem. Now, indeed
Latexmk does not report a detailed error summary like AUCTeX
(it does report undefined references etc...)

For example a \PackageError{foo}{zaza}{tata} will also
cause the latex run to exit with return code 1 on my mac os,
hence the return code detects it independently of log contents.

Could AUCTeX check the return code on platforms allowing it?



This is interesting, but should be implemented in a reliable way.



Bye,
Mosè




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48914: 2021-06-07; C-cC-e environment insertion with first line of contents commented out

[jfbu]

Hi Keita,

Le 10/06/2021 à 08:05, Ikumi Keita a écrit :

Hi Jean,


jfbu  writes:

The result is



% \begin{foo}
%   deliberately missing closing $ after \simeq
Reduces the background count rate by a factor of $R$ ($R\simeq 1/(1-.89) = 9.1
for the shielding I used).
% \end{foo}



Perhaps environment insertion should by default, except
if in doctex-mode, not use % ?



or use it only if **all** lines are commented out ?


How about customizing `LaTeX-insert-into-comments' to nil? This option
has an effect of adding comment prefixes at the beginning of line for
some commands, and defaults to t.



Thank you.  I have set it to nil and will see what happens.



AUCTeX sets this option to t unconditionally in doctex mode, so the
current default makes the standard latex mode to behave like doctex mode
in some aspects. (I'm not sure why it defaults to t.)


It would be better to be able to set it to nil only in non-doctex mode.

But, although I do currently work often with doctex-mode, I rarely
insert an environment in comments, because
1. in my way of using dtx, the documentation for user is not commented
   out in the file
2. only code comments are commented out (sic)
   and I rarely (almost never) use environments as I use there most of
   the time a custom tex macro for multi-paragraph \verb-like behaviour



Some other commands are affected when you set this to nil, so please
report if it brings any undesired experience for you.



I will try to be alert to changes I may detect.

Thanks for the tip.

Jean-François






___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48524: 13.0.11; AUCTeX should not use LaTeX error message for non-LaTeX modes

[jfbu]

Le 04/06/2021 à 08:14, Ikumi Keita a écrit :

Thank you for confirmation again. I renamed a new variable slightly and
pushed the commit to git repo.

I'll close bug#21595 and bug#21517 in addition to this bug.

Hi Keita,
Thanks for taking the time doing this,
Best,
Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48524: 13.0.11; AUCTeX should not use LaTeX error message for non-LaTeX modes

[jfbu]

Le 03/06/2021 à 07:55, Ikumi Keita a écrit :

Sorry for late, I have now applied the patch and it seems
to do exactly what I was expecting.

Thanks for confirmation. The proposed patch has a small incompatibility
with the current AUCTeX that the customize option
`TeX-error-description-list' can no longer have a fallback entry that
matches any error, but I expect that there are few users who customized
it. I included a news entry which warns the incompatibility in the
attached patch.

Does anyone have comments or opinions?


Hi, only to confirm patch applied cleanly.
I tested it with LaTeX and with Plain (with pdftex engine) and it appears
to work as expected, at my locale.  I don't have experience with
customizing TeX-error-description-list so can't comment on the fallback
entry un-customizability.  Here is a situation
causing pdftex to abort abruptly after an initial error, and
then "No help available" is shown.

ABCD

\def\foo{\begingroup\foo}

\foo

\bye

(the "No help available" context will appear if producing PDF not DVI
as it is triggered by an error

==> Fatal error occurred, no output PDF file produced!

generated by pdftex only in pdf mode)


Best,
Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48524: 13.0.11; AUCTeX should not use LaTeX error message for non-LaTeX modes

[jfbu]

Hi Keita,

Le 27/05/2021 à 14:09, Ikumi Keita a écrit :

Hi Jean,


jfbu  writes:

I am of the opinion that AUCTeX should use the original Knuth
error messages.



[...]



The problem is to avoid in Plain TeX runs (or ConTeXt ? I am not
familiar with it) to have the auctex generated error help go into
LaTeX considerations which are not relevant to Plain TeX.


It seems that a similar topic was discussed before[1]. 


Indeed.  I was very articulate back then, I feel I have lost my
vocabulary since.

Tassilo's idea

that AUCTeX allows the form (REGEX . FUNCTION) in addition to (REGEX .
STRING) as entries in `TeX-error-description-list' would need some work,
so the attached rough hack might be of some interest for you.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21595



Sorry for late, I have now applied the patch and it seems
to do exactly what I was expecting.

I.e. this TeX file

\def\foo1{}
\foo.
\bye


triggers this error window on  C-c `

ERROR: Use of \foo doesn't match its definition.

--- TeX said ---
l.2 \foo.
 
--- HELP ---

From the .log file...

If you say, e.g., `\def\a1{...}', then you must always
put `1' after `\a', since control sequence names are
made up of letters only. The macro here has not been
followed by the required stuff, so I'm ignoring it.


which is the actual text in the log file originating in pdftex
sources, copied over from Knuth original TeX.

Note : I applied the patch on my git clone, after
having pulled to get the latest commits, HEAD was
at 93d66d1a Adapt for Texinfo mode

For some reason I had to delete from the patch
the change to tex-jp.el

$ git apply patchlatexerrors
error: patch failed: tex-jp.el:538
error: tex-jp.el: patch does not apply


I suspect some encoding problem on my side (the buffer
indicated a "1" in bottom left) from gunzip


Best,

Jean-François
 





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48524: 13.0.11; AUCTeX should not use LaTeX error message for non-LaTeX modes

[jfbu]

Le 19/05/2021 à 18:16, jfbu a écrit :

I understand this is some work to extract from pdftex.web the
errors (perhaps someone in the last 30+ years or so has done so,
regarding the Knuth original messages, as pdftex adds some of its
own) and I am opening this bug ticket only for reference as for many


As auctex launches pdftex with -interaction=nonstopmode, the
additional help messages displayed by TeX/LaTeX end up in the log file.

So it is only a matter here to fetch the messages from the log,
rather than using the specific ones incorporated into tex-buf.el

This mechanism is already in place where tex-bug.el does not have
an entry matching the message:

ERROR: Extra \or.

--- TeX said ---
l.37 \iftrue\expandafter\fi\or
  
--- HELP ---

From the .log file...

I'm ignoring this; it doesn't match any \if.

So, it should not be complicated.

The problem is to avoid in Plain TeX runs (or ConTeXt ? I am not familiar with 
it) to have the auctex generated error help go into LaTeX considerations which 
are not relevant to Plain TeX.

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48524: 13.0.11; AUCTeX should not use LaTeX error message for non-LaTeX modes

[jfbu]

Hi,

In tex-buf.el I see for example

("Use of [^ ]* doesn't match its definition." .
 "It's probably one of the picture-drawing commands, and you have used
the wrong syntax for specifying an argument. If it's \\@array that
doesn't match its definition, then there is something wrong in an
@-expression in the argument of an array or tabular
environment---perhaps a fragile command that is not \\protect'ed.")


And this is triggered for example by this Plain tex file

\def\foo1{}
\foo.
\bye

But in the source for pdftex pdftex.web see at about line 9480

@ @=
begin print_err("Use of "); sprint_cs(warning_index);
@.Use of x doesn't match...@>
print(" doesn't match its definition");
help4("If you say, e.g., `\def\a1{...}', then you must always")@/
  ("put `1' after `\a', since control sequence names are")@/
  ("made up of letters only. The macro here has not been")@/
  ("followed by the required stuff, so I'm ignoring it.");
error; return;
end

I am of the opinion that AUCTeX should use the original Knuth
error messages.

Even for LaTeX the above error message is now really dated,
but this is not topic of this ticket.

I understand this is some work to extract from pdftex.web the
errors (perhaps someone in the last 30+ years or so has done so,
regarding the Knuth original messages, as pdftex adds some of its
own) and I am opening this bug ticket only for reference as for many
many years each time I have had errors playing around with 
TeX I have always been slightly annoyed to see LaTeX specific
error messages. As a result, I most of the time execute etex or pdftex
in a Terminal bypassing auctex.

! Use of \foo doesn't match its definition.
l.27 \foo.
  
? h
If you say, e.g., `\def\a1{...}', then you must always
put `1' after `\a', since control sequence names are
made up of letters only. The macro here has not been
followed by the required stuff, so I'm ignoring it.


Best,





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48365: 13.0.11; Dollars in distinct comments trigger math mode highlighting in text in-between

[jfbu]

Hi Keita-san
Le 12 mai 2021 à 19:04, Ikumi Keita  a écrit :

 % -*- mode: latex; -*-
 %
 \def\foo_with_underscore{}
 \newcommand\foo{$}%$
 % a comment
 A foo_bar^bar{$}
 % a comment
 B foo_bar^bar{$}
 % a comment
 C foo_bar^bar
 $
 %
 %
 
 In case of file B, which differs only by an added %$ at end of the
 \newcommand line, the \newcommand for example is not highlighted and
 the B line changes colors without applying script style, see
 screenshot
> 
> Fixed in the git repo. Please try.

Seems to work indeed
Somehow I have to hit C-cC-n to get fontification inclusive of subscripts 
getting lowered
to work after adding  a $ at the end of \newcommand\foo{$}%

% -*- mode: latex; -*-
%
\def\foo_with_underscore{}
\newcommand\foo{$}%
% a comment
A foo_bar^bar{$}
% a comment
B foo_bar^bar{$}
% a comment
C foo_bar^bar
$
%
%

but all looks fine to me. Thanks!
Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48365: 13.0.11; Dollars in distinct comments trigger math mode highlighting in text in-between

[jfbu]

Hello Tassilo=Keita-san
Le 12 mai 2021 à 08:49, Tassilo Horn  a écrit :

> Ikumi Keita  writes:
> 
> Hi Ikumi,
> 
>>> Would it make sense to apply these rules:
>> 
>>> 1. a $ in comments can never start math mode
>>> 2. but it can and will always stop math mode
>> 
>> That is a clean idea and, fortunately, easy to implment. Could you test
>> the attached patch?
> 
> I've committed a completely identical patch an hour ago with a diff just
> in the comment explaining what we are doing.  It's very encouraging when
> we both have the very same idea, so I think, it cannot be too wrong. :-)
> 
> Thanks,
> Tassilo

It is now revealed you are only one entity (perhaps an A.I. based
on quantum computing) pretending to be two humans only to
justify coverage of all time zones !

I have pulled the commit and it appears to work fine in my real-life
files (using doctex mode)

But I notice something weird when comparing effect on those two files

File A behaves as expected
% -*- mode: latex; -*-
%
\def\foo_with_underscore{}
\newcommand\foo{$}%
% a comment
A foo_bar^bar{$}
% a comment
B foo_bar^bar{$}
% a comment
C foo_bar^bar
$
%
%

File B seems to have a problem
% -*- mode: latex; -*-
%
\def\foo_with_underscore{}
\newcommand\foo{$}%$
% a comment
A foo_bar^bar{$}
% a comment
B foo_bar^bar{$}
% a comment
C foo_bar^bar
$
%
%


In case of file B, which differs only by an added %$ at end of the \newcommand 
line,
the \newcommand for example is not highlighted
and the B line changes colors without applying script style,
see screenshot



In case of file B I was expecting the B line to be styled in math mode,
it only has its color it seems,
and I was not expecting \newcommand\foo to lose its highlighting,

Perhaps this is a symptom of something else?

Best,
Jean-François



___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48365: 13.0.11; Dollars in distinct comments trigger math mode highlighting in text in-between

[jfbu]

Le 11 mai 2021 à 22:33, Tassilo Horn  a écrit :

> 
>> Sadly, I now have another problem. Consider this:
>> 
>> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
>>{\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%
>> 
>> There is $ in there, and it triggers math mode highlighting which is a
>> priori fine, I can live with that *if I can constrain it to not extend
>> beyond that line*
>> 
>> In the past I would control it this way:
>> 
>> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
>>
>> {\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%$
>> 
>> (observe the added $ at end of second line after the % comment character)
>> 
>> With your patch the %$ does not stop the math highlighting !
> 
> Now that you've mentioned it, I remember I wanted to do that change also
> in the past and Keita-san stopped me from doing so for exactly this
> reason.
> 
> I've pushed another commit which ignores $ in comments with the single
> exception of the "% $ \n" workaround, i.e., a comment with just a $,
> arbitrary spaces/tabs before or after the $, and then the end of the
> line.
> 
> I'm not sure what is worse.  The restriction to have at least balanced $
> also in comments, or the now very restrictive workaround form.  We'll
> see if someone complains because that breaks his
> 
>  % Workaround fix $.
> 
> comment fixes.
> 

Hi Tassilo, sorry for causing all the trouble.

I pulled your commit and it works. For me that's working solution.

Would it make sense to apply these rules:

1. a $ in comments can never start math mode
2. but it can and will always stop math mode

Cheers,

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48365: 13.0.11; Dollars in distinct comments trigger math mode highlighting in text in-between

[jfbu]

Hi Tassilo,

Le 11/05/2021 à 21:26, Tassilo Horn a écrit :

Hi Jean-Francois,


git bisect indicates first bad commit is

commit 6654955216a42936b87f76dc346aad829b1d52fb
Date:   Wed Jun 3 01:44:32 2020 +0900

 Use search-based fontification for $...$ (bug#33139)

Reading the commit message, I see there was extensive discussion and
the change seems to have been discussed in depth and well-motivated. I
wonder if you can confirm that you see the same at your locale as me.


Yes, I see the problem.  I've pushed a fix which ignores $ in comments
just as it already ignored $ in verbatim contexts.

Could you please test and report back?



Yes, it works also in original context, not only in the short test file.
I realize now that after all I did work for a while with this problem
and I see one file where I have lots of extra $'s added in comments
to create pairs of $'s and avoid the propagation, I removed them
and no ill effect arose, the math highlighting was not applied.

But... wait...

Sadly, I now have another problem. Consider this:

\def\XINT:NE:f:noeval:from:braced:u:p #1#2%
{\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%

There is $ in there, and it triggers math mode highlighting which is a priori 
fine,
I can live with that *if I can constrain it to not extend beyond that line*

In the past I would control it this way:

\def\XINT:NE:f:noeval:from:braced:u:p #1#2%
{\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%$

(observe the added $ at end of second line after the % comment character)

With your patch the %$ does not stop the math highlighting !

This is very problematic to me because that problem can't be solved (as I
could solve earlier one, especially now that I understand better what causes it,
via locating extra $'s inside comments)
by adding a commented out $.

It basically means I have not way to stop the highlighting from propagating...

Jean-François




Bye,
Tassilo



___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex







___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#48365: 13.0.11; Dollars in distinct comments trigger math mode highlighting in text in-between

[jfbu]

Consider the following file:

% -*- coding: utf-8; mode: latex; -*-
% $
\def\foo_with_underscore{}
%
%
\def\foo_bar_foo_bar{}
% $
%

The presence of the $ sign in comments trigger math mode highlighting in 
between, as demonstrated in the attached screenshot



This happens in 13.0.11 (installed via Elpa) but did not happen at 12.2.0 and 
in fact I sticked with 12.2.0 for a long period because I had it still by 
accident on another computer where I had started lots of tex coding using very 
often $ in comments for some special reasons (it had another catcode) and when 
on my laptop which was with auctex from git I realized I could not work at all 
anymore because of this highlighting problem I simply rsync'ed from my other 
computer to my laptop as I had no time to devote to this issue. I thought 
perhaps the problem was with doctex-mode but today I see I can trigger it in 
latex-mode.

git bisect indicates first bad commit is

commit 6654955216a42936b87f76dc346aad829b1d52fb
Date:   Wed Jun 3 01:44:32 2020 +0900

Use search-based fontification for $...$ (bug#33139)

Reading the commit message, I see there was extensive discussion and the change 
seems to have been discussed in depth and well-motivated. I wonder if you can 
confirm that you see the same at your locale as me.

Possibly relevant to this in my config are (but I did not try to change them)

 '(font-latex-fontify-script (quote multi-level))

 '(texmathp-search-n-paragraphs 0)

For the latter I dimly recall it was an old issue I had in doctex with 
highlighting too but I don't recall the details and it might be something else 
whatsoever. (I think last week I did try removing this to see if it affected 
the present issue but it did not).




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#36904: 12.1.1; document class completion reports error if beamer is chosen

[jfbu]

Le 3 août 2019 à 15:19, Ikumi Keita  a écrit :

> Hi Jean,
> 
>>>>>> jfbu  writes:
>> Hi,
>> Steps to reproduce:
> 
>> 1. Find a new empty file in new buffer
> 
>> 2. C-c C-e and choose document
> 
>> 3. Then enter beamer in the mini-buffer as document class
> 
>> An error is raised with message
> 
>> Symbol’s value as variable is void: LaTeX-hyperref-package-options-list
> 
> Isn't this the same as bug#35649?
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35649


Yes sorry for noise,
> 
> The fix for bug#35649 was already pushed in the git repository.  (It
> isn't yet incorporated in ELPA release.)


Indeed I discovered bug#35649 from examining the commit messages
in the git repository and finding the c92251cb one mentioning
it

However from the git repo view, it seems not easy to know
which ELPA releases happened,

And https://www.gnu.org/software/auctex/ seems
to be lacking current information on bug fixes

Best,

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#36904: 12.1.1; document class completion reports error if beamer is chosen

[jfbu]

Le 3 août 2019 à 15:02, jfbu  a écrit :

> 
> Le 3 août 2019 à 14:34, jfbu  a écrit :
> 
>> Hi,
>> 
>> Steps to reproduce:
>> 
>> 1. Find a new empty file in new buffer
>> 
>> 2. C-c C-e and choose document
>> 
>> 3. Then enter beamer in the mini-buffer as document class
>> 
>> An error is raised with message
>> 
>> Symbol’s value as variable is void: LaTeX-hyperref-package-options-list
>> 
>> 
>> I don't seem to have any reference to this variable in my configuration 
>> files,
>> 
>> My 12.1.1 has some patches from dev repo but possibly not all.
>> 
>> Sorry if this error does not show on genuine install but I don't have any 
>> time
>> to investigate.
> 
> 
> I can reproduce error with fresh Elpa installed pristine 12.1.2 release
> 
> (by the way, https://www.gnu.org/software/auctex/ isn't informative on 
> current release)
> 
> my custom.el has no reference to this variable, nor my other stuff in emacs
> personal configuration


Sorry for noise but I see in dev repo

$ git log -1 c92251cb
commit c92251cb8dca5a35c818b0ce903277dd36e893ec
Author: Arash Esbati 
Date:   Fri May 17 13:42:14 2019 +0200

Load hyperref.el in `LaTeX-beamer-class-options'

* style/beamer.el (LaTeX-beamer-class-options): Load "hyperref.el"
in order to have `LaTeX-hyperref-package-options-list' defined
when the document class is requested and the style hook hasn't run
yet.  (bug#35649)

hence I suppose mine is a duplicate of bug#35649.

A remark: correct me if I am wrong but the dev repo (git savannah)
url = https://git.savannah.gnu.org/git/auctex.git

has not tags for ELPA releases like 12.1.1 or 12.1.2 ?

This makes it hard to see which commits made it into 12.1.2?
Or am I missing something obvious?

Best,

Jean-François






___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#36904: 12.1.1; document class completion reports error if beamer is chosen

[jfbu]

Le 3 août 2019 à 14:34, jfbu  a écrit :

> Hi,
> 
> Steps to reproduce:
> 
> 1. Find a new empty file in new buffer
> 
> 2. C-c C-e and choose document
> 
> 3. Then enter beamer in the mini-buffer as document class
> 
> An error is raised with message
> 
> Symbol’s value as variable is void: LaTeX-hyperref-package-options-list
> 
> 
> I don't seem to have any reference to this variable in my configuration files,
> 
> My 12.1.1 has some patches from dev repo but possibly not all.
> 
> Sorry if this error does not show on genuine install but I don't have any time
> to investigate.


I can reproduce error with fresh Elpa installed pristine 12.1.2 release

(by the way, https://www.gnu.org/software/auctex/ isn't informative on current 
release)

my custom.el has no reference to this variable, nor my other stuff in emacs
personal configuration

Best,

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#36904: 12.1.1; document class completion reports error if beamer is chosen

[jfbu]

Hi,

Steps to reproduce:

1. Find a new empty file in new buffer

2. C-c C-e and choose document

3. Then enter beamer in the mini-buffer as document class

An error is raised with message

Symbol’s value as variable is void: LaTeX-hyperref-package-options-list


I don't seem to have any reference to this variable in my configuration files,

My 12.1.1 has some patches from dev repo but possibly not all.

Sorry if this error does not show on genuine install but I don't have any time
to investigate.

Best,

Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#36313: 12.1.2; percent symbol in \url{}

[jfbu]

Hi,

Only for testimony regarding this :

Le 27/06/2019 à 13:09, Ryo Furue a écrit :

Thank you very much for this helpful information!  Now I understand that
the reason for the objection is that if the variable is set to t,

AUCTeX [would] rifle through whole remote directory hierarchies in the
search for style files.  [This is a quote from David Kastrup.]


Turns out that for a number of years my office set-up had
a somewhat esoteric way to mount a remote volume which is
only location where I had the rights to install the 5G+
TeXLive releases.

I can confirm that the parsing by AUCTeX of document style
files, starting with \documentclass was excruciatingly slow
on this system (not AUCTeX fault I presume, simply the weird
mount system imposed upon us by the sysadmins.).

Basically for a period of 10 years I was very cautious
to type in full \documentclass{article} etc... and
not rely on C-cC-e with 'document' which would result in a
scan of possible classes, bringing Emacs to a halt in
user interaction and possibility to modify the buffer
for a very long time

For those who care, the situation got fixed recently by
the sysadmins adopting another mount system. (they killed
my access to Maple doing this, but that is another story).

I know this is anecdotical, although not quite off-topic
I hope.

Best,

Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#35284: 12.1.1; new verbatim environment wrongly commented out

[jfbu]

Hi Keita,

Thanks.

But isn't there a bug even for the use case one wants the verbatim to be 
inserted inside the comment?

(which wasn't my case)

Look at commented out last line, and at the added blank line.

\documentclass{article}

\begin{document}
% \begin{verbatim}
% This is a comment
\def\foo#1{foo}
% another comment

% \end{verbatim}
% \end{document}


To be more precise I type

C-cC-e and then verbatim and Return

after having selected with the mouse 3 lines, and the cursor blinks at start of 
\end{document}

Best,

Jean-François


Le 15 avr. 2019 à 16:48, Ikumi Keita  a écrit :

> Hi Jean,
> 
> Please consider customizing the option `LaTeX-insert-into-comments'.
> You will get
> \documentclass{article}
> 
> \begin{document}
> \begin{verbatim}
> % This is a comment
> \def\foo#1{foo}
> % another comment
> \end{verbatim}
> \end{document}
> after the option is set to nil.
> 
> Regards,
> Ikumi Keita
> 
>>>>>> jfbu  writes:
>> Consider this source
> 
>> \documentclass{article}
> 
>> \begin{document}
>> % This is a comment
>> \def\foo#1{foo}
>> % another comment
>> \end{document}
> 
>> Select the three lines delimited by the document environment
> 
>> Hit C-cC-e verbatim
> 
>> Result:
> 
>> \documentclass{article}
> 
>> \begin{document}
>> % \begin{verbatim}
>> % This is a comment
>> \def\foo#1{foo}
>> % another comment
> 
>> % \end{verbatim}
>> % \end{document}




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#35284: 12.1.1; new verbatim environment wrongly commented out

[jfbu]

Emacs  : GNU Emacs 26.1 (build 1, x86_64-apple-darwin13.4.0, Carbon Version 157 
AppKit 1265.21)
 of 2018-06-18
Package: 12.1.1

(my elpa has some patches I think from git repo, but they should not affect 
this)

Consider this source

\documentclass{article}

\begin{document}
% This is a comment
\def\foo#1{foo}
% another comment
\end{document}

Select the three lines delimited by the document environment

Hit C-cC-e verbatim

Result:

\documentclass{article}

\begin{document}
% \begin{verbatim}
% This is a comment
\def\foo#1{foo}
% another comment

% \end{verbatim}
% \end{document}

Regards,

Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#34593: 12.1.1; selecting xelatex from command menu does not reset dvips or dvipdfmx switches

[jfbu]

Le 02/04/2019 à 09:00, Ikumi Keita a écrit :
> Hi Jean, sorry for very late reply.
Hi Ikumi,

Thanks a lot, I am in the midst of some important deadlines
so can not report until a bit,

Best,

Jean-François


> 
> I think that the attached patch will do the job.  However it just resets
> the "PDF from DVI" setting and doesn't restore it when you again change
> the engine to, say, "default".
> Is this what you wanted?  If so, I'll install this change.
> 
> Regards,
> Ikumi Keita
> 
>>>>>> jfbu  writes:
>> Hi,
>> Steps to reproduce.
> 
>> Any latex document previously set-up to do latex+dvips+ps2pdf
>> (or dvipdfmx)
> 
>> select XeTeX as TeX-engine from menu.
> 
>> The dvips + ps2pdf (or dvipdfmx) option remains selected.
> 
>> On C-cC-a  errors arise, because of course no dvi file is produced from 
>> xelatex run.
> 
>> It takes a while until AUCTeX stops.
> 
>> On the positive side, with
> 
>> % Local variables:
>> % TeX-engine: xetex;
>> % End:
> 
> 
>> and C-cC-n 
> 
>> the PDF from Dvi is reset and no problem arises.
> 
>> Could it be added that selecting "Use XeTeX engine" from menu automatically 
>> resets the "PDF from Dvi" setting ?
> 
> 
> 
Hi 





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#34593: 12.1.1; selecting xelatex from command menu does not reset dvips or dvipdfmx switches

[jfbu]

Hi,

Steps to reproduce.

Any latex document previously set-up to do latex+dvips+ps2pdf
(or dvipdfmx)

select XeTeX as TeX-engine from menu.

The dvips + ps2pdf (or dvipdfmx) option remains selected.

On C-cC-a  errors arise, because of course no dvi file is produced from xelatex 
run.

It takes a while until AUCTeX stops.

On the positive side, with

% Local variables:
% TeX-engine: xetex;
% End:


and C-cC-n 

the PDF from Dvi is reset and no problem arises.

Could it be added that selecting "Use XeTeX engine" from menu automatically 
resets the "PDF from Dvi" setting ?

I have a slightly custom TeX-command-list, I don't expect it to be cause of 
this.

Best

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#32345: 12.1.1; wrong preview position for four-byte utf-8 encoded character (xelatex)

[jfbu]

Le 02/08/2018 à 15:06, jfbu a écrit :

There is a problem here with xetex error logs.


I opened an upstream ticket

https://sourceforge.net/p/xetex/bugs/154/

Best,

Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#32345: 12.1.1; wrong preview position for four-byte utf-8 encoded character (xelatex)

[jfbu]

Le 02/08/2018 à 13:34, David Kastrup a écrit :

jfbu  writes:


I obtain partial success with

\documentclass{article}
\usepackage{unicode-math}
\begin{document}

Test: $풞$

\end{document}


[...]


Further the log contains indication something went wrong indeed

l.5 Test: $
풞$
Preview: Tightpage -32891 -32891 32891 32891
./testpreview.tex:5: Preview: Snippet 1 ended.(456786+9830x428605).


Maybe you should bother to mention what you consider "indication
something went wrong indeed".  preview-latex produces error messages on
purpose.  That's the only way to get to the right column.

The problem here is that the character in the error message appears to
be a different character from what is in the source file, so
preview-latex isn't able to correlate it with the source.



So you do understand what I meant then?

Have a nice summer

Jean-François



___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#31686: 12.1.1 ; Generation of Previews for platex with cached preamble fails with filename having spaces

[jfbu]

Hi,

Le 08/06/2018 à 11:19, jfbu a écrit :

Le 02/06/2018 à 14:21, jfbu a écrit :

Notice though that even if that was fixed, bug #31684 would cause a problem


Hi Keita and all,

I can confirm that using proposed patches to fix #31684 and #31685,
this one is cured too in my brief testing with pLaTeX compilation.


Running `Preview-LaTeX' on `abc jap' with ``platex -ini -interaction=nonstopmode "" prv_abc_jap.ini    
"\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
 "\input" "{\detokenize{" \"abc\ jap.tex\" "}}"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(INITEX)
 restricted \write18 enabled.
entering extended mode
(./prv_abc_jap.ini
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 5)
(/usr/local/texlive/2018/texmf-dist/tex/latex/carlisle/mylatex.ltx) 
(/usr/local/texlive/2018/texmf-dist/tex/latex/tools/.tex File ignored))
No auxiliary output files.

[... lines cut ]
No pages of output.
Transcript written on prv_abc_jap.log.

TeX Output finished at Fri Jun  8 11:11:37
Running `Preview-LaTeX' on `abc jap' with ``platex  -kanji=utf8  -file-line-error -interaction=nonstopmode 
\_abc_jap "/AUCTEXINPUT{" \"abc\ jap.tex\" "}"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 5)
CUSTOMISED FORMAT. Preloaded files:
    .
  pldefs.ltx    2018/02/04 v1.6l pLaTeX Kernel (Default settings)
   jy1mc.fd    2018/02/04 v1.6l KANJI font defines
   jy1gt.fd    2018/02/04 v1.6l KANJI font defines
   jt1mc.fd    2018/02/04 v1.6l KANJI font defines
   jt1gt.fd    2018/02/04 v1.6l KANJI font defines
 kinsoku.tex
  "abc jap.tex" jarticle.cls    2018/02/04 v1.7h Standard pLaTeX class
 jsize10.clo    2018/02/04 v1.7h Standard pLaTeX file (size option)
    .
(./abc jap.tex
[ lines cut ]
 )
(see the transcript file for additional information)
Output written on "abc jap.dvi" (1 page, 1584 bytes).
Transcript written on "abc jap.log".

TeX Output exited as expected with code 1 at Fri Jun  8 11:11:37
Running `Preview-DviPNG' with ``dvipng -picky -noghostscript abc\ jap.dvi -o 
abc\ jap.prv/tmppvWcgV/prev%03d.png  -D186 ''
This is dvipng (dvipng (TeX Live)) 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1 (preview-latex version 12.1) (preview-latex tightpage option detected, will 
use its bounding box)]
Preview-DviPNG finished at Fri Jun  8 11:11:37




Due to some mix-up at my side the above is with the first version
of the patches proposed by Keita for #31685.

With the second version of the patches, it does work too, bthere
are some differences in the command line incovations.

Although I am creating a bit of noise, I feel I must now
copy-paste how it really looks like with the v2 of Keita's patches for #31685
at my locale:


Running `Preview-LaTeX' on `abc jap' with ``platex -ini -kanji=utf8 -interaction=nonstopmode "" prv_abc_jap.ini
"\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
 "\input" "{\detokenize{" \"abc\ jap.tex\" "}}"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(INITEX)
 restricted \write18 enabled.
entering extended mode
(./prv_abc_jap.ini
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 5)
(/usr/local/texlive/2018/texmf-dist/tex/latex/carlisle/mylatex.ltx) 
(/usr/local/texlive/2018/texmf-dist/tex/latex/tools/.tex File ignored))
[ cut lines ]
Transcript written on prv_abc_jap.log.

TeX Output finished at Fri Jun  8 11:46:24
Running `Preview-LaTeX' on `abc jap' with ``platex -kanji=utf8 -interaction=nonstopmode -file-line-error 
\_abc_jap "/AUCTEXINPUT{" \"abc\ jap.tex\" "}"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 5)
CUSTOMISED FORMAT. Preloaded files:
.
  pldefs.ltx2018/02/04 v1.6l pLaTeX Kernel (Default settings)
   jy1mc.fd2018/02/04 v1.6l KANJI font defines
   jy1gt.fd2018/02/04 v1.6l KANJI font defines
   jt1mc.fd2018/02/04 v1.6l KANJI font defines
   jt1gt.fd2018/02/04 v1.6l KANJI font defines
 kinsoku.tex
  "abc jap.tex" 
jarticle.cls2018/02/04 v1.7h Standard pLaTeX class

 jsize10.clo2018/

bug#31686: 12.1.1 ; Generation of Previews for platex with cached preamble fails with filename having spaces

[jfbu]

Le 02/06/2018 à 14:21, jfbu a écrit :

Notice though that even if that was fixed, bug #31684 would cause a problem


Hi Keita and all,

I can confirm that using proposed patches to fix #31684 and #31685,
this one is cured too in my brief testing with pLaTeX compilation.


Running `Preview-LaTeX' on `abc jap' with ``platex -ini -interaction=nonstopmode "" prv_abc_jap.ini
"\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
 "\input" "{\detokenize{" \"abc\ jap.tex\" "}}"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(INITEX)
 restricted \write18 enabled.
entering extended mode
(./prv_abc_jap.ini
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 5)
(/usr/local/texlive/2018/texmf-dist/tex/latex/carlisle/mylatex.ltx) 
(/usr/local/texlive/2018/texmf-dist/tex/latex/tools/.tex File ignored))
No auxiliary output files.

[... lines cut ]
No pages of output.
Transcript written on prv_abc_jap.log.

TeX Output finished at Fri Jun  8 11:11:37
Running `Preview-LaTeX' on `abc jap' with ``platex  -kanji=utf8  -file-line-error -interaction=nonstopmode 
\_abc_jap "/AUCTEXINPUT{" \"abc\ jap.tex\" "}"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 5)
CUSTOMISED FORMAT. Preloaded files:
.
  pldefs.ltx2018/02/04 v1.6l pLaTeX Kernel (Default settings)
   jy1mc.fd2018/02/04 v1.6l KANJI font defines
   jy1gt.fd2018/02/04 v1.6l KANJI font defines
   jt1mc.fd2018/02/04 v1.6l KANJI font defines
   jt1gt.fd2018/02/04 v1.6l KANJI font defines
 kinsoku.tex
  "abc jap.tex" 
jarticle.cls2018/02/04 v1.7h Standard pLaTeX class

 jsize10.clo2018/02/04 v1.7h Standard pLaTeX file (size option)
.
(./abc jap.tex
[ lines cut ]
 )
(see the transcript file for additional information)
Output written on "abc jap.dvi" (1 page, 1584 bytes).
Transcript written on "abc jap.log".

TeX Output exited as expected with code 1 at Fri Jun  8 11:11:37
Running `Preview-DviPNG' with ``dvipng -picky -noghostscript abc\ jap.dvi -o 
abc\ jap.prv/tmppvWcgV/prev%03d.png  -D186 ''
This is dvipng (dvipng (TeX Live)) 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1 (preview-latex version 12.1) (preview-latex tightpage option detected, will use its bounding box)] 


Preview-DviPNG finished at Fri Jun  8 11:11:37


Best,

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#31684: 12.1.1; Preview-DviPNG fails with filename having spaces (DviPS is used as fallback)

[jfbu]

Hi Keita

Le 08/06/2018 à 07:02, Ikumi Keita a écrit :

Hi Jean and all,


jfbu  writes:

Experience 2: name it as abc def ghi.tex (so it includes spaces in filename)
Switch to DVI mode
Ask to generate previews for all document.
Answer YES to "Cache preamble?"
It **appears to work** but in fact it doesn't:




Running `Preview-DviPNG' with ``dvipng -picky -noghostscript abc\ def\ ghi.dvi -o 
"abc\ def\ ghi.prv/tmp14749czs/prev%03d.png"  -D186 ''
This is dvipng (dvipng (TeX Live)) 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1 (preview-latex version 12.1) (preview-latex tightpage option detected, will 
use its bounding box)
dvipng: Fatal error, cannot open output file abc\ def\ 
ghi.prv/tmp14749czs/prev001.png


Confirmed.  It seems the reason is that `preview-dvipng-command'
contains spurious quotes.  Various `preview-*-command' are defined as:
(defcustom preview-dvipng-command
   "dvipng -picky -noghostscript %d -o \"%m/prev%%03d.png\""
   ...
(defcustom preview-dvips-command
   "dvips -Pwww -i -E %d -o %m/preview.000"
   ...
(defcustom preview-fast-dvips-command
   "dvips -Pwww %d -o %m/preview.ps"
   ...
(defcustom preview-pdf2dsc-command
   "pdf2dsc %s.pdf %m/preview.dsc"
   ...
.  They don't have quotes around %m except `preview-dvipng-command'.
Removing the quotes makes dvipng works with file name with space on my
side.

In addition, I noticed during test runs that single quotes in
`preview-dvipng-color-string' choke dvipng on w32 platform because
single quotes are not consumed by w32 shell (cmd.exe).

Could you please test the following patch?  (It is for preview.el.in in
the source files, not for preview.el.)



I confirm problem is fixed at my locale for the MWE I posted initially:

(mac os x 10.9.5)

Here is transcript:


...
(see the transcript file for additional information)
Output written on "abc def ghi.dvi" (1 page, 1584 bytes).
Transcript written on "abc def ghi.log".

TeX Output exited as expected with code 1 at Fri Jun  8 10:57:23
Running `Preview-DviPNG' with ``dvipng -picky -noghostscript abc\ def\ ghi.dvi 
-o abc\ def\ ghi.prv/tmpDOwfcQ/prev%03d.png  -D186 ''
This is dvipng (dvipng (TeX Live)) 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1 (preview-latex version 12.1) (preview-latex tightpage option detected, will use its bounding box)] 


Preview-DviPNG finished at Fri Jun  8 10:57:23


My testing does not extend to that part of your patch dealing with options
but I trust it does the right thing...

Best,

Jean-François



___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#31686: 12.1.1 ; Generation of Previews for platex with cached preamble fails with filename having spaces

[jfbu]

Hi,

consider this file

\documentclass{jsarticle}
\def\abc{abc}
\begin{document}
$\abc$
\end{document}

Name it `abc def ghi.tex`.

Compilation (to DVI) works fine.

But generation of previews using cached preamble fails,
the format can not be used:

generation ok

Running `Preview-LaTeX' on `abc def ghi' with ``platex -ini 
-interaction=nonstopmode "" prv_abc_def_ghi.ini
"\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
 "\input" \"abc\ def\ ghi.tex\"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(INITEX)

 etc


but usage fails

Running `Preview-LaTeX' on `abc def ghi' with ``platex  -kanji=utf8  
-interaction=nonstopmode "_abc_def_ghi" \"abc\ def\ ghi.tex\"''
This is e-pTeX, Version 3.14159265-p3.8.0-180226-2.6 (utf8.euc) (TeX Live 2018) 
(preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
! I can't find file `abcdefghi.tex'.
<*> _abc_def_ghi "abc def ghi.tex"
  
(Press Enter to retry, or Control-D to exit)
Please type another input file name
! Emergency stop.
<*> _abc_def_ghi "abc def ghi.tex"
  
No pages of output.
Transcript written on texput.log.

TeX Output exited as expected with code 1 at Sat Jun  2 14:19:27
LaTeX: LaTeX found no preview images


Explanation is simple, the hack of \dump in preview.el is effective only
if \pdfoutput primitive exists. This hack was done to counteract
mylatex.ltx making spaces ignored.

Notice though that even if that was fixed, bug #31684 would cause a problem

Best,

Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#31685: 12.1.1; Preview with cached preamble fails with lualatex engine and filenames with spaces

[jfbu]

Hi,

consider this file

\documentclass{article}
\def\abc{abc}
\begin{document}
$\abc$
\end{document}

and switch engine to luatex.

Then generate previews for document, answering yes to caching preamble.

This fails 

1. the cached format can not be generated

Running `Preview-LaTeX' on `abc def ghi' with ``lualatex -ini 
-interaction=nonstopmode "" prv_abc_def_ghi.ini \ def\ ghi  
-file-line-error   
"\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
 "\input" \"abc\ def\ ghi.tex\"''

notice that the above is ill-formed (see \ def\ ghi -file-line-error) bit

This is LuaTeX, Version 1.07.0 (TeX Live 2018)  (INITEX)
 restricted system commands enabled.
(./prv_abc_def_ghi.ini
LaTeX2e <2018-04-01> patch level 5
(using write cache: 
/usr/local/texlive/2018/texmf-var/luatex-cache/generic)(using read cache: 
/usr/local/texlive/2018/texmf-var/luatex-cache/generic 
/Users/jfb/Library/texlive/2018/texmf-var/luatex-cache/generic)
luaotfload | main : initialization completed in 0.116 seconds 
(/usr/local/texlive/2018/texmf-dist/tex/latex/carlisle/mylatex.ltx))
! I can't find file `def'.
<*>  prv_abc_def_ghi.ini  def 
ghi -file-line-error \nonstopmode\nofile...
(Press Enter to retry, or Control-D to exit)
Please type another input file name
! Emergency stop.
<*>  prv_abc_def_ghi.ini  def 
ghi -file-line-error \nonstopmode\nofile...
 246 words of node memory still in use:
   1 dir, 35 glue_spec nodes
   avail lists: 2:12,3:1,4:1
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on prv_abc_def_ghi.log.


2. even the fallback of not using cached preamble fails  (see bug #31684)

Running `Preview-LaTeX' on `abc def ghi' with ``lualatex --jobname=abc\ def\ 
ghi  -file-line-error   
"\nonstopmode\nofiles\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]\fi}"
 "\input" \"abc\ def\ ghi.tex\"''
This is LuaTeX, Version 1.07.0 (TeX Live 2018) 
 restricted system commands enabled.
LaTeX2e <2018-04-01> patch level 5
(using write cache: 
/usr/local/texlive/2018/texmf-var/luatex-cache/generic)(using read cache: 
/usr/local/texlive/2018/texmf-var/luatex-cache/generic 
/Users/jfb/Library/texlive/2018/texmf-var/luatex-cache/generic)
luaotfload | main : initialization completed in 0.108 seconds
No auxiliary output files.

("./abc def ghi.tex" 
(/usr/local/texlive/2018/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2018/texmf-dist/tex/latex/base/size10.clo(load luc: 
/usr/local/texlive/2018/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)))
No file "abc def ghi".aux.
(/Users/jfb/.emacs.d/elpa/auctex-12.1.1/latex/preview.sty 
(/usr/local/texlive/2018/texmf-dist/tex/generic/luatex85/luatex85.sty) 
(/Users/jfb/.emacs.d/elpa/auctex-12.1.1/latex/prtightpage.def) 
(/Users/jfb/.emacs.d/elpa/auctex-12.1.1/latex/prauctex.def
No auxiliary output files.


(/Users/jfb/.emacs.d/elpa/auctex-12.1.1/latex/prauctex.cfg)) 
(/Users/jfb/.emacs.d/elpa/auctex-12.1.1/latex/prfootnotes.def)
Preview: Fontsize 10pt
Preview: PDFoutput 1
)
./abc def ghi.tex:4: Preview: Snippet 1 started.
<-><->
  
l.4 $
   \abc$
Preview: Tightpage -32891 -32891 32891 32891
./abc def ghi.tex:4: Preview: Snippet 1 ended.(455111+0x911285).
<-><->
  
l.4 $\abc$

[1{/usr/local/texlive/2018/texmf-var/fonts/map/pdftex/updmap/pdftex.map}])
(see the transcript file for additional information)
 362 words of node memory still in use:
   2 hlist, 1 vlist, 1 rule, 2 glue, 4 attribute, 45 glue_spec, 4 
attribute_list, 2 write nodes
   avail lists: 2:14,3:3,4:1,5:11,6:1,7:7,8:3,9:2

Output written on abc def ghi.pdf (1 page, 8584 bytes).
Transcript written on "abc def ghi.log".

TeX Output exited as expected with code 1 at Sat Jun  2 14:03:07
Running `Preview-DviPNG' with ``dvipng -picky -noghostscript abc\ def\ ghi.dvi 
-o "abc\ def\ ghi.prv/tmp14898GFt/prev%03d.png"  -D186 ''
Parser: End of Preview snippet 1 unexpected

Preview-DviPNG killed: 9 at Sat Jun  2 14:03:07


Related notes:

1. Actually caching the preamble when using lualatex is very fragile. It would 
break or
at least be in inconsistent state if any Lua code is executed in the preamble.

Nevertheless, for simple file above, if filename has no spaces, then preview 
generation
appears to work as expected (in PDF mode, luatex engine)

2. When using xelatex, the situation is even simpler, it is impossible currently
to use mylatex.ltx with it. https://github.com/davidcarlisle/dpctex/issues/15

 

This is with AUCTeX 12.1.1.

Jean-François




___
bug-auctex mailing list

bug#31684: 12.1.1; Preview-DviPNG fails with filename having spaces (DviPS is used as fallback)

[jfbu]

Hi,

consider this file

 start
\documentclass{article}
\def\abc{abc}
\begin{document}
$\abc$
\end{document}
 stop

With default engine (pdftex):

Experience 1: name it as abcdefghi.tex.
Switch to DVI mode. (C-cC-tC-p as PDF mode is ON by default)
Ask to generate previews for all document.
Answer YES to "Cache preamble?"
It works.

Experience 2: name it as abc def ghi.tex (so it includes spaces in filename)
Switch to DVI mode
Ask to generate previews for all document.
Answer YES to "Cache preamble?"
It **appears to work** but in fact it doesn't: 


Running `Preview-DviPNG' with ``dvipng -picky -noghostscript abc\ def\ ghi.dvi 
-o "abc\ def\ ghi.prv/tmp14749czs/prev%03d.png"  -D186 ''
This is dvipng (dvipng (TeX Live)) 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1 (preview-latex version 12.1) (preview-latex tightpage option detected, will 
use its bounding box)
dvipng: Fatal error, cannot open output file abc\ def\ 
ghi.prv/tmp14749czs/prev001.png


Preview-DviPNG exited abnormally with code 2 at Sat Jun  2 13:44:48
Running `Preview-DviPS' with ``dvips -Pwww abc\ def\ ghi.dvi -o abc\ def\ 
ghi.prv/tmp14749p9y/preview.ps''
...

So the preview was generated but using ghostscript as a fallback.

In the case with no spaces the process output buffer contains this


TeX Output exited as expected with code 1 at Sat Jun  2 13:50:37
Running `Preview-DviPNG' with ``dvipng -picky -noghostscript abcdefghi.dvi -o 
"abcdefghi.prv/tmp14749bHC/prev%03d.png"  -D186 ''
This is dvipng (dvipng (TeX Live)) 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1 (preview-latex version 12.1) (preview-latex tightpage option detected, will 
use its bounding box)] 

Preview-DviPNG finished at Sat Jun  2 13:50:37


This is with stock AUCTeX 12.1.1.

Jean-François






___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#31217: 12.1.1; typo in TeX-expand-list's "docstring"

[jfbu]

Remember to cover the basics.  Including a minimal LaTeX example
file exhibiting the problem might help.

When doing C-h v TeX-expand-list the following pops up


TeX-expand-list is a compiled Lisp function in ‘tex.el’.

(TeX-expand-list)

Complete list of expansion strings for TeX command names.

Concatenate ‘TeX-expand-list’ and ‘TeX-expand-list-bultin’ making
sure "%p" is the first entry.


there is a typo s/bultin/builtin

Emacs  : GNU Emacs 25.2.3 (x86_64-apple-darwin13.4.0, Carbon Version 157 AppKit 
1265.21)
 of 2017-08-26
Package: 12.1.1




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors

[jfbu]

Hi Mosè

Le 25/10/2017 à 00:59, Mosè Giordano a écrit :

2017-10-24 9:25 GMT+02:00 jfbu <j...@free.fr>:

What about spaces? I know there isn't
a single file with spaces in its path on my TeX installation,
and I personally will never ever attempt to use such in my
TEXMFHOME or in the document repertory or sub-repertories.


TeX and AUCTeX don't have problems with spaces in file names.  I also
avoid spaces in file names, but asking people to completely stop using
spaces in order to make AUCTeX work doesn't look good.


People doing

\section{foo}\label{sec:1: (authorA)}

See \ref{sec:1: (authorA)}

will similarly get bitten by this problem.


Are there really people mixing numeric style and literal style in
labels? :-)  Using anything beside [a-zA-Z0-9-:] in LaTeX labels is
usually a bad idea, just because there are packages playing with
catcodes.  For example, underscores are legal in labels, but there are
cases where you can get into troubles if you use them, see for example
https://tex.stackexchange.com/q/121416/31416 or
https://tex.stackexchange.com/a/18312/31416.


--- start of slightly off-topic LaTeX considerations

As is explained in the answer by HO:


Usually the underscore with its standard catcode "subscript" (8) does
not cause problems, if used inside \label or \ref:

[...]

Also shorthands of package babel are not a problem, because babel
patches the \label/\ref system to add support for shorthands.


Any package making  a character like the underscore globally
active without at the same time using the babel patches for making
it safe in \label/\ref would simply be a buggy package.
HO does end his answer with the "underscore" package and mentions
that package is a good citizen.

A user making the underscore globally active with no further
ado is simply breaking LaTeX and not informed enough.

Notice that babel-french turns the colon : into an active
character, of course in a way compatible with babel's mechanism.
This mechanism is applied by hyperref package in \href parsing.

Ironically, there are issues with xelatex/lualatex where babel-french
does *not* use active characters at all; because the babel
mechanisms do not apply, the behaviour of \href is unexpected.
Very recently indeed, babel-french maintainer pushed a
fix to CTAN to handle that specific issue.


Version:  3.3d  2017-10-19

 Slight change for LuaTeX only:

 The automatic insertion of non-breaking spaces before the colon
 character has been improved: a spurious space is no longer inserted
 in strings like "http://mysite;, "C:\textbackslash Program Files"
 or "10:55".


Regarding that piece of the answer by egreg


Warning. Some characters might give problems when babel is loaded
along with varioref (for example the colon : with French and the
double quote " with many languages). Without varioref these should be
OK. As Martin points out, some packages might redefine _, making it
unusable in labels.


it indicates a bug of varioref, that's all.

--- end of off-topic digression

Now,AUCTeX prompts user at each equation insertion with

(Optional) What label: eq:

now in a paper when it is not sure in advance which
equations one will link to, one is not going to invent
a name each time, and simply using numeric labels eq:1,
eq:2, is rather natural and I am sure people do this.

Or am I really as bezerk I tend to believe, years passing by?

I do agree AUCTeX is still rather robust here because even
using eq:1: as label appears to be ok, problems may arise
when having a space after the second colon.

As people have not complained too much on this issue it
is to some extent indication indeed that AUCTeX's minimal
regex to identify error messages is quite effective.

About


TeX and AUCTeX don't have problems with spaces in file names.


Are spaces escaped in anyway when writing a filename to log?
Unfortunately, here it is not only TeX from TeXBook but rather
also the pdfTeX etc... rules which matters:

They introduced the
filename:linenumber: notation,
dropping the ! at start of line thus making log-parsing
more difficult. Perhaps they could have used a

! filename:linenumber: error

format, but would have this broken expectations from other contexts?

Best

Jean-François







___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors

[jfbu]

Le 23 oct. 2017 à 17:09, Mosè Giordano <m...@gnu.org> a écrit :

> 2017-10-23 14:47 GMT+02:00 jfbu <j...@free.fr>:
>> In real life example the ``:1: `` pattern appeared farther away on the line
>> inside a sentence. To a human, it is obvious it is not a LaTeX error
>> message. I am confident the logic for recognizing such error messages
>> is improvable. I plan to look at it when I get time to make
>> concrete proposal.
> 
> The relevant regexp is at line 1507 of tex-buf.el:
> https://git.savannah.gnu.org/gitweb/?p=auctex.git;a=blob;f=tex-buf.el;h=f458651c2cffc110ef4af4541c6b08af976907fb;hb=HEAD#l1507
> Perhaps ".*" is too greedy, anyway that regexp should match anything
> that is a legal path.  I don't expect it to be supereasy to find a
> regexp matching a path but not a whole sentence ;-)


Indeed. But the regexp is really minimal, is there some documentation
about the underlying difficulties?

Reporting that the LaTeX run had errors, and giving an Error overview
could perhaps be split.

For example if I try this

\documentclass{article}
\begin{document}
Hi
\typeout{./I/am/not/a/file:4: and this is not an error}
\typeout{}
\ERROR
\typeout{}
\typeout{! I am not an error.}

Did it go OK?
\end{document}

with Latexmk, it will only say

Collected error summary (may duplicate other messages):
  latex: Command for 'latex' gave return code 1
  Refer to 'temp2.log' for details

Without the \ERROR, it reports no problem. Now, indeed
Latexmk does not report a detailed error summary like AUCTeX
(it does report undefined references etc...)

For example a \PackageError{foo}{zaza}{tata} will also
cause the latex run to exit with return code 1 on my mac os,
hence the return code detects it independently of log contents.

Could AUCTeX check the return code on platforms allowing it?

If return code is 0, it could then say something like "Log file
contains data looking like errors, but LaTeX run ended with return
code 0". For my example above, with \ERROR commented out,
the return code is 0.

This is why I asked about documentation about the minimal used
regex, because perhaps these were considered already and dismissed
for some reason.

Bye,

Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors

[jfbu]

Hi Mosè

Le 23 oct. 2017 à 14:42, Mosè Giordano <m...@gnu.org> a écrit :

> Hi Jean-François,
> 
> 2017-10-23 11:11 GMT+02:00 jfbu <j...@free.fr>:
>> Hi, here is minimal example:
>> 
>> \documentclass{article}
>> \begin{document}
>> \typeout{Hello:1: }
>> \end{document}
>> 
>> This triggers AUCTeX log parser to report wrongly
>> that there were compilation errors.
>> 
>> The two colons and the space conspire to this result.
>> 
>> It happened in real life example.
> 
> I think you're asking too much :-)  I don't see any meaningful way to
> distinguish between a real error and a message you write to the log
> that is exactly equal to the file-line-error style.  The same happens
> with \typeout{! hello world}.
> 
> Bye,
> Mosè

In real life example the ``:1: `` pattern appeared farther away on the line
inside a sentence. To a human, it is obvious it is not a LaTeX error
message. I am confident the logic for recognizing such error messages
is improvable. I plan to look at it when I get time to make
concrete proposal.

Best,
Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors

[jfbu]

Hi, here is minimal example:

\documentclass{article}
\begin{document}
\typeout{Hello:1: }
\end{document}

This triggers AUCTeX log parser to report wrongly
that there were compilation errors.

The two colons and the space conspire to this result.

It happened in real life example.

Best,

Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25447: 11.90.0; alltt environment should allow being extended in wrapper

[jfbu]

Hi Mosè

Le 14 janv. 2017 à 11:49, Mosè Giordano <m...@gnu.org> a écrit :

> Hi Jean-François,
> 
> 2017-01-14 11:41 GMT+01:00 jfbu <j...@free.fr>:
>> Hi,
>> 
>> \newenvironment{myalltt}
>> {\begin{alltt}%
>>   \IamAllowedToDefineWrapperOfAllTT
>>   \ButFontificationByAucTeXIsProblematic
>>  }
>> {\end{alltt}}
>> 
>> causes fontification problem. I can use \alltt and \endalltt
>> but this forces me to change TeX code for this issue.
>> 
>> (alltt is not implemented like standard verbatim, the latter
>> would indeed not allow the above kind of redefinition)
> 
> This is not limited to "alltt" but to any verbatim-like environment.
> Possible workaround
> 
> --8<---cut here---start->8---
> \newenvironment{myalltt}
> {%
> \begin{alltt}%
>  ...
>  }
> {\end{alltt}}
> --8<---cut here---end--->8---
> 
> Bye,
> Mosè

Thanks for the workaround. In the meantime
I had used 

{\end{alltt}}% \end{alltt}

but yours has even less fontification (only
opening brace)

Bye,
Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25447: 11.90.0; alltt environment should allow being extended in wrapper

[jfbu]

Hi,

\newenvironment{myalltt}
{\begin{alltt}%
   \IamAllowedToDefineWrapperOfAllTT
   \ButFontificationByAucTeXIsProblematic
  }
{\end{alltt}}

causes fontification problem. I can use \alltt and \endalltt
but this forces me to change TeX code for this issue.

(alltt is not implemented like standard verbatim, the latter
would indeed not allow the above kind of redefinition)

Best,

Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

Le 12/01/2017 à 20:40, Mosè Giordano a écrit :

2017-01-12 20:08 GMT+01:00 jfbu <j...@free.fr>:

I get the script raising to work fine, but under the condition
of typing explicitely braces, i.e.

\( x^{y^{z^a_b}} \)

does the expected thing from the docs after having set to
multi-level the ‘font-latex-fontify-script’, but the thing
about electric scripts does not seem to work

\( x^y_z \) does not insert the braces while typing
even with

% Local variables:
% TeX-electric-sub-and-superscript: t
% End:


Does the equation "\( x^y_z \)" start at the beginning of the buffer?
`texmathp' cannot recognize math mode \(...\) starting at bob.  In any
other place it should work fine.  If this is not the culprit, please
open a new issue.



Mystery solved. (I had to cook dinner and then I paid my dues
to politicians on TV -- for a short while)

Looking again at your message the `texmathp' rang a bell

(some problem we discussed here months ago, which I have forgotten
now)

turns out I had this setting:

texmathp-search-n-paragraphs is a variable defined in ‘texmathp.el’.
Its value is 0
Original value was 2

setting it back to 2 solves the issue.

Best wishes,

Jean-François






___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

Le 12/01/2017 à 21:43, jfbu a écrit :

(some problem we discussed here months ago, which I have forgotten
now)



the problem was about use in .dtx file which will never have empty
line in the implementation section due to % prefix.

in my dtx, the documentation section has no % prefix (it has I
think in most other people's dtx's) but nevertheless it may happen
that the dtx is very long and this caused problem from inside the
code section (you can not allow empty lines in code sections
because this create \par tokens that may not be important in LaTeX
context if located in preamble, but may be annoying in TeX
contexts where one can \input style file anywhere), hence I had to
set texmathp-search-n-paragraphs to 0.

I would not need it to be 0 in .tex files.

Best,

Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

Le 12 janv. 2017 à 20:40, Mosè Giordano <m...@gnu.org> a écrit :

> 2017-01-12 20:08 GMT+01:00 jfbu <j...@free.fr>:
>> I get the script raising to work fine, but under the condition
>> of typing explicitely braces, i.e.
>> 
>> \( x^{y^{z^a_b}} \)
>> 
>> does the expected thing from the docs after having set to
>> multi-level the ‘font-latex-fontify-script’, but the thing
>> about electric scripts does not seem to work
>> 
>> \( x^y_z \) does not insert the braces while typing
>> even with
>> 
>> % Local variables:
>> % TeX-electric-sub-and-superscript: t
>> % End:
> 
> Does the equation "\( x^y_z \)" start at the beginning of the buffer?
> `texmathp' cannot recognize math mode \(...\) starting at bob.  In any
> other place it should work fine.  If this is not the culprit, please
> open a new issue.
> 

no it did not start at beginning of buffer but was rather
located at its end. I will open a new issue
(a bit later)
after having looked if something in my .emacs setup causes conflict.

may it have something to do with keyboard input? wait.. I usually
type ^ then SPACE then another char ... no typing x^y directly
without hitting the space bar does not change anything
(the ^ is waiting to see if it will be ê, or ô etc...)

all works fine, but this electric thing.

Best,
Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

I get the script raising to work fine, but under the condition
of typing explicitely braces, i.e. 

\( x^{y^{z^a_b}} \)

does the expected thing from the docs after having set to
multi-level the ‘font-latex-fontify-script’, but the thing
about electric scripts does not seem to work

\( x^y_z \) does not insert the braces while typing
even with 

% Local variables:
% TeX-electric-sub-and-superscript: t
% End:

and reloading the file

Best,

Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

Le 12/01/2017 à 19:57, Mosè Giordano a écrit :

2017-01-12 19:50 GMT+01:00 jfbu <j...@free.fr>:

Hi Mosè,


What is "^" bound to?  Issue

C-h k ^



^ runs the command TeX-insert-sub-or-superscript (found in LaTeX-mode-map),
which is an interactive compiled Lisp function in ‘tex.el’.

It is bound to _, ^.

(TeX-insert-sub-or-superscript ARG)

Insert typed key ARG times and possibly a pair of braces.
Brace insertion is only done if point is in a math construct and
‘TeX-electric-sub-and-superscript’ has a non-nil value.

[back]


Bye,
Mosè

PS: double super- subscripts are not allowed in TeX ;-)



try \input xintexpr.sty\relax\xinttheexpr 2^3^4\relax ;-)



___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

Hi Mosè,

thanks but regarding

Le 12/01/2017 à 19:37, Mosè Giordano a écrit :

In any case I strongly suggest you to set
`TeX-electric-sub-and-superscript' to t, I always find it very useful
also for single character script (in that case braces are redundant,
of course, but they improve readability, IMHO).


it does not work for me (the stuff on top of screenshot was typed
in after having set the variable, and no braces appeared, did I miss
something ?)

but maybe it is time I read the doc first ... ;-)

best,

Jean-François
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

Le 12/01/2017 à 08:38, jfbu a écrit :

The foo^{\psi_n} is ok but all foo_{bar} get the underscore aligned
with exact middle of brace which creates (from a distance and with an
ageing user) this impression about minus signs everywhere.



1. my screenshot is possibly dependent on the font, DejaVu Sans Mono


2. by the way with foo_{bar},  having the _ at the main baseline and the
{bar} with its top at the level of the _, which perhaps is not the
thing one would do a priori, looks like a good option to me. Better
than moving deep down the _ so that it looks like _{bar}, and better
(to me) than having as in my screenshot the _{bar} look like -{bar}

is there a way I can configure the Tassilo's variables so that it looks like


A_
  B_
C

sort of ? (with smaller typefaces)

Best,

Jean-François
   





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#25309: 11.89.8; multi-level script fontification stacks incorrectly

[jfbu]

Hi All,

in the attached screenshot with newly released 11.90, one sees
a feature which I find a bit disturbing: all the subscripts look
like they have a leading minus sign, where in fact it is the underscore
character.

Have you discussed that in the thread already ?
(I read it back then but did not follow all details)

I suppose this is expected result, and as my memory reboots
on each 24h cycle, it may even have nothing to do with this thread
and was like this for ages, but I come asking nevertheless.

The foo^{\psi_n} is ok but all foo_{bar} get the underscore aligned
with exact middle of brace which creates (from a distance and with an
ageing user) this impression about minus signs everywhere.

Cheers

Jean-François

___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#24690: Customize ConTeXt-Mark-version results in wrong-type-argument

[jfbu]

Hi Tassilo,

Le 14/10/2016 à 22:30, Tassilo Horn a écrit :

Mosè Giordano  writes:


This had been already reported and fixed.  However, the change is not
yet available in a released version,


I've released AUCTeX 11.89.6 one hour ago.  It should be available from
ELPA anytime soon.  ;-)

Bye,
Tassilo



I think it took some days because last time I checked it was not
available yet, but right now I have installed it. Thanks !

Jean-François






___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#24668: 11.89.5; Parse failure if long comment at head of file

[jfbu]

Le 12/10/2016 à 12:28, jfbu a écrit :
> Le 11/10/2016 à 17:42, Fran Burstall a écrit :
>> If I put the \documentstyle line in line 1 of the file and
>> then the header, parsing also fails.
> 
> shot in the dark as I don't know your file, but is this a
> typo and you meant \documentclass, or are you using LaTeX 2.09 ?
> 
> (maybe irrelevant to your problem)
> 

indeed as your file which I saw later does have \documentclass

JF






___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#24668: 11.89.5; Parse failure if long comment at head of file

[jfbu]

Le 11/10/2016 à 17:42, Fran Burstall a écrit :

If I put the \documentstyle line in line 1 of the file and
then the header, parsing also fails.


shot in the dark as I don't know your file, but is this a
typo and you meant \documentclass, or are you using LaTeX 2.09 ?

(maybe irrelevant to your problem)

Jean-Francois




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine

[jfbu]

Le 5 nov. 2015 à 10:15, jfbu <j...@free.fr> a écrit :

> the compilation halts immediately (in my experience)
> 
> ERROR: Fatal fontspec error: "cannot-use-pdftex"
> 
> --- TeX said ---
> ! 
> ! The fontspec package requires either XeTeX or LuaTeX to function.
> ! 
> ! You must change your typesetting engine to, e.g., "xelatex" or "lualatex"
> ! instead of plain "latex" or "pdflatex".
> ! 
> ! See the fontspec documentation for further information.
> ! 
> ! For immediate help type H .
> !...  
> 

forgot the important part in the log:

l.43  }
   
|'''
| This is a fatal error: LaTeX will abort.
|...



best,

Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine

[jfbu]

Le 5 nov. 2015 à 10:38, Mosè Giordano  a écrit :

> if more complaints will come I can think about
> changing the default behavior.

I promise not to bribe anyone to emit "dis-like"'s
on AUCTeX's facebook/twitter accounts ;-)

(whatever that means, because I stay safely
light-years away from these so-called social
networks)

bye,
Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine

[jfbu]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.



Hi, 

steps to reproduce:

create file foo.dtx

\iffalse % meta-comment
%<*macos>
\documentclass{article}
\usepackage{fontspec}
\begin{document}
\end{document}
%
\fi
\documentclass{scrdoc}
\begin{document}
\end{document}

try to run (pdf)latex via C-c C-c

you should see the prompt: 

> 
> XeTeX, LuaTeX are required to build this document.
> Do you want to select one of these engines? 
> 

as an aside: sometimes the prompt appears in the
mini-buffer, sometimes as a pop-up (I use framepop.el)
but I have not been able to determine when happens what.

The problem was from a much bigger dtx file, and it
has taken me quite some time to reduce it to the mwe above.

The above structure is quite typical of a dtx file
which can extract files using docstrip, delimited
by guards in the dtx.

In the case at hand, the parsing done by auctex
could possibly identify the \iffalse ... \fi
but in my actual package.dtx, this is more complicated
as I modify catcodes to safely skip hundreds of lines
containing themselves conditionals. Thus it is more
like ~iffalse...~fi in the source.

The mwe above has given me the idea of another one,
which is a foo.tex, not foo.dtx file:

\documentclass{article}

\usepackage{filecontents}

\begin{filecontents}{bar.tex}
\documentclass{article}
\usepackage{fontspec}
\begin{document}
\end{document}
\end{filecontents}

\begin{document}
\end{document}

This will elicit again the 

> XeTeX, LuaTeX are required to build this document.
> Do you want to select one of these engines? 
> 

prompt.

It was hard to get these two mwe's (although now it looks
obvious) because once we get the prompt we can suppress
the entire buffer contents and put anything and we still get
it. Even after removing entirely auto/ directory, etc...

One has to kill the buffer and reload it to get rid
of the prompt (after having killed the fontspec line)

I noticed the issue with a package of mine. I now realize
something has changed in auctex because a Septembre 2013
version of package.dtx now also shows the issue, and I most
definitely did not encounter it back then,

actually I don't think this problem
was showing up with the September 12, 2015 version of
package.dtx, but I forgot when exactly I saw it for the first time.

Best,

Jean-François



Emacs  : GNU Emacs 24.5.7 (x86_64-apple-darwin13.4.0, Carbon Version 157 AppKit 
1265.21)
 of 2015-09-28 on Atago.local
Package: 11.88.8

current state:
==
(setq
 AUCTeX-date "2015-08-28"
 window-system 'mac
 LaTeX-version "2e"
 TeX-style-path '("~/.emacs.d/auctex"
  "/Users/xxx/.emacs.d/elpa/auctex-11.88.8/style"
  "/Users/xxx/.emacs.d/auctex/auto"
  "/Users/xxx/.emacs.d/auctex/style" "auto" "style")
 TeX-auto-save t
 TeX-parse-self t
 TeX-master t
 TeX-command-list '(("TeX"
 "%(PDF)%(tex) %(extraopts) %`%S%(PDFout)%(mode)%' %t"
 TeX-run-TeX nil
 (plain-tex-mode texinfo-mode ams-tex-mode) :help
 "Run plain TeX")
("LaTeX" "%`%l%(mode)%' %t" TeX-run-TeX nil
 (latex-mode doctex-mode) :help "Run LaTeX")
 [...]
 )




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine

[jfbu]

Le 04/11/2015 23:37, Mosè Giordano a écrit :

close 21832
tags 21832 notabug
thanks


2015-11-04 23:30 GMT+01:00 jfbu <j...@free.fr>:

I find it somewhat fragile to decide only on the
basis of having found a \usepackage{fontspec} line
that the engine should be XeTeX or LuaTeX.


Do you have other suggestions?  They're welcome :-)


I don't at this time ... I was surprised by the prompt
for XeTeX/LuaTeX (which in my use case was wrong, but
certainly that was very specific context), and if I had
to pause to think about it, I would be tempted by the somewhat
provocative but sincere feeling that checking for the
engine is not that of a good idea. It would perhaps
if only *one* engine was proposed as candidate, but if one has
to choose between luatex and xetex, that's not much
speed gain compared to doing it beforehand, or
being confronted with a botched pdflatex compilation and
doing it then.

Recently I read a bit of XeTeX doc, and it is perfectly
possible to use it without fontspec package.

I find it a bit surprising to tie discovery of XeTeX/LuateX
to use of fontspec package.

Why not rather a file variable at top of file ? Yes, user will
have thus to put something explicit there, but isn't it actually
better if the file is destined to be exchanged with other people
possibly not using Emacs/AUCTeX ?





This raises maintenance issues on your side as
you must keep an eye on what fontspec will become
in the future, and also on what future engines
might arise etc...


Well, in style/ directory we have 196 files that raise lots of
maintenance issues, so we are used to them ;-)  We do our best to keep
them updated, and we seek for other people helping us.



My defense is now going to become pathetic, but this is time to
reveal that in my practice of auctex I surely underuse by a
factor 1000 the goodies which might come from whatever is in
style/

I must examine that



I'm closing this ticket.



ok
bye,
Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#21595: 11.88.8; TeX help in Plain contaminated by LaTeX

[jfbu]

Le 01/10/2015 16:55, Tassilo Horn a écrit :

jfbu <j...@free.fr> writes:


A guru from the LaTeX3 team tells me it can't be the case,
thus my question is

Does the message somehow come from AUCTeX ?

Perhaps no, in which case sorry for the noise.


Yes, the message comes from AUCTeX.  The variable
`TeX-error-description-list' is an alist of regular expressions matched
agains error messages and such explanations about what that error means
and what might cause it.

The same list is used for plain TeX, LaTeX, ConTeXt etc. and I don't
think it is reasonable to split it into multiple lists just to have some
explanations a bit more specific.  Well, and you are a TeX-pro anyway,
so I'd recommend you put

   (setq TeX-error-description-list '((".*" . "Go figure!")))

into your ~/.emacs. :-)

Bye,
Tassilo



Hi Tassilo,

as I said to Mosè: perhaps in the future, some modifications could
be considered. In the specific case of my test file the Knuth TeX
error message

TeX capacity exceeded, sorry [grouping levels=255]

will remain always quite to the point. This is already nowadays not
quite the case of the LaTeX error message about memory matters.

I will ponder the addition of the line above to my .emacs, but
perhaps I will first make a reading of the database of error
messages in tex-dbg.el as mentioned in the link from Mosè's message.

Bye,

Jean-François







___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#21517: 11.88.8; Error parsing wrong in Plain TeX mode

[jfbu]

Hi Tassilo

Le 19 sept. 2015 à 14:03, Tassilo Horn  a écrit :

>> 
>> I see in the message mini-buffer
>>> TeX errors in `*~/_texlatex/1509/bugauctex output*'. Use C-c ` to display.
>> 
>> On C-c `, I get:
>>> No more errors.
> 
> Ah, there's been a bug in `TeX-TeX-sentinel' which invoked error parsing
> only if there were no errors. ;-)
> 
> I think it is fixed now.  Could you please check and report back?


Yes, I applied the patch to tex-buf.el from the latest commit
and error parsing seems to function as expected in TeX-mode

C-c `  is OK, and Command->Error Overview also

this is at least on my \underline example, but as I never do any
error in TeX coding if not intentionally, it might be
a very long time before I can confirm more generally, though 

;-)

Thanks for the quick fix,

Best,
Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#21517: (11.88.8; Error parsing wrong in Plain TeX mode)

[jfbu]

Le 19 sept. 2015 à 14:04, Tassilo Horn <t...@gnu.org> a écrit :

> jfbu <j...@free.fr> writes:
> 
>>> Then I go to Error Overview in the Command menu, and I get:
>>>> TeX-error-overview: No errror or warning to show
>> 
>> forgot to point out the typo above ("errror") in the AUCTeX message
> 
> That's also fixed now, well, even before the actual error.
> 
> Bye,
> Tassilo

noted, thanks again.

Bye,

Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#20473: 11.88.4; AUCTeX-version incorrect

[jfbu]

Le 1 mai 2015 à 10:59, Tassilo Horn t...@gnu.org a écrit :

 Tassilo Horn t...@gnu.org writes:
 
 jfbu j...@free.fr writes:
 
 in .emacs.d/elpa/auctex-11.88.4/tex-site.el
 
 near the end
 
 (defconst AUCTeX-version 11.88.3
AUCTeX version.
 If not a regular release, the date of the last change.)
 
 which appears incorrect as this is 11.88.4
 
 Oh, indeed.  I've overlooked that when doing the release.  I'm closing
 this bug since it's harmless, and the best I could do was to release
 11.88.5 whose only fix was a corrected version number.  I guess that's
 not worth it.
 
 Ok, 11.88.5 is pushed and should be on ELPA anytime soon.  (It contains
 more changes than just version number. ;-))

much appreciated ;-)

I hesitated doing a bug report for such a thing...

... (11.8.2 also had it wrong, if I checked correctly yesterday)

bye
Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#20473: 11.88.4; AUCTeX-version incorrect

[jfbu]

Hi,

Emacs  : GNU Emacs 24.5.3 (x86_64-apple-darwin13.4.0, Carbon Version 157 AppKit 
1265.21)
 of 2015-04-11 on Atago.local
Package: 11.88.4 installed via ELPA

in .emacs.d/elpa/auctex-11.88.4/tex-site.el

near the end

(defconst AUCTeX-version 11.88.3
AUCTeX version.
If not a regular release, the date of the last change.)

(defconst AUCTeX-date 2015-03-22
  AUCTeX release date using the ISO 8601 format, -mm-dd.)

which appears incorrect as this is 11.88.4

Best
Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#20296: 11.88.3; LaTeX-fill-paragraph gives unexpected result

[jfbu]

Le 10 avr. 2015 à 23:38, Tassilo Horn t...@gnu.org a écrit :

 jfbu j...@free.fr writes:
 
 I do not understand the behavior of LaTeX-fill-paragraph. It keeps
 annoying me with partially filled paragraphs.
 
 Sample .tex file illustrating the problem:
 
 -
 \documentclass{article}
 
 \begin{document}
 % Sample paragraph
 
 Without the separation axiom this does not work, for example let $V$ be an
 infinite dimensional Banach space and let $X = V\cup\{*\}$, and let's 
 declare 
 open the standard open $U\subset V$ as well as $X$ itself. This defines a 
 topology. The space is globally compact in the sense of coverings, but it 
 is not locally compact. Fortunately, it is not separated.
 
 % Applying M-q (LaTeX-fill-paragraph) to the paragraph above we get:
 
 Without the separation axiom this does not work, for example let $V$ be an
 infinite dimensional Banach space and let $X =
 V\cup\{*\}$, and let's declare open the standard open $U\subset V$ as well as
 $X$ itself. This defines a topology. The space is globally compact in the 
 sense
 of coverings, but it is not locally compact. Fortunately, it is not 
 separated.
 
 % fill-column is 78
 \end{document}
 -
 
 With a fresh emacs running AUCTeX 11.88.3 with no configurations, the
 paragraph above is filled to
 
 --8---cut here---start-8---
 Without the separation axiom this does not work, for example let $V$ be an
 infinite dimensional Banach space and let $X = V\cup\{*\}$, and let's declare
 open the standard open $U\subset V$ as well as $X$ itself. This defines a
 topology. The space is globally compact in the sense of coverings, but it is
 not locally compact. Fortunately, it is not separated.
 --8---cut here---end---8---
 
 here when fill-column is 78.  That looks correct to me.  So maybe
 something in your configs causes the bad filling.
 
 Bye,
 Tassilo

Hi Tassilo, 

thanks for having looked into this.

I have identified the bad config (sorry for not having done it earlier).

Turns out I have 

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 ; ...
 '(LaTeX-verbatim-macros-with-delims nil)
 ;...
)

in my custom file

If I comment the LaTeX-verbatim-macros-with-delims setting, the problem
disappears.

(I obtained that via a dichotomy search on both my custom and init files, 
that was full of suspense and the final result is a surprise)

As it stands the effect is:

LaTeX-verbatim-macros-with-delims is a variable defined in `latex.el'.
Its value is nil
Original value was (verb verb*)

As I don't master elisp I must have done an error, and assigning nil
value to this variable is not the correct way to remove verb and verb*
from it.

The rationale for me is that sometimes I redefine the \verb macro to
allow line breaks in the source and also in the dvi/pdf output, thus I don't
care about fill-paragraph not breaking \verb|...| things.

Here is a more complete excerpt with possibly relevant lines:

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(Info-additional-directory-list (quote (/sw/share/info)))
 '(LaTeX-indent-environment-list
   (quote
((verbatim current-indentation)
 (verbatim* current-indentation)
 (everbatim current-indentation)
 (everbatim* current-indentation)
 (array)
 (displaymath)
 (eqnarray)
 (eqnarray*)
 (equation)
 (equation*)
 (picture)
 (tabbing)
 (table)
 (table*)
 (tabular)
 (tabular*
 '(LaTeX-verbatim-environments (quote (verbatim verbatim* everbatim 
everbatim*)))
;;BAD
  '(LaTeX-verbatim-macros-with-delims nil)
;;ENDBAD
 '(TeX-auto-save nil)
 '(TeX-close-quote »)
 '(TeX-command etex)
 ;
 ; many more lines
)

For my current context, commenting out the bad line is enough of a fix
but I would like to understand better why the bad line is bad.

Sorry again for not having looked for a bad config before posting the
bug report (I should have posted the bug report to myself only first)

best
Jean-François




___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#20296: 11.88.3; LaTeX-fill-paragraph gives unexpected result

[jfbu]

Hi Tassilo,

 I have identified the bad config (sorry for not having done it
 earlier).
 
 Turns out I have 
 
 (custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 ; ...
 '(LaTeX-verbatim-macros-with-delims nil)
 ;...
 )
 
 For my current context, commenting out the bad line is enough of a fix
 but I would like to understand better why the bad line is bad.
 
 I can reproduce that here but I have no clue why that line breaks
 indentation.  But at least the problem isn't there in the development
 version.  I'll try to make a new ELPA release ASAP.  Please report back
 if that fixes things.

good news that it is already fixed in the development version !

thus my custom setup for LaTeX-verbatim-macros-with-delims shouldn't
have theoretically by itself caused the trouble ?

I will of course report back when next ELPA release becomes available

These days, I am sometimes off the net for some more or less extended
periods, thus in case feedback is not immediate, it will be because
I am in the off phase,

thanks

Jean-François





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#20296: 11.88.3; LaTeX-fill-paragraph gives unexpected result

[jfbu]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.

Be sure to consult the FAQ section in the manual before submitting
a bug report.  In addition check if the bug is reproducable with an
up-to-date version of AUCTeX.  So please upgrade to the version
available from http://www.gnu.org/software/auctex/ if your
installation is older than the one available from the web site.

If the bug is triggered by a specific (La)TeX file, you should try
to produce a minimal sample file showing the problem and include it
in your report.

Your report will be posted for the auctex package at the GNU bug
tracker.  Visit http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=auctex
to browse existing AUCTeX bugs.


Emacs  : GNU Emacs 24.4.91.1 (x86_64-apple-darwin13.4.0, Carbon Version 157 
AppKit 1265.21)
 of 2015-03-15 on Atago.local
Package: 11.88.3

I do not understand the behavior of LaTeX-fill-paragraph. It keeps annoying
me with partially filled paragraphs.

I always work with hard-wrapped paragraphs and hit M-q very often to rewrap
when I modify things.

But something seems weird with LaTeX-fill-paragraph perhaps related to $..$
material it finds.

Sample .tex file illustrating the problem:

-
\documentclass{article}

\begin{document}
% Sample paragraph

Without the separation axiom this does not work, for example let $V$ be an
infinite dimensional Banach space and let $X = V\cup\{*\}$, and let's declare 
open the standard open $U\subset V$ as well as $X$ itself. This defines a 
topology. The space is globally compact in the sense of coverings, but it 
is not locally compact. Fortunately, it is not separated.

% Applying M-q (LaTeX-fill-paragraph) to the paragraph above we get:

Without the separation axiom this does not work, for example let $V$ be an
infinite dimensional Banach space and let $X =
V\cup\{*\}$, and let's declare open the standard open $U\subset V$ as well as 
$X$ itself. This defines a topology. The space is globally compact in the sense 
of coverings, but it is not locally compact. Fortunately, it is not separated.

% fill-column is 78
\end{document}
-

regards,
Jean-François


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

[Bug-AUCTeX] bug#19155: viewer for dvi output on mac os x

[jfbu]

Hi,

currently TeX-view-program-selection, when it detects
a mac os x system,
associates output-dvi to viewer open which in turn
in TeX-view-program-list-builtin
is mapped to do open %o

However the effect of this ultimate system call
(as one can also see doing  open file.dvi
directly in a Terminal or via ! in a dired buffer)
is first to convert the dvi to pdf format and then
open it in a pdf viewer. (tested on mac os x mavericks)

(Note: people with TeXShop installed or similar will
perhaps have another experience of how the system reacts
to open file.dvi, but of course, I address
here the issue of using emacs+auctex, not TeXShop)

This pretty much defeats the whole purpose of having
chosen dvi as output format!

Perhaps I missed something obvious, but anyway, some
years back I had to deal with this issue, and I describe
here how I went about it:

I defined a xdvi entry in TeX-view-program-list,
which is the same as the one I found destined
to Linux systems in TeX-view-program-list-builtin,
with the sole difference of having replaced

%(o?)xdvi

with

open -a XQuartz  %(o?)xdvi

I then customized TeX-view-program-selection
to let it map output-dvi not to open but to this xdvi viewer.

I don't know how people go about it, but I
am curious why I had to do these things,
and why this is not the default in AUCTeX, on mac os x.

(I hope only naivety and not arrogance will be seen
in my belief that my private customizations should
be made world-wide default ;-) the point of my message
is to ask if someone has a better way to go about this)

Best wishes,

Jean-Francois







___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

Re: [Bug-AUCTeX] problems with preview, how it behaves on my system

[jfbu]

dear all,

I just wanted to say that auctex/preview is awesome, and 
this is why I am happy to report that after copying all
the relevant auctex files from the site-lisp of the Emacs 23.1
at my office (Fedora 13 machine), which have the time
stamp 
$Id: preview.el,v 1.285 2010/10/14 19:30:38 angeli Exp $
in preview.el (I don't know if some later patch was applied)

I now have *none* of the problems I reported below: I just
re-byte-compiled everything with my Emacs 24.2 on mac os x,
(adjusting some paths in auctex.el and preview-latex.el due to a
different repertory structure)

and now preview
generation works beautifully, in dvi mode, in pdf mode, 
for the «document», for the «buffer», for single or multi
file projects... perfect!

and direct and reverse search either with xdvi or Skim (for pdf)
work also perfectly (they already did with the newer auctex/preview)

The more modern auctex I thus (reluctantly) replaced with this
ancestor stolen from the machines at my office had the following
time stamp in its auctex/preview.el file
$Id: preview.el,v 1.286 2011/01/23 18:53:55 angeli Exp $

This is only the tag for the preview.el file, I don't know where
to find other time stamps

as an aside, I got rid of very frustrating error occurred after 
last tex file closed to get back to some more instructive error
messages; like with this test file copied from
http://lists.gnu.org/archive/html/auctex/2012-03/msg3.html

\documentclass{article}
\begin{document}
\emph{
\end{document}

I now get

ERROR: File ended while scanning use of \emph .

--- TeX said ---
! File ended while scanning use of \emph .
--- HELP ---
No help available

and this is much better!

please excuse my intrusion on this list where I can
not help the programmers but only give an account of 
my experience. I have been using AUCTeX/preview for
years and I love it.

Sincerely,

Jean-Francois



jfbu j...@free.fr wrote :

 I have noticed that a number of people have
 reported problems here over the last year or so
 with getting preview to work. For many years
 I did not upgrade my system and it worked fine
 (I used exclusively dvi output)
 
 Here is my current experience after moving to
 Mac OS X 10.8.1, with
 Emacs 24.2 (Mac Port),  TL 2012 installed,
 and the latest version of auctex 11.86 I could fine. 
 (which includes a patch related to the way gs is
 called). I am using the
 normal latex engine for dvi and pdflatex for pdf.
 
 (dvi output): works fine if previews are generated
 for buffer, also when the file is part of 
 a multi-file project. Does not work when
 previews are generated for document: in that
 case a multipage dvi file is created will all
 images, one per page, but next step in processing fails.
 
 (pdf output): fails as above with for document, a
 pdf file is created with one page per image, but next
 step seems to fail. Works for buffer but only
 for a single file document. If from a project with
 a master-file it fails, also when asking previews 
 for buffer, contrarily to the dvi output case.
 
 I did not try previews for region, or at point.
 
 Everything else in AUCTeX works fine as far as I can tell, 
 including direct/reverse search with xdvi under XQuartz and Skim.app 
 for pdf. I applied one or two advices found on the net,
 including one on AUCTeX's way of
 determining if source-specials or synctex should be used,
 because I use sometimes dvi with xdvi, sometimes pdf with Skim.
 (or pdf with Okular 0.10.5 on Fedora 13 distribution at my office) 
 
 Just in passing I mention that to get xdvi (from TL2012/Mac Intel 64bits) 
 to work when launched from Emacs.app 
 I had to add a -unique option to the way it is called when 
 the source-specials are *not* activated. 
 
 Of course I will post logs of (more or less) minimal examples
 if asked.
 
 Sincerely,
 
 JF B.
 
 
 
 
 
 
 ___
 bug-auctex mailing list
 bug-auctex@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-auctex


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

[Bug-AUCTeX] missing (require 'cl) ?

[jfbu]

Hi,

isn't the latest auctex release missing somewhere a (require 'cl)?

I have installed auctex-20120917-a (downloaded from 
http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/auctex/snapshots/ftp/auctex-current.tar.gz)
 this seems to be the latest version of the package.

At some point (I am in the mix of moving to a new laptop and system) nothing 
worked anymore: I got error messages Symbol's function definition is void: 
mapcar*, 

The problem seems to have been mentioned already in another mailing list 
http://lists.gnu.org/archive/html/help-gnu-emacs/2011-12/msg00107.html

and indeed (require 'cl) in my .emacs solves the problem

I realized later that in my .emacs I had moved at some point (require 
'mic-paren) (which as far as I understand does load the cl library) from a 
position before to one after the loading of auctex, 


Sincerely,
JF B.





___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

[Bug-AUCTeX] View hardcoded in tex.el

[jfbu]

Hi,

from tex-buf.el: (previously in tex.el)

(defun TeX-view ()
  Start a viewer without confirmation.
The viewer is started either on region or master file,
depending on the last command issued.
  (interactive)
  (let ((output-file (TeX-active-master (TeX-output-extension
(if (file-exists-p output-file)
(TeX-command View 'TeX-active-master 0)
  (message Output file %S does not exist. output-file

So this hardcodes View

On the other hand there is a variable TeX-command-Show in tex.el which can be 
customized and whose default value is View

I once customized the TeX-command-list and renamed View to something french, 
and I thought that I just add to also customize TeX-command-Show to reflect the 
change. 

It is not until much later that I noticed some things were broken (I think for 
example the toolbar View button; and the C-cC-v). This was two or three years 
ago, and in fact I had just gotten used to not use what was broken. Recently 
(after years of not upgrading) however I am switching to a brand new laptop and 
system, and need to re-install Emacs/AUCTeX, and review all my .emacs. This led 
me to realize that the function TeX-view, which is bound to C-cC-v and to the 
toolbar button, has this hardcoded View. Is this a bug?

Sincerely,

JF B.
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

Re: [Bug-AUCTeX] missing (require 'cl) ?

[jfbu]

 jfbu j...@free.fr writes:
 
 Hi,
 
 isn't the latest auctex release missing somewhere a (require 'cl)?
 
 I have installed auctex-20120917-a (downloaded from
 http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/auctex/snapshots/ftp/auctex-current.tar.gz)
 this seems to be the latest version of the package.
 
 At some point (I am in the mix of moving to a new laptop and system)
 nothing worked anymore: I got error messages Symbol's function
 definition is void: mapcar*,
 
 The problem seems to have been mentioned already in another mailing
 list
 http://lists.gnu.org/archive/html/help-gnu-emacs/2011-12/msg00107.html
 
 and indeed (require 'cl) in my .emacs solves the problem
 
 I realized later that in my .emacs I had moved at some point (require
 mic-paren) (which as far as I understand does load the cl library)
 from a position before to one after the loading of auctex,
 
 In general the policy for Emacs packages considered close to the core is
 to _not_ require cl at run time (in contrast, using cl-macs at compile
 time is more or less developer choice), so it would seem that the proper
 remedy would involve not using mapcar* here.
 
 -- 
 David Kastrup

Thanks David, and thanks for AUCTeX! 

I look at the code in mic-paren.el and it starts with

(eval-when-compile (require 'cl))

This seems to comply with the official policy advised at 
http://www.gnu.org/software/emacs/manual/html_mono/cl.html#Overview

in case avoiding the use of mapcar* proves troublesome, couldn't auctex require 
cl in the same manner mic-paren does? 

(and I have now learned what cl means...)

JF B.


___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

[Bug-AUCTeX] Re : problems with preview, how it behaves on my system

[jfbu]

forgot to say preview-image-type is set to dvipng

- jfbu j...@free.fr wrote :
 I have noticed that a number of people have
 reported problems here over the last year or so
 with getting preview to work. For many years
 I did not upgrade my system and it worked fine
 (I used exclusively dvi output)
 
 Here is my current experience after moving to
 Mac OS X 10.8.1, with
 Emacs 24.2 (Mac Port),  TL 2012 installed,
 and the latest version of auctex 11.86 I could fine. 
 (which includes a patch related to the way gs is
 called). I am using the
 normal latex engine for dvi and pdflatex for pdf.
 
 (dvi output): works fine if previews are generated
 for buffer, also when the file is part of 
 a multi-file project. Does not work when
 previews are generated for document: in that
 case a multipage dvi file is created will all
 images, one per page, but next step in processing fails.
 
 (pdf output): fails as above with for document, a
 pdf file is created with one page per image, but next
 step seems to fail. Works for buffer but only
 for a single file document. If from a project with
 a master-file it fails, also when asking previews 
 for buffer, contrarily to the dvi output case.
 
 I did not try previews for region, or at point.
 
 Everything else in AUCTeX works fine as far as I can tell, 
 including direct/reverse search with xdvi under XQuartz and Skim.app 
 for pdf. I applied one or two advices found on the net,
 including one on AUCTeX's way of
 determining if source-specials or synctex should be used,
 because I use sometimes dvi with xdvi, sometimes pdf with Skim.
 (or pdf with Okular 0.10.5 on Fedora 13 distribution at my office) 
 
 Just in passing I mention that to get xdvi (from TL2012/Mac Intel 64bits) 
 to work when launched from Emacs.app 
 I had to add a -unique option to the way it is called when 
 the source-specials are *not* activated. 
 
 Of course I will post logs of (more or less) minimal examples
 if asked.
 
 Sincerely,
 
 JF B.
 



___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex