xparse g argument should be avoided?
In new versions of xparse the manual states the following: (in 2. Backwards Compatibility)
One role of xparse is to describe existing LaTeX interfaces, including some that are rather unusual in LaTeX (as opposed to formats such as plain TeX) such as delimited arguments. As such, the package defines some argument specifiers that should largely be avoided nowadays as using them in packages leads to inconsistent user interfaces. The simplest syntax is often best, with argument specifications such as mmmm or ommmm (...)
What kind of problems like that 'inconsistent user interfaces' might exhibit using for example g-parameter or G-parameter?
I'm the author of a class that rely on macros based on these parameters and would be good knowing if authors of LaTeX3'xparse will drop the support of these parameters or what issues on which circumstances might exhibit...
Edit: As not everyone is familiar with the different parameter types the xparse package provides, here's the description for g and G from the documentation:
g: An optional argument given inside a pair of TeX group tokens (in standard LaTeX,{...}), which returns-NoValue-if not present.G: As forgbut returns<default>if no value is given:G{<default>}.
latex3 xparse parameters
edited 2 days ago
TeXnician
24.3k63085
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
add a comment |
In new versions of xparse the manual states the following: (in 2. Backwards Compatibility)
One role of xparse is to describe existing LaTeX interfaces, including some that are rather unusual in LaTeX (as opposed to formats such as plain TeX) such as delimited arguments. As such, the package defines some argument specifiers that should largely be avoided nowadays as using them in packages leads to inconsistent user interfaces. The simplest syntax is often best, with argument specifications such as mmmm or ommmm (...)
What kind of problems like that 'inconsistent user interfaces' might exhibit using for example g-parameter or G-parameter?
I'm the author of a class that rely on macros based on these parameters and would be good knowing if authors of LaTeX3'xparse will drop the support of these parameters or what issues on which circumstances might exhibit...
Edit: As not everyone is familiar with the different parameter types the xparse package provides, here's the description for g and G from the documentation:
g: An optional argument given inside a pair of TeX group tokens (in standard LaTeX,{...}), which returns-NoValue-if not present.G: As forgbut returns<default>if no value is given:G{<default>}.
latex3 xparse parameters
edited 2 days ago
TeXnician
24.3k63085
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
2
I think the main issue is that it is not the usual LaTeX style to have optional parameters before the mandatory parameters and that the optional parameters are to be specified with aand not a{}. Another issue is in deterring the last optional parameter which may confuse people if the omit the last optional parameter and put a trailing%after the use of the macro.
– Peter Grill
Dec 7 '18 at 6:10
add a comment |
In new versions of xparse the manual states the following: (in 2. Backwards Compatibility)
One role of xparse is to describe existing LaTeX interfaces, including some that are rather unusual in LaTeX (as opposed to formats such as plain TeX) such as delimited arguments. As such, the package defines some argument specifiers that should largely be avoided nowadays as using them in packages leads to inconsistent user interfaces. The simplest syntax is often best, with argument specifications such as mmmm or ommmm (...)
What kind of problems like that 'inconsistent user interfaces' might exhibit using for example g-parameter or G-parameter?
I'm the author of a class that rely on macros based on these parameters and would be good knowing if authors of LaTeX3'xparse will drop the support of these parameters or what issues on which circumstances might exhibit...
Edit: As not everyone is familiar with the different parameter types the xparse package provides, here's the description for g and G from the documentation:
g: An optional argument given inside a pair of TeX group tokens (in standard LaTeX,{...}), which returns-NoValue-if not present.G: As forgbut returns<default>if no value is given:G{<default>}.
latex3 xparse parameters
edited 2 days ago
TeXnician
24.3k63085
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
In new versions of xparse the manual states the following: (in 2. Backwards Compatibility)
One role of xparse is to describe existing LaTeX interfaces, including some that are rather unusual in LaTeX (as opposed to formats such as plain TeX) such as delimited arguments. As such, the package defines some argument specifiers that should largely be avoided nowadays as using them in packages leads to inconsistent user interfaces. The simplest syntax is often best, with argument specifications such as mmmm or ommmm (...)
What kind of problems like that 'inconsistent user interfaces' might exhibit using for example g-parameter or G-parameter?
I'm the author of a class that rely on macros based on these parameters and would be good knowing if authors of LaTeX3'xparse will drop the support of these parameters or what issues on which circumstances might exhibit...
Edit: As not everyone is familiar with the different parameter types the xparse package provides, here's the description for g and G from the documentation:
g: An optional argument given inside a pair of TeX group tokens (in standard LaTeX,{...}), which returns-NoValue-if not present.G: As forgbut returns<default>if no value is given:G{<default>}.
latex3 xparse parameters
latex3 xparse parameters
edited 2 days ago
TeXnician
24.3k63085
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
edited 2 days ago
TeXnician
24.3k63085
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
edited 2 days ago
TeXnician
24.3k63085
edited 2 days ago
TeXnician
24.3k63085
edited 2 days ago
TeXnician
24.3k63085
24.3k63085
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
asked Dec 7 '18 at 4:04
Emilio Lazo
45429
45429
2
I think the main issue is that it is not the usual LaTeX style to have optional parameters before the mandatory parameters and that the optional parameters are to be specified with aand not a{}. Another issue is in deterring the last optional parameter which may confuse people if the omit the last optional parameter and put a trailing%after the use of the macro.
– Peter Grill
Dec 7 '18 at 6:10
add a comment |
2
I think the main issue is that it is not the usual LaTeX style to have optional parameters before the mandatory parameters and that the optional parameters are to be specified with aand not a{}. Another issue is in deterring the last optional parameter which may confuse people if the omit the last optional parameter and put a trailing%after the use of the macro.
– Peter Grill
Dec 7 '18 at 6:10
2
2
I think the main issue is that it is not the usual LaTeX style to have optional parameters before the mandatory parameters and that the optional parameters are to be specified with a
{}. Another issue is in deterring the last optional parameter which may confuse people if the omit the last optional parameter and put a trailing % after the use of the macro.– Peter Grill
Dec 7 '18 at 6:10
I think the main issue is that it is not the usual LaTeX style to have optional parameters before the mandatory parameters and that the optional parameters are to be specified with a
{}. Another issue is in deterring the last optional parameter which may confuse people if the omit the last optional parameter and put a trailing % after the use of the macro.– Peter Grill
Dec 7 '18 at 6:10
add a comment |
1 Answer
1
active
oldest
votes
The xparse package is primarily meant to allow definition of 'LaTeX2e-like' commands, though it also can standardise the description of a wider range of interfaces. The LaTeX2e kernel is very consistent in using {...} for mandatory arguments and [...] for optional ones ((...) is used for picture-mode arguments). As such, the g-type argument is an outlier: it's not really standard LaTeX2e usage at all. We include it as it does come up in e.g. beamer,
begin{frame}{title}{sub-title}
Probably, written today one would normally use keyval systems for such cases
begin{frame}[title = ..., subtitle = ...]
In general, I would avoid using g-type arguments for new commands.
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
Thanks, and also to @Peter. I'm using these parameters in a convenient way, the same way as they was conceived by LaTeX3 developers I guess. I understand the motivation behind hiding or advising against the use of these parameters, but the text quoted from the manual on 'backwards compatibility' should be understood as 'please don't use them anymore, they will be removed soon'? These 'inconsistent user interfaces' would refer to an inconsistency regarding the standard LaTeX parameter usage or instead it would refer to unpredictable results if we insist on using them?
– Emilio Lazo
Dec 8 '18 at 6:28
@EmilioLazo Inconsistent with LaTeX conventions
– Joseph Wright♦
Dec 8 '18 at 16:37
Yes, it is! Thank you.
– Emilio Lazo
Dec 8 '18 at 18:35
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%2f463626%2fxparse-g-argument-should-be-avoided%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The xparse package is primarily meant to allow definition of 'LaTeX2e-like' commands, though it also can standardise the description of a wider range of interfaces. The LaTeX2e kernel is very consistent in using {...} for mandatory arguments and [...] for optional ones ((...) is used for picture-mode arguments). As such, the g-type argument is an outlier: it's not really standard LaTeX2e usage at all. We include it as it does come up in e.g. beamer,
begin{frame}{title}{sub-title}
Probably, written today one would normally use keyval systems for such cases
begin{frame}[title = ..., subtitle = ...]
In general, I would avoid using g-type arguments for new commands.
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
Thanks, and also to @Peter. I'm using these parameters in a convenient way, the same way as they was conceived by LaTeX3 developers I guess. I understand the motivation behind hiding or advising against the use of these parameters, but the text quoted from the manual on 'backwards compatibility' should be understood as 'please don't use them anymore, they will be removed soon'? These 'inconsistent user interfaces' would refer to an inconsistency regarding the standard LaTeX parameter usage or instead it would refer to unpredictable results if we insist on using them?
– Emilio Lazo
Dec 8 '18 at 6:28
@EmilioLazo Inconsistent with LaTeX conventions
– Joseph Wright♦
Dec 8 '18 at 16:37
Yes, it is! Thank you.
– Emilio Lazo
Dec 8 '18 at 18:35
add a comment |
The xparse package is primarily meant to allow definition of 'LaTeX2e-like' commands, though it also can standardise the description of a wider range of interfaces. The LaTeX2e kernel is very consistent in using {...} for mandatory arguments and [...] for optional ones ((...) is used for picture-mode arguments). As such, the g-type argument is an outlier: it's not really standard LaTeX2e usage at all. We include it as it does come up in e.g. beamer,
begin{frame}{title}{sub-title}
Probably, written today one would normally use keyval systems for such cases
begin{frame}[title = ..., subtitle = ...]
In general, I would avoid using g-type arguments for new commands.
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
Thanks, and also to @Peter. I'm using these parameters in a convenient way, the same way as they was conceived by LaTeX3 developers I guess. I understand the motivation behind hiding or advising against the use of these parameters, but the text quoted from the manual on 'backwards compatibility' should be understood as 'please don't use them anymore, they will be removed soon'? These 'inconsistent user interfaces' would refer to an inconsistency regarding the standard LaTeX parameter usage or instead it would refer to unpredictable results if we insist on using them?
– Emilio Lazo
Dec 8 '18 at 6:28
@EmilioLazo Inconsistent with LaTeX conventions
– Joseph Wright♦
Dec 8 '18 at 16:37
Yes, it is! Thank you.
– Emilio Lazo
Dec 8 '18 at 18:35
add a comment |
The xparse package is primarily meant to allow definition of 'LaTeX2e-like' commands, though it also can standardise the description of a wider range of interfaces. The LaTeX2e kernel is very consistent in using {...} for mandatory arguments and [...] for optional ones ((...) is used for picture-mode arguments). As such, the g-type argument is an outlier: it's not really standard LaTeX2e usage at all. We include it as it does come up in e.g. beamer,
begin{frame}{title}{sub-title}
Probably, written today one would normally use keyval systems for such cases
begin{frame}[title = ..., subtitle = ...]
In general, I would avoid using g-type arguments for new commands.
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
The xparse package is primarily meant to allow definition of 'LaTeX2e-like' commands, though it also can standardise the description of a wider range of interfaces. The LaTeX2e kernel is very consistent in using {...} for mandatory arguments and [...] for optional ones ((...) is used for picture-mode arguments). As such, the g-type argument is an outlier: it's not really standard LaTeX2e usage at all. We include it as it does come up in e.g. beamer,
begin{frame}{title}{sub-title}
Probably, written today one would normally use keyval systems for such cases
begin{frame}[title = ..., subtitle = ...]
In general, I would avoid using g-type arguments for new commands.
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
answered Dec 7 '18 at 7:36
Joseph Wright♦
202k21555882
202k21555882
Thanks, and also to @Peter. I'm using these parameters in a convenient way, the same way as they was conceived by LaTeX3 developers I guess. I understand the motivation behind hiding or advising against the use of these parameters, but the text quoted from the manual on 'backwards compatibility' should be understood as 'please don't use them anymore, they will be removed soon'? These 'inconsistent user interfaces' would refer to an inconsistency regarding the standard LaTeX parameter usage or instead it would refer to unpredictable results if we insist on using them?
– Emilio Lazo
Dec 8 '18 at 6:28
@EmilioLazo Inconsistent with LaTeX conventions
– Joseph Wright♦
Dec 8 '18 at 16:37
Yes, it is! Thank you.
– Emilio Lazo
Dec 8 '18 at 18:35
add a comment |
Thanks, and also to @Peter. I'm using these parameters in a convenient way, the same way as they was conceived by LaTeX3 developers I guess. I understand the motivation behind hiding or advising against the use of these parameters, but the text quoted from the manual on 'backwards compatibility' should be understood as 'please don't use them anymore, they will be removed soon'? These 'inconsistent user interfaces' would refer to an inconsistency regarding the standard LaTeX parameter usage or instead it would refer to unpredictable results if we insist on using them?
– Emilio Lazo
Dec 8 '18 at 6:28
@EmilioLazo Inconsistent with LaTeX conventions
– Joseph Wright♦
Dec 8 '18 at 16:37
Yes, it is! Thank you.
– Emilio Lazo
Dec 8 '18 at 18:35
Thanks, and also to @Peter. I'm using these parameters in a convenient way, the same way as they was conceived by LaTeX3 developers I guess. I understand the motivation behind hiding or advising against the use of these parameters, but the text quoted from the manual on 'backwards compatibility' should be understood as 'please don't use them anymore, they will be removed soon'? These 'inconsistent user interfaces' would refer to an inconsistency regarding the standard LaTeX parameter usage or instead it would refer to unpredictable results if we insist on using them?
– Emilio Lazo
Dec 8 '18 at 6:28
Thanks, and also to @Peter. I'm using these parameters in a convenient way, the same way as they was conceived by LaTeX3 developers I guess. I understand the motivation behind hiding or advising against the use of these parameters, but the text quoted from the manual on 'backwards compatibility' should be understood as 'please don't use them anymore, they will be removed soon'? These 'inconsistent user interfaces' would refer to an inconsistency regarding the standard LaTeX parameter usage or instead it would refer to unpredictable results if we insist on using them?
– Emilio Lazo
Dec 8 '18 at 6:28
@EmilioLazo Inconsistent with LaTeX conventions
– Joseph Wright♦
Dec 8 '18 at 16:37
@EmilioLazo Inconsistent with LaTeX conventions
– Joseph Wright♦
Dec 8 '18 at 16:37
Yes, it is! Thank you.
– Emilio Lazo
Dec 8 '18 at 18:35
Yes, it is! Thank you.
– Emilio Lazo
Dec 8 '18 at 18:35
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f463626%2fxparse-g-argument-should-be-avoided%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I think the main issue is that it is not the usual LaTeX style to have optional parameters before the mandatory parameters and that the optional parameters are to be specified with a
and not a{}. Another issue is in deterring the last optional parameter which may confuse people if the omit the last optional parameter and put a trailing%after the use of the macro.– Peter Grill
Dec 7 '18 at 6:10