GNU bug report logs -
#25309
11.89.8; multi-level script fontification stacks incorrectly
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25309 in the body.
You can then email your comments to 25309 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sat, 31 Dec 2016 14:14:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gennady Uraltsev <gennady.uraltsev <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-auctex <at> gnu.org.
(Sat, 31 Dec 2016 14:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I have discovered multi-level fontification of sub and superscripts. It
is a great idea. I used to use magic-latex-buffer previously to
accomplish the same.
However it seems slightly broken. While the scaling of the text defined
in the face stacks correctly the displacement doesn't!
It gets calculated from the base line. This means that if I write
$x_{y_{z}}$ with multi-line mode then $z$ is not any lower than y.
Similarly in the case $x^{y^{z}}$ z is not higher than y.
In both cases they are only scaled smaller, but this is only because the
height is controlled by a different parameter in a different way.
Another moment when this incorrect behavior is evident is if one writes
$x^y_z$. In this case z is MUCH higher than y because it is actually
displaced w.r.t the level of x and not y. Similarly for $x_y^z$.
Thanks for your time and patience! I really appreciate the fantastic
piece of software you wrote. I have tried many LaTeX editors and AucTeX
is by far the best way to write.
I am attaching a minimal .tex example file and a screenshot.
------------------------------------------------------------------------
Emacs : GNU Emacs 25.1.1 (x86_64-suse-linux-gnu, GTK+ Version 3.20.9)
of 2016-12-22
Package: 11.89.8
current state:
==============
(setq
AUCTeX-date "2016-12-22"
window-system 'x
LaTeX-version "2e"
TeX-style-path '("~/.emacs.d/auctex"
"/home/guraltsev/.emacs.d/elpa/auctex-11.89.8/style"
"/home/guraltsev/.emacs.d/auctex/auto"
"/home/guraltsev/.emacs.d/auctex/style" "auto" "style")
TeX-auto-save nil
TeX-parse-self nil
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" "%(cntxcom) --once --texutil %(extraopts)
%(execopts)%t" TeX-run-TeX nil (context-mode) :help
"Run ConTeXt once")
("ConTeXt Full" "%(cntxcom) %(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")
("Dvipdfmx" "dvipdfmx %d" TeX-run-dvipdfmx nil t :help "Convert
DVI file to PDF with dvipdfmx")
("Ps2pdf" "ps2pdf %f" TeX-run-ps2pdf nil t :help "Convert
PostScript file to PDF")
("Index" "makeindex %s" TeX-run-index nil t :help "Run makeindex
to 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 output files")
("Other" "" TeX-run-command t t :help "Run an arbitrary command"))
)
[Screenshot_20161231_170328.png (image/png, attachment)]
[scripts.tex (text/x-tex, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sat, 31 Dec 2016 14:49:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Hi Gennady,
2016-12-31 15:12 GMT+01:00 Gennady Uraltsev <gennady.uraltsev <at> gmail.com>:
> Hello,
>
> I have discovered multi-level fontification of sub and superscripts.
Honestly, I didn't even know this feature!
> However it seems slightly broken. While the scaling of the text defined
> in the face stacks correctly the displacement doesn't!
Regarding this problem and the other ones you reported earlier, I
don't think I'll have the time to fix them, but patches are always
welcome ;-)
> Thanks for your time and patience! I really appreciate the fantastic
> piece of software you wrote. I have tried many LaTeX editors and AucTeX
> is by far the best way to write.
I'm just one of the many AUCTeX developers, but I'm sure we're all
always glad to read such nice comments!
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sat, 31 Dec 2016 14:58:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I use Emacs a lot but I am not very familiar with coding. During this
winter break I tried to look through the code base a bit to learn.
The multi-level fontification was introduced by
Tassilo Horn with commit 513490f on 2015-09-03.
I'll see if I manage to write a patch. The most challenging of the bugs
seems to be the one about the background of preview-latex and the
opacity of tikzpictures. It probably is a bug with pgf/tikz.
Cheers for a Happy New Year!
Gennady
On 31/12/16 17:47, Mosè Giordano wrote:
> Hi Gennady,
>
> 2016-12-31 15:12 GMT+01:00 Gennady Uraltsev <gennady.uraltsev <at> gmail.com>:
>> Hello,
>>
>> I have discovered multi-level fontification of sub and superscripts.
>
> Honestly, I didn't even know this feature!
>
>> However it seems slightly broken. While the scaling of the text defined
>> in the face stacks correctly the displacement doesn't!
>
> Regarding this problem and the other ones you reported earlier, I
> don't think I'll have the time to fix them, but patches are always
> welcome ;-)
>
>> Thanks for your time and patience! I really appreciate the fantastic
>> piece of software you wrote. I have tried many LaTeX editors and AucTeX
>> is by far the best way to write.
>
> I'm just one of the many AUCTeX developers, but I'm sure we're all
> always glad to read such nice comments!
>
> Bye,
> Mosè
>
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sat, 31 Dec 2016 15:03:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 25309 <at> debbugs.gnu.org (full text, mbox):
2016-12-31 15:57 GMT+01:00 Gennady Uraltsev <gennady.uraltsev <at> gmail.com>:
> Hello,
>
> I use Emacs a lot but I am not very familiar with coding. During this
> winter break I tried to look through the code base a bit to learn.
>
> The multi-level fontification was introduced by
> Tassilo Horn with commit 513490f on 2015-09-03.
Wow, I didn't even remember such change! My memory is failing :-(
Tassilo, when/if you have time (I don't want to break your holidays ;-),
could you please give a look at this?
Thank you,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 09:39:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Gennady, Uwe & Mosè,
[CC'ing Uwe because I know he uses this feature.]
>> The multi-level fontification was introduced by
>> Tassilo Horn with commit 513490f on 2015-09-03.
>
> Wow, I didn't even remember such change! My memory is failing :-(
>
> Tassilo, when/if you have time (I don't want to break your holidays
> ;-), could you please give a look at this?
I just had a look and Gennady is correct in that there is an issue here
although what I get is a bit different from his observations.
With `font-latex-fontify-script' set to 'multi-level or 'invisible, what
I expect in $a^b^c$ is that the b is raised above a and a bit smaller,
and c is raised above b and again a bit smaller. What I actually see is
that b is raised above a and a bit smaller but c is raised to the very
same height as b and has b's size.
Sadly, I have no clue why that's the case. The code worked as intended
when I wrote it and there haven't been any changes to it AFAICS. Maybe
something is Emacs changed? I've tried Emacs 25.1 and master with the
same results.
Does anyone of you have an older Emacs copy (22.x, 23.x, 24.x) installed
and can check what the results are with that?
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 09:42:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Gennady, Uwe & Mosè,
[CC'ing Uwe because I know he uses this feature.]
>> The multi-level fontification was introduced by
>> Tassilo Horn with commit 513490f on 2015-09-03.
>
> Wow, I didn't even remember such change! My memory is failing :-(
>
> Tassilo, when/if you have time (I don't want to break your holidays
> ;-), could you please give a look at this?
I just had a look and Gennady is correct in that there is an issue here
although what I get is a bit different from his observations.
With `font-latex-fontify-script' set to 'multi-level or 'invisible, what
I expect in $a^b^c$ is that the b is raised above a and a bit smaller,
and c is raised above b and again a bit smaller. What I actually see is
that b is raised above a and a bit smaller but c is raised to the very
same height as b and has b's size.
Sadly, I have no clue why that's the case. The code worked as intended
when I wrote it and there haven't been any changes to it AFAICS. Maybe
something is Emacs changed? I've tried Emacs 25.1 and master with the
same results.
Does anyone of you have an older Emacs copy (22.x, 23.x, 24.x) installed
and can check what the results are with that?
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 09:47:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 25309 <at> debbugs.gnu.org (full text, mbox):
> Mosè Giordano <mose <at> gnu.org> writes:
> Hi Gennady, Uwe & Mosè,
> [CC'ing Uwe because I know he uses this feature.]
> I just had a look and Gennady is correct in that there is an issue here
> although what I get is a bit different from his observations.
> With `font-latex-fontify-script' set to 'multi-level or 'invisible, what
> I expect in $a^b^c$ is that the b is raised above a and a bit smaller,
> and c is raised above b and again a bit smaller. What I actually see is
> that b is raised above a and a bit smaller but c is raised to the very
> same height as b and has b's size.
Confirmed.
> Sadly, I have no clue why that's the case. The code worked as intended
> when I wrote it and there haven't been any changes to it AFAICS. Maybe
> something is Emacs changed? I've tried Emacs 25.1 and master with the
> same results.
Confirmed.
> Does anyone of you have an older Emacs copy (22.x, 23.x, 24.x) installed
> and can check what the results are with that?
I have 24.x,[1] but I have to change my init file because right now I
obtain on start the following error:
Warning (emacs): Unable to activate package `with-editor'.
Required package `emacs-24.4' is unavailable
Warning (initialization): An error occurred while loading `/home/oub/.emacs':
Symbol's function definition is void: function-put
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with
the `--debug-init' option to view a complete error backtrace.
Warning (emacs): Unable to activate package `with-editor'.
Required package `emacs-24.4' is unavailable
So auctex does not load.
I think I will use emacs -Q and cook some short auctex only init file
and report back.
Uwe
Footnotes:
[1] I think I still have some hard disk with an older ubuntu version and
with 23 or 22 around but that I have to look up.
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 09:52:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 25309 <at> debbugs.gnu.org (full text, mbox):
> Mosè Giordano <mose <at> gnu.org> writes:
> Hi Gennady, Uwe & Mosè,
> [CC'ing Uwe because I know he uses this feature.]
> Does anyone of you have an older Emacs copy (22.x, 23.x, 24.x)
> installed and can check what the results are with that?
Hm I run emacs -Q load a simple auctex-init file which uses my auctex
git version which I compiled with 25 (or 26 not sure))
In any case I obtain an error:
Debugger entered--Lisp error: (void-function function-put)
function-put(TeX--if-macro-fboundp lisp-indent-function 2)
byte-code("\300\301\302\303#\210\304\301\305\306#\210\307\310!\210\311\312\313\"\207"
[function-put TeX--if-macro-fboundp lisp-indent-function 2 put
edebug-form-spec (symbolp form) require easymenu defalias
TeX-maybe-remove-help #[(menu) "\207" [menu] 1 "Compatibility
function that would remove :help entries if on XEmacs,\nbut does
nothing in Emacs."]] 4)
require(tex)
byte-code("\300\301!\210\300\302!\210\300\303!\207" [require tex tex-style tex-ispell] 2)
command-execute(LaTeX-mode record)
execute-extended-command(nil "LaTeX-mode")
call-interactively(execute-extended-command nil nil)
Maybe it would be better to use auctex from the package system, but I
have a problem with my init file, odd odd.
Any ideas?
Uwe
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 10:10:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Uwe Brauer <oub <at> mat.ucm.es> writes:
> I have 24.x,[1] but I have to change my init file because right now I
> obtain on start the following error:
> Warning (emacs): Unable to activate package `with-editor'.
with-editor is used by magit, as far as I know.
> Required package `emacs-24.4' is unavailable
> Warning (initialization): An error occurred while loading `/home/oub/.emacs':
>
> Symbol's function definition is void: function-put
Yes, that's a new function in emacs 25. That's probably because auctex
has been compiled with a more recent version of Emacs than the one you
are running right now.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 10:39:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 25309 <at> debbugs.gnu.org (full text, mbox):
>>> "Tassilo" == Tassilo Horn <tsdh <at> gnu.org> writes:
> Uwe Brauer <oub <at> mat.ucm.es> writes:
>> I have 24.x,[1] but I have to change my init file because right now I
>> obtain on start the following error:
>> Warning (emacs): Unable to activate package `with-editor'.
> with-editor is used by magit, as far as I know.
>> Required package `emacs-24.4' is unavailable
>> Warning (initialization): An error occurred while loading `/home/oub/.emacs':
>>
>> Symbol's function definition is void: function-put
> Yes, that's a new function in emacs 25. That's probably because auctex
> has been compiled with a more recent version of Emacs than the one you
> are running right now.
I de installed magit (never used it anyhow) tried to use the auctex
version as provided by the package system. Did not work. So in order not
to lose more type, I just created a new user. Started emacs 24 and
installed auctex via the package system, then I set the variable
`font-latex-fontify-script' to 'invisible,
But the behavior you described for 25 and 26 *also* occurred in 24. I
can't say anything for 22 or 23.
Uwe
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 12:11:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
Sorry for the delay in responding. I powered up an Ubuntu 16.10 virtual
machine and installed emacs available there (24.4) the same problem is
there. Attaching screenshot.
Gennady
On 01/01/17 12:51, Uwe Brauer wrote:
>
> > Mosè Giordano <mose <at> gnu.org> writes:
> > Hi Gennady, Uwe & Mosè,
>
> > [CC'ing Uwe because I know he uses this feature.]
>
>
>
> > Does anyone of you have an older Emacs copy (22.x, 23.x, 24.x)
> > installed and can check what the results are with that?
>
> Hm I run emacs -Q load a simple auctex-init file which uses my auctex
> git version which I compiled with 25 (or 26 not sure))
>
> In any case I obtain an error:
>
> Debugger entered--Lisp error: (void-function function-put)
> function-put(TeX--if-macro-fboundp lisp-indent-function 2)
> byte-code("\300\301\302\303#\210\304\301\305\306#\210\307\310!\210\311\312\313\"\207"
> [function-put TeX--if-macro-fboundp lisp-indent-function 2 put
> edebug-form-spec (symbolp form) require easymenu defalias
> TeX-maybe-remove-help #[(menu) "\207" [menu] 1 "Compatibility
> function that would remove :help entries if on XEmacs,\nbut does
> nothing in Emacs."]] 4)
> require(tex)
> byte-code("\300\301!\210\300\302!\210\300\303!\207" [require tex tex-style tex-ispell] 2)
> command-execute(LaTeX-mode record)
> execute-extended-command(nil "LaTeX-mode")
> call-interactively(execute-extended-command nil nil)
>
> Maybe it would be better to use auctex from the package system, but I
> have a problem with my init file, odd odd.
>
>
> Any ideas?
>
>
> Uwe
>
[Screenshot_Ubuntu16_10_emacs24_4.png (image/png, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 12:13:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry,
it was version 24.5
Gennady
On 01/01/17 15:10, Gennady Uraltsev wrote:
> Hello,
>
> Sorry for the delay in responding. I powered up an Ubuntu 16.10 virtual
> machine and installed emacs available there (24.4) the same problem is
> there. Attaching screenshot.
>
> Gennady
>
> On 01/01/17 12:51, Uwe Brauer wrote:
>>
>> > Mosè Giordano <mose <at> gnu.org> writes:
>> > Hi Gennady, Uwe & Mosè,
>>
>> > [CC'ing Uwe because I know he uses this feature.]
>>
>>
>>
>> > Does anyone of you have an older Emacs copy (22.x, 23.x, 24.x)
>> > installed and can check what the results are with that?
>>
>> Hm I run emacs -Q load a simple auctex-init file which uses my auctex
>> git version which I compiled with 25 (or 26 not sure))
>>
>> In any case I obtain an error:
>>
>> Debugger entered--Lisp error: (void-function function-put)
>> function-put(TeX--if-macro-fboundp lisp-indent-function 2)
>> byte-code("\300\301\302\303#\210\304\301\305\306#\210\307\310!\210\311\312\313\"\207"
>> [function-put TeX--if-macro-fboundp lisp-indent-function 2 put
>> edebug-form-spec (symbolp form) require easymenu defalias
>> TeX-maybe-remove-help #[(menu) "\207" [menu] 1 "Compatibility
>> function that would remove :help entries if on XEmacs,\nbut does
>> nothing in Emacs."]] 4)
>> require(tex)
>> byte-code("\300\301!\210\300\302!\210\300\303!\207" [require tex tex-style tex-ispell] 2)
>> command-execute(LaTeX-mode record)
>> execute-extended-command(nil "LaTeX-mode")
>> call-interactively(execute-extended-command nil nil)
>>
>> Maybe it would be better to use auctex from the package system, but I
>> have a problem with my init file, odd odd.
>>
>>
>> Any ideas?
>>
>>
>> Uwe
>>
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 12:54:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Everyone,
I tried installing auctex thorough elpa in emacs 24.3.1 . It was
difficult as it gave errors quite often, however after trying again
several times I managed to do it.
The problem is still there.
Some care should be taken! After customizing the variable
font-latex-fontify-script to value multi-level one should be careful to
restart fontification (or emacs proper). Otherwise the changes doesn't
manifest itself.
Cheers,
Gennady
P.S. Attached screenshot
On 01/01/17 12:36, Tassilo Horn wrote:
> Mosè Giordano <mose <at> gnu.org> writes:
>
> Hi Gennady, Uwe & Mosè,
>
> [CC'ing Uwe because I know he uses this feature.]
>
>>> The multi-level fontification was introduced by
>>> Tassilo Horn with commit 513490f on 2015-09-03.
>>
>> Wow, I didn't even remember such change! My memory is failing :-(
>>
>> Tassilo, when/if you have time (I don't want to break your holidays
>> ;-), could you please give a look at this?
>
> I just had a look and Gennady is correct in that there is an issue here
> although what I get is a bit different from his observations.
>
> With `font-latex-fontify-script' set to 'multi-level or 'invisible, what
> I expect in $a^b^c$ is that the b is raised above a and a bit smaller,
> and c is raised above b and again a bit smaller. What I actually see is
> that b is raised above a and a bit smaller but c is raised to the very
> same height as b and has b's size.
>
> Sadly, I have no clue why that's the case. The code worked as intended
> when I wrote it and there haven't been any changes to it AFAICS. Maybe
> something is Emacs changed? I've tried Emacs 25.1 and master with the
> same results.
>
> Does anyone of you have an older Emacs copy (22.x, 23.x, 24.x) installed
> and can check what the results are with that?
>
> Bye,
> Tassilo
>
[Screenshot_Leap42_2_emacs24_3_1.png (image/png, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 14:30:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 25309 <at> debbugs.gnu.org (full text, mbox):
>>> "Gennady" == Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
> Hello Everyone,
> I tried installing auctex thorough elpa in emacs 24.3.1 . It was
> difficult as it gave errors quite often, however after trying again
> several times I managed to do it.
I did this also, version 23.4.1, but did not encounter any installation
problem via elpa.
> The problem is still there.
Confirmed.
> Some care should be taken! After customizing the variable
> font-latex-fontify-script to value multi-level one should be careful to
> restart fontification (or emacs proper). Otherwise the changes doesn't
> manifest itself.
I set it to invisible and confirm what you found out.
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 15:29:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Uwe Brauer <oub <at> mat.ucm.es> writes:
Hi Uwe & Gennady,
sadly I'm unable to build emacs 24.3 or 24.4 from the sources and my
distro doesn't provide binary builds of any emacs version except for the
current one. :-(
> > Some care should be taken! After customizing the variable
> > font-latex-fontify-script to value multi-level one should be
> > careful to restart fontification (or emacs proper). Otherwise the
> > changes doesn't manifest itself.
>
> I set it to invisible and confirm what you found out.
So to be clear: do you say that the feature works for you both with
emacs 24.3 with the slight complication that you have to toggle
`font-lock-mode' after setting `font-latex-fontify-script' to
multi-level or invisible? If not, what are you doing exactly to get it
working?
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 15:47:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dear Tassilo,
Actually no, the bug appears in all three versions: 24.3 24.4 and 25.1
(current). In the identical manner. You can see the results from the
attached screenshots and the exmaple tex file.
Let me try to explain what I understood of the problem:
The relevant variables with apropriate values are:
font-latex-fontify-script multi-level
font-latex-scipt-display ((raise -0.3) raise 0.3)
and the two faces
Font Latex Superscript Face ((t
(:height 0.8)))
Font Latex Subscript Face: ((t
(:height 0.8)))
What happens is that the font faces always get applied and the compound
(you see the font getting smaller progressively) this is because for
font specifications, specifying a fractional value means taking the
parent font and modifying it by that factor (for hight).
A different behavior happens for
font-latex-scipt-display ((raise -0.3) raise 0.3).
According to manual the first part is relative to subscripts and the
second to superscripts.
Immagine an expression like
base^{u2^{u3_{d1}}}_{d2_{d3^{u4_{d4^{u5}}}}}}
the raising gets applied only if the first consecutive sub or super
script of a series. That means that ^{x} appears raised unless the
containing expression is also a superscript. Similarly lowering a
subscript gets applied only if the containing expression is NOT another
subscript.
In the above example the raising gets applied to u2 u4 u5 and not u3
Lowering (negative raising) gets applied to d1 d2 d4 but not d3
Notice also that the raising gets calculated with respect to the base
line and not the containing level.
Finally the "apparent" going down of the stack
1^{2^{3^{4}}} is due simply to the fact that the font gets smaller
Cheers,
Gena
On 01/01/17 18:28, Tassilo Horn wrote:
> Uwe Brauer <oub <at> mat.ucm.es> writes:
>
> Hi Uwe & Gennady,
>
> sadly I'm unable to build emacs 24.3 or 24.4 from the sources and my
> distro doesn't provide binary builds of any emacs version except for the
> current one. :-(
>
>> > Some care should be taken! After customizing the variable
>> > font-latex-fontify-script to value multi-level one should be
>> > careful to restart fontification (or emacs proper). Otherwise the
>> > changes doesn't manifest itself.
>>
>> I set it to invisible and confirm what you found out.
>
> So to be clear: do you say that the feature works for you both with
> emacs 24.3 with the slight complication that you have to toggle
> `font-lock-mode' after setting `font-latex-fontify-script' to
> multi-level or invisible? If not, what are you doing exactly to get it
> working?
>
> Bye,
> Tassilo
>
[Screenshot-Leap42_2-emacs24_3_1.png (image/png, attachment)]
[Screenshot-Leap42_2-emacs25_1.png (image/png, attachment)]
[Screenshot-Ubuntu16_10-emacs24_5.png (image/png, attachment)]
[scripts.tex (text/x-tex, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 15:49:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dear Tassilo,
Actually no, the bug appears in all three versions: 24.3 24.4 and 25.1
(current). In the identical manner. You can see the results from the
attached screenshots and the exmaple tex file.
Let me try to explain what I understood of the problem:
The relevant variables with apropriate values are:
font-latex-fontify-script multi-level
font-latex-scipt-display ((raise -0.3) raise 0.3)
and the two faces
Font Latex Superscript Face ((t
(:height 0.8)))
Font Latex Subscript Face: ((t
(:height 0.8)))
What happens is that the font faces always get applied and the compound
(you see the font getting smaller progressively) this is because for
font specifications, specifying a fractional value means taking the
parent font and modifying it by that factor (for hight).
A different behavior happens for
font-latex-scipt-display ((raise -0.3) raise 0.3).
According to manual the first part is relative to subscripts and the
second to superscripts.
Immagine an expression like
base^{u2^{u3_{d1}}}_{d2_{d3^{u4_{d4^{u5}}}}}}
the raising gets applied only if the first consecutive sub or super
script of a series. That means that ^{x} appears raised unless the
containing expression is also a superscript. Similarly lowering a
subscript gets applied only if the containing expression is NOT another
subscript.
In the above example the raising gets applied to u2 u4 u5 and not u3
Lowering (negative raising) gets applied to d1 d2 d4 but not d3
Notice also that the raising gets calculated with respect to the base
line and not the containing level.
Finally the "apparent" going down of the stack
1^{2^{3^{4}}} is due simply to the fact that the font gets smaller
Cheers,
Gena
On 01/01/17 18:28, Tassilo Horn wrote:
> Uwe Brauer <oub <at> mat.ucm.es> writes:
>
> Hi Uwe & Gennady,
>
> sadly I'm unable to build emacs 24.3 or 24.4 from the sources and my
> distro doesn't provide binary builds of any emacs version except for the
> current one. :-(
>
>> > Some care should be taken! After customizing the variable
>> > font-latex-fontify-script to value multi-level one should be
>> > careful to restart fontification (or emacs proper). Otherwise the
>> > changes doesn't manifest itself.
>>
>> I set it to invisible and confirm what you found out.
>
> So to be clear: do you say that the feature works for you both with
> emacs 24.3 with the slight complication that you have to toggle
> `font-lock-mode' after setting `font-latex-fontify-script' to
> multi-level or invisible? If not, what are you doing exactly to get it
> working?
>
> Bye,
> Tassilo
>
[Screenshot-Leap42_2-emacs24_3_1.png (image/png, attachment)]
[Screenshot-Leap42_2-emacs25_1.png (image/png, attachment)]
[Screenshot-Ubuntu16_10-emacs24_5.png (image/png, attachment)]
[scripts.tex (text/x-tex, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 16:21:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
Hi Gennady,
> The relevant variables with apropriate values are:
>
> font-latex-fontify-script multi-level
> font-latex-scipt-display ((raise -0.3) raise 0.3)
>
> and the two faces
>
> Font Latex Superscript Face ((t
> (:height 0.8)))
>
> Font Latex Subscript Face: ((t
> (:height 0.8)))
Right.
> What happens is that the font faces always get applied and the
> compound (you see the font getting smaller progressively) this is
> because for font specifications, specifying a fractional value means
> taking the parent font and modifying it by that factor (for hight).
Seems to be the case although only with scripts containing {...} with
nested scripts.
> A different behavior happens for font-latex-scipt-display ((raise
> -0.3) raise 0.3). According to manual the first part is relative to
> subscripts and the second to superscripts.
>
> Immagine an expression like
>
> base^{u2^{u3_{d1}}}_{d2_{d3^{u4_{d4^{u5}}}}}}
>
> the raising gets applied only if the first consecutive sub or super
> script of a series. That means that ^{x} appears raised unless the
> containing expression is also a superscript. Similarly lowering a
> subscript gets applied only if the containing expression is NOT
> another subscript.
Yes, that seems to be the current behavior.
> In the above example the raising gets applied to u2 u4 u5 and not u3
> Lowering (negative raising) gets applied to d1 d2 d4 but not d3
>
> Notice also that the raising gets calculated with respect to the base
> line and not the containing level.
>
> Finally the "apparent" going down of the stack
> 1^{2^{3^{4}}} is due simply to the fact that the font gets smaller
I've also re-read the docs in the meantime and wondered how this feature
could have worked at all at. But I'm pretty sure that back at that time
when I added the feature, $x^y^z$ was displayed as one would expect,
i.e., y raised above x and smaller, z raised above y and smaller. Uwe,
do you remember?
But again, even if it worked it would be a mystery why...
Bye,
Tassilo
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 17:40:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 25309 <at> debbugs.gnu.org (full text, mbox):
>>> "Gennady" == Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
> Dear Tassilo,
> Actually no, the bug appears in all three versions: 24.3
I can confirm this. The bug appears in 24.3 and auctex from elpa.
Uwe
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Sun, 01 Jan 2017 19:26:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 25309 <at> debbugs.gnu.org (full text, mbox):
> Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
> Hi Gennady,
> Right.
> Seems to be the case although only with scripts containing {...} with
> nested scripts.
> Yes, that seems to be the current behavior.
> I've also re-read the docs in the meantime and wondered how this feature
> could have worked at all at. But I'm pretty sure that back at that time
> when I added the feature, $x^y^z$ was displayed as one would expect,
> i.e., y raised above x and smaller, z raised above y and smaller. Uwe,
> do you remember?
Not really. I also don't really need that feature. I just checked out
org mode which has some sort of latex support, it does not work there
neither, so I start to think it never worked but I am not sure of
course.
Uwe
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 10:11:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Uwe Brauer <oub <at> mat.ucm.es> writes:
Hi Uwe and Gennady,
> Not really. I also don't really need that feature.
Given that it doesn't work and produces even wrong results, I removed
the complete feature, i.e., the values multi-level and invisible. I
don't see how it could be made working without parsing the actual math
expressions and incrementally computing the right `raise' values.
Of course, if anyone of you wants to bring it back, patches are always
welcome!
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 10:15:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 25309 <at> debbugs.gnu.org (full text, mbox):
>>> "Tassilo" == Tassilo Horn <tsdh <at> gnu.org> writes:
> Uwe Brauer <oub <at> mat.ucm.es> writes:
> Hi Uwe and Gennady,
>> Not really. I also don't really need that feature.
> Given that it doesn't work and produces even wrong results, I removed
> the complete feature, i.e., the values multi-level and invisible. I
> don't see how it could be made working without parsing the actual math
> expressions and incrementally computing the right `raise' values.
What? Do I understand correctly you removed the feature that $a^b$ is
displayed correctly (that is b raised ^ invisible), because it does not
work for the (rare) case of nested expressions like $a^b^c$?
Please don't. The invisible feature is very nice and as I said the case
$a^b^c$ is very rare.
But maybe I misunderstood you.
Uwe
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 10:26:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Uwe Brauer <oub <at> mat.ucm.es> writes:
Hi Uwe,
> > Given that it doesn't work and produces even wrong results, I removed
> > the complete feature, i.e., the values multi-level and invisible. I
> > don't see how it could be made working without parsing the actual math
> > expressions and incrementally computing the right `raise' values.
>
> What? Do I understand correctly you removed the feature that $a^b$ is
> displayed correctly (that is b raised ^ invisible), because it does
> not work for the (rare) case of nested expressions like $a^b^c$?
Yes, exactly.
> Please don't. The invisible feature is very nice and as I said the
> case $a^b^c$ is very rare.
Sorry, but I think there's no value in a feature which only works in the
simplest cases and might be wrong otherwise. Have a look at Gennady's
screenshots. There are examples where its completely confusing with
`multi-level' and would definitely make you read something else than
what has been written with `invisible'.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 13:20:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 25309 <at> debbugs.gnu.org (full text, mbox):
> Uwe Brauer <oub <at> mat.ucm.es> writes:
> Hi Uwe,
> Yes, exactly.
> Sorry, but I think there's no value in a feature which only works in the
> simplest cases and might be wrong otherwise. Have a look at Gennady's
> screenshots.
I have seen his shots, these are border line cases, which are used very
little. Look I have written mathematics with latex over the last 25
years and in countless occasions I have used ^or  but never nested
expressions and this is also true for the publications and writings I
have seen in these years. I reckon that 95 % of the people writing
mathematics never use nested ^. So I could understand your argument if
there were 50 % non nested and 50 % nested but it is the case. Please
don't move us back to the middle age.
> There are examples where its completely confusing with
> `multi-level' and would definitely make you read something else than
> what has been written with `invisible'.
What's about the following compromise:
Remove multi-level, but leave invisible and add to the docstring
something like
Please note that invisible only works for a simple sub and superscripts.
Nested constructions are not supported, in fact those can be displayed in
a confusing way. If you need those constructs please do not use the
invisible option.
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 17:48:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Uwe Brauer <oub <at> mat.ucm.es> writes:
Hi Uwe,
> I have seen his shots, these are border line cases, which are used very
> little. Look I have written mathematics with latex over the last 25
> years and in countless occasions I have used ^or  but never nested
> expressions and this is also true for the publications and writings I
> have seen in these years. I reckon that 95 % of the people writing
> mathematics never use nested ^. So I could understand your argument if
> there were 50 % non nested and 50 % nested but it is the case.
That might indicate that you are working in a field of math where there
are few exponentiated expressions which are already exponentiated. But
I don't think that exponents have grown out of vogue in general. ;-)
> Please don't move us back to the middle age.
Come on, reverting this broken feature doesn't move us back to the
middle ages.
> > There are examples where its completely confusing with
> > `multi-level' and would definitely make you read something else
> > than what has been written with `invisible'.
>
> What's about the following compromise:
>
> Remove multi-level, but leave invisible and add to the docstring
> something like
>
> Please note that invisible only works for a simple sub and
> superscripts. Nested constructions are not supported, in fact those
> can be displayed in a confusing way.
"In fact, those will be displayed in a completely wrong way!" would be
more correct.
> If you need those constructs please do not use the invisible option.
Let's use this compromise: I have already removed the feature but you
are free to put
--8<---------------cut here---------------start------------->8---
(require 'font-latex)
(defun font-latex-match-script-chars (limit)
(let ((p (point)))
(and (re-search-forward "[_^]" limit t)
(let ((pos (match-beginning 0)))
(and (font-latex-faces-present-p 'font-latex-math-face pos)
(not (font-latex-faces-present-p '(font-lock-constant-face
font-lock-builtin-face
font-lock-comment-face
font-latex-verbatim-face) pos))
;; Check for backslash quoting
(not (let ((odd nil)
(pos pos))
(while (eq (char-before pos) ?\\)
(setq pos (1- pos) odd (not odd)))
odd)))))))
(add-to-list 'font-latex-keywords-2
'(font-latex-match-script-chars
(0 '(face font-latex-math-face invisible t)))
t)
--8<---------------cut here---------------end--------------->8---
into your ~/.emacs, and then scripts will be hidden again. (You don't
need to configure `font-latex-fontify-script'. Just let it on its
default value of t for Emacs.)
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 17:59:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 25309 <at> debbugs.gnu.org (full text, mbox):
> Uwe Brauer <oub <at> mat.ucm.es> writes:
> Hi Uwe,
> That might indicate that you are working in a field of math where there
> are few exponentiated expressions which are already exponentiated. But
> I don't think that exponents have grown out of vogue in general. ;-)
Well I really wish to see these publications, maybe in algebra. You are
really claiming that expressions of the sort a^b^c are frequent? I
rather say they are not, but we better leave that topic.
> Come on, reverting this broken feature doesn't move us back to the
> middle ages.
Well that is the way I feel about it, in fact this feature was the last
reason, among others, to convince me to change back to GNU emacs, which
I left at the time of 18.57.
> "In fact, those will be displayed in a completely wrong way!" would be
> more correct.
Whatever.
> Let's use this compromise: I have already removed the feature but you
> are free to put
> into your ~/.emacs, and then scripts will be hidden again. (You don't
> need to configure `font-latex-fontify-script'. Just let it on its
> default value of t for Emacs.)
Ok fair enough I can live with that :-D, I thought the feature required
more hacking. You might receive more complains in the future, though,
:-D
Uwe
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 18:50:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello everyone,
I am sorry for all the problems that have arisen. I wanted to contribute
to the discussion somewhat.
1) Personally I often have double subscripts i.e. expressions of the form
$
\int_{a_i}^{a_{i+1}}
$
(I am a PhD in math)
2) LaTeX (or at least AMS) forbids expressions of the type $a_b_c$ and
$a^b^c$.
ERROR: Double subscript.
--- TeX said ---
l.106 $a_b_
c$
--- HELP ---
There are two subscripts in a row in a mathematical
formula---something like x_{2}_{3}, which makes no sense.
The only acceptable syntax is:
$a_{b_c}$
An idea would be to never make a _ disappear if it is already
super/sub-script fontified. Also disable fontification of
sub/superscripts on any line such that there are two _ not separated by
a { and the same for ^
I am trying to implement something like it but I am no expert in elisp
so it'll take me some time.
Cheers,
Gennady
On 02/01/17 20:58, Uwe Brauer wrote:
>
> > Uwe Brauer <oub <at> mat.ucm.es> writes:
> > Hi Uwe,
>
>
> > That might indicate that you are working in a field of math where there
> > are few exponentiated expressions which are already exponentiated. But
> > I don't think that exponents have grown out of vogue in general. ;-)
>
> Well I really wish to see these publications, maybe in algebra. You are
> really claiming that expressions of the sort a^b^c are frequent? I
> rather say they are not, but we better leave that topic.
>
> > Come on, reverting this broken feature doesn't move us back to the
> > middle ages.
>
> Well that is the way I feel about it, in fact this feature was the last
> reason, among others, to convince me to change back to GNU emacs, which
> I left at the time of 18.57.
>
> > "In fact, those will be displayed in a completely wrong way!" would be
> > more correct.
>
> Whatever.
>
> > Let's use this compromise: I have already removed the feature but you
> > are free to put
>
>
> > into your ~/.emacs, and then scripts will be hidden again. (You don't
> > need to configure `font-latex-fontify-script'. Just let it on its
> > default value of t for Emacs.)
>
> Ok fair enough I can live with that :-D, I thought the feature required
> more hacking. You might receive more complains in the future, though,
> :-D
>
> Uwe
>
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Mon, 02 Jan 2017 19:45:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> "Gennady" == Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
> Hello everyone,
> I am sorry for all the problems that have arisen. I wanted to contribute
> to the discussion somewhat.
This is for sure not your fault.
> 1) Personally I often have double subscripts i.e. expressions of the form
> $
> \int_{a_i}^{a_{i+1}}
> $
> (I am a PhD in math)
ok.
> An idea would be to never make a _ disappear if it is already
> super/sub-script fontified. Also disable fontification of
> sub/superscripts on any line such that there are two _ not separated by
> a { and the same for ^
> I am trying to implement something like it but I am no expert in elisp
> so it'll take me some time.
Now that you mentioned it, now I remember that xsymbol, a xemacs
package, seems to have chosen such an approach, I attach a screenshot.
So your idea makes a lot of sense. I have no idea how difficult it would
be to implement. Tassilo?
[x-sym-inv.png (image/png, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 08:28:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
> 2) LaTeX (or at least AMS) forbids expressions of the type $a_b_c$ and
> $a^b^c$.
>
>
> ERROR: Double subscript.
>
> --- TeX said ---
> l.106 $a_b_
> c$
> --- HELP ---
> There are two subscripts in a row in a mathematical
> formula---something like x_{2}_{3}, which makes no sense.
>
> The only acceptable syntax is:
>
> $a_{b_c}$
Ah, right. That makes things a bit easier. Basically, we can assume
that in $a^{b^c}$ the {b^c} part is already fontified and risen, so in
the case where we are going to fontify ^c we would need to
increment/decrement the `raise' value. I'll play around with this.
Bye,
Tassilo
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 09:16:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tassilo Horn <tsdh <at> gnu.org> writes:
>> The only acceptable syntax is:
>>
>> $a_{b_c}$
>
> Ah, right. That makes things a bit easier. Basically, we can assume
> that in $a^{b^c}$ the {b^c} part is already fontified and risen, so in
> the case where we are going to fontify ^c we would need to
> increment/decrement the `raise' value. I'll play around with this.
How about that? (see the two screenshots, one with multi-level the
other with invisible)
[scripts.png (image/png, attachment)]
[scripts-invisible.png (image/png, attachment)]
[Message part 4 (text/plain, inline)]
Bye,
Tassilo
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 09:18:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 25309 <at> debbugs.gnu.org (full text, mbox):
>>> "Tassilo" == Tassilo Horn <tsdh <at> gnu.org> writes:
> Tassilo Horn <tsdh <at> gnu.org> writes:
>>> The only acceptable syntax is:
>>>
>>> $a_{b_c}$
>>
>> Ah, right. That makes things a bit easier. Basically, we can assume
>> that in $a^{b^c}$ the {b^c} part is already fontified and risen, so in
>> the case where we are going to fontify ^c we would need to
>> increment/decrement the `raise' value. I'll play around with this.
> How about that? (see the two screenshots, one with multi-level the
> other with invisible)
Absolutely great. :-D
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 09:34:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 25309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Yep! Looks fantastic!
On 03/01/17 12:17, Uwe Brauer wrote:
>>>> "Tassilo" == Tassilo Horn <tsdh <at> gnu.org> writes:
>
> > Tassilo Horn <tsdh <at> gnu.org> writes:
>
> >>> The only acceptable syntax is:
> >>>
> >>> $a_{b_c}$
> >>
> >> Ah, right. That makes things a bit easier. Basically, we can assume
> >> that in $a^{b^c}$ the {b^c} part is already fontified and risen, so in
> >> the case where we are going to fontify ^c we would need to
> >> increment/decrement the `raise' value. I'll play around with this.
>
> > How about that? (see the two screenshots, one with multi-level the
> > other with invisible)
>
> Absolutely great. :-D
>
[signature.asc (application/pgp-signature, attachment)]
Reply sent
to
Tassilo Horn <tsdh <at> gnu.org>:
You have taken responsibility.
(Tue, 03 Jan 2017 09:47:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gennady Uraltsev <gennady.uraltsev <at> gmail.com>:
bug acknowledged by developer.
(Tue, 03 Jan 2017 09:47:01 GMT)
Full text and
rfc822 format available.
Message #103 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
> Yep! Looks fantastic!
>>
>> Absolutely great. :-D
Ok, great. Committed and pushed! I'm closing this bug then.
Thanks,
Tassilo
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 10:13:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Tassilo,
2017-01-03 10:45 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
> Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
>
>> Yep! Looks fantastic!
>>>
>>> Absolutely great. :-D
>
> Ok, great. Committed and pushed! I'm closing this bug then.
Thank you, this is amazing!
A couple of requests:
1) could you please mention this feature in doc/changes.texi?
2) is it possible to set a limit to scaling?
\(a^{b^{c^{d^{e^{f^{g^{h}}}}}}}\)
is hardly readable, see the attached screenshot (though it's uncommon
to have hyper-nested scripts). This is unreadble also in the output
document, but I think that the source code should always be readable.
In my pixelated example, position of the baseline starts to be wrong
after the fifth nested script (but this depends on the font and its
size), maybe we can stop scaling after the ~4th nested script?
Bye,
Mosè
[nested-scripts.png (image/png, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 15:29:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Mosè,
>> Ok, great. Committed and pushed! I'm closing this bug then.
>
> Thank you, this is amazing!
>
> A couple of requests:
>
> 1) could you please mention this feature in doc/changes.texi?
Done!
> 2) is it possible to set a limit to scaling?
>
> \(a^{b^{c^{d^{e^{f^{g^{h}}}}}}}\)
>
> is hardly readable, see the attached screenshot (though it's uncommon
> to have hyper-nested scripts). This is unreadble also in the output
> document, but I think that the source code should always be readable.
Ok, there's a new variable `font-latex-fontify-script-max-level' which
defines up to which scriptification level the script faces are applied
again (thereby causing the decrease in font size).
> In my pixelated example, position of the baseline starts to be wrong
> after the fifth nested script (but this depends on the font and its
> size), maybe we can stop scaling after the ~4th nested script?
A problem of the previous version of the feature was that the raise
factors were just added up and didn't account for the fact that the font
size also shrinks. In the current version, with each level the addition
to the raise value gets smaller (about 80% of the previous addition).
Probably, the faces' :height value and this raise factor should be in
sync somehow. However, right now the :height value can be customized by
the user whereas the "addition for level x = 80% of the addition for
level x-1" is currently hard-coded by putting in a polynom which I have
extrapolated for the values
1 1
2 0.8
3 0.64
4 0.512
5 0.4096
6 0.32768
7 0.262144
8 0.2097152
Hm, Gennady, maybe you know something better?
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 15:29:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Mosè,
>> Ok, great. Committed and pushed! I'm closing this bug then.
>
> Thank you, this is amazing!
>
> A couple of requests:
>
> 1) could you please mention this feature in doc/changes.texi?
Done!
> 2) is it possible to set a limit to scaling?
>
> \(a^{b^{c^{d^{e^{f^{g^{h}}}}}}}\)
>
> is hardly readable, see the attached screenshot (though it's uncommon
> to have hyper-nested scripts). This is unreadble also in the output
> document, but I think that the source code should always be readable.
Ok, there's a new variable `font-latex-fontify-script-max-level' which
defines up to which scriptification level the script faces are applied
again (thereby causing the decrease in font size).
> In my pixelated example, position of the baseline starts to be wrong
> after the fifth nested script (but this depends on the font and its
> size), maybe we can stop scaling after the ~4th nested script?
A problem of the previous version of the feature was that the raise
factors were just added up and didn't account for the fact that the font
size also shrinks. In the current version, with each level the addition
to the raise value gets smaller (about 80% of the previous addition).
Probably, the faces' :height value and this raise factor should be in
sync somehow. However, right now the :height value can be customized by
the user whereas the "addition for level x = 80% of the addition for
level x-1" is currently hard-coded by putting in a polynom which I have
extrapolated for the values
1 1
2 0.8
3 0.64
4 0.512
5 0.4096
6 0.32768
7 0.262144
8 0.2097152
Hm, Gennady, maybe you know something better?
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Tue, 03 Jan 2017 15:59:01 GMT)
Full text and
rfc822 format available.
Message #115 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
2017-01-03 16:27 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
> Ok, there's a new variable `font-latex-fontify-script-max-level' which
> defines up to which scriptification level the script faces are applied
> again (thereby causing the decrease in font size).
>
>> In my pixelated example, position of the baseline starts to be wrong
>> after the fifth nested script (but this depends on the font and its
>> size), maybe we can stop scaling after the ~4th nested script?
>
> A problem of the previous version of the feature was that the raise
> factors were just added up and didn't account for the fact that the font
> size also shrinks. In the current version, with each level the addition
> to the raise value gets smaller (about 80% of the previous addition).
I think it's perfect now for most cases! Thank you so much.
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 12:53:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Everyone,
I was testing out this new mode and there seems still to be some small
problem. The simplest case is as follows:
write the following
$1=x^2$
in the standard order and make sure that electric $ mode is off i.e. the
typing should look like this (with | being the cursor):
|
$|
$1|
$1=|
$1=x|
$1=x^|
$1=x^2|
$1=x^2$|
Everything works fine. However let's try this order:
|
$|
$1|
$1=|
$1=x|
$1=x$|
$1=x|$
$1=x^|$
$1=x^2|$
Notice that $ is then "raised". Now erase the exponents by doing
$1=x^2|$
$1=x^|$
$1=x^$
The problem is that the closing $ is still raised.
When I have more info I'll write more.
Cheers,
Gennady
On 03/01/17 18:57, Mosè Giordano wrote:
> 2017-01-03 16:27 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
>> Ok, there's a new variable `font-latex-fontify-script-max-level' which
>> defines up to which scriptification level the script faces are applied
>> again (thereby causing the decrease in font size).
>>
>>> In my pixelated example, position of the baseline starts to be wrong
>>> after the fifth nested script (but this depends on the font and its
>>> size), maybe we can stop scaling after the ~4th nested script?
>>
>> A problem of the previous version of the feature was that the raise
>> factors were just added up and didn't account for the fact that the font
>> size also shrinks. In the current version, with each level the addition
>> to the raise value gets smaller (about 80% of the previous addition).
>
> I think it's perfect now for most cases! Thank you so much.
>
> Bye,
> Mosè
>
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 16:10:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Hi Tassilo,
while trying to reproduce the problem reported by Gennady (I can
confirm it), I noticed another glitch. Now the baseline of the script
is slightly above (below) of "^" ("_"), see the attached screenshot
(left: as it was before, right: as it is now).
Regarding the problem reported by Gennady, also before your latest changes, with
$1=x^$
the last "$" is raised, as it should be, but adding the "2" fixes the
position of "$" immediately.
Thanks,
Mosè
2017-01-04 13:52 GMT+01:00 Gennady Uraltsev <gennady.uraltsev <at> gmail.com>:
> Hello Everyone,
>
> I was testing out this new mode and there seems still to be some small
> problem. The simplest case is as follows:
>
> write the following
>
> $1=x^2$
>
> in the standard order and make sure that electric $ mode is off i.e. the
> typing should look like this (with | being the cursor):
>
> |
> $|
> $1|
> $1=|
> $1=x|
> $1=x^|
> $1=x^2|
> $1=x^2$|
>
> Everything works fine. However let's try this order:
>
> |
> $|
> $1|
> $1=|
> $1=x|
> $1=x$|
> $1=x|$
> $1=x^|$
> $1=x^2|$
>
> Notice that $ is then "raised". Now erase the exponents by doing
> $1=x^2|$
> $1=x^|$
> $1=x^$
> The problem is that the closing $ is still raised.
>
>
> When I have more info I'll write more.
>
> Cheers,
>
> Gennady
>
>
> On 03/01/17 18:57, Mosè Giordano wrote:
>> 2017-01-03 16:27 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
>>> Ok, there's a new variable `font-latex-fontify-script-max-level' which
>>> defines up to which scriptification level the script faces are applied
>>> again (thereby causing the decrease in font size).
>>>
>>>> In my pixelated example, position of the baseline starts to be wrong
>>>> after the fifth nested script (but this depends on the font and its
>>>> size), maybe we can stop scaling after the ~4th nested script?
>>>
>>> A problem of the previous version of the feature was that the raise
>>> factors were just added up and didn't account for the fact that the font
>>> size also shrinks. In the current version, with each level the addition
>>> to the raise value gets smaller (about 80% of the previous addition).
>>
>> I think it's perfect now for most cases! Thank you so much.
>>
>> Bye,
>> Mosè
>>
>
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 16:57:01 GMT)
Full text and
rfc822 format available.
Message #124 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:
Hi Gennady,
> Notice that $ is then "raised". Now erase the exponents by doing
> $1=x^2|$
> $1=x^|$
> $1=x^$
> The problem is that the closing $ is still raised.
I think I have fixed it. The unfontification code was only removing
display properties equalling the literal specifications in
`font-latex-script-display' which didn't match anymore because the raise
values are now computed dynamically.
I also forgot to remove the new script-level text properties I'm using
to stop text shrinking after `font-latex-fontify-script-max-level'
levels.
Bye,
Tassilo
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 17:00:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
2017-01-04 17:08 GMT+01:00 Mosè Giordano <mose <at> gnu.org>:
> Hi Tassilo,
>
> while trying to reproduce the problem reported by Gennady (I can
> confirm it), I noticed another glitch. Now the baseline of the script
> is slightly above (below) of "^" ("_"), see the attached screenshot
> (left: as it was before, right: as it is now).
Of course the attachment was not there :-)
[position_of_scripts.png (image/png, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 17:04:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Mosè,
> while trying to reproduce the problem reported by Gennady (I can
> confirm it), I noticed another glitch. Now the baseline of the script
> is slightly above (below) of "^" ("_"), see the attached screenshot
> (left: as it was before, right: as it is now).
Where is the screenshot?
> Regarding the problem reported by Gennady, also before your latest
> changes, with
>
> $1=x^$
>
> the last "$" is raised, as it should be, but adding the "2" fixes the
> position of "$" immediately.
Yeah, yeah, that's already fixed. :-)
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 17:44:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Mosè,
>> while trying to reproduce the problem reported by Gennady (I can
>> confirm it), I noticed another glitch. Now the baseline of the
>> script is slightly above (below) of "^" ("_"), see the attached
>> screenshot (left: as it was before, right: as it is now).
>
> Of course the attachment was not there :-)
I do the same all the time. :-)
Anyway, my sense for aesthetics is very rudimentary so you have to
explain to me where the bug is. What I did, however, is that I changed
the default raise values from ±0.3 to ±0.5. So indeed the superscripts
are a bit more raised and the subscripts a bit more lowered.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 17:46:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello everyone,
I can confirm that everything works. Thanks a lot!
Gennady
On 04/01/17 19:58, Tassilo Horn wrote:
> Mosè Giordano <mose <at> gnu.org> writes:
>
> Hi Mosè,
>
>> while trying to reproduce the problem reported by Gennady (I can
>> confirm it), I noticed another glitch. Now the baseline of the script
>> is slightly above (below) of "^" ("_"), see the attached screenshot
>> (left: as it was before, right: as it is now).
>
> Where is the screenshot?
>
>> Regarding the problem reported by Gennady, also before your latest
>> changes, with
>>
>> $1=x^$
>>
>> the last "$" is raised, as it should be, but adding the "2" fixes the
>> position of "$" immediately.
>
> Yeah, yeah, that's already fixed. :-)
>
> Bye,
> Tassilo
>
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 17:53:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
2017-01-04 18:43 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
> Anyway, my sense for aesthetics is very rudimentary so you have to
> explain to me where the bug is. What I did, however, is that I changed
> the default raise values from ±0.3 to ±0.5. So indeed the superscripts
> are a bit more raised and the subscripts a bit more lowered.
The bug, in my opinion, is that the "2" is slightly above of "^", and
"3" is slightly below of "_". In particular the subscript is more
problematic because it looks like it's written "-3" (ok, in my example
there are braces, ideally remove them). My suggestion is just to put
"^" and "_" at the same level as the scripts (as I think it was
before, at least it looks like this).
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Wed, 04 Jan 2017 19:09:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Mosè,
> The bug, in my opinion, is that the "2" is slightly above of "^", and
> "3" is slightly below of "_". In particular the subscript is more
> problematic because it looks like it's written "-3" (ok, in my example
> there are braces, ideally remove them). My suggestion is just to put
> "^" and "_" at the same level as the scripts (as I think it was
> before, at least it looks like this).
No, the scripts have always been at the base level, just the sub/super
script formula was raised. But you are right that when raising with a
factor of 0.5 especially the _ is pretty much in the middle of the
lowered formula thus could be confused with a minus.
Hm, also raising/lowering the ^ and _ seems to be a littlebit more
involved... I tried that once (and it was buggy) but I didn't try it
more because it didn't look good in my opinion (too small and somehow
strange).
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 05 Jan 2017 10:12:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
> The bug, in my opinion, is that the "2" is slightly above of "^", and
> "3" is slightly below of "_". In particular the subscript is more
> problematic because it looks like it's written "-3" (ok, in my example
> there are braces, ideally remove them).
I think I came up with a solution: fontify the script characters
themselves with a custom face. Thereby, I also made the code that makes
^ and _ invisible if `font-latex-fontify-script' is `invisible' a bit
better so that errors like $x^^2$ or $x^_2$ aren't hidden anymore.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 05 Jan 2017 11:53:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Tassilo,
2017-01-05 11:11 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
>
> I think I came up with a solution: fontify the script characters
> themselves with a custom face.
I like this solution, I'm starting to love the multi-level mode
(though I don't think I'll personally use many nested scripts)!
Fontifying those characters differently from the rest of the equation
is really effective and does solve the issue you mentioned in
invisible mode.
However, I don't think it completely solves the problem I reported,
just works around it ;-) This is more evident in multi-level mode,
see the attached screenshot (I swear it's there this time!). The
caret is (almost always) in the wrong position, compared to the number
it is raising. In my opinion, the top of the caret should line up
with the top of what it raises, see the "^{2}" in the text line below
the equation. Of course, something similar for the underscore.
Bye,
Mosè
[nested-superscripts.png (image/png, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 05 Jan 2017 12:24:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
2017-01-05 12:51 GMT+01:00 Mosè Giordano <mose <at> gnu.org>:
> In my opinion, the top of the caret should line up
> with the top of what it raises, see the "^{2}" in the text line below
> the equation. Of course, something similar for the underscore.
Thinking about this twice, this may not be the best solution, because
the caret could be too much high compared to the base of the power
(and the same for the underscore). There will be anyway a tension
between keeping the carte close to the base and to the exponent.
Something in the middle?
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 05 Jan 2017 12:33:01 GMT)
Full text and
rfc822 format available.
Message #154 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
I know what I did wrong. Will fix when I'm back home.
Bye,
Tassilo
Am 5. Januar 2017 13:23:00 schrieb Mosè Giordano <mose <at> gnu.org>:
> 2017-01-05 12:51 GMT+01:00 Mosè Giordano <mose <at> gnu.org>:
>> In my opinion, the top of the caret should line up
>> with the top of what it raises, see the "^{2}" in the text line below
>> the equation. Of course, something similar for the underscore.
>
> Thinking about this twice, this may not be the best solution, because
> the caret could be too much high compared to the base of the power
> (and the same for the underscore). There will be anyway a tension
> between keeping the carte close to the base and to the exponent.
> Something in the middle?
>
> Bye,
> Mosè
>
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 05 Jan 2017 13:02:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Mosè Giordano <mose <at> gnu.org> writes:
Hi Mosè,
> However, I don't think it completely solves the problem I reported,
> just works around it ;-) This is more evident in multi-level mode, see
> the attached screenshot (I swear it's there this time!).
Oh, it is indeed!
> The caret is (almost always) in the wrong position, compared to the
> number it is raising. In my opinion, the top of the caret should line
> up with the top of what it raises, see the "^{2}" in the text line
> below the equation. Of course, something similar for the underscore.
The problem was that the face/display specs for the script chars
replaced the existing specs (math and sub/superscript), thus they were
never shrunken. Now I prepend the spec which means that the shrinking
happens also for ^_ which are themselves part of a sub- or superscript.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 05 Jan 2017 16:09:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
2017-01-05 14:01 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
> The problem was that the face/display specs for the script chars
> replaced the existing specs (math and sub/superscript), thus they were
> never shrunken. Now I prepend the spec which means that the shrinking
> happens also for ^_ which are themselves part of a sub- or superscript.
Very good! My problem is still there, but the different face is a
nice compromise. Thank you!
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 05 Jan 2017 20:42:01 GMT)
Full text and
rfc822 format available.
Message #163 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
>>> "Tassilo" == Tassilo Horn <tsdh <at> gnu.org> writes:
Hi Tassilo
> The problem was that the face/display specs for the script chars
> replaced the existing specs (math and sub/superscript), thus they were
> never shrunken. Now I prepend the spec which means that the shrinking
> happens also for ^_ which are themselves part of a sub- or superscript.
Thanks very much for all your effort, it works now very nicely!
Uwe
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Fri, 06 Jan 2017 11:46:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
> I know what I did wrong. Will fix when I'm back home.
Hi Tassilo,
thanks a ton for doing this. I think there is an issue with the code
since I'm getting the following in *Message* buffer:
Error during redisplay: (jit-lock-function 1) signaled (void-function copy-list)
Recipe for invoking:
\documentclass{article}
%% eval first:
%% (jit-lock-debug-mode 1)
%% (setq debug-on-error t)
\begin{document}
Put point inside math $$ and press `_'
\end{document}
Results in:
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-function copy-list)
copy-list((raise -0.5))
font-latex--get-script-props(136 :sub)
font-latex-script(136)
eval((font-latex-script (match-beginning 0)))
font-lock-fontify-keywords-region(113 153 nil)
font-lock-default-fontify-region(113 153 nil)
font-latex-fontify-region(113 153 nil)
font-lock-fontify-region(113 153)
#[257 "\211\300\301\"\211\242\306=\203
run-hook-wrapped(#[257 "\211\300\301\"\211\242\306=\203
jit-lock--run-functions(113 153)
jit-lock-fontify-now(113 153)
jit-lock--debug-fontify()
apply(jit-lock--debug-fontify nil)
timer-event-handler([t 0 0 0 t jit-lock--debug-fontify nil idle 0])
--8<---------------cut here---------------end--------------->8---
Can others reproduce this?
Best, Arash
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Fri, 06 Jan 2017 14:28:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Arash Esbati <arash.esbati+ml <at> gmail.com> writes:
Hi Arash,
> thanks a ton for doing this.
You're welcome.
> I think there is an issue with the code since I'm getting the
> following in *Message* buffer:
>
> Error during redisplay: (jit-lock-function 1) signaled (void-function copy-list)
Ah, copy-list is a cl function which might not be available. I replaced
it with the builtin `copy-sequence' which seems to be available in all
supported Emacs and XEmacs versions.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Fri, 06 Jan 2017 14:46:02 GMT)
Full text and
rfc822 format available.
Message #172 received at 25309-done <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
> Arash Esbati <arash.esbati+ml <at> gmail.com> writes:
>
>> I think there is an issue with the code since I'm getting the
>> following in *Message* buffer:
>>
>> Error during redisplay: (jit-lock-function 1) signaled (void-function copy-list)
>
> Ah, copy-list is a cl function which might not be available. I replaced
> it with the builtin `copy-sequence' which seems to be available in all
> supported Emacs and XEmacs versions.
Thanks! Confirmed, it is fixed now.
Best, Arash
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 07:40:02 GMT)
Full text and
rfc822 format available.
Message #175 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi All,
in the attached screenshot with newly released 11.90, one sees
a feature which I find a bit disturbing: all the subscripts look
like they have a leading minus sign, where in fact it is the underscore
character.
Have you discussed that in the thread already ?
(I read it back then but did not follow all details)
I suppose this is expected result, and as my memory reboots
on each 24h cycle, it may even have nothing to do with this thread
and was like this for ages, but I come asking nevertheless.
The foo^{\psi_n} is ok but all foo_{bar} get the underscore aligned
with exact middle of brace which creates (from a distance and with an
ageing user) this impression about minus signs everywhere.
Cheers
Jean-François
[Capture d’écran 2017-01-12 à 08.28.45.png (image/png, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 17:36:02 GMT)
Full text and
rfc822 format available.
Message #178 received at submit <at> debbugs.gnu.org (full text, mbox):
Le 12/01/2017 à 08:38, jfbu a écrit :
> The foo^{\psi_n} is ok but all foo_{bar} get the underscore aligned
> with exact middle of brace which creates (from a distance and with an
> ageing user) this impression about minus signs everywhere.
1. my screenshot is possibly dependent on the font, DejaVu Sans Mono
2. by the way with foo_{bar}, having the _ at the main baseline and the
{bar} with its top at the level of the _, which perhaps is not the
thing one would do a priori, looks like a good option to me. Better
than moving deep down the _ so that it looks like _{bar}, and better
(to me) than having as in my screenshot the _{bar} look like -{bar}
is there a way I can configure the Tassilo's variables so that it looks like
A_
B_
C
sort of ? (with smaller typefaces)
Best,
Jean-François
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 18:38:02 GMT)
Full text and
rfc822 format available.
Message #181 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Hi Jean-François,
2017-01-12 8:38 GMT+01:00 jfbu <jfbu <at> free.fr>:
> Hi All,
>
> in the attached screenshot with newly released 11.90, one sees
> a feature which I find a bit disturbing: all the subscripts look
> like they have a leading minus sign, where in fact it is the underscore
> character.
>
> Have you discussed that in the thread already ?
> (I read it back then but did not follow all details)
>
> I suppose this is expected result, and as my memory reboots
> on each 24h cycle, it may even have nothing to do with this thread
> and was like this for ages, but I come asking nevertheless.
>
> The foo^{\psi_n} is ok but all foo_{bar} get the underscore aligned
> with exact middle of brace which creates (from a distance and with an
> ageing user) this impression about minus signs everywhere.
Yes, the discussion about this issue started with this message:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25309#127 Indeed the
change of the face of caret and underscore was meant to address this
issue.
In any case I strongly suggest you to set
`TeX-electric-sub-and-superscript' to t, I always find it very useful
also for single character script (in that case braces are redundant,
of course, but they improve readability, IMHO).
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 18:52:01 GMT)
Full text and
rfc822 format available.
Message #184 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Mosè,
thanks but regarding
Le 12/01/2017 à 19:37, Mosè Giordano a écrit :
> In any case I strongly suggest you to set
> `TeX-electric-sub-and-superscript' to t, I always find it very useful
> also for single character script (in that case braces are redundant,
> of course, but they improve readability, IMHO).
it does not work for me (the stuff on top of screenshot was typed
in after having set the variable, and no braces appeared, did I miss
something ?)
but maybe it is time I read the doc first ... ;-)
best,
Jean-François
[Capture d’écran 2017-01-12 à 19.47.53.png (image/png, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 18:59:02 GMT)
Full text and
rfc822 format available.
Message #187 received at 25309 <at> debbugs.gnu.org (full text, mbox):
2017-01-12 19:50 GMT+01:00 jfbu <jfbu <at> free.fr>:
> Hi Mosè,
>
> thanks but regarding
>
> Le 12/01/2017 à 19:37, Mosè Giordano a écrit :
>>
>> In any case I strongly suggest you to set
>> `TeX-electric-sub-and-superscript' to t, I always find it very useful
>> also for single character script (in that case braces are redundant,
>> of course, but they improve readability, IMHO).
>
>
> it does not work for me (the stuff on top of screenshot was typed
> in after having set the variable, and no braces appeared, did I miss
> something ?)
What is "^" bound to? Issue
C-h k ^
Bye,
Mosè
PS: double super- subscripts are not allowed in TeX ;-)
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 19:02:01 GMT)
Full text and
rfc822 format available.
Message #190 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Le 12/01/2017 à 19:57, Mosè Giordano a écrit :
> 2017-01-12 19:50 GMT+01:00 jfbu <jfbu <at> free.fr>:
>> Hi Mosè,
>
> What is "^" bound to? Issue
>
> C-h k ^
>
^ runs the command TeX-insert-sub-or-superscript (found in LaTeX-mode-map),
which is an interactive compiled Lisp function in âtex.elâ.
It is bound to _, ^.
(TeX-insert-sub-or-superscript ARG)
Insert typed key ARG times and possibly a pair of braces.
Brace insertion is only done if point is in a math construct and
âTeX-electric-sub-and-superscriptâ has a non-nil value.
[back]
> Bye,
> Mosè
>
> PS: double super- subscripts are not allowed in TeX ;-)
>
try \input xintexpr.sty\relax\xinttheexpr 2^3^4\relax ;-)
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 19:09:02 GMT)
Full text and
rfc822 format available.
Message #193 received at 25309 <at> debbugs.gnu.org (full text, mbox):
I get the script raising to work fine, but under the condition
of typing explicitely braces, i.e.
\( x^{y^{z^a_b}} \)
does the expected thing from the docs after having set to
multi-level the âfont-latex-fontify-scriptâ, but the thing
about electric scripts does not seem to work
\( x^y_z \) does not insert the braces while typing
even with
% Local variables:
% TeX-electric-sub-and-superscript: t
% End:
and reloading the file
Best,
Jean-François
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 19:25:01 GMT)
Full text and
rfc822 format available.
Message #196 received at 25309 <at> debbugs.gnu.org (full text, mbox):
2017-01-12 20:01 GMT+01:00 jfbu <jfbu <at> free.fr>:
> Le 12/01/2017 à 19:57, Mosè Giordano a écrit :
>>
>> 2017-01-12 19:50 GMT+01:00 jfbu <jfbu <at> free.fr>:
>>>
>>> Hi Mosè,
>>
>>
>> What is "^" bound to? Issue
>>
>> C-h k ^
>>
>
> ^ runs the command TeX-insert-sub-or-superscript (found in LaTeX-mode-map),
> which is an interactive compiled Lisp function in âtex.elâ.
>
> It is bound to _, ^.
>
> (TeX-insert-sub-or-superscript ARG)
>
> Insert typed key ARG times and possibly a pair of braces.
> Brace insertion is only done if point is in a math construct and
> âTeX-electric-sub-and-superscriptâ has a non-nil value.
Uh, I don't know what's happening here. Could you please open a new ticket?
> try \input xintexpr.sty\relax\xinttheexpr 2^3^4\relax ;-)
Cool!
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 19:42:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 25309 <at> debbugs.gnu.org (full text, mbox):
2017-01-12 20:08 GMT+01:00 jfbu <jfbu <at> free.fr>:
> I get the script raising to work fine, but under the condition
> of typing explicitely braces, i.e.
>
> \( x^{y^{z^a_b}} \)
>
> does the expected thing from the docs after having set to
> multi-level the âfont-latex-fontify-scriptâ, but the thing
> about electric scripts does not seem to work
>
> \( x^y_z \) does not insert the braces while typing
> even with
>
> % Local variables:
> % TeX-electric-sub-and-superscript: t
> % End:
Does the equation "\( x^y_z \)" start at the beginning of the buffer?
`texmathp' cannot recognize math mode \(...\) starting at bob. In any
other place it should work fine. If this is not the culprit, please
open a new issue.
Bye,
Mosè
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 19:48:01 GMT)
Full text and
rfc822 format available.
Message #202 received at 25309 <at> debbugs.gnu.org (full text, mbox):
Le 12 janv. 2017 à 20:40, Mosè Giordano <mose <at> gnu.org> a écrit :
> 2017-01-12 20:08 GMT+01:00 jfbu <jfbu <at> free.fr>:
>> I get the script raising to work fine, but under the condition
>> of typing explicitely braces, i.e.
>>
>> \( x^{y^{z^a_b}} \)
>>
>> does the expected thing from the docs after having set to
>> multi-level the âfont-latex-fontify-scriptâ, but the thing
>> about electric scripts does not seem to work
>>
>> \( x^y_z \) does not insert the braces while typing
>> even with
>>
>> % Local variables:
>> % TeX-electric-sub-and-superscript: t
>> % End:
>
> Does the equation "\( x^y_z \)" start at the beginning of the buffer?
> `texmathp' cannot recognize math mode \(...\) starting at bob. In any
> other place it should work fine. If this is not the culprit, please
> open a new issue.
>
no it did not start at beginning of buffer but was rather
located at its end. I will open a new issue
(a bit later)
after having looked if something in my .emacs setup causes conflict.
may it have something to do with keyboard input? wait.. I usually
type ^ then SPACE then another char ... no typing x^y directly
without hitting the space bar does not change anything
(the ^ is waiting to see if it will be ê, or ô etc...)
all works fine, but this electric thing.
Best,
Jean-François
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 20:44:02 GMT)
Full text and
rfc822 format available.
Message #205 received at submit <at> debbugs.gnu.org (full text, mbox):
Le 12/01/2017 à 20:40, Mosè Giordano a écrit :
> 2017-01-12 20:08 GMT+01:00 jfbu <jfbu <at> free.fr>:
>> I get the script raising to work fine, but under the condition
>> of typing explicitely braces, i.e.
>>
>> \( x^{y^{z^a_b}} \)
>>
>> does the expected thing from the docs after having set to
>> multi-level the âfont-latex-fontify-scriptâ, but the thing
>> about electric scripts does not seem to work
>>
>> \( x^y_z \) does not insert the braces while typing
>> even with
>>
>> % Local variables:
>> % TeX-electric-sub-and-superscript: t
>> % End:
>
> Does the equation "\( x^y_z \)" start at the beginning of the buffer?
> `texmathp' cannot recognize math mode \(...\) starting at bob. In any
> other place it should work fine. If this is not the culprit, please
> open a new issue.
>
Mystery solved. (I had to cook dinner and then I paid my dues
to politicians on TV -- for a short while)
Looking again at your message the `texmathp' rang a bell
(some problem we discussed here months ago, which I have forgotten
now)
turns out I had this setting:
texmathp-search-n-paragraphs is a variable defined in âtexmathp.elâ.
Its value is 0
Original value was 2
setting it back to 2 solves the issue.
Best wishes,
Jean-François
Information forwarded
to
bug-auctex <at> gnu.org:
bug#25309; Package
auctex.
(Thu, 12 Jan 2017 20:50:02 GMT)
Full text and
rfc822 format available.
Message #208 received at submit <at> debbugs.gnu.org (full text, mbox):
Le 12/01/2017 à 21:43, jfbu a écrit :
> (some problem we discussed here months ago, which I have forgotten
> now)
the problem was about use in .dtx file which will never have empty
line in the implementation section due to % prefix.
in my dtx, the documentation section has no % prefix (it has I
think in most other people's dtx's) but nevertheless it may happen
that the dtx is very long and this caused problem from inside the
code section (you can not allow empty lines in code sections
because this create \par tokens that may not be important in LaTeX
context if located in preamble, but may be annoying in TeX
contexts where one can \input style file anywhere), hence I had to
set texmathp-search-n-paragraphs to 0.
I would not need it to be 0 in .tex files.
Best,
Jean-François
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 10 Feb 2017 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 187 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.