RE: Wrong type argument: symbolp, when inserting equation reftex-label

[JOSE MARIA MARTIN OLALLA]

Yes, you got it right. The current Debian 12 released 2023 is shipping AUCTeX 
12.2.

I removed the apt-installed AUCTeX and did the package-install stuff.

It worked like charm.

Many many thanks.

I must add I have been an Emacs-AUCTeX user since the 2000s or so. I love 
acknowledging the terrific contribution that free software do in the studies I 
got published.
Sometimes these acknowledgements get published[1].
I take this opportunity to thank you all again.

[1]https://www.nature.com/articles/s41598-019-43220-8#Ack1
[https://media.springernature.com/m685/springer-static/image/art%3A10.1038%2Fs41598-019-43220-8/MediaObjects/41598_2019_43220_Fig1_HTML.png]
Seasonal synchronization of sleep timing in industrial and pre-industrial 
societies - Scientific 
Reports
www.nature.com





José María Martín Olalla

+34-9545-56075

https://orcid.org/-0002-3750-9113

Universidad de Sevilla


De: Arash Esbati 
Enviado: martes, 14 de noviembre de 2023 21:42
Para: JOSE MARIA MARTIN OLALLA 
Cc: auctex@gnu.org 
Asunto: Re: Wrong type argument: symbolp, when inserting equation reftex-label

Jose Maria Martin Olalla  writes:

> Many thanks Arash,
>
> AUCTeX version is 12.2
>
> AUCTeX, emacs and the whole texmf were installed via apt install

Thanks for the clarification.  Do I get it right that the current Debian
12 (released this year) is shipping a 4 years old version of AUCTeX[1]?

> I evaluated the code in scratch, or I think so: M+: and the code, no
> line breaks. The minibuffer returned nil.

Yes, this is then expected since you didn't install AUCTeX from ELPA.
My suggestion presumed that.  You have 2 choices now:

  • Activate AUCTeX the way you do it from your init file after 'emacs
-Q' (I have no idea how one is supposed to do it on Debian)

  • You uninstall AUCTeX via apt and install it from ELPA as described
here[2].  Then you can try the instruction I sent.

> I opened a *.tex file with a TeX-master in local variables. However
> the full AUCTeX bundle for LaTeX files was not available in the major
> mode. Instead, the default TeX environment that is loaded with 'emacs
> -Q filename.tex' was available. As if the eval code did not activate
> AUCTeX actually. As a result C-c C-e did not launch an environment.

Yes, this is then expected.  What you did doesn't match your AUCTeX
installation.

Best, Arash

Footnotes:
[1]  https://lists.gnu.org/archive/html/info-auctex/2019-10/msg1.html

[2]  
https://www.gnu.org/software/auctex/manual/auctex/Installation.html#Installation

Synctex and auctex: request for help

[Rahguzar]

Hi,
I have been looking to improve the synctex experience with `pdf-tools`
and `auctex` especially with my preferred way of writing every paragraph
on one line and using `visual-line-mode` for reflowing the text. Fixing
backward search turned out not to be too difficult see
https://github.com/vedang/pdf-tools/issues/242 but it seems like making
forward text search more accurate is harder.

Basically the situation seems to be that although synctex is
theoretically capable to providing an accurate column number, it needs
tex engines to provide this information which none of them do. So it
only provides line level information. However a given source line can
correspond to multiple lines in pdf (and vice versa) and I in that case
synctex provides multiple results about the query asking editors to
somehow chose the best one.

However `pdf-tools` only gives access to first result of synctex forward
search. I don't know `c` but I think that is happening here,
https://github.com/vedang/pdf-tools/blob/c69e7656a4678fe25afbd29f3503dd19ee7f9896/server/epdfinfo.c#L3188C21-L3188C21
This seems to correspond to only to a single or occasionally two pdf
lines corresponding to the same source line but not all of the lines. Is
someone who knows `c` and wants better forward search willing to either:

1) Change `cmd_synctex_forward_search` in `epdfinfo.c` so that it
returns the edges corresponding to the bounding box of the whole region
of pdf corresponding to the source line? My guess is (I am not sure)
that this would simply be the union of all the rectangles in individual
search results. Some care would be need when the paragraph get split
across pages.

2) Probably easier and backward compatible. Add a new function to
`epdfinfo.c` that returns the whole list of search results and expose
that to lisp so that the region can be determined from lisp.

With this change in `c` code, I think I can use techniques similar to
those used for backward search and those in `pdf-isearch` for
highlighting to get word level accuracy. But without a good bound on the
pdf region to search, it is hard to get good enough performance.

I have also posted the same message on pdf-tools repo:
https://github.com/vedang/pdf-tools/issues/244

Thanks,
Rahguzar