Minted tango theme indentation
The following mwe shows the problem I am facing:
documentclass{article}
usepackage{minted}
begin{document}
usemintedstyle{tango}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
usemintedstyle{emacs}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
end{document}
The above code produces the following output:
It can clearly be seen that the first line in the function using the tango style in incorrectly indented. Im fairly sure that this problem is minted-related and does not directly have to do with pygmentize, since I checked the output to HTML files and it seemed fine. The problem only occurs after the function keyword and only in the tango theme (according to my testing). Adding whitespace (i.e. spaces after the parenthesis or blank lines between the keyword and the first line) does not seem to solve the problem. Further, using spaces instead of tabs for indentation does not change the output (assuming the tabsize is equal to the number of spaces).
Another problem I am facing is this artefact after function definitions with multiple return values. The mwe can easily be extended to produce the following output:
where the red box is completely unwanted. This is however related directly to pygmentize, since the screenshot was taken from an HTML output. Still, help would be appreciated.
What is the problem here?
minted matlab
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
add a comment |
The following mwe shows the problem I am facing:
documentclass{article}
usepackage{minted}
begin{document}
usemintedstyle{tango}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
usemintedstyle{emacs}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
end{document}
The above code produces the following output:
It can clearly be seen that the first line in the function using the tango style in incorrectly indented. Im fairly sure that this problem is minted-related and does not directly have to do with pygmentize, since I checked the output to HTML files and it seemed fine. The problem only occurs after the function keyword and only in the tango theme (according to my testing). Adding whitespace (i.e. spaces after the parenthesis or blank lines between the keyword and the first line) does not seem to solve the problem. Further, using spaces instead of tabs for indentation does not change the output (assuming the tabsize is equal to the number of spaces).
Another problem I am facing is this artefact after function definitions with multiple return values. The mwe can easily be extended to produce the following output:
where the red box is completely unwanted. This is however related directly to pygmentize, since the screenshot was taken from an HTML output. Still, help would be appreciated.
What is the problem here?
minted matlab
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
I might have to revise my earlier comment. A bit of experimenting shows that the problematicPYG{+w}{ }comes frompygmentize's-f latexoption. The first issue might therefore also be apygmentizeissue and not amintedone. I can reproduce a similar issue withpygmentize's HTML output, where with the default style the issue is not visible. It becomes visible once you change thebackground-colorof.w.
– moewe
Feb 13 at 19:54
2
One more: It is quite likely that the problem is not withpygmentize, but rather with pygments itself as I can reproduce the problematic white space handling even on pygments.org/demo/6783503 (the effect is not really visible, but if you check the HTML source you can see that only the spaces iniline are marked up withw, those in thejline are not marked up). I have not been able to find a lexer that gives a similarly inconsistent output (most others that I randomly tried don't usewfor the indentation).
– moewe
Feb 13 at 20:11
Well, interesting. Definitely seems like both problems arepygmentsrelated, as i can also reproduce this with other examples using it directly. I guess this is largely off topic then, my bad. I should have investigated further.
– Martin Zach
Feb 13 at 20:28
I'm pretty sure the space issue is connected to bitbucket.org/birkenfeld/pygments-main/src/… That bit of the lexer is the only place whereWhitespaceis used, which means that one certain spaces at or around a function declaration get marked up asWhitespaceall other space presumably ends up as justText(i.e. with no special markup). ...
– moewe
Feb 13 at 20:32
1
... I guess you could re-ask on Stackoverflow, where Python would at least be on topic. But really you should be reporting this as a bug or feature request at bitbucket.org/birkenfeld/pygments-main/issues
– moewe
Feb 13 at 20:33
add a comment |
The following mwe shows the problem I am facing:
documentclass{article}
usepackage{minted}
begin{document}
usemintedstyle{tango}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
usemintedstyle{emacs}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
end{document}
The above code produces the following output:
It can clearly be seen that the first line in the function using the tango style in incorrectly indented. Im fairly sure that this problem is minted-related and does not directly have to do with pygmentize, since I checked the output to HTML files and it seemed fine. The problem only occurs after the function keyword and only in the tango theme (according to my testing). Adding whitespace (i.e. spaces after the parenthesis or blank lines between the keyword and the first line) does not seem to solve the problem. Further, using spaces instead of tabs for indentation does not change the output (assuming the tabsize is equal to the number of spaces).
Another problem I am facing is this artefact after function definitions with multiple return values. The mwe can easily be extended to produce the following output:
where the red box is completely unwanted. This is however related directly to pygmentize, since the screenshot was taken from an HTML output. Still, help would be appreciated.
What is the problem here?
minted matlab
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
The following mwe shows the problem I am facing:
documentclass{article}
usepackage{minted}
begin{document}
usemintedstyle{tango}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
usemintedstyle{emacs}
begin{minted}{matlab}
function test()
i = 1;
j = 1;
end
end{minted}
end{document}
The above code produces the following output:
It can clearly be seen that the first line in the function using the tango style in incorrectly indented. Im fairly sure that this problem is minted-related and does not directly have to do with pygmentize, since I checked the output to HTML files and it seemed fine. The problem only occurs after the function keyword and only in the tango theme (according to my testing). Adding whitespace (i.e. spaces after the parenthesis or blank lines between the keyword and the first line) does not seem to solve the problem. Further, using spaces instead of tabs for indentation does not change the output (assuming the tabsize is equal to the number of spaces).
Another problem I am facing is this artefact after function definitions with multiple return values. The mwe can easily be extended to produce the following output:
where the red box is completely unwanted. This is however related directly to pygmentize, since the screenshot was taken from an HTML output. Still, help would be appreciated.
What is the problem here?
minted matlab
minted matlab
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
asked Feb 13 at 19:13
Martin ZachMartin Zach
332
332
I might have to revise my earlier comment. A bit of experimenting shows that the problematicPYG{+w}{ }comes frompygmentize's-f latexoption. The first issue might therefore also be apygmentizeissue and not amintedone. I can reproduce a similar issue withpygmentize's HTML output, where with the default style the issue is not visible. It becomes visible once you change thebackground-colorof.w.
– moewe
Feb 13 at 19:54
2
One more: It is quite likely that the problem is not withpygmentize, but rather with pygments itself as I can reproduce the problematic white space handling even on pygments.org/demo/6783503 (the effect is not really visible, but if you check the HTML source you can see that only the spaces iniline are marked up withw, those in thejline are not marked up). I have not been able to find a lexer that gives a similarly inconsistent output (most others that I randomly tried don't usewfor the indentation).
– moewe
Feb 13 at 20:11
Well, interesting. Definitely seems like both problems arepygmentsrelated, as i can also reproduce this with other examples using it directly. I guess this is largely off topic then, my bad. I should have investigated further.
– Martin Zach
Feb 13 at 20:28
I'm pretty sure the space issue is connected to bitbucket.org/birkenfeld/pygments-main/src/… That bit of the lexer is the only place whereWhitespaceis used, which means that one certain spaces at or around a function declaration get marked up asWhitespaceall other space presumably ends up as justText(i.e. with no special markup). ...
– moewe
Feb 13 at 20:32
1
... I guess you could re-ask on Stackoverflow, where Python would at least be on topic. But really you should be reporting this as a bug or feature request at bitbucket.org/birkenfeld/pygments-main/issues
– moewe
Feb 13 at 20:33
add a comment |
I might have to revise my earlier comment. A bit of experimenting shows that the problematicPYG{+w}{ }comes frompygmentize's-f latexoption. The first issue might therefore also be apygmentizeissue and not amintedone. I can reproduce a similar issue withpygmentize's HTML output, where with the default style the issue is not visible. It becomes visible once you change thebackground-colorof.w.
– moewe
Feb 13 at 19:54
2
One more: It is quite likely that the problem is not withpygmentize, but rather with pygments itself as I can reproduce the problematic white space handling even on pygments.org/demo/6783503 (the effect is not really visible, but if you check the HTML source you can see that only the spaces iniline are marked up withw, those in thejline are not marked up). I have not been able to find a lexer that gives a similarly inconsistent output (most others that I randomly tried don't usewfor the indentation).
– moewe
Feb 13 at 20:11
Well, interesting. Definitely seems like both problems arepygmentsrelated, as i can also reproduce this with other examples using it directly. I guess this is largely off topic then, my bad. I should have investigated further.
– Martin Zach
Feb 13 at 20:28
I'm pretty sure the space issue is connected to bitbucket.org/birkenfeld/pygments-main/src/… That bit of the lexer is the only place whereWhitespaceis used, which means that one certain spaces at or around a function declaration get marked up asWhitespaceall other space presumably ends up as justText(i.e. with no special markup). ...
– moewe
Feb 13 at 20:32
1
... I guess you could re-ask on Stackoverflow, where Python would at least be on topic. But really you should be reporting this as a bug or feature request at bitbucket.org/birkenfeld/pygments-main/issues
– moewe
Feb 13 at 20:33
I might have to revise my earlier comment. A bit of experimenting shows that the problematic
PYG{+w}{ } comes from pygmentize's -f latex option. The first issue might therefore also be a pygmentize issue and not a minted one. I can reproduce a similar issue with pygmentize's HTML output, where with the default style the issue is not visible. It becomes visible once you change the background-color of .w.– moewe
Feb 13 at 19:54
I might have to revise my earlier comment. A bit of experimenting shows that the problematic
PYG{+w}{ } comes from pygmentize's -f latex option. The first issue might therefore also be a pygmentize issue and not a minted one. I can reproduce a similar issue with pygmentize's HTML output, where with the default style the issue is not visible. It becomes visible once you change the background-color of .w.– moewe
Feb 13 at 19:54
2
2
One more: It is quite likely that the problem is not with
pygmentize, but rather with pygments itself as I can reproduce the problematic white space handling even on pygments.org/demo/6783503 (the effect is not really visible, but if you check the HTML source you can see that only the spaces in i line are marked up with w, those in the j line are not marked up). I have not been able to find a lexer that gives a similarly inconsistent output (most others that I randomly tried don't use w for the indentation).– moewe
Feb 13 at 20:11
One more: It is quite likely that the problem is not with
pygmentize, but rather with pygments itself as I can reproduce the problematic white space handling even on pygments.org/demo/6783503 (the effect is not really visible, but if you check the HTML source you can see that only the spaces in i line are marked up with w, those in the j line are not marked up). I have not been able to find a lexer that gives a similarly inconsistent output (most others that I randomly tried don't use w for the indentation).– moewe
Feb 13 at 20:11
Well, interesting. Definitely seems like both problems are
pygments related, as i can also reproduce this with other examples using it directly. I guess this is largely off topic then, my bad. I should have investigated further.– Martin Zach
Feb 13 at 20:28
Well, interesting. Definitely seems like both problems are
pygments related, as i can also reproduce this with other examples using it directly. I guess this is largely off topic then, my bad. I should have investigated further.– Martin Zach
Feb 13 at 20:28
I'm pretty sure the space issue is connected to bitbucket.org/birkenfeld/pygments-main/src/… That bit of the lexer is the only place where
Whitespace is used, which means that one certain spaces at or around a function declaration get marked up as Whitespace all other space presumably ends up as just Text (i.e. with no special markup). ...– moewe
Feb 13 at 20:32
I'm pretty sure the space issue is connected to bitbucket.org/birkenfeld/pygments-main/src/… That bit of the lexer is the only place where
Whitespace is used, which means that one certain spaces at or around a function declaration get marked up as Whitespace all other space presumably ends up as just Text (i.e. with no special markup). ...– moewe
Feb 13 at 20:32
1
1
... I guess you could re-ask on Stackoverflow, where Python would at least be on topic. But really you should be reporting this as a bug or feature request at bitbucket.org/birkenfeld/pygments-main/issues
– moewe
Feb 13 at 20:33
... I guess you could re-ask on Stackoverflow, where Python would at least be on topic. But really you should be reporting this as a bug or feature request at bitbucket.org/birkenfeld/pygments-main/issues
– moewe
Feb 13 at 20:33
add a comment |
0
active
oldest
votes
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%2f474750%2fminted-tango-theme-indentation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f474750%2fminted-tango-theme-indentation%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
I might have to revise my earlier comment. A bit of experimenting shows that the problematic
PYG{+w}{ }comes frompygmentize's-f latexoption. The first issue might therefore also be apygmentizeissue and not amintedone. I can reproduce a similar issue withpygmentize's HTML output, where with the default style the issue is not visible. It becomes visible once you change thebackground-colorof.w.– moewe
Feb 13 at 19:54
2
One more: It is quite likely that the problem is not with
pygmentize, but rather with pygments itself as I can reproduce the problematic white space handling even on pygments.org/demo/6783503 (the effect is not really visible, but if you check the HTML source you can see that only the spaces iniline are marked up withw, those in thejline are not marked up). I have not been able to find a lexer that gives a similarly inconsistent output (most others that I randomly tried don't usewfor the indentation).– moewe
Feb 13 at 20:11
Well, interesting. Definitely seems like both problems are
pygmentsrelated, as i can also reproduce this with other examples using it directly. I guess this is largely off topic then, my bad. I should have investigated further.– Martin Zach
Feb 13 at 20:28
I'm pretty sure the space issue is connected to bitbucket.org/birkenfeld/pygments-main/src/… That bit of the lexer is the only place where
Whitespaceis used, which means that one certain spaces at or around a function declaration get marked up asWhitespaceall other space presumably ends up as justText(i.e. with no special markup). ...– moewe
Feb 13 at 20:32
1
... I guess you could re-ask on Stackoverflow, where Python would at least be on topic. But really you should be reporting this as a bug or feature request at bitbucket.org/birkenfeld/pygments-main/issues
– moewe
Feb 13 at 20:33