Bad neighbours: amscd and mtpro2












4















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.










share|improve this question




















  • 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


















4















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.










share|improve this question




















  • 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
















4












4








4








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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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
















  • 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












1 Answer
1






active

oldest

votes


















5














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.



enter image description here





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}


enter image description here






share|improve this answer


























  • 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






  • 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











  • @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











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
});


}
});














draft saved

draft discarded


















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









5














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.



enter image description here





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}


enter image description here






share|improve this answer


























  • 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






  • 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











  • @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
















5














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.



enter image description here





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}


enter image description here






share|improve this answer


























  • 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






  • 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











  • @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














5












5








5







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.



enter image description here





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}


enter image description here






share|improve this answer















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.



enter image description here





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}


enter image description here







share|improve this answer














share|improve this answer



share|improve this answer








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





    @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











  • @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











  • 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





    @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











  • @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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

mysqli_query(): Empty query in /home/lucindabrummitt/public_html/blog/wp-includes/wp-db.php on line 1924

How to change which sound is reproduced for terminal bell?

Can I use Tabulator js library in my java Spring + Thymeleaf project?