Scope of LaTeX code
In C/C++ or other language, the code and variables have scope. Is this the same in LaTeX?
I struggled to understand the behavior of below code--
documentclass[doubleside]{article}
usepackage{lipsum}
begin{document}
%% case 1
%%
lipsum[5]
{
flushright
Huge
}
%% case 2
%%
lipsum[5]
{
Huge
flushright
}
%% case 3
%%
lipsum[5]
{
Huge
flushright
}
end{document}
Hope you can understand my difficulty of understanding what I got (maybe it's my familiarity with C/C++ that makes it difficult) --
scoping
asked 2 hours ago
MaxMax
406
add a comment |
In C/C++ or other language, the code and variables have scope. Is this the same in LaTeX?
I struggled to understand the behavior of below code--
documentclass[doubleside]{article}
usepackage{lipsum}
begin{document}
%% case 1
%%
lipsum[5]
{
flushright
Huge
}
%% case 2
%%
lipsum[5]
{
Huge
flushright
}
%% case 3
%%
lipsum[5]
{
Huge
flushright
}
end{document}
Hope you can understand my difficulty of understanding what I got (maybe it's my familiarity with C/C++ that makes it difficult) --
scoping
asked 2 hours ago
MaxMax
406
1
Note if you want to compare with C, remember TeX is a macro expansion language not a compiled language, so it is far closer to the C pre-processor #define mechanism than it is to C itself.
– David Carlisle
1 hour ago
add a comment |
In C/C++ or other language, the code and variables have scope. Is this the same in LaTeX?
I struggled to understand the behavior of below code--
documentclass[doubleside]{article}
usepackage{lipsum}
begin{document}
%% case 1
%%
lipsum[5]
{
flushright
Huge
}
%% case 2
%%
lipsum[5]
{
Huge
flushright
}
%% case 3
%%
lipsum[5]
{
Huge
flushright
}
end{document}
Hope you can understand my difficulty of understanding what I got (maybe it's my familiarity with C/C++ that makes it difficult) --
scoping
asked 2 hours ago
MaxMax
406
In C/C++ or other language, the code and variables have scope. Is this the same in LaTeX?
I struggled to understand the behavior of below code--
documentclass[doubleside]{article}
usepackage{lipsum}
begin{document}
%% case 1
%%
lipsum[5]
{
flushright
Huge
}
%% case 2
%%
lipsum[5]
{
Huge
flushright
}
%% case 3
%%
lipsum[5]
{
Huge
flushright
}
end{document}
Hope you can understand my difficulty of understanding what I got (maybe it's my familiarity with C/C++ that makes it difficult) --
scoping
scoping
asked 2 hours ago
MaxMax
406
asked 2 hours ago
MaxMax
406
edited 1 hour ago
Max
asked 2 hours ago
MaxMax
406
asked 2 hours ago
MaxMax
406
asked 2 hours ago
MaxMax
406
406
1
Note if you want to compare with C, remember TeX is a macro expansion language not a compiled language, so it is far closer to the C pre-processor #define mechanism than it is to C itself.
– David Carlisle
1 hour ago
add a comment |
1
Note if you want to compare with C, remember TeX is a macro expansion language not a compiled language, so it is far closer to the C pre-processor #define mechanism than it is to C itself.
– David Carlisle
1 hour ago
1
1
Note if you want to compare with C, remember TeX is a macro expansion language not a compiled language, so it is far closer to the C pre-processor #define mechanism than it is to C itself.
– David Carlisle
1 hour ago
Note if you want to compare with C, remember TeX is a macro expansion language not a compiled language, so it is far closer to the C pre-processor #define mechanism than it is to C itself.
– David Carlisle
1 hour ago
add a comment |
1 Answer
1
active
oldest
votes
tex has local and global scope as determined by groups ({...} and begin...end in your examples (begin...end forming a group as they are macros that expand to use of the tex primitive begingroup and endgroup group constructs.)
Commands can be defined to have local or global action but the ones you show are local, a global assignment is not restored when the group ends.
However your confusing output is caused by user error, flushright is not intended to be used as a command (the command form is raggedleft) it is the implementation of the start of the begin{flushright} end{flushright} environment.
TeX's linebreaking is optimised over a paragraph, using the settings at the end of the paragraph.
The important thing here is that (unlike raggedleft) flushright executes par so ends the previous paragraph so:
In the first case the paragraph is finished, and set with normal settings then locally huge font and ragged setting is set up but discarded at } before being used.
In the second case Huge fonts and baseline is set up, so the paragraph is set with a huge baseline when the par in flushright is executed.
In the third case, the paragraph is set with the normal settings by the implicit par at the blank line, and so the local settings in the following group are not used at all.
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
It is perhaps worth noting that with a previous version oflipsumthe same behavior would not show; it does now becauselipsumissuesparat the beginning rather than at the end. This can be exemplified by{Hugelipsum[1]smallpar}, that gives a different result with TL2017 than with the up-to-date version.
– egreg
1 hour ago
@David: Thanks. Do you meanflushrightis correct in syntax but should not be used because of its "incorrect" semantics? But I don't think there is right or wrong semantics of the code itself. It's up to the user of the code. I struggle to understand while we can useflushrightwithout LaTeX complaining it's not intended to be used.
– Max
1 hour ago
@Max noflushrightshould never be used in that form. It is not an error asbegin{foo} end{foo}isbegingroupfoo...endfooendgroupsoflushrightneeds to be defined to implementbegin{flushright}but you could replace every use offlushrightin the above bybegin{flushright}end{flushright}or in fact replace them all by a blank line, and see the same output. the only part of theflushrightdefinition that you are using ispar
– David Carlisle
1 hour ago
@David Thanks, solushrightis a red herring. After some more trial I got what you mean and started to understand LaTeX's behavior. A simpler version of the test code then would be{lipsum[5]Hugepar}. The spacing in the paragraph before par is determined byHuge. What's even more non-intuitive though, is that the font size of the "current" paragraph is not determined byHuge!
– Max
14 mins ago
@Max the text is set using the locally specified fonts onto a horizontal list: you would expectaaa textbf{bbb} textit{ccc}to use roman italic and bold fonts, not ignore that and use the font at the end of a paragraph! but then this long horizontal list is broken into lines as a single operation at the end of the paragraph so the linespacing that matters is just the one at the end.
– David Carlisle
4 mins ago
|
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%2f471793%2fscope-of-latex-code%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
tex has local and global scope as determined by groups ({...} and begin...end in your examples (begin...end forming a group as they are macros that expand to use of the tex primitive begingroup and endgroup group constructs.)
Commands can be defined to have local or global action but the ones you show are local, a global assignment is not restored when the group ends.
However your confusing output is caused by user error, flushright is not intended to be used as a command (the command form is raggedleft) it is the implementation of the start of the begin{flushright} end{flushright} environment.
TeX's linebreaking is optimised over a paragraph, using the settings at the end of the paragraph.
The important thing here is that (unlike raggedleft) flushright executes par so ends the previous paragraph so:
In the first case the paragraph is finished, and set with normal settings then locally huge font and ragged setting is set up but discarded at } before being used.
In the second case Huge fonts and baseline is set up, so the paragraph is set with a huge baseline when the par in flushright is executed.
In the third case, the paragraph is set with the normal settings by the implicit par at the blank line, and so the local settings in the following group are not used at all.
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
It is perhaps worth noting that with a previous version oflipsumthe same behavior would not show; it does now becauselipsumissuesparat the beginning rather than at the end. This can be exemplified by{Hugelipsum[1]smallpar}, that gives a different result with TL2017 than with the up-to-date version.
– egreg
1 hour ago
@David: Thanks. Do you meanflushrightis correct in syntax but should not be used because of its "incorrect" semantics? But I don't think there is right or wrong semantics of the code itself. It's up to the user of the code. I struggle to understand while we can useflushrightwithout LaTeX complaining it's not intended to be used.
– Max
1 hour ago
@Max noflushrightshould never be used in that form. It is not an error asbegin{foo} end{foo}isbegingroupfoo...endfooendgroupsoflushrightneeds to be defined to implementbegin{flushright}but you could replace every use offlushrightin the above bybegin{flushright}end{flushright}or in fact replace them all by a blank line, and see the same output. the only part of theflushrightdefinition that you are using ispar
– David Carlisle
1 hour ago
@David Thanks, solushrightis a red herring. After some more trial I got what you mean and started to understand LaTeX's behavior. A simpler version of the test code then would be{lipsum[5]Hugepar}. The spacing in the paragraph before par is determined byHuge. What's even more non-intuitive though, is that the font size of the "current" paragraph is not determined byHuge!
– Max
14 mins ago
@Max the text is set using the locally specified fonts onto a horizontal list: you would expectaaa textbf{bbb} textit{ccc}to use roman italic and bold fonts, not ignore that and use the font at the end of a paragraph! but then this long horizontal list is broken into lines as a single operation at the end of the paragraph so the linespacing that matters is just the one at the end.
– David Carlisle
4 mins ago
|
show 1 more comment
tex has local and global scope as determined by groups ({...} and begin...end in your examples (begin...end forming a group as they are macros that expand to use of the tex primitive begingroup and endgroup group constructs.)
Commands can be defined to have local or global action but the ones you show are local, a global assignment is not restored when the group ends.
However your confusing output is caused by user error, flushright is not intended to be used as a command (the command form is raggedleft) it is the implementation of the start of the begin{flushright} end{flushright} environment.
TeX's linebreaking is optimised over a paragraph, using the settings at the end of the paragraph.
The important thing here is that (unlike raggedleft) flushright executes par so ends the previous paragraph so:
In the first case the paragraph is finished, and set with normal settings then locally huge font and ragged setting is set up but discarded at } before being used.
In the second case Huge fonts and baseline is set up, so the paragraph is set with a huge baseline when the par in flushright is executed.
In the third case, the paragraph is set with the normal settings by the implicit par at the blank line, and so the local settings in the following group are not used at all.
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
It is perhaps worth noting that with a previous version oflipsumthe same behavior would not show; it does now becauselipsumissuesparat the beginning rather than at the end. This can be exemplified by{Hugelipsum[1]smallpar}, that gives a different result with TL2017 than with the up-to-date version.
– egreg
1 hour ago
@David: Thanks. Do you meanflushrightis correct in syntax but should not be used because of its "incorrect" semantics? But I don't think there is right or wrong semantics of the code itself. It's up to the user of the code. I struggle to understand while we can useflushrightwithout LaTeX complaining it's not intended to be used.
– Max
1 hour ago
@Max noflushrightshould never be used in that form. It is not an error asbegin{foo} end{foo}isbegingroupfoo...endfooendgroupsoflushrightneeds to be defined to implementbegin{flushright}but you could replace every use offlushrightin the above bybegin{flushright}end{flushright}or in fact replace them all by a blank line, and see the same output. the only part of theflushrightdefinition that you are using ispar
– David Carlisle
1 hour ago
@David Thanks, solushrightis a red herring. After some more trial I got what you mean and started to understand LaTeX's behavior. A simpler version of the test code then would be{lipsum[5]Hugepar}. The spacing in the paragraph before par is determined byHuge. What's even more non-intuitive though, is that the font size of the "current" paragraph is not determined byHuge!
– Max
14 mins ago
@Max the text is set using the locally specified fonts onto a horizontal list: you would expectaaa textbf{bbb} textit{ccc}to use roman italic and bold fonts, not ignore that and use the font at the end of a paragraph! but then this long horizontal list is broken into lines as a single operation at the end of the paragraph so the linespacing that matters is just the one at the end.
– David Carlisle
4 mins ago
|
show 1 more comment
tex has local and global scope as determined by groups ({...} and begin...end in your examples (begin...end forming a group as they are macros that expand to use of the tex primitive begingroup and endgroup group constructs.)
Commands can be defined to have local or global action but the ones you show are local, a global assignment is not restored when the group ends.
However your confusing output is caused by user error, flushright is not intended to be used as a command (the command form is raggedleft) it is the implementation of the start of the begin{flushright} end{flushright} environment.
TeX's linebreaking is optimised over a paragraph, using the settings at the end of the paragraph.
The important thing here is that (unlike raggedleft) flushright executes par so ends the previous paragraph so:
In the first case the paragraph is finished, and set with normal settings then locally huge font and ragged setting is set up but discarded at } before being used.
In the second case Huge fonts and baseline is set up, so the paragraph is set with a huge baseline when the par in flushright is executed.
In the third case, the paragraph is set with the normal settings by the implicit par at the blank line, and so the local settings in the following group are not used at all.
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
tex has local and global scope as determined by groups ({...} and begin...end in your examples (begin...end forming a group as they are macros that expand to use of the tex primitive begingroup and endgroup group constructs.)
Commands can be defined to have local or global action but the ones you show are local, a global assignment is not restored when the group ends.
However your confusing output is caused by user error, flushright is not intended to be used as a command (the command form is raggedleft) it is the implementation of the start of the begin{flushright} end{flushright} environment.
TeX's linebreaking is optimised over a paragraph, using the settings at the end of the paragraph.
The important thing here is that (unlike raggedleft) flushright executes par so ends the previous paragraph so:
In the first case the paragraph is finished, and set with normal settings then locally huge font and ragged setting is set up but discarded at } before being used.
In the second case Huge fonts and baseline is set up, so the paragraph is set with a huge baseline when the par in flushright is executed.
In the third case, the paragraph is set with the normal settings by the implicit par at the blank line, and so the local settings in the following group are not used at all.
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
edited 1 hour ago
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
answered 1 hour ago
David CarlisleDavid Carlisle
487k4111231868
487k4111231868
It is perhaps worth noting that with a previous version oflipsumthe same behavior would not show; it does now becauselipsumissuesparat the beginning rather than at the end. This can be exemplified by{Hugelipsum[1]smallpar}, that gives a different result with TL2017 than with the up-to-date version.
– egreg
1 hour ago
@David: Thanks. Do you meanflushrightis correct in syntax but should not be used because of its "incorrect" semantics? But I don't think there is right or wrong semantics of the code itself. It's up to the user of the code. I struggle to understand while we can useflushrightwithout LaTeX complaining it's not intended to be used.
– Max
1 hour ago
@Max noflushrightshould never be used in that form. It is not an error asbegin{foo} end{foo}isbegingroupfoo...endfooendgroupsoflushrightneeds to be defined to implementbegin{flushright}but you could replace every use offlushrightin the above bybegin{flushright}end{flushright}or in fact replace them all by a blank line, and see the same output. the only part of theflushrightdefinition that you are using ispar
– David Carlisle
1 hour ago
@David Thanks, solushrightis a red herring. After some more trial I got what you mean and started to understand LaTeX's behavior. A simpler version of the test code then would be{lipsum[5]Hugepar}. The spacing in the paragraph before par is determined byHuge. What's even more non-intuitive though, is that the font size of the "current" paragraph is not determined byHuge!
– Max
14 mins ago
@Max the text is set using the locally specified fonts onto a horizontal list: you would expectaaa textbf{bbb} textit{ccc}to use roman italic and bold fonts, not ignore that and use the font at the end of a paragraph! but then this long horizontal list is broken into lines as a single operation at the end of the paragraph so the linespacing that matters is just the one at the end.
– David Carlisle
4 mins ago
|
show 1 more comment
It is perhaps worth noting that with a previous version oflipsumthe same behavior would not show; it does now becauselipsumissuesparat the beginning rather than at the end. This can be exemplified by{Hugelipsum[1]smallpar}, that gives a different result with TL2017 than with the up-to-date version.
– egreg
1 hour ago
@David: Thanks. Do you meanflushrightis correct in syntax but should not be used because of its "incorrect" semantics? But I don't think there is right or wrong semantics of the code itself. It's up to the user of the code. I struggle to understand while we can useflushrightwithout LaTeX complaining it's not intended to be used.
– Max
1 hour ago
@Max noflushrightshould never be used in that form. It is not an error asbegin{foo} end{foo}isbegingroupfoo...endfooendgroupsoflushrightneeds to be defined to implementbegin{flushright}but you could replace every use offlushrightin the above bybegin{flushright}end{flushright}or in fact replace them all by a blank line, and see the same output. the only part of theflushrightdefinition that you are using ispar
– David Carlisle
1 hour ago
@David Thanks, solushrightis a red herring. After some more trial I got what you mean and started to understand LaTeX's behavior. A simpler version of the test code then would be{lipsum[5]Hugepar}. The spacing in the paragraph before par is determined byHuge. What's even more non-intuitive though, is that the font size of the "current" paragraph is not determined byHuge!
– Max
14 mins ago
@Max the text is set using the locally specified fonts onto a horizontal list: you would expectaaa textbf{bbb} textit{ccc}to use roman italic and bold fonts, not ignore that and use the font at the end of a paragraph! but then this long horizontal list is broken into lines as a single operation at the end of the paragraph so the linespacing that matters is just the one at the end.
– David Carlisle
4 mins ago
It is perhaps worth noting that with a previous version of
lipsum the same behavior would not show; it does now because lipsum issues par at the beginning rather than at the end. This can be exemplified by {Hugelipsum[1]smallpar}, that gives a different result with TL2017 than with the up-to-date version.– egreg
1 hour ago
It is perhaps worth noting that with a previous version of
lipsum the same behavior would not show; it does now because lipsum issues par at the beginning rather than at the end. This can be exemplified by {Hugelipsum[1]smallpar}, that gives a different result with TL2017 than with the up-to-date version.– egreg
1 hour ago
@David: Thanks. Do you mean
flushright is correct in syntax but should not be used because of its "incorrect" semantics? But I don't think there is right or wrong semantics of the code itself. It's up to the user of the code. I struggle to understand while we can use flushright without LaTeX complaining it's not intended to be used.– Max
1 hour ago
@David: Thanks. Do you mean
flushright is correct in syntax but should not be used because of its "incorrect" semantics? But I don't think there is right or wrong semantics of the code itself. It's up to the user of the code. I struggle to understand while we can use flushright without LaTeX complaining it's not intended to be used.– Max
1 hour ago
@Max no
flushright should never be used in that form. It is not an error as begin{foo} end{foo} is begingroupfoo...endfooendgroup so flushright needs to be defined to implement begin{flushright} but you could replace every use of flushright in the above by begin{flushright}end{flushright} or in fact replace them all by a blank line, and see the same output. the only part of the flushright definition that you are using is par– David Carlisle
1 hour ago
@Max no
flushright should never be used in that form. It is not an error as begin{foo} end{foo} is begingroupfoo...endfooendgroup so flushright needs to be defined to implement begin{flushright} but you could replace every use of flushright in the above by begin{flushright}end{flushright} or in fact replace them all by a blank line, and see the same output. the only part of the flushright definition that you are using is par– David Carlisle
1 hour ago
@David Thanks, so
lushright is a red herring. After some more trial I got what you mean and started to understand LaTeX's behavior. A simpler version of the test code then would be {lipsum[5]Hugepar}. The spacing in the paragraph before par is determined by Huge. What's even more non-intuitive though, is that the font size of the "current" paragraph is not determined by Huge!– Max
14 mins ago
@David Thanks, so
lushright is a red herring. After some more trial I got what you mean and started to understand LaTeX's behavior. A simpler version of the test code then would be {lipsum[5]Hugepar}. The spacing in the paragraph before par is determined by Huge. What's even more non-intuitive though, is that the font size of the "current" paragraph is not determined by Huge!– Max
14 mins ago
@Max the text is set using the locally specified fonts onto a horizontal list: you would expect
aaa textbf{bbb} textit{ccc} to use roman italic and bold fonts, not ignore that and use the font at the end of a paragraph! but then this long horizontal list is broken into lines as a single operation at the end of the paragraph so the linespacing that matters is just the one at the end.– David Carlisle
4 mins ago
@Max the text is set using the locally specified fonts onto a horizontal list: you would expect
aaa textbf{bbb} textit{ccc} to use roman italic and bold fonts, not ignore that and use the font at the end of a paragraph! but then this long horizontal list is broken into lines as a single operation at the end of the paragraph so the linespacing that matters is just the one at the end.– David Carlisle
4 mins ago
|
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%2f471793%2fscope-of-latex-code%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
1
Note if you want to compare with C, remember TeX is a macro expansion language not a compiled language, so it is far closer to the C pre-processor #define mechanism than it is to C itself.
– David Carlisle
1 hour ago