Bad neighbours: amscd and mtpro2
The following code shows how amscd
and mtpro2
do not play well together with the subscriptcorrection
option enabled:
documentclass{article}
usepackage[subscriptcorrection]{mtpro2}
usepackage{amscd}
begin{document}
[
begin{CD}
H_{R}(U) @>d >> B
end{CD}
]
end{document}
This halts with the error
! Package amscd Error: Invalid use of @.
It can be sort of corrected with
disablesubscriptcorrection
before the diagram, but the results are less than optimal.
I expect that the problem has to do with catcode values of _ like in here, but nonetheless the conflict is there. The question is:
Who is at fault here? amscd
or mtpro2
? Or even LaTeX for now allowing interaction between packages.
amsmath mtpro
add a comment |
The following code shows how amscd
and mtpro2
do not play well together with the subscriptcorrection
option enabled:
documentclass{article}
usepackage[subscriptcorrection]{mtpro2}
usepackage{amscd}
begin{document}
[
begin{CD}
H_{R}(U) @>d >> B
end{CD}
]
end{document}
This halts with the error
! Package amscd Error: Invalid use of @.
It can be sort of corrected with
disablesubscriptcorrection
before the diagram, but the results are less than optimal.
I expect that the problem has to do with catcode values of _ like in here, but nonetheless the conflict is there. The question is:
Who is at fault here? amscd
or mtpro2
? Or even LaTeX for now allowing interaction between packages.
amsmath mtpro
2
An unfortunate combination of circumstances.
– egreg
Jan 23 at 18:44
@Sebastiano That's indeed the problem to solve.
– egreg
Jan 23 at 18:45
@egreg Sorry I thought it was just the problem of the position of@
or TeX primitive syntax$$...$$
. I have deleted my previous comment for your edit = my comment. Thank you always very much.
– Sebastiano
Jan 23 at 18:48
add a comment |
The following code shows how amscd
and mtpro2
do not play well together with the subscriptcorrection
option enabled:
documentclass{article}
usepackage[subscriptcorrection]{mtpro2}
usepackage{amscd}
begin{document}
[
begin{CD}
H_{R}(U) @>d >> B
end{CD}
]
end{document}
This halts with the error
! Package amscd Error: Invalid use of @.
It can be sort of corrected with
disablesubscriptcorrection
before the diagram, but the results are less than optimal.
I expect that the problem has to do with catcode values of _ like in here, but nonetheless the conflict is there. The question is:
Who is at fault here? amscd
or mtpro2
? Or even LaTeX for now allowing interaction between packages.
amsmath mtpro
The following code shows how amscd
and mtpro2
do not play well together with the subscriptcorrection
option enabled:
documentclass{article}
usepackage[subscriptcorrection]{mtpro2}
usepackage{amscd}
begin{document}
[
begin{CD}
H_{R}(U) @>d >> B
end{CD}
]
end{document}
This halts with the error
! Package amscd Error: Invalid use of @.
It can be sort of corrected with
disablesubscriptcorrection
before the diagram, but the results are less than optimal.
I expect that the problem has to do with catcode values of _ like in here, but nonetheless the conflict is there. The question is:
Who is at fault here? amscd
or mtpro2
? Or even LaTeX for now allowing interaction between packages.
amsmath mtpro
amsmath mtpro
edited Jan 24 at 22:00
Paulo Ney
asked Jan 23 at 17:51
Paulo NeyPaulo Ney
1,117917
1,117917
2
An unfortunate combination of circumstances.
– egreg
Jan 23 at 18:44
@Sebastiano That's indeed the problem to solve.
– egreg
Jan 23 at 18:45
@egreg Sorry I thought it was just the problem of the position of@
or TeX primitive syntax$$...$$
. I have deleted my previous comment for your edit = my comment. Thank you always very much.
– Sebastiano
Jan 23 at 18:48
add a comment |
2
An unfortunate combination of circumstances.
– egreg
Jan 23 at 18:44
@Sebastiano That's indeed the problem to solve.
– egreg
Jan 23 at 18:45
@egreg Sorry I thought it was just the problem of the position of@
or TeX primitive syntax$$...$$
. I have deleted my previous comment for your edit = my comment. Thank you always very much.
– Sebastiano
Jan 23 at 18:48
2
2
An unfortunate combination of circumstances.
– egreg
Jan 23 at 18:44
An unfortunate combination of circumstances.
– egreg
Jan 23 at 18:44
@Sebastiano That's indeed the problem to solve.
– egreg
Jan 23 at 18:45
@Sebastiano That's indeed the problem to solve.
– egreg
Jan 23 at 18:45
@egreg Sorry I thought it was just the problem of the position of
@
or TeX primitive syntax $$...$$
. I have deleted my previous comment for your edit = my comment. Thank you always very much.– Sebastiano
Jan 23 at 18:48
@egreg Sorry I thought it was just the problem of the position of
@
or TeX primitive syntax $$...$$
. I have deleted my previous comment for your edit = my comment. Thank you always very much.– Sebastiano
Jan 23 at 18:48
add a comment |
1 Answer
1
active
oldest
votes
The problem clearly is in the subscript: mtpro2
makes _
math active and its expansion throws in a redefinition of the scratch macro next
, which CD
expects not to change.
Whose fault is it? This question has no answer, I'm afraid. Possibly the most culpable is CD
, where next
is used in a dubious way, assuming its meaning will not change for a long span of time. However, it's quite late for changing it.
A simple workaround would be protecting the entry by braces.
begin{CD}
{H_{R}(U)} @>d >> B
end{CD}
The issue can also be fixed on the mtpro2
side using a different command name than next
in a crucial macro.
documentclass{article}
usepackage{amsmath}
usepackage{amscd}
usepackage[subscriptcorrection,lite]{mtpro2}
makeatletter
begingrouplccode`~=`_
lowercase{endgroupdef~}{futureletnext@@@s@@b}
defs@@b{ifcatrelaxnoexpandnext@@@expandaftersbelse
expandafters@@b@fi}
makeatother
begin{document}
[
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
[
disablesubscriptcorrection
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
end{document}
I added the version with disablesubscriptcorrection
to show that the correction is indeed done as expected in the first diagram.
There are much better packages for diagrams, which won't suffer from this problem.
Just by way of example, here's a diagram impossible to draw with CD
; it sports the subscript correction and also arrow matching those of mtpro2
.
documentclass{article}
usepackage{amsmath}
usepackage[subscriptcorrection,lite]{mtpro2}
usepackage{tikz-cd}
tikzcdset{arrow style=math font}
begin{document}
[
begin{tikzcd}
H_{A}(U) arrow[r,"d"] arrow[dr,"varphi"] &
B arrow[d]
\
& C
end{tikzcd}
]
end{document}
I have two questions, the first one of them is -- it seems that the problem is with LaTeX then, for now allowing a space where conflicting definitions would trespass on one another?
– Paulo Ney
Jan 23 at 18:58
the other being: What are thebetter packages
for diagrams? As far as I know bothxymatrix
anddisgrams
suffer from the same issues...
– Paulo Ney
Jan 23 at 19:00
1
@PauloNey not sure what you mean by the problem is with latex. TeX is a macro expansion language and there is no namespacing or encapsulation of internal implementation of commands, All definitions have potential conflict with all other definitions, it is only by social contract of packages using "hopefully unique" names likemypackage@next
that such conflicts can be avoided.
– David Carlisle
Jan 23 at 21:00
@DavidCarlisle that is exactly what I meant, there is no namespacing, but latex could enforce a naming convention for the macros -- in order to make the packages better neighbours.
– Paulo Ney
Jan 24 at 21:59
@PauloNey how can it enforce it? it's recommended for latex2e and made more or less essential for natural use in expl3/latex but even in expl3 code there is virtually no way to enforce it. latex is written in tex it can not change the rules of that language.
– David Carlisle
Jan 24 at 22:10
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f471545%2fbad-neighbours-amscd-and-mtpro2%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The problem clearly is in the subscript: mtpro2
makes _
math active and its expansion throws in a redefinition of the scratch macro next
, which CD
expects not to change.
Whose fault is it? This question has no answer, I'm afraid. Possibly the most culpable is CD
, where next
is used in a dubious way, assuming its meaning will not change for a long span of time. However, it's quite late for changing it.
A simple workaround would be protecting the entry by braces.
begin{CD}
{H_{R}(U)} @>d >> B
end{CD}
The issue can also be fixed on the mtpro2
side using a different command name than next
in a crucial macro.
documentclass{article}
usepackage{amsmath}
usepackage{amscd}
usepackage[subscriptcorrection,lite]{mtpro2}
makeatletter
begingrouplccode`~=`_
lowercase{endgroupdef~}{futureletnext@@@s@@b}
defs@@b{ifcatrelaxnoexpandnext@@@expandaftersbelse
expandafters@@b@fi}
makeatother
begin{document}
[
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
[
disablesubscriptcorrection
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
end{document}
I added the version with disablesubscriptcorrection
to show that the correction is indeed done as expected in the first diagram.
There are much better packages for diagrams, which won't suffer from this problem.
Just by way of example, here's a diagram impossible to draw with CD
; it sports the subscript correction and also arrow matching those of mtpro2
.
documentclass{article}
usepackage{amsmath}
usepackage[subscriptcorrection,lite]{mtpro2}
usepackage{tikz-cd}
tikzcdset{arrow style=math font}
begin{document}
[
begin{tikzcd}
H_{A}(U) arrow[r,"d"] arrow[dr,"varphi"] &
B arrow[d]
\
& C
end{tikzcd}
]
end{document}
I have two questions, the first one of them is -- it seems that the problem is with LaTeX then, for now allowing a space where conflicting definitions would trespass on one another?
– Paulo Ney
Jan 23 at 18:58
the other being: What are thebetter packages
for diagrams? As far as I know bothxymatrix
anddisgrams
suffer from the same issues...
– Paulo Ney
Jan 23 at 19:00
1
@PauloNey not sure what you mean by the problem is with latex. TeX is a macro expansion language and there is no namespacing or encapsulation of internal implementation of commands, All definitions have potential conflict with all other definitions, it is only by social contract of packages using "hopefully unique" names likemypackage@next
that such conflicts can be avoided.
– David Carlisle
Jan 23 at 21:00
@DavidCarlisle that is exactly what I meant, there is no namespacing, but latex could enforce a naming convention for the macros -- in order to make the packages better neighbours.
– Paulo Ney
Jan 24 at 21:59
@PauloNey how can it enforce it? it's recommended for latex2e and made more or less essential for natural use in expl3/latex but even in expl3 code there is virtually no way to enforce it. latex is written in tex it can not change the rules of that language.
– David Carlisle
Jan 24 at 22:10
|
show 1 more comment
The problem clearly is in the subscript: mtpro2
makes _
math active and its expansion throws in a redefinition of the scratch macro next
, which CD
expects not to change.
Whose fault is it? This question has no answer, I'm afraid. Possibly the most culpable is CD
, where next
is used in a dubious way, assuming its meaning will not change for a long span of time. However, it's quite late for changing it.
A simple workaround would be protecting the entry by braces.
begin{CD}
{H_{R}(U)} @>d >> B
end{CD}
The issue can also be fixed on the mtpro2
side using a different command name than next
in a crucial macro.
documentclass{article}
usepackage{amsmath}
usepackage{amscd}
usepackage[subscriptcorrection,lite]{mtpro2}
makeatletter
begingrouplccode`~=`_
lowercase{endgroupdef~}{futureletnext@@@s@@b}
defs@@b{ifcatrelaxnoexpandnext@@@expandaftersbelse
expandafters@@b@fi}
makeatother
begin{document}
[
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
[
disablesubscriptcorrection
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
end{document}
I added the version with disablesubscriptcorrection
to show that the correction is indeed done as expected in the first diagram.
There are much better packages for diagrams, which won't suffer from this problem.
Just by way of example, here's a diagram impossible to draw with CD
; it sports the subscript correction and also arrow matching those of mtpro2
.
documentclass{article}
usepackage{amsmath}
usepackage[subscriptcorrection,lite]{mtpro2}
usepackage{tikz-cd}
tikzcdset{arrow style=math font}
begin{document}
[
begin{tikzcd}
H_{A}(U) arrow[r,"d"] arrow[dr,"varphi"] &
B arrow[d]
\
& C
end{tikzcd}
]
end{document}
I have two questions, the first one of them is -- it seems that the problem is with LaTeX then, for now allowing a space where conflicting definitions would trespass on one another?
– Paulo Ney
Jan 23 at 18:58
the other being: What are thebetter packages
for diagrams? As far as I know bothxymatrix
anddisgrams
suffer from the same issues...
– Paulo Ney
Jan 23 at 19:00
1
@PauloNey not sure what you mean by the problem is with latex. TeX is a macro expansion language and there is no namespacing or encapsulation of internal implementation of commands, All definitions have potential conflict with all other definitions, it is only by social contract of packages using "hopefully unique" names likemypackage@next
that such conflicts can be avoided.
– David Carlisle
Jan 23 at 21:00
@DavidCarlisle that is exactly what I meant, there is no namespacing, but latex could enforce a naming convention for the macros -- in order to make the packages better neighbours.
– Paulo Ney
Jan 24 at 21:59
@PauloNey how can it enforce it? it's recommended for latex2e and made more or less essential for natural use in expl3/latex but even in expl3 code there is virtually no way to enforce it. latex is written in tex it can not change the rules of that language.
– David Carlisle
Jan 24 at 22:10
|
show 1 more comment
The problem clearly is in the subscript: mtpro2
makes _
math active and its expansion throws in a redefinition of the scratch macro next
, which CD
expects not to change.
Whose fault is it? This question has no answer, I'm afraid. Possibly the most culpable is CD
, where next
is used in a dubious way, assuming its meaning will not change for a long span of time. However, it's quite late for changing it.
A simple workaround would be protecting the entry by braces.
begin{CD}
{H_{R}(U)} @>d >> B
end{CD}
The issue can also be fixed on the mtpro2
side using a different command name than next
in a crucial macro.
documentclass{article}
usepackage{amsmath}
usepackage{amscd}
usepackage[subscriptcorrection,lite]{mtpro2}
makeatletter
begingrouplccode`~=`_
lowercase{endgroupdef~}{futureletnext@@@s@@b}
defs@@b{ifcatrelaxnoexpandnext@@@expandaftersbelse
expandafters@@b@fi}
makeatother
begin{document}
[
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
[
disablesubscriptcorrection
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
end{document}
I added the version with disablesubscriptcorrection
to show that the correction is indeed done as expected in the first diagram.
There are much better packages for diagrams, which won't suffer from this problem.
Just by way of example, here's a diagram impossible to draw with CD
; it sports the subscript correction and also arrow matching those of mtpro2
.
documentclass{article}
usepackage{amsmath}
usepackage[subscriptcorrection,lite]{mtpro2}
usepackage{tikz-cd}
tikzcdset{arrow style=math font}
begin{document}
[
begin{tikzcd}
H_{A}(U) arrow[r,"d"] arrow[dr,"varphi"] &
B arrow[d]
\
& C
end{tikzcd}
]
end{document}
The problem clearly is in the subscript: mtpro2
makes _
math active and its expansion throws in a redefinition of the scratch macro next
, which CD
expects not to change.
Whose fault is it? This question has no answer, I'm afraid. Possibly the most culpable is CD
, where next
is used in a dubious way, assuming its meaning will not change for a long span of time. However, it's quite late for changing it.
A simple workaround would be protecting the entry by braces.
begin{CD}
{H_{R}(U)} @>d >> B
end{CD}
The issue can also be fixed on the mtpro2
side using a different command name than next
in a crucial macro.
documentclass{article}
usepackage{amsmath}
usepackage{amscd}
usepackage[subscriptcorrection,lite]{mtpro2}
makeatletter
begingrouplccode`~=`_
lowercase{endgroupdef~}{futureletnext@@@s@@b}
defs@@b{ifcatrelaxnoexpandnext@@@expandaftersbelse
expandafters@@b@fi}
makeatother
begin{document}
[
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
[
disablesubscriptcorrection
begin{CD}
H_{A}(U) @>d >> B
end{CD}
]
end{document}
I added the version with disablesubscriptcorrection
to show that the correction is indeed done as expected in the first diagram.
There are much better packages for diagrams, which won't suffer from this problem.
Just by way of example, here's a diagram impossible to draw with CD
; it sports the subscript correction and also arrow matching those of mtpro2
.
documentclass{article}
usepackage{amsmath}
usepackage[subscriptcorrection,lite]{mtpro2}
usepackage{tikz-cd}
tikzcdset{arrow style=math font}
begin{document}
[
begin{tikzcd}
H_{A}(U) arrow[r,"d"] arrow[dr,"varphi"] &
B arrow[d]
\
& C
end{tikzcd}
]
end{document}
edited Jan 23 at 21:47
answered Jan 23 at 18:24
egregegreg
716k8619023190
716k8619023190
I have two questions, the first one of them is -- it seems that the problem is with LaTeX then, for now allowing a space where conflicting definitions would trespass on one another?
– Paulo Ney
Jan 23 at 18:58
the other being: What are thebetter packages
for diagrams? As far as I know bothxymatrix
anddisgrams
suffer from the same issues...
– Paulo Ney
Jan 23 at 19:00
1
@PauloNey not sure what you mean by the problem is with latex. TeX is a macro expansion language and there is no namespacing or encapsulation of internal implementation of commands, All definitions have potential conflict with all other definitions, it is only by social contract of packages using "hopefully unique" names likemypackage@next
that such conflicts can be avoided.
– David Carlisle
Jan 23 at 21:00
@DavidCarlisle that is exactly what I meant, there is no namespacing, but latex could enforce a naming convention for the macros -- in order to make the packages better neighbours.
– Paulo Ney
Jan 24 at 21:59
@PauloNey how can it enforce it? it's recommended for latex2e and made more or less essential for natural use in expl3/latex but even in expl3 code there is virtually no way to enforce it. latex is written in tex it can not change the rules of that language.
– David Carlisle
Jan 24 at 22:10
|
show 1 more comment
I have two questions, the first one of them is -- it seems that the problem is with LaTeX then, for now allowing a space where conflicting definitions would trespass on one another?
– Paulo Ney
Jan 23 at 18:58
the other being: What are thebetter packages
for diagrams? As far as I know bothxymatrix
anddisgrams
suffer from the same issues...
– Paulo Ney
Jan 23 at 19:00
1
@PauloNey not sure what you mean by the problem is with latex. TeX is a macro expansion language and there is no namespacing or encapsulation of internal implementation of commands, All definitions have potential conflict with all other definitions, it is only by social contract of packages using "hopefully unique" names likemypackage@next
that such conflicts can be avoided.
– David Carlisle
Jan 23 at 21:00
@DavidCarlisle that is exactly what I meant, there is no namespacing, but latex could enforce a naming convention for the macros -- in order to make the packages better neighbours.
– Paulo Ney
Jan 24 at 21:59
@PauloNey how can it enforce it? it's recommended for latex2e and made more or less essential for natural use in expl3/latex but even in expl3 code there is virtually no way to enforce it. latex is written in tex it can not change the rules of that language.
– David Carlisle
Jan 24 at 22:10
I have two questions, the first one of them is -- it seems that the problem is with LaTeX then, for now allowing a space where conflicting definitions would trespass on one another?
– Paulo Ney
Jan 23 at 18:58
I have two questions, the first one of them is -- it seems that the problem is with LaTeX then, for now allowing a space where conflicting definitions would trespass on one another?
– Paulo Ney
Jan 23 at 18:58
the other being: What are the
better packages
for diagrams? As far as I know both xymatrix
and disgrams
suffer from the same issues...– Paulo Ney
Jan 23 at 19:00
the other being: What are the
better packages
for diagrams? As far as I know both xymatrix
and disgrams
suffer from the same issues...– Paulo Ney
Jan 23 at 19:00
1
1
@PauloNey not sure what you mean by the problem is with latex. TeX is a macro expansion language and there is no namespacing or encapsulation of internal implementation of commands, All definitions have potential conflict with all other definitions, it is only by social contract of packages using "hopefully unique" names like
mypackage@next
that such conflicts can be avoided.– David Carlisle
Jan 23 at 21:00
@PauloNey not sure what you mean by the problem is with latex. TeX is a macro expansion language and there is no namespacing or encapsulation of internal implementation of commands, All definitions have potential conflict with all other definitions, it is only by social contract of packages using "hopefully unique" names like
mypackage@next
that such conflicts can be avoided.– David Carlisle
Jan 23 at 21:00
@DavidCarlisle that is exactly what I meant, there is no namespacing, but latex could enforce a naming convention for the macros -- in order to make the packages better neighbours.
– Paulo Ney
Jan 24 at 21:59
@DavidCarlisle that is exactly what I meant, there is no namespacing, but latex could enforce a naming convention for the macros -- in order to make the packages better neighbours.
– Paulo Ney
Jan 24 at 21:59
@PauloNey how can it enforce it? it's recommended for latex2e and made more or less essential for natural use in expl3/latex but even in expl3 code there is virtually no way to enforce it. latex is written in tex it can not change the rules of that language.
– David Carlisle
Jan 24 at 22:10
@PauloNey how can it enforce it? it's recommended for latex2e and made more or less essential for natural use in expl3/latex but even in expl3 code there is virtually no way to enforce it. latex is written in tex it can not change the rules of that language.
– David Carlisle
Jan 24 at 22:10
|
show 1 more comment
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f471545%2fbad-neighbours-amscd-and-mtpro2%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
An unfortunate combination of circumstances.
– egreg
Jan 23 at 18:44
@Sebastiano That's indeed the problem to solve.
– egreg
Jan 23 at 18:45
@egreg Sorry I thought it was just the problem of the position of
@
or TeX primitive syntax$$...$$
. I have deleted my previous comment for your edit = my comment. Thank you always very much.– Sebastiano
Jan 23 at 18:48