xparse g argument should be avoided?












6















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 for g but returns <default> if no value is given: G{<default>}.







latex3 xparse parameters







share|improve this question




















  • 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


















6















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 for g but returns <default> if no value is given: G{<default>}.







latex3 xparse parameters







share|improve this question




















  • 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
















6












6








6








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 for g but returns <default> if no value is given: G{<default>}.







latex3 xparse parameters







share|improve this question
















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 for g but returns <default> if no value is given: G{<default>}.







latex3 xparse parameters




latex3 xparse parameters






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 30 '18 at 12:46









TeXnician

24.7k63187




24.7k63187










asked Dec 7 '18 at 4:04









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
















  • 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










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







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












1 Answer
1






active

oldest

votes


















8














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.






share|improve this answer
























  • 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











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









8














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.






share|improve this answer
























  • 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
















8














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.






share|improve this answer
























  • 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














8












8








8







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 7 '18 at 7:36









Joseph Wright♦Joseph Wright

203k21556883




203k21556883













  • 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



















  • 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

















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


















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%2f463626%2fxparse-g-argument-should-be-avoided%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

Berounka

Image
Berounka.mw-parser-output .entete.map{background-image:url("//upload.wikimedia.org/wikipedia/commons/7/7a/Picto_infobox_map.png")} Caractéristiques Longueur 139  km Bassin 8 861  km 2 Bassin collecteur Elbe Débit moyen ? Cours Source Confluence de la Mže et de la Radbuza · Localisation Pilsen · Altitude 305  m · Coordonnées 49° 45′ 13″ N, 13° 23′ 24″ E Confluence Vltava · Localisation Prague · Altitude 187  m · Coordonnées 49° 59′ 43″ N, 14° 24′ 04″ E Géographie Pays traversés   République tchèque modifier   La Berounka est une rivière de la République tchèque. Elle porte le nom de Mže depuis sa source en Allemagne près de la frontière jusqu'à sa confluence avec la Radbuza à Plzeň. Elle continue ensuite sous le nom de Berounka jusqu'à sa confluence avec la Vltava, près de Prague. La rivière est une destination prisée pour les amateurs de canoë, qui appréc...
Read more

Sphinx de Gizeh

Image
Pour les articles homonymes, voir Sphinx. Sphinx de Gizeh.mw-parser-output .entete.egypte-antique{background-image:url("//upload.wikimedia.org/wikipedia/commons/c/cc/Picto_infobox_ancient_Egypt.png")} Site d'Égypte antique Le visage du sphinx de Gizeh. Noms en arabe أبو الهول , Abou al-Hôl Localisation Région Basse-Égypte Coordonnées 29° 58′ 31″ nord, 31° 08′ 16″ est Géolocalisation sur la carte : Égypte Sphinx de Gizeh modifier   Le sphinx de Gizeh est la statue thérianthrope qui se dresse devant les grandes pyramides du plateau de Gizeh, en Basse-Égypte. Sculpture monumentale monolithique la plus grande du monde [ 1 ] avec 73,5 mètres de longueur, 14 mètres de largeur et 20,22 mètres de hauteur, elle représente un sphinx couchant. Réalisée vers -2500, elle serait attribuée à Djédefrê, l'un des pharaons de la IV e  dynastie, représentant son père le pharaon Khéops. Sommaire 1 Étymologie 2 Desc...
Read more

Different font size/position of beamer's navigation symbols template's content depending on regular/plain...

Image
3 Let's suppose I'd like to divert the navigation symbols template (e.g. in order replace them by the frame numbers, see this bug report ;) I would be facing troubles regarding the font size/position, depending on regular/plain frames, as shown by the following MCE. How could I get rid of these troubles? documentclass{beamer} usetheme{PaloAlto} setbeamertemplate{navigation symbols}{insertframenumber/inserttotalframenumber} begin{document} begin{frame} frametitle{A regular frame} end{frame} begin{frame}[plain] frametitle{A plain frame} end{frame} end{document} beamer header-footer share | improve this question asked Dec 10 '18 a...
Read more