going on with top posting ...
Le 01/03/2016 20:55, Vincent Belaïche a écrit :
> Ok I see. I made some test, and character ÷ (obélus in French) is invisible in verbatim without any preparation provided that you are using OT1 font encoding. See:
>
> \documentclass{minimal}
> \usepackage[OT1]{fontenc}
I can not use OT1 in my document ;-).
> \begin{document}
> \verb+\÷documentclass+
> \end{document}
>
>
> Well, it would be nice if there was some character different from \
> btu for which font encoding generate the same glyph as \, then you
> could use this character in the verbatim in place of \, in order to
> foul the AUCTeX parser...
Actually verbatim sanitizes very few characters. In particular all
characters in the 128-255 range (if 8bit input encoding) or UTF-8
characters remain active and expand (naturally) to the correct slot
of the T1 fonts (not going into Unicode engines for simplicity here).
Hence one only needs to modify the definition of one such character
not elsewhere used. For example your obelus ÷ expands to \textdiv.
With \def\textdiv{\textbackslash} the trick is done.
I need to be able to copy paste from my document to
test the code snippets. It is easier for me to say to ignore
some character like ¡ rather than redefine some other character like ÷.
>
> One more idea to fool the parser : place all the verbatim stuff into
> a separate file and load it with verbatim input
> (http://www.tex.ac.uk/FAQ-verbfile.html).
In matters of verbatim, I prefer to handle it all myself ;-)
You could also place the
> verbatim stuff into some file my-stuff.tex, then process it by some
> script that verbatimize all the special characters (e.g. replace \ by
> \textbackslash) into some other file my-stuff-verb.tex, and then
> \input my-stuff-verb.tex (you would need a Makefile to do that).
This is not an option, because the file must be a stand-alone dtx file
that people can compile via tex foo.dtx or the like. Actually the
dtx self-extracts some files, not the opposite.
Not to say that this is no good work-flow, as on a bigger package
I have now split the source, and the dtx is build via make prior
to CTAN upload. Hence in this case definitely the things confusing
the AUCTeX parser could be relegated to auxiliary files I would
rarely have to deal with. In the case of the original dtx this
thread was started with, it was not big enough for me into going
into that approach.
The bigger dtx was becoming truly big, and AUCTeX parsing generally
speaking was starting to cause me problems ; I resisted the idea
of splitting a long time because I enjoyed search/replace for macro
names in one unique file ; I now have to do a bit more working
with multiple files. But loading is faster and I can use either
latex mode or doctex mode depending on which sub-file I am working on.
Actually, with the bigger dtx a Makefile triggers some scripts
which builds up the dtx suitable for CTAN, and strips it from
private comments during the build. My efficiency is much impeded
when I can't write insults in comments, but obviously when you
end up publishing your work on CTAN you have to be a bit careful.
Thanks to your obelus ÷ I now enjoy my private comments and feel
liberated.
>
> Not sure whether this was already said during the discussion, for
> your information you can disable automatic parse (info "(auctex)
> Parsing Files") by setting to nil TeX-parse-self and TeX-auto-save in
> file local way, so some local AUCTeX patch only on your machine would
> be not too annoying --- it is acceptable to wait for the 3s once and
> for all, or every time you press C-c C-n, the problem is waiting so
> much on C-x C-s.
Now that I have the ¡ inserted, I do not feel like I need to do these
things.
>
> One more idea on the AUCTeX front is as follows: the (verbatim-p) in
> Mosè's patch could be made conditional on some new variable
> TeX-parse-strict-p defaulting to nil, so the patch would (edited by
> hand from Mosè's patch, not tested) :>
> --- a/tex.el
> +++ b/tex.el
> @@ -4065,7 +4065,8 @@ you should not use something like `[\\(]' for a
> character range."
> (match-beginning (car b))))))
> (symbol (nth 2 entry))
> (match (nth 1 entry)))
> - (unless (TeX-in-comment)
> + (unless (or (TeX-in-comment)
> + (and TeX-parse-strict-p (TeX-verbatim-p)))
> (looking-at (nth 0 entry))
> (if (fboundp symbol)
> (funcall symbol match)
> So you would just make file-locally TeX-parse-strict-p true, and both TeX-auto-save TeX-parse-self false.
>
If only I at last learned e-Lisp some day...
> One more idea is the following : my speculation is that AUCTeX is
> slow because when you do (verbatim-p) or something like that in the
> code patch you will regexp search backward and forward, so if S is
> the size of the file to scan, you need to scan over potentially S^2
> characters instead of S because of the secondary search. Maybe it
> would be possible to make the code more efficient by scanning for
> \begin and \end commands at the same time as \documentclass and
> \usepackage, placing the search result into some variable and then
> using the search results to make it all.>
not competent to comment ;-)
> Vincent.
thanks,
Jean-François
>
> ----------------------------------------
>> Subject: Re: [AUCTeX] overlay prompting
>> From: ***@free.fr
>> Date: Tue, 1 Mar 2016 08:10:20 +0100
>> CC: ***@gnu.org
>> To: ***@hotmail.fr
>>
>> Bonjour Vincent
>>
>> let's take a risk and reply without testing either ;-)
>>
>> I trust the \^^64ocumentclass will fool the AUCTeX parser (it should ;-) )
>> but the problem is that within a verbatim the ^ is sanitized to catcode 12.
>> Thus the latex run will actually print verbatim ^^64.
>>
>> The ^^ input form needs ^ to be of catcode 7.
>>
>> It actually works with any catcode 7 character (I used this in the source
>> of a package). For example && if you do \catcode`& 7.
>>
>> But & is also sanitized by verbatim:
>>
>> ~$ latexdef dospecials
>>
>> \dospecials:
>> macro:->\do \ \do \\\do \{\do \}\do \$\do \&\do \#\do \^\do \_\do \%\do \~
>>
>> and besides, I may need it to naturally for tabulars.
>>
>> Thus this approach would need at least the same amount of preparation
>> as the technique of \doc¡umentclass which I adopted near the end of the
>> thread (which works using \catcode`\¡ 9 ).
>>
>> Best, Jean-François
>>
>> Le 29 févr. 2016 à 23:38, Vincent Belaïche <***@hotmail.fr> a écrit :
>>
>>> Salut Jean-François,
>>>
>>> Not tested idea :
>>>
>>> Can't you fool the parser by writing \^^64ocumentclass instead of \documentclass when you are inside the verbatim env.
>>>
>>> I guess that the ^^64 is parsed by TeX input processor, so it is not sensitive to verbatim catcodification. Am I wrong ?
>>>
>>> Vincent.
>>>
>>> ----------------------------------------
>>>> To: ***@gnu.org
>>>> From: ***@free.fr
>>>> Date: Mon, 25 Jan 2016 22:45:40 +0100
>>>> Subject: Re: [AUCTeX] overlay prompting
>>>>
>>>> Hi Mosè,
>>>>
>>>> Le 25/01/2016 21:21, Mosè Giordano a écrit :
>>>>> Hi Jean-François,
>>>>>
>>>>> 2016-01-25 10:08 GMT+01:00 jfbu <***@free.fr>:
>>>>>> My document has other AUCTeX-parsing related problems. For example
>>>>>>
>>>>>> \begin{verbatim}
>>>>>> \usepackage{fontspec}
>>>>>> \end{verbatim}
>>>>>>
>>>>>> similarly triggers AUCTeX to prompt me for xetex/luatex compilation.
>>>>>> This made the workflow a bit painful, but I forgot about it last time
>>>>>> as I was doing latex runs via a Makefile.
>>>>>
>>>>> (setq TeX-check-engine nil)
>>>>>
>>>>> makes the warning go away.
>>>>
>>>> ah yes, actually you already told me so in the fontspec thread,
>>>> thanks for reminding me
>>>>
>>>>>
>>>>>> Also, perhaps commands like \setmainfont also make AUCTeX's parser react,
>>>>>> or is it only \documentclass and \usepackage ?
>>>>>
>>>>> \setmainfont isn't parsed.
>>>>
>>>> ok, then perhaps I will do the ¡ trick after all.
>>>>
>>>> Rather than \let¡\empty, I could also simply do \catcode`\¡ 9
>>>> to tell TeX/LaTeX to ignore it rather than have it be active
>>>> (which it is via \usepackage[latin1]{inputenc}) with an empty
>>>> expansion
>>>>
>>>> best regards,
>>>>
>>>> Jean-François
>>>>
>>>>
>>>> _______________________________________________
>>>> auctex mailing list
>>>> ***@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/auctex
>>>
>>
>
>