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
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
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
24 mins 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
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
edited 16 mins ago
Max
asked 57 mins ago
MaxMax
406
406
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
24 mins ago
add a comment |
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
24 mins 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
24 mins 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
24 mins 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.
It is perhaps worth noting that with a previous version oflipsum
the same behavior would not show; it does now becauselipsum
issuespar
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
8 mins ago
@David: Thanks. Do you meanflushright
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 useflushright
without LaTeX complaining it's not intended to be used.
– Max
4 mins ago
add a 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.
It is perhaps worth noting that with a previous version oflipsum
the same behavior would not show; it does now becauselipsum
issuespar
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
8 mins ago
@David: Thanks. Do you meanflushright
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 useflushright
without LaTeX complaining it's not intended to be used.
– Max
4 mins ago
add a 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.
It is perhaps worth noting that with a previous version oflipsum
the same behavior would not show; it does now becauselipsum
issuespar
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
8 mins ago
@David: Thanks. Do you meanflushright
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 useflushright
without LaTeX complaining it's not intended to be used.
– Max
4 mins ago
add a 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.
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.
edited 35 mins ago
answered 42 mins ago
David CarlisleDavid Carlisle
487k4111231868
487k4111231868
It is perhaps worth noting that with a previous version oflipsum
the same behavior would not show; it does now becauselipsum
issuespar
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
8 mins ago
@David: Thanks. Do you meanflushright
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 useflushright
without LaTeX complaining it's not intended to be used.
– Max
4 mins ago
add a comment |
It is perhaps worth noting that with a previous version oflipsum
the same behavior would not show; it does now becauselipsum
issuespar
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
8 mins ago
@David: Thanks. Do you meanflushright
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 useflushright
without LaTeX complaining it's not intended to be used.
– Max
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
8 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
8 mins 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
4 mins 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
4 mins ago
add a 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
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
24 mins ago