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

[Mosè Giordano]

2015-11-04 23:50 GMT+01:00 jfbu :
>> 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

fontspec requires two engines, we can't select one of the two for the
user.  The point is that compilation will certainly fail if one loads
particular packages, provided that there aren't conditionals.  A
prompt suggesting you the action to take is better than waiting for
the compilation to finish and then try to realize what went wrong.

> 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.

Indeed the problem is the other way round: you can't use fontspec
without {Xe,Lua}TeX.

> 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 ?

We already have a file-local variable to specify the engine to use,
`TeX-engine', the check is only for those who forget to set it
properly.

Cheers,
Mosè



___
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

[Mosè Giordano]

close 21832
tags 21832 notabug
thanks


2015-11-04 23:30 GMT+01:00 jfbu :
> 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 :-)

> 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.

I'm closing this ticket.

Bye,
Mosè



___
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

[Mosè Giordano]

Hi Jean-François,

2015-11-04 22:47 GMT+01:00 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)

Or just set `TeX-check-engine' to nil ;-)

I don't think can really deal with TeX conditionals, bud I'd like to
be proven wrong.

If the problem is the prompt you can change the value of
`TeX-check-engine' and this ticket will be closed, if this is a
request to implement parsing of conditionals we can keep this open,
even if for me would be "wontfix" or "patches welcome".

Bye,
Mosè



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

bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine

[Mosè Giordano]

Hi Uwe,

2015-11-04 16:17 GMT+01:00 Uwe Brauer :
>
> Hello
>
> The following problem only occurs in GNU emacs 24.5 or 25.0.50.
>
> I have two files:
>
> The first is saved in latin-1 but its header state
> \usepackage[utf8]{inputenc}
>
> And the other is the other way around
> saved in UTF8 header is
>
> \usepackage[latin1]{inputenc}
>
>
> Both are displayed correctly in Xemacs and but not in GNU emacs.

GNU Emacs has "latexenc" package which opens a file with the encoding
specified by the inputenc package and I think this feature is
valuable, since the actual file encoding should match the inputenc
encoding anyway.  Then, I believe this is the classic case of "this
isn't a bug but a feature".

Cheers,
Mosè



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

bug#21814: 11.88.9; Completion of documentclass partially broken

[Mosè Giordano]

Hi Fran,

2015-11-02 16:08 GMT+01:00 Fran Burstall :
> Greetings,
>
> I have TeX-arg-input-file-search set to nil since the search
> for documentclasses to populate LaTeX-global-class-files
> takes too long.

This kind of file search has been somewhat improved around a month
ago, did you try it lately?  Now AUCTeX avoids searching in duplicates
directories, the improvement is of a factor of ~2, nothing
exceptional, but stil better than before.

> I would have expected that when I do C-c C-e to insert a
> documentclass, I would still be able to do a completing read
> populated by LaTeX-style-list.  In fact, no completion is
> offered at all.
>
> The problem is in the function TeX-arg-document which never
> sets LaTeX-global-class-files  if TeX-arg-input-file-search
> is nil.

You're right, thanks for having spot this!  I've fixed it.

Bye,
Mosè



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

bug#19504: 11.88; [siunitx] unit appears without backslash

[Mosè Giordano]

Hi all,

this bug should be fixed now.

Bye,
Mosè


2015-04-14 23:16 GMT+02:00 Mosè Giordano :
> Hello,
>
> here is my take to fix the bug: there are three different versions of
> `TeX-completing-read-multiple' as suggested by Tassilo.  I'm just not
> sure it works with all 24.* versions of Emacs.  A serious problem is
> that there are a couple of internal functions (crm--*), and we had
> problems  in the past with internal functions,[1] for which we still
> get bug reports nowadays.
>
> Actually, the change by Roland Winkler which caused this bug is the
> same which forced us to make `TeX-completing-read-multiple' always
> return nil,[2] so perhaps we could also revert that change, but in
> this way we would break backward compatibility in turn.
>
> Bye,
> Mosè
>
> Note:
>
> [1]  http://comments.gmane.org/gmane.emacs.aquamacs.devel/240
> [2]  http://comments.gmane.org/gmane.emacs.auctex.devel/3375
>
> 2015-03-12 23:05 GMT+01:00 Mosè Giordano :
>> Hi Tassilo,
>>
>> 2015-03-12 9:51 GMT+01:00 Tassilo Horn :
>>> Mosè Giordano  writes:
>>>
>>>>> PS: The plan is actually to move the minibuffer completion in that
>>>>> direction for normal minibuffer completion, so that TAB is bound to
>>>>> completion-at-point in the minibuffer as well.
>>>>
>>>> Uh, thanks for the suggestion, but according to git blame
>>>> `completion-at-point' exists since 2009, so Emacs <23 is left out.
>>>
>>> Sorry, I didn't follow this issue closely.  But isn't it the case that
>>> some quite recent change in Emacs is the culprit?
>>
>> Yes, with this commit
>> http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commitdiff;h=9c44569ea2a18099307e0571d523d8637000a153
>> `completing-read-multiple' ignores empty strings, which was essential
>> for completion of `siunitx' units.
>>
>>> In that case,
>>> `TeX-completing-read-multiple' could have 3 versions instead of the
>>> current two (one for Emacs, one for XEmacs), i.e., one for Emacs <= 22,
>>> one for Emacs 23+, and one for XEmacs.
>>
>> As I said some messages ago, the best I can think is to copy the last
>> Emacs implementation before the mentioned commit (making sure return
>> value for empty input is always nil) for all Emacs versions, so we
>> should be able to keep the number of versions of
>> `TeX-completing-read-multiple' as low as two.  The problem will be of
>> course some more work on our side to maintain the function, if needed.
>>
>> Bye,
>> Mosè



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

bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatexx

[Mosè Giordano]

2015-10-08 9:39 GMT+02:00 Tassilo Horn :
> Mosè Giordano  writes:
>
>>> Another approach with the same limitations would be that we add a
>>> variable `TeX-expand-list-builtin' with all the current default
>>> expansions and leave `TeX-expand-list' to the user.
>>>
>>> I think we should probably do the latter because we use that approach
>>> for several other variables already.
>>
>> Are you going to implement this?  If you can't, I think I can do that
>> as well.
>
> My spare time is currently quite limited, so feel free to implement it
> yourself.

Done, I'm closing this ticket.

Cheers,
Mosè



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

bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatexx

[Mosè Giordano]

Hi Tassilo,

2015-09-22 8:37 GMT+02:00 Tassilo Horn :
> Another approach with the same limitations would be that we add a
> variable `TeX-expand-list-builtin' with all the current default
> expansions and leave `TeX-expand-list' to the user.
>
> I think we should probably do the latter because we use that approach
> for several other variables already.

Are you going to implement this?  If you can't, I think I can do that as well.

Bye,
Mosè



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

bug#21642: 11.87; synctex

[Mosè Giordano]

close 21642
tags 21642 notabug
thanks


Hi Livio,

2015-10-07 21:06 GMT+02:00 Livio Flaminio :
> On 10/07/2015 08:36 PM, Mosè Giordano wrote:
>>
>> I can't reproduce even with Evince, using git version of AUCTeX.  By
>> the way, I just noticed you're running an old version of AUCTeX, could
>> you try to update it?  It's fairly simple if you use ELPA.
>
> Fixed with the ELPA version of auctex.
> Thanks

Thank you for the confirmation, I'm closing this ticket.

Bye,
Mosè



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

bug#21642: 11.87; synctex

[Mosè Giordano]

Hi Livio,

2015-10-07 20:06 GMT+02:00 Livio Flaminio :
> On 10/07/2015 07:00 PM, Mosè Giordano wrote:
>>
>> Which viewer are you using?  I can't reproduce with Okular.
>
> Hi Mosè,
> I am on Linux Mint (rebecca) and I use evince as a viewer
> My path was
>
> TD/TD_années_prec/combined.tex
>
> It worked after I changed it to
>
> TD/TD_annees_prec/combined.tex
>
> With the path in utf8, I get a pop out message
> saying that the file is now in read-only mode (and in fact
> a new BLANK buffer with the same filename is opened)
>
> The message buffer shows
>
> LaTeX: successfully formatted {29} pages
> Use M-x make-directory RET RET to create the directory and its parents
> Applying style hooks... done
> TeX-evince-sync-view: Couldn't find the Evince instance for
> file:///home/livio/syn/Essential/Teaching/2013-2014/M32/TD/TD_années_prec/combined.pdf
> user-error: Minibuffer window is not active
> Sorting environment...
> Removing duplicates... done

I can't reproduce even with Evince, using git version of AUCTeX.  By
the way, I just noticed you're running an old version of AUCTeX, could
you try to update it?  It's fairly simple if you use ELPA.

Bye,
Mosè



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

bug#21642: 11.87; synctex

[Mosè Giordano]

Hi Livio,

2015-10-07 18:28 GMT+02:00 Livio Flaminio :
> Reverse search fails if the file path contains non-ascii characters.

Which viewer are you using?  I can't reproduce with Okular.

Bye,
Mosè



___
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

[Mosè Giordano]

2015-10-01 14:28 GMT+02:00 jfbu :
> However you may keep this in mind if one day before the 22th
> century LaTeX3 starts being widely used, perhaps that will
> mean then a need for a complete rewrite of the format error
> messages.

I know some members of the LaTeX3 team are Emacs users, probably
AUCTeX too, you may suggest them to provide us with updated help
messages before the 22th century ;-)

Bye,
Mosè



___
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

[Mosè Giordano]

Hi Jean-François,

2015-10-01 7:24 GMT+02:00 jfbu :
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.
>
> The following TeX source file
>
> \def\foo{\begingroup\foo}\foo
>
> \bye
>
> when run from a TeX-mode Emacs/AUCTeX buffer generates on C-c `,
> after compilation has halted on a TeX capacity exceeded error,
> a buffer displaying a long text of which I reproduce only the start
> here:
>
> ERROR: TeX capacity exceeded, sorry [grouping levels=255].
>
> --- TeX said ---
> \foo ->\begingroup
>\foo
> l.1 \def\foo{\begingroup\foo}\foo
>  --- HELP ---
> TeX has just run out of space and aborted its execution. Before you
> panic, remember that the least likely cause of this error is TeX not
> having the capacity to process your document.  It was probably an
> error in your input file that caused TeX to run out of room. The
> following discussion explains how to decide whether you've really
> exceeded TeX's capacity and, if so, what to do. If the problem is an
> error in the input, you may have to use the divide and conquer method
> described previously to locate it. LaTeX seldom runs out of space on a
> short input file, so if running it on the last few pages before the
> error indicator's position still produces the error, then there's
> almost certainly something wrong in the input file.
>
> The end of the error indicator tells what kind of space TeX ran out
> of. The more common ones are listed below, with an explanation of
> their probable causes.
>
> buffer size
> ===
> Can be caused by too long a piece of text as the argument
>
> [continued]
>
> The rest of the text has many many references to LaTeX.
>
> As the context here is Plain TeX this longish info is mostly
> irrelevant (it provides useful information to average LaTeX
> users, but nothing spicy to well trained macro programmers ;-) )
>
> For some years I thought that the message originated in the
> help system of the tex binary itself (my Emacs is configured
> actually to run etex not tex if that matters), but it appears
> that I could very well
> have erred completely. I of course realized Knuth would not
> have included such a message, but perhaps the binaries of
> my TeXLive installation did provide an extended help system.
>
> 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 ?

Yes, AUCTeX has help messages builtin in `TeX-error-description-list'
variable, seemingly provided by someone called Leslie Lamport [1],
maybe you've heard about him.   These messages are sometimes more
verbose and useful than help messages present in log file.  If AUCTeX
can't find help messages in its database, falls back on log file.
Probably all those reference to LaTeX come from Lamport.

Being `TeX-error-description-list' a variable I'm not sure to have it
would be easy to have different values for different modes (plain
TeX/LaTeX/you name it).

Bye,
Mosè


Reference:
[1] 
http://git.savannah.gnu.org/gitweb/?p=auctex.git;a=blob;f=doc/history.texi;hb=HEAD



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

bug#21532: 11.88.8; Change environment feature don't works fine.

[Mosè Giordano]

2015-09-22 13:57 GMT+02:00 Tassilo Horn :
> Orlando Iovino  writes:
>
>>> else. If the mouse cursor is on \end{document} and I digit 'C-u C-c
>>> C-e', AUCTeX will change the minipage environment.
>> Sorry: I meant \end{minipage}.
>
> I don't see what should be wrong with that behavior.  It changes the
> nearest environment containing point, so if you want to change the
> itemize, point has to be somewhere in that.

I agree that it's safer to stay *inside* an environment to change it,
but there is a mismatch between what (LaTeX-current-environment)
returns when point is on environment name in "\end{environment}" and
which environment is actually changed.

Bye,
Mosè



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

bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatexx

[Mosè Giordano]

Hi Tassilo,

2015-09-22 8:37 GMT+02:00 Tassilo Horn :
> Uwe Brauer  writes:
>
>>> This entry is there by default, you must have set
>>> `TeX-expand-list' somewhere.
>>
>> I think what happens is this: I have TeX-expand-list customized and
>> emacs copies all its values into, in my case, custom-init.el and saves
>> the changes I did. So if a new variable is added to that list it seems
>> that the list in custom-init.el «blocks» the new feature. At least for
>> Xemacs why this does not happen in GNU I do not know.
>
> I think it's the same there.  The customization facility sets variables,
> thus it is simply not really good for variables whose default value is a
> non-empty list.  I think we could use a :set property function to handle
> these situation where the function wouldn't actually set the value but
> just add to it, e.g., using `push' or `pushnew'.  But then the problem
> would be that the user wouldn't have a chance to remove entries from
> such variables.  Well, in the case of `TeX-expand-list' he could add
> do-nothing entries to override the default ones, I guess.

Yes, in general I agree that someone may want to remove an entry from
a list, but in this particular case I don't see why one should want to
do that, this would cause only problems.  Overriding a default
expander is fine instead.

> Another approach with the same limitations would be that we add a
> variable `TeX-expand-list-builtin' with all the current default
> expansions and leave `TeX-expand-list' to the user.
>
> I think we should probably do the latter because we use that approach
> for several other variables already.

Agreed.

Bye,
Mosè



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

bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatex

[Mosè Giordano]

2015-09-21 15:02 GMT+02:00 Uwe Brauer :
>
>
>
>
>> On 21 Sep 2015, at 13:45, Mosè Giordano  wrote:
>>
>> Hi Uwe,
>>
>> 2015-09-21 12:49 GMT+02:00 Uwe Brauer :
>>>
>>> Hi
>>>
>>>
>>> I finally, thanks to Mose can compile the latest git as a xemacs pkg, I
>>> installed it but when trying to run latex I obtain the following error
>>> message which I attach:
>>>
>>> Uwe Brauer
>>>
>>>
>>> Running `LaTeX' on `new' with ``latex %(file-line-error)  -src-specials 
>>> -interaction=nonstopmode "\input" new.tex''
>>> /bin/sh: Syntax error: "(" unexpected
>>
>> I can't reproduce this error with XEmacs 21.4.22.  It seems
>> "%(file-line-error)" didn't get expanded for you, but for me it does
>> work:
>>
>>Running `LaTeX' on `foo' with ``pdflatex -file-line-error --synctex=1
>>-interaction=nonstopmode "\input" foo.tex''
>>
>> Do you have "%(file-line-error)" in `TeX-expand-list'?
>>
>
> No i don't neither in gnu emacs nor in xemacs.

This entry is there by default, you must have set `TeX-expand-list' somewhere.

> However auctex git works with gnu emacs but not with xemacs both with 
> settings which worked in 11.88

file-line-error has been introduced three days after release of AUCTeX
11.88, that's why you don't have problems with that package.  Maybe in
GNU Emacs you also customized `LaTeX-command-style' removing
"%(file-line-error)".

Bye,
Mosè



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

bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatex

[Mosè Giordano]

Hi Uwe,

2015-09-21 12:49 GMT+02:00 Uwe Brauer :
>
> Hi
>
>
> I finally, thanks to Mose can compile the latest git as a xemacs pkg, I
> installed it but when trying to run latex I obtain the following error
> message which I attach:
>
> Uwe Brauer
>
>
> Running `LaTeX' on `new' with ``latex %(file-line-error)  -src-specials 
> -interaction=nonstopmode "\input" new.tex''
> /bin/sh: Syntax error: "(" unexpected

I can't reproduce this error with XEmacs 21.4.22.  It seems
"%(file-line-error)" didn't get expanded for you, but for me it does
work:

Running `LaTeX' on `foo' with ``pdflatex -file-line-error --synctex=1
-interaction=nonstopmode "\input" foo.tex''

Do you have "%(file-line-error)" in `TeX-expand-list'?

Bye,
Mosè



___
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

[Mosè Giordano]

Hi Jean-François,

2015-09-19 14:15 GMT+02:00 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

Oops, sorry, I think those bugs were my fault, thanks for having
spotted them!

> 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

I wonder how many plain TeX users we have (or at least plain TeX users only,
no LaTeX, who care to report bugs): bug fixed with commit

* 1a5d447 (2013-04-17)  Fix plain TeX abbrev table name.

(http://git.savannah.gnu.org/gitweb/?p=auctex.git;a=commitdiff;h=1a5d447)
made opening plain TeX files pretty uncomfortable, still was never
reported before the fix, which came 2.5 years after the bug had been
introduced and 5 months after previous stable version.

Bye,
Mosè



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

bug#21512: filecontents

[Mosè Giordano]

Hi Jim

2015-09-18 14:23 GMT+02:00 Hefferon, James S. :
>
> Hello,
>
> Thank you for AUCTeX.  I use it every day.
>
> When I am inside a .tex file, in the preamble but after the \documentclass, 
> and I do a control-C control-E followed by "filecontents" I get a message in 
> the minibuffer to "Put filecontents before \documentclass".
>
> That warning is based on incorrect documentation of the filecontents command; 
> in fact that command can go anywhere in the preamble.

Which version of AUCTeX are you using?  This should have already been
fixed with commit

* cad437e (2013-01-29)  * latex.el (LaTeX-env-contents): Replaced
regular expression with

(http://git.savannah.gnu.org/gitweb/?p=auctex.git;a=commitdiff;h=cad437eec728058261951f28cd779c2d4f2eb3b7)
which went into AUCTeX 11.88.

Bye,
Mosè



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

bug#21483: 2015-09-05; keybinding problem: global-binding overrides local-binding?

[Mosè Giordano]

close 21483
tags 21483 notabug
thanks

I'm closing this ticket as it isn't a bug.  I've already replied to
auctex-devel mailing list
(https://lists.gnu.org/archive/html/auctex-devel/2015-09/msg00100.html),
here is my answer for reference:

I can't reproduce your problem in Emacs 24.5 (and I don't think this
bug, if exists, has anything to do with AUCTeX).

If I know map name, I usually set local keys with

--8<---cut here---start->8---
(eval-after-load "latex"
  '(progn
 (define-key LaTeX-mode-map [(control right)] 'my-turn-bidi-on)
 (define-key LaTeX-mode-map [(control left)] 'my-turn-bidi-off)
 (define-key LaTeX-mode-map [(f31)]   'TeX-fold-buffer)
 (define-key LaTeX-mode-map [(f30)]   'TeX-fold-clearout-buffer)
 (define-key LaTeX-mode-map [(control f30)] 'preview-clearout-buffer)))
--8<---cut here---end--->8---

Bye,
Mosè


2015-09-15 12:43 GMT+02:00 Uwe Brauer :
>
> Hello
>
> This is my setting:
>
> (add-hook 'LaTeX-mode-hook 'my-latex-mode-key)
>
> (defun my-latex-mode-key ()
>   "Setting of the following keys"
>   (interactive)
>   (local-set-key [(control right)] 'my-turn-bidi-on)
>   (local-set-key [(control left)] 'my-turn-bidi-off)
>   (local-set-key [(f31)]   'TeX-fold-buffer)
>   (local-set-key [(f30)]   'TeX-fold-clearout-buffer)
>   (local-set-key [(control f30)] 'preview-clearout-buffer))
>
> However this binding is ignored, the global-key-binding is taken
> instead.
>
> I have to evaluate the function my-latex-mode-key and then switch latex
> mode off and on. Very annoying.
>
> Uwe Brauer
>
>
>
>
>
> Emacs  : GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
>  of 2015-08-28
> Package: 2015-09-05
>
> current state:
> ==
> (setq
>  AUCTeX-date "2015-09-05"
>  window-system 'x
>  LaTeX-version "2e"
>  TeX-style-path '("/home/oub/ALLES/var/auctex" 
> "/home/oub/emacs/site-lisp/packages/auctex-git/auctex/style"
>   "/home/oub/.emacs.d/auctex/auto" "/home/oub/tex/sty/auto" 
> "auto" "style")
>  TeX-auto-save t
>  TeX-parse-self t
>  TeX-master t
>  TeX-command-list '(("TeX" "%(PDF)%(tex) %(file-line-error) %(extraopts) 
> %`%S%(PDFout)%(mode)%' %t"
>  TeX-run-TeX nil (plain-tex-mode ams-tex-mode 
> texinfo-mode) :help "Run plain TeX")
> ("LaTeX" "%`%l%(mode)%' %t" TeX-run-TeX nil (latex-mode 
> doctex-mode) :help "Run LaTeX")
> ("Makeinfo" "makeinfo %(extraopts) %t" TeX-run-compile 
> nil (texinfo-mode) :help
>  "Run Makeinfo with Info output")
> ("Makeinfo HTML" "makeinfo %(extraopts) --html %t" 
> TeX-run-compile nil (texinfo-mode)
>  :help "Run Makeinfo with HTML output")
> ("AmSTeX" "amstex %(PDFout) %(extraopts) %`%S%(mode)%' 
> %t" TeX-run-TeX nil (ams-tex-mode)
>  :help "Run AMSTeX")
> ("ConTeXt" "texexec --once --texutil %(extraopts) 
> %(execopts)%t" TeX-run-TeX nil
>  (context-mode) :help "Run ConTeXt once")
> ("ConTeXt Full" "texexec %(extraopts) %(execopts)%t" 
> TeX-run-TeX nil (context-mode) :help
>  "Run ConTeXt until completion")
> ("BibTeX" "bibtex %s" TeX-run-BibTeX nil t :help "Run 
> BibTeX")
> ("Biber" "biber %s" TeX-run-Biber nil t :help "Run Biber")
> ("View" "%V" TeX-run-discard-or-function t t :help "Run 
> Viewer")
> ("Print" "%p" TeX-run-command t t :help "Print the file")
> ("Queue" "%q" TeX-run-background nil t :help "View the 
> printer queue" :visible
>  TeX-queue-command)
> ("File" "%(o?)dvips %d -o %f " TeX-run-dvips t t :help 
> "Generate PostScript file")
> ("Dvips" "%(o?)dvips %d -o %f " TeX-run-dvips nil t :help 
> "Convert DVI file to PostScript")
> ("Ps2pdf" "ps2pdf %f" TeX-run-ps2pdf nil t :help "Convert 
> PostScript file to PDF")
> ("Index" "makeindex %s" TeX-run-command nil t :help 
> "Create index file")
> ("Xindy" "texindy %s" TeX-run-command nil t :help "Run 
> xindy to create index file")
> ("Check" "lacheck %s" TeX-run-compile nil (latex-mode) 
> :help
>  "Check LaTeX file for correctness")
> ("ChkTeX" "chktex -v6 %s" TeX-run-compile nil 
> (latex-mode) :help
>  "Check LaTeX file for common mistakes")
> ("Spell" "(TeX-ispell-document \"\")" TeX-run-function 
> nil t :help
>  "Spell-check the document")
> ("Clean" "TeX-clean" TeX-run-function nil t :help "Delete 
> generated intermediate files")
> ("Clean All" "(TeX-clean t)" TeX-run-function nil t :help
>  "Delete generated intermediate and o

bug#21434: Re: bug#21434: BUG Report: "mark-sexp" function disable.

[Mosè Giordano]

2015-09-11 3:26 GMT+02:00 赵瑞昌 :
> Thank you Mosè, for your reply.
>
> I have a try `emacs -q'. The problem still exist.
> `mark-sexp' is expected to mark the whole range of env., but only the 
> ``\begin'' was marked.

You're telling that `mark-sexp' is expected to mark the environment,
but this isn't true: `mark-sexp' is expect to mark "parentheses".  If
you want to mark an environment use `C-c .', bound to
`LaTeX-mark-environment'.

Bye,
Mosè



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

bug#21434: BUG Report: "mark-sexp" function disable.

[Mosè Giordano]

Hi!

2015-09-08 7:23 GMT+02:00 赵瑞昌 :
> Dear Developer,
>
> When enter a `*.tex' file and initiate auctex(11.86), the function 
> `mark-sexp'(and also `forward/backward-sexp) is disabled.
> The correspond key-bindings (C-M-@ or ESC ) also get no 
> responses (which are well previously).

I can't reproduce your bug, at least not with AUCTeX 11.88, C-M-@ and
C-M-left/right do work for me.  Are you sure there is nothing in your
init file disabling this feature?  Try opening Emacs with

emacs -q

in order not to load your init file.

Bye,
Mosè



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

bug#21183: 11.88; Wrap line break references to labels

[Mosè Giordano]

Hi Christop,

2015-08-31 11:39 GMT+02:00 Ortner, Christoph :
> sorry for the late response. Yes, thank you, this clarifies everything!

Thanks for reporting back, I'm closing this ticket.

Bye,
Mosè



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

bug#21259: Regex of (this)pagestyle in TeX-complete-list

[Mosè Giordano]

Hi Arash,

2015-08-14 21:32 GMT+02:00 Arash Esbati :
> Hi all,
>
> if I start emacs with `emacs --eval '(setq debug-on-error t)' &' type
> the following a tex file:
>
> \thispagestyle{`C-M-i'
>
> I get this error:
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (error "Can't find completion for 
> \"\\thispagestyle{\"")
>   signal(error ("Can't find completion for \"\\thispagestyle{\""))
>   error("Can't find completion for \"%s\"" "\\thispagestyle{")
>   TeX-complete-symbol()
>   call-interactively(TeX-complete-symbol nil nil)
>   command-execute(TeX-complete-symbol)
> --8<---cut here---end--->8---
>
> It is due to a bug in the definition of `TeX-complete-list' in
> `latex.el' (line 5913):
>
> --8<---cut here---start->8---
> (setq TeX-complete-list
>   (append '(;; snipped
> ("\\(this\\)?pagestyle{\\([A-Za-z]*\\)"
>  1 LaTeX-pagestyle-list "}"))
> TeX-complete-list))
> --8<---cut here---end--->8---
>
> The number refers to the wrong subgroup in the regex.  There are two
> ways to fix this: Make `\\(this\\)' a shy-group or replace `1' with `2'.
>
> Please find attached a patch going the second route since it looks more
> coherent to the rest of definitions in `TeX-complete-list'.

Agreed.  Patch installed, thanks!

Bye,
Mosè



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

bug#21188: Preview installed from the package manager changes LaTeX-mode-hook

[Mosè Giordano]

Hi Arash,

2015-08-10 22:37 GMT+02:00 Arash Esbati :
> Tassilo Horn  writes:
>
>> Arash Esbati  writes:
>>
>>> 2)  Eval in scratch buffer
>>> (load "auctex.el" nil t t)
>>
>> How can you do that without telling Emacs where auctex.el resides?
>
> Sorry, my bad, yanked the wrong item.  I eval'ed:
>
> (load "~/.emacs.d/lisp/auctex.el" nil t t)
>
>>> 3)  Open a tex file and emacs says:
>>>
>>> Debugger entered--Lisp error: (void-function LaTeX-preview-setup)
>>
>> `LaTeX-preview-setup' is autoloaded from preview-latex.el.  So it relies
>> on
>>
>>   (load "preview-latex.el" nil t t)
>>
>> also being in your ~/.emacs.  Although I can omit that but still don't
>> get that error...
>>
>> But I guess it wouldn't hurt to wrap the call in an fboundp check...
>
> Thanks, I updated AUCTeX and the error (not warning) is gone.  I will
> check this on my other box this weekend.  I wonder why this happened to
> me while you and Mosè do not have this issue.

I'm curious too, thanks for looking into it.  I can reproduce your
error only if I load `auctex' but don't load `preview-latex' and then
run `TeX-LaTeX-mode', but opening a LaTeX files works flawless even
without loading `preview-latex' (and before Tassilo's last commit).

Could you please remove the "Mail-Followup-To: bug-auctex@gnu.org"
cookie from your emails?  This setting would open a new bug report for
everyone replying to you ;-)

Bye,
Mosè



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

bug#21188: Preview installed from the package manager changes LaTeX-mode-hook

[Mosè Giordano]

Hi Tassilo,

2015-08-10 8:07 GMT+02:00 Tassilo Horn :
> Mosè Giordano  writes:
>
>> Tassilo, the only point of your commit I don't understand is: what
>> happens when `declare-function' is not bound?
>
> You get a warning during compilation.

I was referring to the runtime behavior, but you replied me in another
message: `LaTeX-preview-setup' is an autoloaded function, so there
shouldn't be errors.

Bye,
Mosè



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

bug#21194: 2015-06-01; add support for ffap via kpsewhich

[Mosè Giordano]

Hi Nicolas,

2015-08-09 18:49 GMT+02:00 Nicolas Richard :
> Hello Mosè
>
> Mosè Giordano  writes:
>> This is smarter than your function in the sense that it looks at
>> current macro to determine the extension (didn't test it, but I think
>> your implementation would open "article.sty" instead of the more
>> sensible "article.cls" with point on "article").
>
> Indeed, there are a few ways to confuse my code, but it doesn't bite me
> often (I never use article class anyway :p). I've fixed this nonetheless.
>
> I pushed the result to emacs master, so it should make its way to emacs
> 25.1.

Cool!  Thank you!

Bye,
Mosè



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

bug#21188: Preview installed from the package manager changes LaTeX-mode-hook

[Mosè Giordano]

Hi Arash,

2015-08-09 14:28 GMT+02:00 Arash Esbati :
> Tassilo Horn  writes:
>
> Hi Tassilo,
>
>> I've just released GNU AUCTeX 11.88.7 on ELPA, and the problem should be
>> fixed now.  Please test and report back if if works now.
>
> I've installed the latest version from git with your patch and get the
> following when I open a tex file:
>
> (void-function LaTeX-preview-setup)
>
> Recipe:
>
> 1)  Start emacs with
> emacs --eval '(setq debug-on-error t)' -Q &
>
> 2)  Eval in scratch buffer
> (load "auctex.el" nil t t)
>
> 3)  Open a tex file and emacs says:
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (void-function LaTeX-preview-setup)
>   LaTeX-preview-setup()
>   TeX-latex-mode()
>   apply(TeX-latex-mode nil)
>   latex-mode()
>   set-auto-mode-0(latex-mode nil)
>   set-auto-mode()
>   normal-mode(t)
>   after-find-file(nil t)
>   find-file-noselect-1(# "~/Latex/temp.tex" nil nil 
> "~/Latex/temp.tex" (281474976722716 2925265949))
>   find-file-noselect("~/Latex/temp.tex" nil nil t)
>   find-file("~/Latex/temp.tex" t)
>   call-interactively(find-file nil nil)
>   command-execute(find-file)
> --8<---cut here---end--->8---

I can't reproduce the error with Emacs 24.5 and git AUCTeX.  Which
version of Emacs are you running?

Tassilo, the only point of your commit I don't understand is: what
happens when `declare-function' is not bound?

Bye,
Mosè



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

bug#21194: 2015-06-01; add support for ffap via kpsewhich

[Mosè Giordano]

Hi Nicolas!

2015-08-05 19:34 GMT+02:00 Nicolas Richard :
> Hi all,
>
> I'm using the following customizations, which I thought I'd share with
> you. As the subject says it, it uses kpsewhich for guessing a filename
> at point. It allows to use M-x ffap with point on "geometry" to find
> geometry.sty, or with point on "memoir" to find memoir.cls.
>
> It is very quick because it calls kpsewhich only once.
>
> I'm not making this into an actual patch because while it works
> fine on my system, it's not ready for inclusion yet. I'm open to
> your ideas to make it better and eventually include it.
>
> ;; a first step is :
> ;; don't allow braces as possible characters in a filename (otherwise
> ;; \input{foo} is seen as a possible filename, instead of just foo)
> ;; (this is because of a recent change in emacs, see commit
> ;; ba6c32b6decaa2a72a3d5f854efd513e8e82c118 for detail)
>
> (push '(latex-mode "--:$+<>@-Z_[:alpha:]~*?" "<@" "@>;.,!:")
>   ffap-string-at-point-mode-alist)
>
> ;; second step is to extend rules for finding file at point, and use kpsewhich
>
> (defun yf/ffap-latex-mode (name)
>   "ffap function in latex buffers"
>   (if (file-exists-p name)
>   name
> (let ((curbuf (current-buffer)))
>   (with-temp-buffer
> (let ((suffixes '(".sty" ".cls" ".ltx" ".tex" "" ".ldf"))
>   (prefixes '("" "beamertheme"
>   "beamercolortheme"
>   "beamerfonttheme"
>   "beamerinnertheme"
>   "beameroutertheme"))
>   args)
>   (setq args (apply #'append (mapcar
>   (lambda (suffix)
> (mapcar
>  (lambda (prefix)
>(concat prefix name suffix))
>  prefixes))
>   suffixes)))
>   (let ((process-environment (buffer-local-value 'process-environment 
> curbuf))
> (exec-path (buffer-local-value 'exec-path curbuf)))
> (apply #'call-process "kpsewhich"  nil  t  nil args))
>   (when (< (point-min) (point-max))
> (buffer-substring (goto-char (point-min)) (point-at-eol
>
> ;; use the above
> (advice-add 'ffap-latex-mode :override 'yf/ffap-latex-mode)
>
> Comments welcome!

I like this idea, indeed in my init file I've something similar:

--8<---cut here---start->8---
(defun mg-TeX-kpsewhich-find-file (&optional name)
  "Visit file associated to NAME searching for it with kpsewhich.
If NAME is nil prompt for a file name.  If there is an active
region, use it as initial input.  When it is called with
\\[universal-argument] prefix, visit file in another window, in
the current one otherwise."
  (interactive)
  (if (executable-find "kpsewhich")
  (let* ((fun (if current-prefix-arg 'find-file-other-window 'find-file))
 (default-directory (TeX-master-directory))
 (name (or name (TeX-read-string
 "File name: "
 (if (TeX-active-mark)
 (buffer-substring-no-properties
  (region-beginning) (region-end))
 (file (replace-regexp-in-string
"[\n\r]*\\'" ""
(shell-command-to-string (concat "kpsewhich " name)
(if (and (not (zerop (length file))) (file-exists-p file))
(funcall fun file)
  (message (concat "File " name " not found."
(message "Kpsewhich not available.")))

;; From an original idea of John Wickerson and a first simple implementation of
;; David Carlisle: http://tex.stackexchange.com/q/113376
(defun mg-LaTeX-find-file-at-point ()
  "Visit LaTeX file searching for it with kpsewhich.
File basename is guessed from text around point and its extension
is guessed from current macro.  When it is called with
\\[universal-argument] prefix, visit file in another window, in
the current one otherwise.

See also `mg-TeX-kpsewhich-find-file'."
  (interactive)
  (let* ((file-name-regexp "-~/A-Za-z0-9_.$#%:+")
 ;; Get filename at point.
 (name
  ;; Check whether character at point is a valid file name
  ;; character.
  (if (string-match (concat "[" file-name-regexp "]")
(string (char-after)))
  (save-excursion
(skip-chars-backward file-name-regexp)
(looking-at (concat "\\([" file-name-regexp "]+\\)"))
(TeX-match-buffer 1
 ;; Get current macro once.
 (current-macro (TeX-current-macro))
 ;; Guess file extension based on current macro.
 (extension (cond
 ((or (equal "usepackage" current-macro)
  (equal "RequirePackage" current-macro)
  (equal "RequirePackageWithOptions" current-macro))
  ".sty")
 ((or (equal "documentclass" current-macro)
  (equal "documentstyle" current

bug#21183: 11.88; Wrap line break references to labels

[Mosè Giordano]

Hi Cristoph,

2015-08-03 22:28 GMT+02:00 Ortner, Christoph :
> If I do automatic line wrap in paragraphs with latex labels, e.g.,
> \ref{eq:a long descriptive label}
> then it will often be separated into two lines, and the reference
> breaks. Same problem with labels themselves in fact.

This document

--8<---cut here---start->8---
\documentclass{article}
\begin{document}
\begin{equation}
  \label{eq:a very long label with spaces in it}
  a+b=c
\end{equation}
This is a very long paragraph with a~(\ref{eq:a very long label with spaces in
  it})
\end{document}
--8<---cut here---end--->8---

compiles fine for me, even with a line break in the ref macro.  I'd
suggest not to use spaces in labels at all, see also
https://tex.stackexchange.com/questions/149701/are-latexs-label-names-case-sensitive-can-label-names-contain-spaces#comment340547_149704

Anyway, you can add the ref macro (and all other ref-like macros) to
the `LaTeX-verbatim-macros-with-braces-local' variable in your init
file, in order to avoid breaking it:

(add-to-list 'LaTeX-verbatim-macros-with-braces-local "ref")

Let me know if this suffices.

Bye,
Mosè



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

bug#20781: Xemacs 21.4.22 MaC OS Yosmite: (customize-option 'TeX-view-program-list) fails with error

[Mosè Giordano]

Hi Tassilo,

2015-06-10 10:47 GMT+02:00 Tassilo Horn :
> Mosè Giordano  writes:
>
>>> Using Xemacs 21.4.22 mule on Mac OS Yosmite, I obtain the following
>>> error when trying to run
>>> (customize-option 'TeX-view-program-list) fails with error
>>> However
>>> (customize-option 'TeX-command-list)
>>>
>>> Works!!
>>
>> Why do you think this has something to do with AUCTeX?  I cannot see
>> what we can do to fix this bug, which I cannot reproduce with GNU
>> Emacs on GNU/Linux.  We have very few system dependent configurations,
>> I guess a system dependent bug comes from somewhere else.
>
> Uwe, you could try out the current Git version instead of 11.88.  In
> 11.88 the :type of `TeX-view-program-list' changed from (alist ...) to
> (repeat (list ...)).  Maybe Xemacs 21.4.22 has a problem with the alist
> type, who knows...

Uh, I forgot to mention I tried with XEmacs (21.4.22) on GNU/Linux
too: same result, no error here.

Bye,
Mosè



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

bug#20781: Xemacs 21.4.22 MaC OS Yosmite: (customize-option 'TeX-view-program-list) fails with error

[Mosè Giordano]

Hi Uwe,

2015-06-10 8:44 GMT+02:00 Uwe Brauer :
>
> Using Xemacs 21.4.22 mule on Mac OS Yosmite, I obtain the following
> error when trying to run
> (customize-option 'TeX-view-program-list) fails with error
> However
> (customize-option 'TeX-command-list)
>
> Works!!

Why do you think this has something to do with AUCTeX?  I cannot see
what we can do to fix this bug, which I cannot reproduce with GNU
Emacs on GNU/Linux.  We have very few system dependent configurations,
I guess a system dependent bug comes from somewhere else.

Bye,
Mosè



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

bug#20513: 11.88.5; TeX-view-program-list generated in wrong format by Customize

[Mosè Giordano]

2015-05-07 11:03 GMT+02:00 David Kastrup :
> Tassilo Horn  writes:
>
>> Mosè Giordano  writes:
>>
>>> I agree, but I confirm `TeX-view-program-list' is built in the wrong
>>> way when changed with customize interface, as reported by Дарио.  It
>>> worked as expected before commit
>>>
>>>   * 59ccf34 (2014-11-28) Check the viewer executable exists before
>>> opening it.
>>>
>>> where the customization type of the variable was changed from an alist
>>> to a repeated list, but the command part of the type hasn't been
>>> modified.  How should it be fixed?
>>
>> I think the problem is that the command part is a group of a choice
>> where one choice is a list again.  A group is a list, and list is a
>> list, so command parts will result in ((stuff)) where it should be just
>> (stuff).  So can't you simply remove the outer
>>
>>   (group :tag "Command parts"
>>
>> and that's it?
>
> I seem to remember that there is some option in the customization
> definition where some group will be folded into the surrounding list.
>
> Ah yes, (info "(elisp) Splicing into Lists").
>
> File: elisp.info,  Node: Splicing into Lists,  Next: Type Keywords,  Prev: 
> Composite Types,  Up: Customization Types
>
> 14.4.3 Splicing into Lists
> --
>
> The ‘:inline’ feature lets you splice a variable number of elements into
> the middle of a ‘list’ or ‘vector’ customization type.  You use it by
> adding ‘:inline t’ to a type specification which is contained in a
> ‘list’ or ‘vector’ specification.
>
>Normally, each entry in a ‘list’ or ‘vector’ type specification
> describes a single element type.  But when an entry contains ‘:inline
> t’, the value it matches is merged directly into the containing
> sequence.  For example, if the entry matches a list with three elements,
> those become three elements of the overall sequence.  This is analogous
> to ‘,@’ in a backquote construct (*note Backquote::).

Thanks to both, the bug should be fixed now.

Bye,
Mosè



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

bug#20513: 11.88.5; TeX-view-program-list generated in wrong format by Customize

[Mosè Giordano]

2015-05-07 10:51 GMT+02:00 Tassilo Horn :
> Mosè Giordano  writes:
>
>> I agree, but I confirm `TeX-view-program-list' is built in the wrong
>> way when changed with customize interface, as reported by Дарио.  It
>> worked as expected before commit
>>
>>   * 59ccf34 (2014-11-28)  Check the viewer executable exists before opening 
>> it.
>>
>> where the customization type of the variable was changed from an alist
>> to a repeated list, but the command part of the type hasn't been
>> modified.  How should it be fixed?
>
> I think the problem is that the command part is a group of a choice
> where one choice is a list again.  A group is a list, and list is a
> list, so command parts will result in ((stuff)) where it should be just
> (stuff).  So can't you simply remove the outer
>
>   (group :tag "Command parts"
>
> and that's it?

That's what I thought, but why it used to work when the type was an
alist?  Back then, also using command parts resulted in (stuff)
instead of ((stuff)).  What am I missing?

Bye,
Mosè



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

bug#20513: 11.88.5; TeX-view-program-list generated in wrong format by Customize

[Mosè Giordano]

Hi Tassilo,

2015-05-07 8:39 GMT+02:00 Tassilo Horn :
> Дарио Ѓорѓевски  writes:
>
> Hi!
>
>> Consider the following customization of the TeX-view-program-list
>> variable: http://i.imgur.com/xP6Cx5k.png
>> The generated Lisp expression looks like so:
>> '(("SumatraPDF"
>>(("SumatraPDF.exe"
>>  (mode-io-correlate " -forward-search %b %n")
>>  " %o"))
>>"SumatraPDF.exe"))
>>
>> This causes TeX-view-command-raw (tex.el, line 1354) to go into an
>> *infinite loop*. I do not know why the infinite loop occurs, however,
>> I know that changing
>>
>> (dolist (elt car spec)
>> to
>> (dolist (elt (car spec))
>>
>> solves the issue.
>
> The former line looks strange, indeed.  However, it seems you are
> looking at a different tex.el than the one that ships with ELPA AUCTeX
> 11.88.5.

I agree, but I confirm `TeX-view-program-list' is built in the wrong
way when changed with customize interface, as reported by Дарио.  It
worked as expected before commit

  * 59ccf34 (2014-11-28)  Check the viewer executable exists before opening it.

where the customization type of the variable was changed from an alist
to a repeated list, but the command part of the type hasn't been
modified.  How should it be fixed?

Bye,
Mosè



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

bug#20488: acknowledged by developer (Re: bug#20488: Problems with Icelandic quotation marks)

[Mosè Giordano]

Hi Joseph,

2015-05-04 13:56 GMT+02:00 Joseph Timothy Foley :
> Thank you for that solution, though it has a minor error in it:
> You sent:
> (add-to-list 'TeX-quote-language-alist
>   '("icelandic" "\"'" "\"'" nil))
>
> When it should be:
> (add-to-list 'TeX-quote-language-alist
>   '("icelandic" "\"`" "\"'" nil))
> Note the right single quote.

That's what I wrote, see
https://debbugs.gnu.org/cgi/bugreport.cgi?msg=8;bug=20488

> In the AUCTex distribution, it appears that this is supposed to be
> already set via icelandic.el. Am I confused about how TeX-quote-language
> vs TeX-quote-language-alist works?
>
> in elpa/auctex-11.88.3/style/icelandic.el
>
> (TeX-add-style-hook
>  "icelandic"
>  (lambda ()
>(set-syntax-table LaTeX-icelandic-mode-syntax-table)
>(unless (eq (car TeX-quote-language) 'override)
>  (setq TeX-quote-language '("icelandic" "\"`" "\"'" t)))
>(setq LaTeX-babel-hyphen-language "icelandic")
>;; Fontification of quotation marks.
>(when (fboundp 'font-latex-add-quotes)
>  (font-latex-add-quotes '("\"`" "\"'"))
>  (font-latex-add-quotes '("\"<" "\">" french)))
>(run-hooks 'TeX-language-is-hook))
>  LaTeX-dialect)

The difference between what I wrote in my code and what is done in
icelandic.el is the last item of the list: it's t in the style file,
and nil in my code.  The fourth item of the list controls whether the
quote is inserted after the first or the second press of ", see
https://gnu.org/software/auctex/manual/auctex.html#index-TeX_002dquote_002dlanguage_002dalist

Bye,
Mosè



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

bug#20488: Problems with Icelandic quotation marks

[Mosè Giordano]

close 20488
tags 20488 notabug
thanks


Hi Joseph,

2015-05-03 0:19 GMT+02:00 Joseph Timothy Foley :
> The Icelandic support in AUCTeX seems to be having issues with quotation
> marks.  If I type ", it doesn't replace it with the right marks.  It
> simply puts ".  I have to press " twice in order to get it to create "`
> and "'.  Am I missing something?

Well, the behavior you reported is exactly what is described in the
AUCTeX manual (info "(auctex)European") [1], so I wouldn't call it a
bug.

> I searched on google and could not
> find anyone else with a similar issue.
> When the system is not editing a document in with biber, " expands
> correctly to the `` and '' as normal.

You can achieve the behavior you expected by setting the
`TeX-quote-language-alist' variable.  Add the following code to your
init file

(add-to-list 'TeX-quote-language-alist
 '("icelandic" "\"`'" "\"'" nil))

Now you can insert the right quotation marks by pressing " just once.

I'm going to close this ticket.

Bye,
Mosè

Note:
[1] https://gnu.org/software/auctex/manual/auctex.html#European



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

bug#20359: Indentation bug in newest version of AUCTeX

[Mosè Giordano]

Hi Peter,

2015-04-17 17:14 GMT+02:00 Peter Harpending :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello there,
>
> I have the newest version of AUCTeX available on Melpa/Elpa/online,
> which is 11.88.4. I just updated it yesterday; I'm not sure what version
> I had before.
>
> Before, running fill-paragraph on my various paragraphs would indent my
> file like so: http://ix.io/hWy
>
> Now, it's doing this: http://ix.io/hWz. Notice the lack of indentation
> following the \item, and such. I haven't changed any of the LaTeX
> variables. My LaTeX-indent-level is 2.
>
> Thank you,
>
> Peter Harpending

How do you fill your paragraphs?  Do you select all of them at once
and then issue M-q or do you do it one by one?  I can reproduce your
problem if I try to fill all the paragraphs together, but works as
expected when I fill just one paragraph (which is what I usually do).
I can reproduce this behavior also in AUCTeX 11.87, so it's not even
so new.

Bye,
Mosè



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

bug#19504: 11.88; [siunitx] unit appears without backslash

[Mosè Giordano]

Hello,

here is my take to fix the bug: there are three different versions of
`TeX-completing-read-multiple' as suggested by Tassilo.  I'm just not
sure it works with all 24.* versions of Emacs.  A serious problem is
that there are a couple of internal functions (crm--*), and we had
problems  in the past with internal functions,[1] for which we still
get bug reports nowadays.

Actually, the change by Roland Winkler which caused this bug is the
same which forced us to make `TeX-completing-read-multiple' always
return nil,[2] so perhaps we could also revert that change, but in
this way we would break backward compatibility in turn.

Bye,
Mosè

Note:

[1]  http://comments.gmane.org/gmane.emacs.aquamacs.devel/240
[2]  http://comments.gmane.org/gmane.emacs.auctex.devel/3375

2015-03-12 23:05 GMT+01:00 Mosè Giordano :
> Hi Tassilo,
>
> 2015-03-12 9:51 GMT+01:00 Tassilo Horn :
>> Mosè Giordano  writes:
>>
>>>> PS: The plan is actually to move the minibuffer completion in that
>>>> direction for normal minibuffer completion, so that TAB is bound to
>>>> completion-at-point in the minibuffer as well.
>>>
>>> Uh, thanks for the suggestion, but according to git blame
>>> `completion-at-point' exists since 2009, so Emacs <23 is left out.
>>
>> Sorry, I didn't follow this issue closely.  But isn't it the case that
>> some quite recent change in Emacs is the culprit?
>
> Yes, with this commit
> http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commitdiff;h=9c44569ea2a18099307e0571d523d8637000a153
> `completing-read-multiple' ignores empty strings, which was essential
> for completion of `siunitx' units.
>
>> In that case,
>> `TeX-completing-read-multiple' could have 3 versions instead of the
>> current two (one for Emacs, one for XEmacs), i.e., one for Emacs <= 22,
>> one for Emacs 23+, and one for XEmacs.
>
> As I said some messages ago, the best I can think is to copy the last
> Emacs implementation before the mentioned commit (making sure return
> value for empty input is always nil) for all Emacs versions, so we
> should be able to keep the number of versions of
> `TeX-completing-read-multiple' as low as two.  The problem will be of
> course some more work on our side to maintain the function, if needed.
>
> Bye,
> Mosè
diff --git a/tex.el b/tex.el
index 394814e..3b54d79 100644
--- a/tex.el
+++ b/tex.el
@@ -716,18 +716,57 @@ overlays."
 edit-utils >= 2.32 for XEmacs.")))
 
 (if (fboundp 'completing-read-multiple)
-(defun TeX-completing-read-multiple
-	(prompt table &optional predicate require-match initial-input
-		hist def inherit-input-method)
-  "Like `completing-read-multiple' which see.
-Ensures that empty input results in nil across different emacs versions."
-  (let ((result (completing-read-multiple prompt table predicate
-	  require-match initial-input
-	  hist def inherit-input-method)))
-	(if (equal result '("")) nil result)))
+(if (< emacs-major-version 24)
+	;; GNU Emacs < 24
+	(defun TeX-completing-read-multiple
+	(prompt table &optional predicate require-match initial-input
+		hist def inherit-input-method)
+	  "Like `completing-read-multiple' which see.
+Ensures that empty input results is nil across different emacs versions."
+	  (let ((result (completing-read-multiple prompt table predicate
+		  require-match initial-input
+		  hist def inherit-input-method)))
+	(if (equal result '("")) nil result)))
+  ;; GNU Emacs >= 24
+  (defun TeX-completing-read-multiple
+	  (prompt table &optional predicate require-match initial-input
+		  hist def inherit-input-method)
+	"Like `completing-read-multiple' which see.
+Ensures that empty input results is nil across different emacs versions."
+	;; Based on implementation in lisp/emacs-lisp/crm.el in Emacs git
+	;; revision 327f1f6f6d934e58921179275547b2d09f219f32 (Sun, 17 Mar 2013
+	;; 00:19:09 +)
+	(unwind-protect
+	(progn
+	  (add-hook 'choose-completion-string-functions
+			'crm--choose-completion-string)
+	  (let* ((minibuffer-completion-table #'crm--collection-fn)
+		 (minibuffer-completion-predicate predicate)
+		 ;; see completing_read in src/minibuf.c
+		 (minibuffer-completion-confirm
+		  (unless (eq require-match t) require-match))
+		 (crm-completion-table table)
+		 (map (if require-match
+			  crm-local-must-match-map
+			crm-local-completion-map))
+		 ;; If the user enters empty input, `read-from-minibuffer'
+		 ;; returns the empty string, not DEF.
+		 (input (read-from-minibuffer
+			 prompt initial-input map
+			 nil hist def inherit-input-method))
+		  

bug#20227: 11.88.3; indentation of \[ ... \] environment is broken

[Mosè Giordano]

Hi Todor,

2015-03-29 23:44 GMT+02:00 Todor Tsankov :
> 
>
> The automatic indentation of the \[ ... \] environment does not seem to
> work correctly. Of the three examples below only the first one looks
> right.
>
> I obtained those results by selecting the entire environment and running
> indent-region.
>
> Thanks for looking into this.
>
> \[
>   x
> \]
>
> \[
>   \begin{split}
>   x &= y \\
>   y &= z
> \end{split}
> \]
>
> \begin{itemize}
> \item Some text here
>   \[
>   x
> \]
> \end{itemize}

Thanks for the very good bug report.  It should be fixed now with commit

c2f6e9c[Fix #20227] Fix indentation of \[...\] math mode.

Bye,
Mosè



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

bug#19504: 11.88; [siunitx] unit appears without backslash

[Mosè Giordano]

Hi Tassilo,

2015-03-12 9:51 GMT+01:00 Tassilo Horn :
> Mosè Giordano  writes:
>
>>> PS: The plan is actually to move the minibuffer completion in that
>>> direction for normal minibuffer completion, so that TAB is bound to
>>> completion-at-point in the minibuffer as well.
>>
>> Uh, thanks for the suggestion, but according to git blame
>> `completion-at-point' exists since 2009, so Emacs <23 is left out.
>
> Sorry, I didn't follow this issue closely.  But isn't it the case that
> some quite recent change in Emacs is the culprit?

Yes, with this commit
http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commitdiff;h=9c44569ea2a18099307e0571d523d8637000a153
`completing-read-multiple' ignores empty strings, which was essential
for completion of `siunitx' units.

> In that case,
> `TeX-completing-read-multiple' could have 3 versions instead of the
> current two (one for Emacs, one for XEmacs), i.e., one for Emacs <= 22,
> one for Emacs 23+, and one for XEmacs.

As I said some messages ago, the best I can think is to copy the last
Emacs implementation before the mentioned commit (making sure return
value for empty input is always nil) for all Emacs versions, so we
should be able to keep the number of versions of
`TeX-completing-read-multiple' as low as two.  The problem will be of
course some more work on our side to maintain the function, if needed.

Bye,
Mosè



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

bug#19504: 11.88; [siunitx] unit appears without backslash

[Mosè Giordano]

2015-03-11 16:27 GMT+01:00 Stefan Monnier :
>> Unfortunately no, one can also insert the unit without using macros,
>> so we can't always add the leading backslash
>
> So the user could enter "\second \per meter"?

Yes, something like that: you can enter units using macros (e.g.
"\second\per\metre") but also literally (e.g. "s/m").  The package is
useful because at least adjusts the spacing between the value and the
unit.

> I'm getting the feeling that completing-read-multiple is just not the
> right tool for the job.  Could it be that what you want instead is to
> have (in the minibuffer) completion that doesn't apply to the whole
> minibuffer (but that is instead more like in-buffer completion).
>
> So you'd want a `read-string' where you setup
> completion-at-point-functions inside the minibuffer and where you bind
> TAB to `completion-at-point'.
>
>
>
> Stefan
>
>
> PS: The plan is actually to move the minibuffer completion in that
> direction for normal minibuffer completion, so that TAB is bound to
> completion-at-point in the minibuffer as well.

Uh, thanks for the suggestion, but according to git blame
`completion-at-point' exists since 2009, so Emacs <23 is left out.

Bye,
Mosè



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

bug#19504: 11.88; [siunitx] unit appears without backslash

[Mosè Giordano]

Hi Stefan,

2015-03-09 18:56 GMT+01:00 Stefan Monnier :
>> returning also empty strings.  This change is not even mentioned in
>> the Incompatible Lisp Changes section of the NEWS file.
>
> Lots of changes aren't mentioned.  Only the ones that we expect to be
> noticed are mentioned.

Well, this was noticed too ;-)

>> For the time being I don't have a solution, apart from defining
>> `TeX-completing-read-multiple' as the old version of
>> `completing-read-multiple', or someone fixing
>> `completing-read-multiple' upstream, at least making
>> trimming optional.
>
> IIUC you always need a leading \, so you could simply always add
> a leading backslash if one is missing.
> Of course, I'm not sure that IUC.

Unfortunately no, one can also insert the unit without using macros,
so we can't always add the leading backslash

Bye,
Mosè



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

bug#19724: 11.88; preview with pdftex not working

[Mosè Giordano]

close 19724
tags 19724 notabug
thanks


Hi,

2015-01-29 21:39 GMT+01:00  :
> David, removing %(file-line-error) from LaTeX-command-style solved the
> problem: preview is working fine now. Thank you!
>
> Also, in case it's useful: I temporarily reinstalled the previous version of
> AucTeX (11.88 – now it's 11.88.2), and preview was working fine there – and
> in that version the default LaTeX-command-style did NOT have the
> %(file-line-error) part.

You can set `TeX-file-line-error' to nil if you don't want the
file:line:error style, instead of customizing `LaTeX-command-style' or
downgrading AUCTeX.

Unfortunately, MiKTeX' compilers are less detailed when
file:line:error style is requested, I cannot see any
good reason for this behavior.  On the other side, with TeX Live you
have same verbosity + file:line:error style.

I'm going to close this bug report.

Bye,
Mosè



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

bug#19673: 11.88; AUCTEX 11.88.1 view command bug

[Mosè Giordano]

Hi Tassilo,

2015-01-27 3:20 GMT-05:00 Tassilo Horn :
> I did that now in the auctex git repository.

Probably you would like to remove the check for "start" from the
"dvips and start" viewer as well ;-)

> Um, could you please teach
> me how to sync that change to ELPA?  I know there's something better
> than manual diff/patch, no?

Add to your AUCTeX repository the elpa remote
git remote add elpa git://git.sv.gnu.org/emacs/elpa.git
and then fetch the AUCTeX branch
git fetch elpa externals/auctex:elpa
Now you should be able to merge one branch into the other, or
cherry-pick single commits from them, this is what I did for a commit
by Stefan Monnier some weeks ago.

Bye,
Mosè



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

bug#19673: 11.88; AUCTEX 11.88.1 view command bug

[Mosè Giordano]

Hi Shawn and Tassilo,

and sorry for the late reply.

2015-01-25 3:18 GMT-05:00 Tassilo Horn :
> "Shawn Way"  writes:
>
> Hi Shawn & Mosè,
>
>> The latex file compiles just fine, however when the viewer is invoked
>> (from either the menu, C-c C-c or C-c C-v) the following error is
>> produced:
>>
>> Cannot find "start" viewer. Select another one in
>> 'TeX-view-program-selection'.
>>
>> This occurs when I upgrade from 11.88 to 11.88.1. When I remove 11.88.1
>> and revert back to 11.88, the function is working just fine.
>
> Thanks for the report.  Mosè, it seems the error comes from the code you
> added in commit 59ccf3416d53064785d3feee8bcbf8074612386a which checks if
> the viewer executable actually exists.
>
> Shawn uses windows where the viewer is "start".  Maybe that's some
> internal command you cannot find with `executable-find'?  E.g.,
> something like a shell builtin command like "alias" in bash/zsh?

We need to know which is the problem: if it's what you suggested
(start is not strictly a binary and `find-executable' cannot find it)
then we can just remove start from the list of executable to be
checked.

Admittedly, I don't use Windows and I wasn't able to test the change
on that system, but I made a research and I understood that "start"
was a system program or something like that.  Again, if it's not an
executable, remove the third element of the "start" item in
`TeX-view-program-list-builtin' and we'll need to fix it also
upstream.

Bye,
Mosè



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

bug#19517: [SOLVED-sort of] recursive requires with recent auctex versions.

[Mosè Giordano]

close 19517
tags 19517 notabug
thanks


Hi Bernard,

2015-01-09 17:58 GMT+01:00 Bernard Hurley :
> On Wed, Jan 07, 2015 at 04:41:32PM +0100, Mosč Giordano wrote:
>
>> This is not a common problem, we have received only one other similar
>> report a few months ago
>> http://lists.gnu.org/archive/html/bug-auctex/2014-05/msg00017.html but
>> there was no follow up to this message
>> http://lists.gnu.org/archive/html/bug-auctex/2014-06/msg3.html  I
>> really don't know what's the problem, your help in finding the culprit
>> would be great.
>>
>
> I am running the latest version of Emacs 24 - GNU Emacs 24.4.50.1 from the 
> git repository - I regularly update it.
>
> I will certainly investigate what is happening, but I don't have a lot of 
> time at the moment.

I have the stable version of Emacs 24.4.  Could it be possible you
have something broken in your Emacs build?  You already reported this
problem some months ago:
https://lists.gnu.org/archive/html/auctex-devel/2014-07/msg00077.html
We have received in total two such reports (you were both using an
unstable version of Emacs, for that matter), but no one has been able
to trace the origin of the bug.

You can use your proposed solution on your system to temporarily work
around the bug, but I don't think it's acceptable as an upstream fix.
Even if it were so, it would have to be fixed in the package manager,
not the AUCTeX package itself.  Then I don't think there is something
we, as AUCTeX developers, can do and this is why I've closed this
ticket, but feel free to write here more information as you find them
anyway.

Bye,
Mosè



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

bug#19517: [SOLVED-sort of] recursive requires with recent auctex versions.

[Mosè Giordano]

Hi Bernard,

2015-01-07 12:40 GMT+01:00 Bernard Hurley :
> Hi Mosè,
>
> On Tue, Jan 06, 2015 at 03:37:18PM +0100, Mosč Giordano wrote:
>> Hi Bernard,
>>
>> 2015-01-05 18:28 GMT+01:00 Bernard Hurley :
>> > Hi All,
>> >
>> I cannot understand your problem.  Have you installed AUCTeX using
>> ELPA
>
> Indeed I have so there shouldn't be any problems and there are no problems 
> with any of the other packages I have installed using ELPA.  However ELPA IS 
> NOT INITIALISING AUCTeX CORRECTLY.

Sorry but I cannot reproduce your error with AUCTeX 11.88 on GNU Emacs
24.4.  Which is your Emacs version?  Have you tried starting up Emacs
with a clean init file (not `emacs -q', ELPA packages won't be loaded
in that case)?

This is not a common problem, we have received only one other similar
report a few months ago
http://lists.gnu.org/archive/html/bug-auctex/2014-05/msg00017.html but
there was no follow up to this message
http://lists.gnu.org/archive/html/bug-auctex/2014-06/msg3.html  I
really don't know what's the problem, your help in finding the culprit
would be great.

Bye,
Mosè



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

bug#19517: [SOLVED-sort of] recursive requires with recent auctex versions.

[Mosè Giordano]

Hi Bernard,

2015-01-05 18:28 GMT+01:00 Bernard Hurley :
> Hi All,
>
> I'm new to this list but I gather some of you have been having problems with
> recursive require in latest versions of auctex.
>
> The problem seems to arise because elpa does not initialise auctex properly 
> (see
> below).  I'm not sure exactly why and when it happens but it seems to have
> something to do with what other packages are being initialised; either that or
> it has something to do with the way "auctex.el" loads "tex.el".  Personally I
> don't have time to work out exactly what is happening - I am more concerned 
> with
> getting it working- so I have come up with a stop-gap solution, which may help
> others.

I cannot understand your problem.  Have you installed AUCTeX using
ELPA and you have a line like
  (load "auctex")
in you init file?  If so, just remove that line, there is no need to
manually load packages installed with the builtin package manager
(unless you requested otherwise).

Bye,
Mosè



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

bug#19504: 11.88; [siunitx] unit appears without backslash

[Mosè Giordano]

2015-01-04 12:41 GMT+01:00 Mosè Giordano :
> tag 19504 confirmed
> thanks
>
>
> Hi Uwe,
>
> 2015-01-04 12:22 GMT+01:00 Uwe Siart :
>> When I try to enter an siunitx \SI macro I get the unit without
>> backslash even if I enter it correctly with a backslash. For instance if
>> I do
>>
>> C-c RET SI RET RET 5 RET RET \kHz RET
>>
>> I get "\SI{5}{kHz}" but I expect "\SI{5}{\kHz}". This happens to every
>> valid unit macro. It is always the first backslash that gets lost.
>> Entering "\meter\per\second" results in "meter\per\second".
>
> Thanks for the report, I can confirm this bug, but it has been
> introduced by a recent version of Emacs, I just tested with Emacs
> 23.3.1 and it works as expected.  I cannot remember which version of
> Emacs I used when I developed the siunitx style file, probably 24.2 or
> 24.3.  I'll try to find the culprit.

For the record, this commit is the culprit:
http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commitdiff;h=9c44569ea2a18099307e0571d523d8637000a153
 `LaTeX-arg-siunitx-unit' relies on `completing-read-multiple'
returning also empty strings.  This change is not even mentioned in
the Incompatible Lisp Changes section of the NEWS file.  For the time
being I don't have a solution, apart from defining
`TeX-completing-read-multiple' as the old version of
`completing-read-multiple', or someone fixing
`completing-read-multiple' upstream, at least making trimming
optional.

Bye,
Mosè



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

bug#19504: 11.88; [siunitx] unit appears without backslash

[Mosè Giordano]

tag 19504 confirmed
thanks


Hi Uwe,

2015-01-04 12:22 GMT+01:00 Uwe Siart :
> When I try to enter an siunitx \SI macro I get the unit without
> backslash even if I enter it correctly with a backslash. For instance if
> I do
>
> C-c RET SI RET RET 5 RET RET \kHz RET
>
> I get "\SI{5}{kHz}" but I expect "\SI{5}{\kHz}". This happens to every
> valid unit macro. It is always the first backslash that gets lost.
> Entering "\meter\per\second" results in "meter\per\second".

Thanks for the report, I can confirm this bug, but it has been
introduced by a recent version of Emacs, I just tested with Emacs
23.3.1 and it works as expected.  I cannot remember which version of
Emacs I used when I developed the siunitx style file, probably 24.2 or
24.3.  I'll try to find the culprit.

Bye,
Mosè



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

bug#19281: 11.86; environment update fails when environment name contains \

[Mosè Giordano]

Hi Tassilo,

2014-12-10 8:38 GMT+01:00 Tassilo Horn :
> Mosè Giordano  writes:
>
> Hi!
>
>> 2014-12-09 10:34 GMT+01:00 Tassilo Horn :
>>>> Or matching everything between the opening and the closing brace
>>>> (allowing at least one level of braces)?
>>>
>>> Either that, or we could also rely on syntax tables.  I.e., since
>>> `LaTeX-find-matching-end' already brings us to the end of the
>>> environment name,
>>>
>>>   (let ((end (point)))
>>> (forward-char)
>>> (backward-sexp)
>>> (forward-char)
>>> (buffer-substring-no-properties (point) end))
>>>
>>> gives us the environment name.
>>
>> Good idea, except that `LaTeX-find-matching-end' fails to find the
>> closing brace of \end when the environment name is a macro with
>> arguments.
>
> Ah, indeed.  During my testing it always stopped at
> \end{\whatever{foo}|} with | being point, so I assumed that's where it's
> supposed to stop, i.e., right after the environment name, not right
> after the environment.
>
> I guess it's better to also test the simple cases, not only the complex
> ones. ;-)
>
>> The attached patch should fix this problem.
>> `LaTeX-environment-name-regexp' needs to be a function because if it
>> were a variable it would always keep the original value, also in
>> buffers with different values for `TeX-grop' and `TeX-grcl' (or not?).
>
> Correct.  Well, it could also be a variable that's initialized in
> `LaTeX-common-initialization' or so after a call to
> `hack-local-variables' to apply file local variables first.  But IMO
> it's better to have it as a function.
>
>> Probably `LaTeX-modify-environment' can be simplified following your
>> suggestion,
>
> On a second thought, the syntax-table approach will fail in case the
> environment name is something unbalanced like \foo[{] which is unlikely
> but possible.  So better stick to the regexp-search.
>
>> the patch sketches an idea how to fix `LaTeX-find-matching-end', but
>> can be improved.
>
> Looks good to me.

Ok, thanks, patch installed.

Bye,
Mosè



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

bug#19281: 11.86; environment update fails when environment name contains \

[Mosè Giordano]

Hi Tassilo,

2014-12-09 10:34 GMT+01:00 Tassilo Horn :
>> Or matching everything between the opening and the closing brace
>> (allowing at least one level of braces)?
>
> Either that, or we could also rely on syntax tables.  I.e., since
> `LaTeX-find-matching-end' already brings us to the end of the
> environment name,
>
>   (let ((end (point)))
> (forward-char)
> (backward-sexp)
> (forward-char)
> (buffer-substring-no-properties (point) end))
>
> gives us the environment name.

Good idea, except that `LaTeX-find-matching-end' fails to find the
closing brace of \end when the environment name is a macro with
arguments.  The attached patch should fix this problem.
`LaTeX-environment-name-regexp' needs to be a function because if it
were a variable it would always keep the original value, also in
buffers with different values for `TeX-grop' and `TeX-grcl' (or not?).
Probably `LaTeX-modify-environment' can be simplified following your
suggestion, the patch sketches an idea how to fix
`LaTeX-find-matching-end', but can be improved.

Bye,
Mosè
diff --git a/latex.el b/latex.el
index 0022ae2..477ef66 100644
--- a/latex.el
+++ b/latex.el
@@ -729,6 +729,15 @@ environment just inserted, the buffer position just before
 (run-hook-with-args 'LaTeX-after-insert-env-hooks
 			environment env-start env-end)))
 
+(defun LaTeX-environment-name-regexp ()
+  "Return the regexp matching the name of a LaTeX environment.
+This matches everything different from a TeX closing brace but
+allowing one level of TeX group braces."
+  (concat "\\([^" (regexp-quote TeX-grcl) (regexp-quote TeX-grop) "]*\\("
+	  (regexp-quote TeX-grop) "[^" (regexp-quote TeX-grcl)
+	  (regexp-quote TeX-grop) "]*" (regexp-quote TeX-grcl) "\\)*[^"
+	  (regexp-quote TeX-grcl) (regexp-quote TeX-grop) "]*\\)"))
+
 (defun LaTeX-modify-environment (environment)
   "Modify current ENVIRONMENT."
   (save-excursion
@@ -736,7 +745,7 @@ environment just inserted, the buffer position just before
 (re-search-backward (concat (regexp-quote TeX-esc)
 "end"
 (regexp-quote TeX-grop)
-" *\\([a-zA-Z*]*\\)"
+(LaTeX-environment-name-regexp)
 (regexp-quote TeX-grcl))
 			(save-excursion (beginning-of-line 1) (point)))
 (replace-match (concat TeX-esc "end" TeX-grop environment TeX-grcl) t t)
@@ -745,7 +754,7 @@ environment just inserted, the buffer position just before
 (re-search-forward (concat (regexp-quote TeX-esc)
 			   "begin"
 			   (regexp-quote TeX-grop)
-			   " *\\([a-zA-Z*]*\\)"
+			   (LaTeX-environment-name-regexp)
 			   (regexp-quote TeX-grcl))
 		   (save-excursion (end-of-line 1) (point)))
 (replace-match (concat TeX-esc "begin" TeX-grop environment TeX-grcl) t t)))
@@ -4124,7 +4133,7 @@ environment in commented regions with the same comment prefix."
 	 (comment-prefix (and in-comment (TeX-comment-prefix)))
 	 (case-fold-search nil))
 (save-excursion
-  (skip-chars-backward "a-zA-Z \t{")
+  (skip-chars-backward (concat "a-zA-Z \t" (regexp-quote TeX-grop)))
   (unless (bolp)
 	(backward-char 1)
 	(and (looking-at regexp)
@@ -4143,7 +4152,8 @@ environment in commented regions with the same comment prefix."
 	(setq level (1+ level))
 	  (setq level (1- level)
 (if (= level 0)
-	(search-forward "}")
+	(re-search-forward
+	 (concat TeX-grop (LaTeX-environment-name-regexp) TeX-grcl))
   (error "Can't locate end of current environment"
 
 (defun LaTeX-find-matching-begin ()
@@ -4158,7 +4168,7 @@ environment in commented regions with the same comment prefix."
 	 (in-comment (TeX-in-commented-line))
 	 (comment-prefix (and in-comment (TeX-comment-prefix)))
 	 (case-fold-search nil))
-(skip-chars-backward "a-zA-Z \t{")
+(skip-chars-backward (concat "a-zA-Z \t" (regexp-quote TeX-grop)))
 (unless (bolp)
   (backward-char 1)
   (and (looking-at regexp)
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#19281: 11.86; environment update fails when environment name contains \

[Mosè Giordano]

To anyone replying to my previous message: please do not CC
cont...@debbugs.gnu.org, unless you really want to send control
messages.

Thanks,
Mosè

2014-12-08 19:34 GMT+01:00 Mosè Giordano :
> tag 19281 confirmed
> thanks
>
>
> Hi Manuel,
>
> 2014-12-05 17:17 GMT+01:00 Manuel Sorge :
>>
>> I tried to update an environment in a latex document via C-u C-c C-e or
>> LaTeX-modify-environment but mistyped the name as 'theorem\'. I tried to
>> correct my error via C-u C-c C-e again but I got a search failed message:
>>
>> LaTeX-modify-environment: Search failed: "end{ *\\([a-zA-Z*]*\\)}"
>
> I can confirm the bug you reported.  Indeed, `\begin' and `\end'
> accept as valid environment names macros (not your case though) and
> macros with arguments, while `LaTeX-modify-environment' searches for
> names matching "[a-zA-Z*]".  So, I'm not sure how to fix it: Just add
> `TeX-esc' to the regexp?  Or matching everything between the opening
> and the closing brace (allowing at least one level of braces)?
> Suggestions welcome.
>
> Bye,
> Mosè



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

bug#19281: 11.86; environment update fails when environment name contains \

[Mosè Giordano]

tag 19281 confirmed
thanks


Hi Manuel,

2014-12-05 17:17 GMT+01:00 Manuel Sorge :
>
> I tried to update an environment in a latex document via C-u C-c C-e or
> LaTeX-modify-environment but mistyped the name as 'theorem\'. I tried to
> correct my error via C-u C-c C-e again but I got a search failed message:
>
> LaTeX-modify-environment: Search failed: "end{ *\\([a-zA-Z*]*\\)}"

I can confirm the bug you reported.  Indeed, `\begin' and `\end'
accept as valid environment names macros (not your case though) and
macros with arguments, while `LaTeX-modify-environment' searches for
names matching "[a-zA-Z*]".  So, I'm not sure how to fix it: Just add
`TeX-esc' to the regexp?  Or matching everything between the opening
and the closing brace (allowing at least one level of braces)?
Suggestions welcome.

Bye,
Mosè



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

bug#19301: Style file for mathtools bug

[Mosè Giordano]

Hi Andrew,

2014-12-07 19:27 GMT+01:00 Andrew Francis Swann :
> mathtools.el of 2011-02-13 has small typo in TeX-add-style-hook.  There we
> have
>
> (setq LaTeX-label-alist
>  (append '(("lgathered". LaTeX-amsmath-label)
>("rgathered"   . LaTeX-amsmath-label)
>("multlined". LaTeX-amsmath-label)
>LaTeX-label-alist
>
> which has the last LaTeX-label-alist included in the quote.  It ought to be
>
> (setq LaTeX-label-alist
>  (append '(("lgathered". LaTeX-amsmath-label)
>("rgathered"   . LaTeX-amsmath-label)
>("multlined". LaTeX-amsmath-label))
>LaTeX-label-alist)))
>
>
> with one closing bracket moved from the last to the penultimate line.
>
> One symptom of the miscoding is that addition of labels does not work as
> expected.

thanks for the report!  The bug has been fixed with commit

8c6a5ae [Fix #19301] Fix closing bracket in style/mathtools.el.

Bye,
Mosè



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

bug#19273: 11.88; compile error with auctex.el

[Mosè Giordano]

Hi eDgar,

2014-12-06 22:15 GMT+01:00  :
> Same here. I also have the problem. I got rid of my previous AUCTeX
> installation from the package manager, and ran
> emacs -Q
> M-x package-install RET auctex
>
> The solution by Alexandre also works with me.
>

As a general rule for packages installed through ELPA, you must *not*
load them with `load', the package manager takes care of it, unless
you explicitly request not to do so.

Bye,
Mosè



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

bug#19260: 11.88; problem with omega

[Mosè Giordano]

Hi Uwe,

2014-12-03 18:42 GMT+01:00 Uwe Brauer :
> On 12/03/2014 06:18 PM, Mosè Giordano wrote:
> It seems lambda has been replaced by lamed, you should have it in your
> distribution.  See http://en.wikipedia.org/wiki/Omega_%28TeX%29
>
>
> right, which is funny since lamed is hebrew, while lamda is greek (and omega
> of course).

Also aleph is Hebrew ;-)

> The point is: shouldn't the
> default configuration of omega in Auctex be changed then?

It seems MiKTeX still use the old names omega and lambda (please,
correct me if I'm wrong), so I don't think we should change the
default values of {La,}TeX-Omega-command, but I added the choices for
those variable, to help people choose the right command.

Bye,
Mosè



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

bug#19273: 11.88; compile error with auctex.el

[Mosè Giordano]

2014-12-04 22:26 GMT+01:00 Alexandre René :
> I've attached a copy of auctex.el. The change is on line 32.

Thanks.  Instead of "~/.emacs.d/elpa/auctex-11.88/style" did you have
"style"?  In this case, I cannot see why you should need to do that
manual change.  Do you have customization related to AUCTeX in your
init file?  Could you please try to remove the package and then
reinstall it in a clean Emacs session?

To me, it looks more an Emacs bug than an AUCTeX one, if it's really a bug.

Please, do not remove 19...@debbugs.gnu.org from the CC list.

Bye,
Mosè



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

bug#19273: 11.88; compile error with auctex.el

[Mosè Giordano]

Hi Alexandre,

2014-12-04 20:11 GMT+01:00 Alexandre René :
> […]
> 
> (I apologize if this has already been fixed, but I couldn't find anything
> related to this in the git repository.)
>
> I just upgraded AUCtex from 11.87 to 11.88 on two of my machines through ELPA.
> In both cases, I get the following error message:
> """
> ~/.emacs.d/elpa/auctex-11.88/auctex.el:Error: Opening directory: no such
> file or directory, /home/alex/style/
> """
>
> As a workaround, I can hard-code the path to the style directory
> ("~/.emacs.d/elpa/auctex-11.88/style") in auctex.el and then AUCtex
> loads without a hitch.

I cannot reproduce this error on my system with a fresh installation
from ELPA.  What did you change exactly in auctex.el?

Bye,
Mosè



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

bug#19260: 11.88; problem with omega

[Mosè Giordano]

Hi Uwe,

2014-12-03 15:30 GMT+01:00 Uwe Brauer :
>
> Hi
>
> On Kubuntu I have texlive-omega installed, but when I set the TeX engine
> to Omega (for the first time in decades) I received the following error:
>
> Running `LaTeX' on `fixpoint-scheme' with ``lambda  -src-specials 
> -interaction=nonstopmode "\input" fixpoint-scheme.tex''
> /bin/sh: lambda: not found
>
> TeX Output exited abnormally with code 127 at Wed Dec  3 15:29:43
>
>
> This is not the end of the world since I usually use either latex or
> xelatex, but I am now curious.

It seems lambda has been replaced by lamed, you should have it in your
distribution.  See http://en.wikipedia.org/wiki/Omega_%28TeX%29

Bye,
Mosè



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

bug#19121: [Bug-AUCTeX] bug#19121: bug#19121: AUCTeX should report an error if selected viewer fails

[Mosè Giordano]

Patch fixed (the original one didn't really work with a list of
executables) and installed.

Bye,
Mosè


2014-11-25 16:49 GMT+01:00 Davide G. M. Salvetti :
>>>>>>  MG == Mosè Giordano [2014-11-24]
>
> [...]
>
> MG> Does someone have other suggestions?
>
> Hi Mosè,
>
> I reviewed your patch; I could not come up with anything better, and
> while it does have some drawbacks[1], it is indeed an improvement over
> the current situation, thanks!
>
> Footnotes:
> [1]  Beside the need to fiddle with a much customized variable, your
> patch only checks if the executable exists, but it won't notice run-time
> failures.
>
> --
> Thanks,
> Davide
>



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

bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels)

[Mosè Giordano]

2014-11-27 18:58 GMT+01:00 Uwe Brauer :
> Hi Mosè,
>
>
>> Hi Uwe and all,
>> 2014-11-27 11:39 GMT+01:00 Uwe Brauer :
>
>> I hope it's clear I wrote those messages in a hurry, just to give the 
> idea.
>
> I was going to write you. I changed nullp to null applied your old patch and
> it did not work as expected. *However* your *new* patch
>
>> I changed my mind. I propose the attached patch which restores (full)
>> compatibility with the old version of LaTeX-label: the optioanl `type'
>> argument select the look up table to be used for the default prefix of
>> the label, if it's nil (or absent) you are always prompted for a
>> label.  AUCTeX code always uses the appropriate value for the type
>> argument, but users will also be able to force the insertion of the
>> label (or continue to use the old syntax of the function).
>
> Works beautifully! Thanks for all your efforts, I appreciate it a lot.

Ok, patch applied then.

> (I still prefer some days more of testing before trying to release a
> Xemacs pkg)

Thank you!

Bye,
Mosè



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

bug#19199: 11.88; scan-error

[Mosè Giordano]

merge 19178
thanks


2014-11-27 11:23 GMT+01:00 Uwe Brauer :
>>> "Mos" == Mos   writes:
>
>> Hi Uwe,
>> 2014-11-26 19:31 GMT+01:00 Uwe Brauer :
>>>
>>> This bug seems more serious
>
>> actually to me it seems a duplicate of #19178, you error is triggered
>> by your `LaTeX-rem-insert' function.  Do you agree?
>
> Yes too tired yesterday. I think I modified my insert-rem function
> evaluated and it did not work as expected I forget to change it back
> sorry for the noise.

Don't worry ;-)  I'm merging this ticket as duplicate of the other one,

Bye,
Mosè



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

bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels)

[Mosè Giordano]

Hi Uwe and all,

2014-11-27 11:39 GMT+01:00 Uwe Brauer :
>>> "Mos" == Mos   writes:
>
>>> -""
>>> +""))
>>> + ((nullp type)
>>> +  "")))
>>  
>
>> Sorry, I meant nil instead of ""
>
> Hi
>
> I modified (hopefully correctly) your patch, applied it
> then used my old definitions such as
> (defun LaTeX-rem-insert (environment)   ;Version:1.20
> (if (y-or-n-p
>  (format "Do you want a title "))
> (let ((title (read-input " Title: ")))
>   (LaTeX-insert-environment "rem" (concat "[" title "]"))
>   (and (LaTeX-label environment)
>(newline-and-indent)))
>   (LaTeX-insert-environment "rem")
>   (and (LaTeX-label environment)
>(newline-and-indent
>
> and got an error. I attach the modified patch, and the error

I hope it's clear I wrote those messages in a hurry, just to give the idea.

I changed my mind. I propose the attached patch which restores (full)
compatibility with the old version of LaTeX-label: the optioanl `type'
argument select the look up table to be used for the default prefix of
the label, if it's nil (or absent) you are always prompted for a
label.  AUCTeX code always uses the appropriate value for the type
argument, but users will also be able to force the insertion of the
label (or continue to use the old syntax of the function).

Bye,
Mosè
diff --git a/latex.el b/latex.el
index 80d2761..571f010 100644
--- a/latex.el
+++ b/latex.el
@@ -933,7 +933,14 @@ If nil, act like the empty string is given, but do not prompt."
 ("eqnarray" . LaTeX-eqnarray-label))
   "Lookup prefixes for labels.
 An alist where the CAR is the environment name, and the CDR
-either the prefix or a symbol referring to one."
+either the prefix or a symbol referring to one.
+
+If the name is not found, or if the CDR is nil, no label is
+automatically inserted for that environment.
+
+If you want to automatically insert a label for a environment but
+with an empty prefix, use the empty string \"\" as the CDR of the
+corresponding entry."
   :group 'LaTeX-label
   :type '(repeat (cons (string :tag "Environment")
 		   (choice (string :tag "Label prefix")
@@ -941,10 +948,16 @@ either the prefix or a symbol referring to one."
 
 (make-variable-buffer-local 'LaTeX-label-alist)
 
-(defun LaTeX-label (name type)
+(defun LaTeX-label (name &optional type)
   "Insert a label for NAME at point.
-TYPE can be either environment or section.  If
-`LaTeX-label-function' is a valid function, LaTeX label will
+The optional TYPE argument can be either environment or section:
+in the former case this function looks up `LaTeX-label-alist' to
+choose which prefix to use for the label, in the latter case
+`LaTeX-section-label' will be looked up instead.  If TYPE is nil,
+you will be always prompted for a label, with an empty default
+prefix.
+
+If `LaTeX-label-function' is a valid function, LaTeX label will
 transfer the job to this function."
   (let ((prefix (cond
 		 ((eq type 'environment)
@@ -955,7 +968,9 @@ transfer the job to this function."
 			  LaTeX-section-label
 			(and (listp LaTeX-section-label)
 			 (cdr (assoc name LaTeX-section-label
-		""
+		""))
+		 ((null type)
+		  "")))
 	label)
 (when (symbolp prefix)
   (setq prefix (symbol-value prefix)))
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels)

[Mosè Giordano]

> -""
> +""))
> + ((nullp type)
> +  "")))
 

Sorry, I meant nil instead of ""


2014-11-26 19:45 GMT+01:00 Mosè Giordano :
> 2014-11-26 12:57 GMT+01:00 Uwe Brauer :
>>
>> Hi Mosè
>>> Hi Uwe,
>>> 2014-11-25 18:48 GMT+01:00 Uwe Brauer :
>>
>>> I agree backward compatibility should be preserved as long as possible
>>> (but not at any cost), but about what?  Most users only customize
>>> variables, don't fiddle with functions, if they write some elisp we
>>> hope they're also able to read the doc string of a function and see
>>> which are its arguments, if they've been changed.  But please consider
>>> the first version of a program (nor the second, the third, and so on)
>>> is not perfect, when you develop it you arrive at a point in which you
>>> must choose between keeping it bugged/broken, and fix it and break
>>> compatibility (or fork it).
>>
>> My point is the following: if you improve a function or variable by
>> adding more options it should be done, in my opinion, in way the user
>> has not to change his old settings.
>>
>>> Regarding the change to `LaTeX-label', the whole point of it was to
>>> let users choose to which environments label should be inserted.  The
>>> addition of the second argument was needed to discriminate between
>>> environments and sections as suggested by Vladimir.
>>
>> I don't want to start this discussion again, since  I also use reftex,
>> my labels look typically
>>
>>   \label{rem:fixpoint-scheme:2}
>>
>> Meaning that this  is the second remark in the file called fixpoint-scheme. 
>> For
>> me this is enough I wouldn't need to add more information like the one
>> concerning the section, but I understand there are users with other needs.
>>
>>
>>> Defaulting `prefix' to an empty string when no type is provided (in
>>> order to make this argument optional) would defeat the whole
>>> purpose of the change. Only defaulting `prefix' to nil wouldn't
>>> break old codes using `LateX-label' function, but keeping the
>>> second argument mandatory helps users be aware of the change of the
>>> syntax of `LaTeX-label'.
>>
>> I had a look at the code and it is really a complete rewrite. From my
>> philosophical  point of view, the "appropriate" approach would have been
>> to leave the second argument optionally not mandatory, and a user
>> interested in this enhancement could consult the documentation and not
>> the other way around: that the long-term-user gets an error and presumes
>> a bug.
>>
>> Something like this.
>> (defun LaTeX-label (name &optional type)
>>
>>
>>> Moral: I'm not going to change `LaTeX-label'.
>>
>> Would you accept an (ugly) patch? (Also the changes that I do this any
>> time soon are  unlikely due to my workload and other priorities, such as
>> the xemacs pkg sync.)
>
> See the attached patch: this makes second argument optional but
> doesn't change the spirit of LaTeX-label.
>
> Bye,
> Mosè



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

bug#19199: 11.88; scan-error

[Mosè Giordano]

Hi Uwe,

2014-11-26 19:31 GMT+01:00 Uwe Brauer :
>
> This bug seems more serious

actually to me it seems a duplicate of #19178, you error is triggered
by your `LaTeX-rem-insert' function.  Do you agree?

Bye,
Mosè



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

bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels)

[Mosè Giordano]

2014-11-26 12:57 GMT+01:00 Uwe Brauer :
>
> Hi Mosè
>> Hi Uwe,
>> 2014-11-25 18:48 GMT+01:00 Uwe Brauer :
>
>> I agree backward compatibility should be preserved as long as possible
>> (but not at any cost), but about what?  Most users only customize
>> variables, don't fiddle with functions, if they write some elisp we
>> hope they're also able to read the doc string of a function and see
>> which are its arguments, if they've been changed.  But please consider
>> the first version of a program (nor the second, the third, and so on)
>> is not perfect, when you develop it you arrive at a point in which you
>> must choose between keeping it bugged/broken, and fix it and break
>> compatibility (or fork it).
>
> My point is the following: if you improve a function or variable by
> adding more options it should be done, in my opinion, in way the user
> has not to change his old settings.
>
>> Regarding the change to `LaTeX-label', the whole point of it was to
>> let users choose to which environments label should be inserted.  The
>> addition of the second argument was needed to discriminate between
>> environments and sections as suggested by Vladimir.
>
> I don't want to start this discussion again, since  I also use reftex,
> my labels look typically
>
>   \label{rem:fixpoint-scheme:2}
>
> Meaning that this  is the second remark in the file called fixpoint-scheme. 
> For
> me this is enough I wouldn't need to add more information like the one
> concerning the section, but I understand there are users with other needs.
>
>
>> Defaulting `prefix' to an empty string when no type is provided (in
>> order to make this argument optional) would defeat the whole
>> purpose of the change. Only defaulting `prefix' to nil wouldn't
>> break old codes using `LateX-label' function, but keeping the
>> second argument mandatory helps users be aware of the change of the
>> syntax of `LaTeX-label'.
>
> I had a look at the code and it is really a complete rewrite. From my
> philosophical  point of view, the "appropriate" approach would have been
> to leave the second argument optionally not mandatory, and a user
> interested in this enhancement could consult the documentation and not
> the other way around: that the long-term-user gets an error and presumes
> a bug.
>
> Something like this.
> (defun LaTeX-label (name &optional type)
>
>
>> Moral: I'm not going to change `LaTeX-label'.
>
> Would you accept an (ugly) patch? (Also the changes that I do this any
> time soon are  unlikely due to my workload and other priorities, such as
> the xemacs pkg sync.)

See the attached patch: this makes second argument optional but
doesn't change the spirit of LaTeX-label.

Bye,
Mosè
diff --git a/latex.el b/latex.el
index 80d2761..fa18167 100644
--- a/latex.el
+++ b/latex.el
@@ -941,7 +941,7 @@ either the prefix or a symbol referring to one."
 
 (make-variable-buffer-local 'LaTeX-label-alist)
 
-(defun LaTeX-label (name type)
+(defun LaTeX-label (name &optional type)
   "Insert a label for NAME at point.
 TYPE can be either environment or section.  If
 `LaTeX-label-function' is a valid function, LaTeX label will
@@ -955,7 +955,9 @@ transfer the job to this function."
 			  LaTeX-section-label
 			(and (listp LaTeX-section-label)
 			 (cdr (assoc name LaTeX-section-label
-		""
+		""))
+		 ((nullp type)
+		  "")))
 	label)
 (when (symbolp prefix)
   (setq prefix (symbol-value prefix)))
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels)

[Mosè Giordano]

Hi Uwe,

2014-11-25 18:48 GMT+01:00 Uwe Brauer :
>>> "Mos" == Mos   writes:
>
>> 2014-11-25 15:42 GMT+01:00 Uwe Brauer :
>>> Grrr, this breaks backwards[1] compatibility
>
>> This time I'd call it backward ;-)
>
>>> Couldn't that have been optional?
>
>> Well, perhaps yes and I'll think about making it optional, but you
>> took part into the discussion about this change and didn't object :-)
>
>
> Oops starting Alzheimer? Usually I have the holy principle
>
> Thou shalt not make code which is backward or forward incompatible.
>
> It is even hang over my desk in my office :-D

I agree backward compatibility should be preserved as long as possible
(but not at any cost), but about what?  Most users only customize
variables, don't fiddle with functions, if they write some elisp we
hope they're also able to read the doc string of a function and see
which are its arguments, if they've been changed.  But please consider
the first version of a program (nor the second, the third, and so on)
is not perfect, when you develop it you arrive at a point in which you
must choose between keeping it bugged/broken, and fix it and break
compatibility (or fork it).

Regarding the change to `LaTeX-label', the whole point of it was to
let users choose to which environments label should be inserted.  The
addition of the second argument was needed to discriminate between
environments and sections as suggested by Vladimir.  Defaulting
`prefix' to an empty string when no type is provided (in order to make
this argument optional) would defeat the whole purpose of the change.
Only defaulting `prefix' to nil wouldn't break old codes using
`LateX-label' function, but keeping the second argument mandatory
helps users be aware of the change of the syntax of `LaTeX-label'.
Moral: I'm not going to change `LaTeX-label'.

Bye,
Mosè



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

bug#19178: [no label inserted]

[Mosè Giordano]

2014-11-25 19:06 GMT+01:00 Uwe Brauer :
>
>> 2014-11-25 15:52 GMT+01:00 Uwe Brauer :
>
>> See the documentation for `LaTeX-label-alist'
>> 
> (https://www.gnu.org/software/auctex/manual/auctex.html#index-LaTeX_002dlabel_002dalist)
>
>>  If you want to automatically insert a label for a environment but
>>  with an empty prefix, use the empty string '""' as the cdr of the
>>  corresponding entry.
>
>> so you should add an appropriate entry to that variable, probably
>> '("rem" . "") or so.
>
> Well
>
> (defun LaTeX-rem-insert-old (environment)   ;Version:1.20
>   (if (y-or-n-p
>(format "Do you want a title "))
>   (let ((title (read-input " Title: ")))
> (LaTeX-insert-environment "rem" (concat "[" title "]"))
> (and (LaTeX-label environment '("rem" . ""))
>  (newline-and-indent)))
> (LaTeX-insert-environment "rem")
> (and (LaTeX-label environment '("rem" . ""))
>(newline-and-indent
>
>
>  does not do anything as before, that is no label inserted.

I said to add '("rem" . "") to `LaTeX-label-alist' variable, not to
pass it as second argument of `LaTeX-label'.

Bye,
Mosè



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

bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels)

[Mosè Giordano]

2014-11-25 15:42 GMT+01:00 Uwe Brauer :
> Grrr, this breaks backwards[1] compatibility

This time I'd call it backward ;-)

> Couldn't that have been optional?

Well, perhaps yes and I'll think about making it optional, but you
took part into the discussion about this change and didn't object :-)

Bye,
Mosè



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

bug#19178: [no label inserted] (was: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels)

[Mosè Giordano]

2014-11-25 15:52 GMT+01:00 Uwe Brauer :
>
>> Hi Uwe,
>> 2014-11-25 15:11 GMT+01:00 Uwe Brauer :
>
>> This is not a bug: `LaTeX-label' now has two arguments, the label to
>> be inserted and the type, either environment or section, so you have
>> to replace your call to `LaTeX-label' with
>> (LaTeX-label environment 'environment)
>
>
> This seems not to work. Here is my new setting:
>
> (defun LaTeX-rem-insert (environment)   ;Version:1.20
>   (if (y-or-n-p
>(format "Do you want a title "))
>   (let ((title (read-input " Title: ")))
> (LaTeX-insert-environment "rem" (concat "[" title "]"))
> (and (LaTeX-label environment 'environment)
>  (newline-and-indent)))
> (LaTeX-insert-environment "rem")
> (and (LaTeX-label environment 'environment)
>(newline-and-indent
>
> However the following gets inserted:
>
>
>
> \begin{rem}[Blabla]
>
> \end{rem}
>
>
> That is NO label.

See the documentation for `LaTeX-label-alist'
(https://www.gnu.org/software/auctex/manual/auctex.html#index-LaTeX_002dlabel_002dalist)

 If you want to automatically insert a label for a environment but
 with an empty prefix, use the empty string '""' as the cdr of the
 corresponding entry.

so you should add an appropriate entry to that variable, probably
'("rem" . "") or so.

Bye,
Mosè



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

[Bug-AUCTeX] bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels

[Mosè Giordano]

Hi Uwe,

2014-11-25 15:11 GMT+01:00 Uwe Brauer :
>
>
> Hello
>
> I used for years the following function
>
> (defun LaTeX-rem-insert (environment)   ;Version:1.20
>   (if (y-or-n-p
>(format "Do you want a title "))
>   (let ((title (read-input " Title: ")))
> (LaTeX-insert-environment "rem" (concat "[" title "]"))
> (and (LaTeX-label environment)
>  (newline-and-indent)))
> (LaTeX-insert-environment "rem")
> (and (LaTeX-label environment)
>(newline-and-indent
>
> Which worked till version 11.87, however in 11.88 an error is triggered
> which I attach below.

This is not a bug: `LaTeX-label' now has two arguments, the label to
be inserted and the type, either environment or section, so you have
to replace your call to `LaTeX-label' with
(LaTeX-label environment 'environment)

Bye,
Mosè



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

[Bug-AUCTeX] bug#19121: bug#19121: bug#19121: AUCTeX should report an error if selected viewer fails

[Mosè Giordano]

Hi David,

2014-11-23 13:12 GMT+01:00 David Kastrup :
>> Does someone have other suggestions?
>
> The only alternative I see is not to detach the viewing process (or you
> won't get any information about the process).  You'd want specially
> named process buffers for View/Compile/etc then in order to avoid "a
> compilation is in progress.  Abort?" prompts and so on.  Changing to a
> detached process, IIRC, solved a number of headaches.  It might be
> possible to get rid of most of them in some other way.  However, having
> several viewers into the same document open would then likely not be
> workable.  Also working with source specials and readjusting the
> position, which tends to require another call of the same executable
> without killing the previous one, would likely get into trouble.

Indeed I thought about not discarding the output of the command, but
didn't come up with a simple solution.

In the following days I'll expand and refine my previous patch.

Bye,
Mosè



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

[Bug-AUCTeX] bug#19121: bug#19121: AUCTeX should report an error if selected viewer fails

[Mosè Giordano]

Hi Davide,

2014-11-20 16:07 GMT+01:00 Davide G. M. Salvetti :
> Package: auctex
> Version: 11.83
> Severity: normal
> Usertags: bugs.debian.org/409795
>
> Neither `C-c C-c', nor `C-c C-v', nor `tool-bar view' appear to report
> any error if the viewer selected by `TeX-view-program-selection' isn't
> installed.
>
> It would be useful if AUCTeX would check if the selected viewer is
> installed on the system, falling back to some other viewer if available;
> at a minimum, however, AUCTeX should give some clue to the user about
> the failure to start a viewer.
>
> This bug has been originally reported by a Debian user: see
> , in
> particular items marked `0' and `2' by the original submitter.

The attached patch addresses this problem: it adds a third, optional,
element to `TeX-view-program-list' and
`TeX-view-program-list-builtin', with the name of the executable
associated to that viewer and checks inside `TeX-view-command-raw' if
that executable exists.  I'm not very fond of this solution because it
needs to add another element to a widely customized variable (although
the element is optional, so it won't break backward compatibility),
but I have no other idea to fix it.

Does someone have other suggestions?

Bye,
Mosè
diff --git a/tex.el b/tex.el
index 3b530cb..505ce5c 100644
--- a/tex.el
+++ b/tex.el
@@ -1147,10 +1147,10 @@ the requirements are met."
 	   (paper-letter " -paper us")
 	   (paper-legal " -paper legal")
 	   (paper-executive " -paper 7.25x10.5in")
-	   " %d"))
-  ("dvips and gv" "%(o?)dvips %d -o && gv %f")
-  ("gv" "gv %o")
-  ("xpdf" ("xpdf -remote %s -raise %o" (mode-io-correlate " %(outpage)")))
+	   " %d") "%(o?)xdvi")
+  ("dvips and gv" "%(o?)dvips %d -o && gv %f" ,(list "%(o?)dvips" "gv"))
+  ("gv" "gv %o" "gv")
+  ("xpdf" ("xpdf -remote %s -raise %o" (mode-io-correlate " %(outpage)")) "xpdf")
   ("Evince" ,(if (TeX-evince-dbus-p :forward)
 		 'TeX-evince-sync-view
 		   `("evince" (mode-io-correlate
@@ -1159,9 +1159,9 @@ the requirements are met."
 			   ,(if (string-match "--page-index"
 		  (shell-command-to-string "evince --help"))
 " -i %(outpage)"
-  " -p %(outpage)")) " %o")))
-  ("Okular" ("okular --unique %o" (mode-io-correlate "#src:%n%a")))
-  ("xdg-open" "xdg-open %o"
+  " -p %(outpage)")) " %o")) "evince")
+  ("Okular" ("okular --unique %o" (mode-io-correlate "#src:%n%a")) "okular")
+  ("xdg-open" "xdg-open %o"))) "xdg-open")
   "Alist of built-in viewer specifications.
 This variable should not be changed by the user who can use
 `TeX-view-program-list' to add new viewers or overwrite the
@@ -1319,16 +1319,28 @@ predicates are true, nil otherwise."
 (defun TeX-view-command-raw ()
   "Choose a viewer and return its unexpanded command string."
   (let ((selection TeX-view-program-selection)
-	entry viewer spec command)
+	entry viewer item executable spec command)
 ;; Find the appropriate viewer.
 (while (and (setq entry (pop selection)) (not viewer))
   (when (TeX-view-match-predicate (car entry))
 	(setq viewer (cadr entry
 (unless viewer
   (error "No matching viewer found"))
-;; Get the command line or function spec.
-(setq spec (cadr (assoc viewer (append TeX-view-program-list
-	   TeX-view-program-list-builtin
+(setq item (assoc viewer (append TeX-view-program-list
+ TeX-view-program-list-builtin))
+	  ;; Get the command line or function spec.
+	  spec (cadr item)
+	  ;; Get the name of the executable(s) associated to the viewer.
+	  executable (nth 2 item))
+;; Check the executable exists.
+(unless (or (null executable)
+		(cond ((stringp executable)
+		   (executable-find (TeX-command-expand executable nil)))
+		  ((listp executable)
+		   (dolist (exec executable)
+			 (executable-find (TeX-command-expand exec nil))
+  (error (format "Cannot find %S viewer.  \
+Select another one in `TeX-view-program-selection'" viewer)))
 (cond ((functionp spec)
 	   ;; Converting the function call to a string is ugly, but
 	   ;; the backend currently only supports strings.
@@ -1337,8 +1349,8 @@ predicates are true, nil otherwise."
 	   spec)
 	  ((null spec)
 	   (error
-	(format "Unknown %S viewer. \
-Check the `TeX-view-program-selection' variable." viewer)))
+	(format "Unknown %S viewer.  \
+Check the `TeX-view-program-selection' variable" viewer)))
 	  (t
 	   ;; Build the unexpanded command line.  Pieces with predicates are
 	   ;; only added if the predicate is evaluated positively.
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

Re: [Bug-AUCTeX] 11.88; missing preview-latex.el

[Mosè Giordano]

Hi Chandler,

2014-11-09 21:05 GMT+01:00 Chandler Armstrong :
> I've installed AUCTeX 11.88 via package-list-packages from elpa and entered
> the following in my .emacs:
>
> (load "auctex.el" nil t t)
> (load "preview-latex.el" nil t t)

You must *not* manually load packages installed via package
infrastructure, just remove those lines and you're done.  It's also
explained in the AUCTeX manual.

Bye,
Mosè

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

Re: [Bug-AUCTeX] [RFH] Debian reported upstream bugs

[Mosè Giordano]

Ciao Davide,

2014-11-02 0:08 GMT+01:00 Davide G. M. Salvetti :
> Hello developers,
>
> I would like to ask for your help with Debian reported AUCTeX bugs
> tagged upstream: could you please take a look to the following list and
> help me to sort out bugs that still apply to the current AUCTeX release
> from bugs that have already been fixed or are no more applicable?
>
> 
>

Bugs fixed upstream for sure before 11.88 release are

#695340 TeX-source-correlate-method setting should be improved
with commit 
http://git.savannah.gnu.org/cgit/auctex.git/commit/?id=fc05c8e6a4f72a278f7c70b389331ea4773ccbde

#120031 auctex: Prompts do not inherit input-method
with commit 
http://git.savannah.gnu.org/cgit/auctex.git/commit/?id=6d14dade82c9b8e4f56eb216bcf9761ca6b3fa63
but just a few occurrences of `read-string' have been replaced with
`TeX-read-string'

#767324 Error running timer `font-latex-jit-lock-force-redisplay'
(not tagged upstream) with commit
http://git.savannah.gnu.org/cgit/auctex.git/commit/?id=5b5ef6eeb0468c273a329a05d31b3788fd46b5d7

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; LaTeX-newline doesn't insert newline when comment-auto-fill-only-comments is set

[Mosè Giordano]

Hi Piet,

2014-10-19 19:33 GMT+02:00 Piet van Oostrum :
> Ralf Angeli wrote:
>
>  > * Mosè Giordano (2014-10-19) writes:
>  >
>  > > Thank you.  I've just noticed also insertion of other environments,
>  > > like itemize, gives weird results when
>  > > `comment-auto-fill-only-comments' is non-nil.  Does it make sense to
>  > > let-bind this variable to nil when calling `indent-new-comment-line'
>  > > in the line referenced by Piet?
>  >
>  > Actually I'm a bit surprised that the behavior of
>  > `comment-indent-new-line' is changed in such a way by the value of
>  > `comment-auto-fill-only-comments'.  Especially since the doc string of
>  > `comment-indent-new-line' does not mention anything about it.
>  >
>  > Anyway, setting `comment-auto-fill-only-comments' to nil would work but
>  > might be a bit strange because it does not seem to be directly related
>  > to the behavior of `comment-indent-new-line'. An alternative could be to
>  > call `comment-indent-new-line' only when point is actually in a
>  > comment. But this will mean more code on our side.
>  >
>  > I don't have a clear preference for any solution.  Perhaps let-binding
>  > the variable might currently be the saver alternative.
>  >
>  > --
>  > Ralf
>
> (This is a copy of an earlier message by me that you – Ralf – did not receive 
> directly)
>
> I think I have found another solution. LaTeX-newline should check if it is 
> inside a comment and then call indent-new-comment-line, and if not, call 
> newline.
>
> I propose to replace the
> (t
>  (indent-new-comment-line)))
> with
> ((TeX-in-comment)
>  (indent-new-comment-line))
> (t
>  (newline)))

Ok, I'll apply this change tomorrow, I can't do that right now.

Thank you,
bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; LaTeX-newline doesn't insert newline when comment-auto-fill-only-comments is set

[Mosè Giordano]

Hi Ralf,

2014-10-19 16:19 GMT+02:00 Ralf Angeli :
> * Mosč Giordano (2014-10-18) writes:
>
>> 2014-10-18 10:53 GMT+02:00 Piet van Oostrum :
>>>
>>> The problem can be solved  by changing the last cond part in LaTeX-newline 
>>> from
>>>
>>> (t
>>>  (indent-new-comment-line)))
>>> to
>>> (t
>>>  (newline)))
>>>
>>
>> Thanks for the report!  I can reproduce the bug and your change does
>> indeed fix it, but I'm wondering whether applying it would cause side
>> effects in other places, e.g. dtx files.  Ralf, you wrote this
>> function, what do you think?
>
> The change would indeed defeat the purpose of `LaTeX-newline'.  If
> `LaTeX-insert-into-comments' is t, the function makes sure that
> inserting a line break in a comment will insert a comment starter in the
> new line.  You can test this with the following line in a LaTeX
> document:
>
> % foo-!-
>
> The -!- marks the cursor position.  If you call `LaTeX-newline' here,
> you will get the following result:
>
> % foo
> % -!-
>
> With the proposed change you'd get this:
>
> % foo
> -!-

Thank you.  I've just noticed also insertion of other environments,
like itemize, gives weird results when
`comment-auto-fill-only-comments' is non-nil.  Does it make sense to
let-bind this variable to nil when calling `indent-new-comment-line'
in the line referenced by Piet?

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; LaTeX-newline doesn't insert newline when comment-auto-fill-only-comments is set

[Mosè Giordano]

Hi Piet,

2014-10-18 10:53 GMT+02:00 Piet van Oostrum :
>
> This bug shows up when I start a new document and enter C-e C-e document 
> Iinsert document environment. The document shows up as follows:
>
> \begin{document}
>
> \end{document}
> \documentclass{article}
>
> I.e the documentclass comes at the end. I traced this to LaTeX-newline not 
> inserting newlines, and this only happens when both 
> LaTeX-insert-into-comments and comment-auto-fill-only-comments are TRUE.
> The reason is that LaTeX calls (indent-new-comment-line) even when not in a 
> comment, but indent-new-comment-line doesn't do anything in this case. It 
> says:
>
> ;; If we are not inside a comment and we only auto-fill comments,
> ;; don't do anything (unless no comment syntax is defined).
>
> The problem can be solved  by changing the last cond part in LaTeX-newline 
> from
>
> (t
>  (indent-new-comment-line)))
> to
> (t
>  (newline)))
>

Thanks for the report!  I can reproduce the bug and your change does
indeed fix it, but I'm wondering whether applying it would cause side
effects in other places, e.g. dtx files.  Ralf, you wrote this
function, what do you think?

Bye,
Mosè

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

Re: [Bug-AUCTeX] 2014-07-17; git version does not work with hyperref

[Mosè Giordano]

2014-10-12 19:51 GMT+02:00 Uwe Brauer :
>
>> Hi Uwe,
>> 2014-09-23 14:37 GMT+02:00 Uwe Brauer :
>
>> I can't see the example, maybe you copied the log instead of the
>> source in the body of the email.
>
>
> Oops here it comes

Also in this case I can reproduce the bug with XEmacs but not with GNU
Emacs.  It seems there are some incompatibilities with XEmacs.

Bye,
Mosè

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

Re: [Bug-AUCTeX] preview-1.287; preview seems to scan commented commands

[Mosè Giordano]

Hi Uwe,

2014-10-12 19:12 GMT+02:00 Uwe Brauer :
>
> Remember to cover the basics.  Including a minimal LaTeX example
> file exhibiting the problem might help.
>
> Hello I attach a file which does not generates png for me if I have the
> commented-out text in my file, when I erase these lines everything is
> fine.

I can reproduce the bug with XEmacs but not with GNU Emacs, though I'm
not familiar enough with preview internals to find the culprit by
myself.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 2014-07-17; git version does not work with hyperref

[Mosè Giordano]

Hi Uwe,

2014-09-23 14:37 GMT+02:00 Uwe Brauer :
>
> 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 bug report will be posted to the AUCTeX bug reporting list.
> 
>
> The following minimal example does not work using preview-document.
> The log file is attached. Commenting out they hyperref call makes
> preview-document to work again.

I can't see the example, maybe you copied the log instead of the
source in the body of the email.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; ctrl-C ` not working as it should

[Mosè Giordano]

Hi Kevin,

2014-09-16 8:09 GMT+02:00 Kevin R Vixie :
> It seems that this part of my preamble:
>
> \usepackage[bookmarks=true, % true means bookmarks
> bookmarksnumbered=false, % left window are numbered
> bookmarksopen=false, % true means only level 1 are displayed.
> colorlinks=true,
> linkcolor=red]{hyperref}
>
>
> is causing the problem because when I comment it
> out, the problem goes away. But that is still a bug
> since this has always worked before ...
>
>
> On 09/15/2014 10:59 PM, Kevin R Vixie wrote:
>> ((Sorry about the possible resend -- emacs not configured to
>> send these bug reports properly))
>>
>> --text follows this line--
>>
>>
>> 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 reproducible 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 bug report will be posted to the AUCTeX bug reporting list.
>> 
>>
>> Just upgraded to Trusty from precise and now, when there is even the
>> simplest error in a LaTeX file, and I hit "ctrl-C `" to view it, I get
>> "error occurred after last TeX file closed". I can induce this error
>> by adding a simple misspelling to a correctly written (and
>> correctly compiling) Latex file, like \gamma --> \gammma.

Wow, this is the most asked question of the day on the AUCTeX mailing
lists!  The solution is to call latex with the file line error style,
as explained also in the FAQ of AUCTeX:
http://www.gnu.org/software/auctex/manual/auctex.html#FAQ  You can
accomplish that by adding the following code to your init file:

  (setq LaTeX-command-style
'(("" "%(PDF)%(latex) -file-line-error %S%(PDFout)")))

See also http://tex.stackexchange.com/q/124246/31416  By the way, are
you the Kevin R. Vixie on TeX.stackexchange?  Your question has been
marked as a duplicate of this one.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; Bug in the expansion of %' in TeX-expand-list

[Mosè Giordano]

Hi Nicolas,

2014-08-24 22:01 GMT+02:00 Nicolas Richard :
> Hi Mosè,
>
> Mosè Giordano  writes:
>> Does someone know why this test
>> --8<---cut here---start->8---
>> (require 'ert)
>> (require 'tex-buf)
>>
>> (ert-deftest TeX-command-expansion ()
>>   (should (string=
>>(progn
>>  (add-to-list 'TeX-command-list
>>   (cons "Test" '(" %`%' %t" TeX-run-command t t)))
>>  (TeX-command-expand (nth 1 (assoc "Test" TeX-command-list))
>>  'TeX-master-file))
>>(concat
>> "%%  \"\\input\" " (file-name-nondirectory (buffer-file-name))
>> ".tex"
>> --8<---cut here---end--->8---
>> fails, though the `should' macro returns t?  It seems I need to get
>> familiar with ERT.
>
> Here, it fails with an error:
> F TeX-command-expansion
> (wrong-type-argument stringp nil)
> because when running the test, (buffer-file-name) returns nil.

Right, thank you so much!

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; Bug in the expansion of %' in TeX-expand-list

[Mosè Giordano]

2014-08-24 20:06 GMT+02:00 Mosè Giordano :
>> One can exhibit the problem by putting for instance  before the %'
>> in a TeX-command-list entry. Normally, this sequence should expand to
>> %%. However, because of the bug, it is expanded a second time after %'
>> has been expanded, thus yielding a single %. This is illustrated in the
>> attached file auctex-bugtest.el.
>
> Thank you also for the recipe to reproduce the bug, I'll try to write
> an ERT test for it.

Does someone know why this test
--8<---cut here---start->8---
(require 'ert)
(require 'tex-buf)

(ert-deftest TeX-command-expansion ()
  (should (string=
   (progn
 (add-to-list 'TeX-command-list
  (cons "Test" '(" %`%' %t" TeX-run-command t t)))
 (TeX-command-expand (nth 1 (assoc "Test" TeX-command-list))
 'TeX-master-file))
   (concat
"%%  \"\\input\" " (file-name-nondirectory (buffer-file-name))
".tex"
--8<---cut here---end--->8---
fails, though the `should' macro returns t?  It seems I need to get
familiar with ERT.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; Bug in the expansion of %' in TeX-expand-list

[Mosè Giordano]

Hi Florent,

2014-08-24 16:01 GMT+02:00 Florent Rougon :
> Hello,
>
> Here is a tiny patch for a bug in the expansion of %' in TeX-expand-list
> (tex.el): when it inserts the concatenation of TeX-command-text and
> " \"\\input\"" into the command line being constructed, it does:
>
>   (setq pos (+ (length TeX-command-text) 9))
>
> where 9 is the length of " \"\\input\"". However, this number
> (+ (length TeX-command-text) 9) should be *added to the current value*
> of pos instead of replacing it. The result with the buggy code is that
> TeX-command-expand will start expanding the command line under
> construction again from (+ (length TeX-command-text) 9), which is
> earlier than it should be (and therefore expand things that ought to be
> left as is).

Thank you for the bug report and patch, I've installed it.  This was a
tiny change, but for the future consider assigning the copyright to
the FSF, so you'll be able to provide much longer patches ;-)  In
addition, a ChangeLog entry for the possible future patches would be
really useful.

> One can exhibit the problem by putting for instance  before the %'
> in a TeX-command-list entry. Normally, this sequence should expand to
> %%. However, because of the bug, it is expanded a second time after %'
> has been expanded, thus yielding a single %. This is illustrated in the
> attached file auctex-bugtest.el.

Thank you also for the recipe to reproduce the bug, I'll try to write
an ERT test for it.

Bye,
Mosè

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

Re: [Bug-AUCTeX] Fontification error?

[Mosè Giordano]

Hi Jobst,

2014-08-16 20:00 GMT+02:00 Hoffmann, Jobst :
> Hi,
>
> after entering the command
>
> emacs --no-splash --no-init-file --no-site-file
> --load /usr/share/emacs/site-lisp/tex-site.el fancyvrb_tst.tex
>
> and filling the buffer with
>
> --%<
> \documentclass{article}
>
> \usepackage{fancyvrb}
>
> \begin{document}
>
> \begin{VerbatimOut}{f.txt}
> \begin{itemize}
> \item blabla
> \end{itemize}
> \end{VerbatimOut}
>
> \begin{itemize}
> \item blabla
> \end{itemize}
>
> \begin{VerbatimOut}{g.txt}
> \begin{itemize}
> \item blabla
> \end{itemize}
> \end{VerbatimOut}
>
> \begin{itemize} (but how to cope with
> \item blabla
> \end{itemize}
>
> \end{document}
> --%<
> the fontification fails as shown in the attached .png-file.

Thanks for your bug report.

> Am I doing something wrong? If not is there a simpler remedy than
> entering an empty VerbatimOut-environment?

No, you aren't doing anything wrong, it's just AUCTeX unable to treat
verbatim environment with a mandatory argument.  We already fixed a
similar issue for an optional argument, see commit
* 32fc9b Fix fontification of optional argument to verbatim environments.
(http://git.savannah.gnu.org/cgit/auctex.git/commit/?id=32fc9bd6eab8c3eff29d6b16b51859d445c12fbf)
 Probably we need a similar patch.  Now I don't have enough time to
address this bug, but if someone wants to look at this, please go
ahead :-)

Bye,
Mosè

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

Re: [Bug-AUCTeX] 2014-02-10; \intertext-macro not properly indented inside align-environments

[Mosè Giordano]

Hi Simon,

2014-08-14 7:39 GMT+02:00 Simon Campese :
> Hello,
>
> I just recognized that when typing mathematics inside align or align*
> environments (which are provided by the amsmath package), \intertext
> macros are not recognized as being typeset on a new line by auctex. For 
> example,
> autoindenting the code
>
> \begin{align*}
> F_1 &= 1 \\
> F_2 &= 2
> \intertext{and}
> F_{n+1} &= (n+1) F_n
> \end{align*}
>
> yields
>
> \begin{align*}
>   F_1 &= 1 \\
>   F_2 &= 2
> \intertext{and}
> F_{n+1} &= (n+1) F_n
> \end{align*}
>
> instead of
>
> \begin{align*}
>   F_1 &= 1 \\
>   F_2 &= 2
>   \intertext{and}
>   F_{n+1} &= (n+1) F_n
> \end{align*}
>
> Unfortunately I don't know enough Elisp to fix this myself but I guess
> that the parser just checks for '\\' to recognize a new line and a
> simple cases statement including '\intertext' has to be added.
> And while you're at it, I guess the same is true for '\shortintertext'
> from the mathtools package.

From the amsmath user's guide:

\intertext may only appear right after a \\ or \\* command.

If you insert a \\ before the \intertext command AUCTeX is able to
correctly align the & separators and the problem goes away.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; TeX-add-to-list?

[Mosè Giordano]

Hi Uwe,

2014-07-24 12:51 GMT+02:00 Uwe Brauer :
>
>> Hi Uwe,
>> 2014-07-23 17:41 GMT+02:00 Uwe Brauer :
>
>> This question is getting so frequent to be probably worth an own entry
>> in the FAQs.  The function `TeX-add-to-alist' has been introduced in
>> git version and is called in parsed files.  The solution is simply to
>> reparse the file with C-C C-n.
>
>
> Oops I am sorry I forgot to add something very important: I cannot open
> the file I just see the error message but the files is closed. So this
> bug is more serious for me (and for other Xemacs users?). I had to
> delete the file found in the auto directory.

The problem is only for people using, under AUCTeX <= 11.87, file
parsed by the git version.  You are switching back and forth between
these two versions, and this is definitely not a common case.  It
isn't true you cannot open the file, it's only the buffer which is not
displayed, but the buffer is there, you only need to switch to the TeX
buffer and reparse the file.

>> Another possibility could be to define the function if it's unbound,
>> but I'd like to avoid filling the parsed file with such checks.
>> Anyway, parsed file produced by AUCTeX 11.87 and git version are
>> slightly incompatible, and this is stated in the news for future 11.88
>> release, so a reparse is always needed anyway.
>
>
> What puzzles me is all this happened under the *git* version of auctex!
> And we are back to the question of backward/forward compatibility. What
> is the advantage of this new function?

Much better management of package options.  Until 11.87, they were
mixed up with packages and it was impossible to determine which
package loaded a specific option.

The incompatibility you mention (always forward) is temporary, a
reparse, triggered by saving the file with an appropriate option,
would make it go away.  In addition, parsed file should not be shared
among collaborators, so people working on the same document and using
different AUCTeX versions should not be affected.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; TeX-add-to-list?

[Mosè Giordano]

Hi Uwe,

2014-07-23 17:41 GMT+02:00 Uwe Brauer :
>
>
>
> Hello
>
> When entering a recent created file I receive an error I never seen
> before and which I attach. I can create new files though!

This question is getting so frequent to be probably worth an own entry
in the FAQs.  The function `TeX-add-to-alist' has been introduced in
git version and is called in parsed files.  The solution is simply to
reparse the file with C-C C-n.

Another possibility could be to define the function if it's unbound,
but I'd like to avoid filling the parsed file with such checks.
Anyway, parsed file produced by AUCTeX 11.87 and git version are
slightly incompatible, and this is stated in the news for future 11.88
release, so a reparse is always needed anyway.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; Tikz and Maketitle problem

[Mosè Giordano]

Hi Tassilo,

2014-06-25 23:18 GMT+02:00 Tassilo Horn :
> I'll do that when I find some spare time after my move which might take
> another week or two.  Mosè, if you want, you can also do it whenever you
> want.

Ok, I can help, just let me now what I've to do :-)

Bye,
Mosè

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

Re: [Bug-AUCTeX] 11.87; documentation preview-latex

[Mosè Giordano]

Hi Tak,

2014-06-06 11:37 GMT+02:00 Tak Kunihiro :
> I installed auctex-11.87.5 via ELPA and noticed that a line suggested on
> "auctex-readme.txt" yields error.
> (load "preview-latex.el" nil t t)
>
> My system cannot find "preview-latex.el".  I deleted the line and now it
> works.  I wonder the line should be something like following.
> (load "preview.el" nil t t)
>
> Emacs  : GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
> Package: 11.87.5

when you install a package with the Emacs built-in package manager you
don't need to load it manually with a `load' function.

Bye,
Mosè

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

Re: [Bug-AUCTeX] [SOLVED] recursive require

[Mosè Giordano]

Hi Salome,

2014-05-28 9:52 GMT+02:00 g...@scheiberspace.ch :
> I do not insist on it, I'd rather not use it if I don't need to. But with an
> empty '.emacs' or emacs -q, AUCTeX seems not to be loaded here. Or maybe it
> is but something else is missing? How can I know if AUCTeX is loaded?
> When I start with an empty '.emacs' and then open a tex-file, I have "TeX"
> in the menu bar but not "LaTeX" (as I used to). Commands as C-c C-s do not
> what I'd expect them to do.

What exactly does C-c C-s in your case?  In the menu bar is there only
"TeX" or also "Command"?  In the former case you're using the TeX mode
bundled with Emacs, in the latter case you're using AUCTeX but with
plain-tex-mode and that would explain why C-c C-s doesn't work (it's
defined only in AUCTeX latex-mode).

You can see whether AUCTeX has been enabled in a TeX/LaTeX file if the
"TeX" or "LaTeX" menu contains references to AUCTeX.

Bye,
Mosè

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

Re: [Bug-AUCTeX] [SOLVED] recursive require

[Mosè Giordano]

Hi Salome,

2014-05-26 11:30 GMT+02:00 Salome =?iso-8859-1?Q?S=F6dergran
:
> With this minimal init-file everything works fine:
>
>(setq debug-on-error t)
>(add-to-list 'load-path "~/.emacs.d/elpa/auctex-11.87.5")
>(require 'tex-site)
>(require 'package)
>(package-initialize)
>
> Both the auctex-path and require are needed before the package-functions.
> What would I have to change to make AUCTeX work without (require 'tex-site)?

An empty or non-existing `.emacs' works  for me (i.e., AUCTeX is
automatically loaded by the package manager), I can't understand why
you insist on requiring `tex-site'.

Bye,
Mosè

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

Re: [Bug-AUCTeX] [SOLVED] recursive require

[Mosè Giordano]

Hi Salome,

2014-05-24 16:06 GMT+02:00 Salome =?iso-8859-1?Q?S=F6dergran
:
> With lots of try-and-error I managed to solve my problem with:
>>  Error: (error "Recursive `require' for feature `tex-site'")
> .
> I think the two decisive things were the following:
>
> 1st, adding the auctex-path explicitly to the load path:
>   (add-to-list 'load-path "~/.emacs.d/elpa/auctex-11.87.5")
>
>   2nd, putting (require 'tex-site) in the right place, e.g. /before/
>   (require 'package)
>   (package-initialize)
>
> Everything's up and running again :-)
> Salome

if you install a package using the Emacs package manager you don't
need to load it using a `require'.

Bye,
Mosè

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

Re: [Bug-AUCTeX] 2014-04-16; (extraopts) difficulties

[Mosè Giordano]

Hi Tassilo,

2014-04-25 7:47 GMT+02:00 Tassilo Horn :
> Mosè Giordano  writes:
>
>> The problem should be
>>  (add-to-list 'TeX-expand-list
>
> No, I think the problem is
>
>   '(TeX-expand-list (quote (("%(dir)" (lambda nil default-directory))
>...)))
>
> in his custom-variables-section.  That's a modified old version of the
> variable which doesn't contain an expander for %(extraopts).
>
> I'd suggest you remove that there.  If you need to modify some entries
> of it, it's better to add a new entry in front of it using `add-to-list'
> as you do above.  Then you are not excluded when new entries are added
> by us.

After a more careful test I think you're right!

Bye,
Mosè

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

Re: [Bug-AUCTeX] 2014-04-16; (extraopts) difficulties

[Mosè Giordano]

Hi Benjamin,

2014-04-24 21:05 GMT+02:00 Benjamin Slade :
> (possibly relevant things) from my .emacs:
>
> [...]

The problem should be
--8<---cut here---start->8---
 (add-to-list 'TeX-expand-list
  '("%(-PDF)"
(lambda ()
  (cond ((string-match "TeX-engine: pdftex"
(buffer-string)) "-pdf")
((string-match "TeX-engine: luatex"
(buffer-string)) "-pdflatex=lualatex -pdf")
((string-match "TeX-engine: xetex"
(buffer-string)) "-pdflatex=xelatex -pdf")
(t "-dvi -pdfps")
--8<---cut here---end--->8---
in the `eval-after-load'.  I don't have enough time to understand why
this triggers that bug, but if you think you actually don't need that
snippet of code just remove, or comment, it.

By the way, with git version of AUCTeX you don't need anymore special
tricks to make Okular forward/inverse search work ;-)

Bye,
Mosè

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

Re: [Bug-AUCTeX] 2014-04-16; (extraopts) difficulties

[Mosè Giordano]

2014-04-23 22:02 GMT+02:00 Benjamin Slade :
> (setq
>  [...]
>  TeX-command-list '(("Latexmk" "latexmk %(-PDF) -synctex=1 %s" TeX-run-TeX 
> nil t :help
>  "Run Latexmk on file to build everything.")
> ("Make" "Makefile" TeX-run-command nil t)
> ("TeX" "%(PDF)%(tex) %`%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")
> ("Makeinfo" "makeinfo %t" TeX-run-compile nil 
> (texinfo-mode) :help
>  "Run Makeinfo with Info output")
> ("Makeinfo HTML" "makeinfo --html %t" TeX-run-compile nil 
> (texinfo-mode) :help
>  "Run Makeinfo with HTML output")
> ("AmSTeX" "%(PDF)amstex %`%S%(PDFout)%(mode)%' %t" 
> TeX-run-TeX nil
>  (ams-tex-mode) :help "Run AMSTeX")
> ("ConTeXt" "texexec --once --texutil %(execopts)%t" 
> TeX-run-TeX nil
>  (context-mode) :help "Run ConTeXt once")
> ("ConTeXt Full" "texexec %(execopts)%t" TeX-run-TeX nil 
> (context-mode) :help
>  "Run ConTeXt until completion")
> ("BibTeX" "bibtex %s" TeX-run-BibTeX nil t :help "Run 
> BibTeX")
> ("View" "%V" TeX-run-discard-or-function t t :help "Run 
> Viewer")
> ("Print" "%p" TeX-run-command t t :help "Print the file")
> ("Queue" "%q" TeX-run-background nil t :help "View the 
> printer queue" :visible
>  TeX-queue-command)
> ("File" "%(o?)dvips %d -o %f " TeX-run-command t t :help
>  "Generate PostScript file")
> ("Index" "makeindex %s" TeX-run-command nil t :help 
> "Create index file")
> ("Check" "lacheck %s" TeX-run-compile nil (latex-mode) 
> :help
>  "Check LaTeX file for correctness")
> ("Spell" "(TeX-ispell-document \"\")" TeX-run-function 
> nil t :help
>  "Spell-check the document")
> ("Clean" "TeX-clean" TeX-run-function nil t :help
>  "Delete generated intermediate files")
> ("Clean All" "(TeX-clean t)" TeX-run-function nil t :help
>  "Delete generated intermediate and output files")
> ("Other" "" TeX-run-command t t :help "Run an arbitrary 
> command"))
>  )

That's strange: the default "TeX" command string is
"%(PDF)%(tex) %(extraopts) %`%S%(PDFout)%(mode)%' %t"
instead you have
"%(PDF)%(tex) %`%S%(PDFout)%(mode)%' %t"
How come the "%(extraopts)" appears in your command?  Did Tassilo
guess right saying you fiddled with `TeX-expand-list'?

Bye,
Mosè

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

Re: [Bug-AUCTeX] Minor documentation compile bug

[Mosè Giordano]

Hi Russel,

2014-03-05 23:08 GMT+01:00 Russell Sim :
> Hey,
>
> I have noticed that when running AUCTeX from git I get an error while
> compiling the info files.  From what I can see it's caused by some
> missing braces.
>

My `makeinfo' version (5.2) doesn't complain about that missing pair
of braces, anyway I'm going to fix it, thank you!

Bye,
Mosè

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