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

[jfbu]

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

2017-01-12 20:08 GMT+01:00 jfbu :

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

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

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

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

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


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



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

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

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

turns out I had this setting:

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

setting it back to 2 solves the issue.

Best wishes,

Jean-François






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

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

[jfbu]

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

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



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

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

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

Best,

Jean-François





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

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

[jfbu]

Le 12 janv. 2017 à 20:40, Mosè Giordano  a écrit :

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

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

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

all works fine, but this electric thing.

Best,
Jean-François





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

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

[Mosè Giordano]

2017-01-12 20:08 GMT+01:00 jfbu :
> I get the script raising to work fine, but under the condition
> of typing explicitely braces, i.e.
>
> \( x^{y^{z^a_b}} \)
>
> does the expected thing from the docs after having set to
> multi-level the ‘font-latex-fontify-script’, but the thing
> about electric scripts does not seem to work
>
> \( x^y_z \) does not insert the braces while typing
> even with
>
> % Local variables:
> % TeX-electric-sub-and-superscript: t
> % End:

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è



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

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

[Mosè Giordano]

2017-01-12 20:01 GMT+01:00 jfbu :
> Le 12/01/2017 à 19:57, Mosè Giordano a écrit :
>>
>> 2017-01-12 19:50 GMT+01:00 jfbu :
>>>
>>> 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è



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

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

[jfbu]

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

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

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

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

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

and reloading the file

Best,

Jean-François


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

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

[jfbu]

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

2017-01-12 19:50 GMT+01:00 jfbu :

Hi Mosè,


What is "^" bound to?  Issue

C-h k ^



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

It is bound to _, ^.

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

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

[back]


Bye,
Mosè

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



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



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

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

[jfbu]

Hi Mosè,

thanks but regarding

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

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


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

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

best,

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

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

[Mosè Giordano]

Hi Jean-François,

2017-01-12 8:38 GMT+01:00 jfbu :
> Hi All,
>
> in the attached screenshot with newly released 11.90, one sees
> a feature which I find a bit disturbing: all the subscripts look
> like they have a leading minus sign, where in fact it is the underscore
> character.
>
> Have you discussed that in the thread already ?
> (I read it back then but did not follow all details)
>
> I suppose this is expected result, and as my memory reboots
> on each 24h cycle, it may even have nothing to do with this thread
> and was like this for ages, but I come asking nevertheless.
>
> The foo^{\psi_n} is ok but all foo_{bar} get the underscore aligned
> with exact middle of brace which creates (from a distance and with an
> ageing user) this impression about minus signs everywhere.

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è



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

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

[jfbu]

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

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



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


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

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


A_
  B_
C

sort of ? (with smaller typefaces)

Best,

Jean-François
   





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

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

[jfbu]

Hi All,

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

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

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

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

Cheers

Jean-François

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

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

[Arash Esbati]

Tassilo Horn  writes:

> Arash Esbati  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



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

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

[Tassilo Horn]

Arash Esbati  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



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

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

[Arash Esbati]

Tassilo Horn  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



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

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

[Uwe Brauer]

>>> "Tassilo" == Tassilo Horn  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 



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

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

[Mosè Giordano]

2017-01-05 14:01 GMT+01:00 Tassilo Horn :
> 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è



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

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

[Tassilo Horn]

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 :


2017-01-05 12:51 GMT+01:00 Mosè Giordano :

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è







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

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

[Tassilo Horn]

Mosè Giordano  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



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

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

[Tassilo Horn]

Mosè Giordano  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



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

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

[Mosè Giordano]

2017-01-04 18:43 GMT+01:00 Tassilo Horn :
> 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è



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

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

[Gennady Uraltsev]

Hello everyone,

I can confirm that everything works. Thanks a lot!

Gennady


On 04/01/17 19:58, Tassilo Horn wrote:
> Mosè Giordano  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
Description: OpenPGP digital signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Tassilo Horn]

Mosè Giordano  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



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

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

[Tassilo Horn]

Mosè Giordano  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



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

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

[Mosè Giordano]

2017-01-04 17:08 GMT+01:00 Mosè Giordano :
> 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 :-)
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Tassilo Horn]

Gennady Uraltsev  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
Description: PGP signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Mosè Giordano]

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 :
> 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 :
>>> 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è
>>
>



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

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

[Gennady Uraltsev]

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 :
>> 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
Description: OpenPGP digital signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Mosè Giordano]

2017-01-03 16:27 GMT+01:00 Tassilo Horn :
> 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è



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

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

[Tassilo Horn]

Mosè Giordano  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



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

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

[Tassilo Horn]

Gennady Uraltsev  writes:

> Yep! Looks fantastic!
>> 
>> Absolutely great. :-D

Ok, great.  Committed and pushed!  I'm closing this bug then.

Thanks,
Tassilo


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

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

[Gennady Uraltsev]

Yep! Looks fantastic!

On 03/01/17 12:17, Uwe Brauer wrote:
 "Tassilo" == Tassilo Horn  writes:
> 
>> Tassilo Horn  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
Description: OpenPGP digital signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Uwe Brauer]

>>> "Tassilo" == Tassilo Horn  writes:

   > Tassilo Horn  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



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

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

[Tassilo Horn]

Gennady Uraltsev  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
Description: PGP signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Uwe Brauer]

>>> "Gennady" == Gennady Uraltsev  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?

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

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

[Gennady Uraltsev]

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  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
Description: OpenPGP digital signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Uwe Brauer]

   > Uwe Brauer  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 



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

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

[Tassilo Horn]

Uwe Brauer  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



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

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

[Uwe Brauer]

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





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

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

[Tassilo Horn]

Uwe Brauer  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



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

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

[Tassilo Horn]

Uwe Brauer  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



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

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

[Uwe Brauer]

> Gennady Uraltsev  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 



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

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

[Uwe Brauer]

>>> "Gennady" == Gennady Uraltsev  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 



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

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

[Tassilo Horn]

Gennady Uraltsev  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
Description: PGP signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Tassilo Horn]

Uwe Brauer  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



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

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

[Uwe Brauer]

>>> "Gennady" == Gennady Uraltsev  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.



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

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

[Gennady Uraltsev]

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  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
Description: OpenPGP digital signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Gennady Uraltsev]

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  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
Description: OpenPGP digital signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Uwe Brauer]

>>> "Tassilo" == Tassilo Horn  writes:

> Uwe Brauer  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 



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

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

[Tassilo Horn]

Uwe Brauer  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



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

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

[Uwe Brauer]

   > Mosè Giordano  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 



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

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

[Uwe Brauer]

   > Mosè Giordano  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.





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

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

[Tassilo Horn]

Mosè Giordano  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



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

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

[Tassilo Horn]

Mosè Giordano  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



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

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

[Mosè Giordano]

2016-12-31 15:57 GMT+01:00 Gennady Uraltsev :
> 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è



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

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

[Gennady Uraltsev]

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 :
>> 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
Description: OpenPGP digital signature
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

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

[Mosè Giordano]

Hi Gennady,

2016-12-31 15:12 GMT+01:00 Gennady Uraltsev :
> 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è



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