Mrthfx

What does it mean to describe someone as a butt steak?

High voltage LED indicator 40-1000 VDC without additional power supply

Why doesn't a class having private constructor prevent inheriting from this class? How to control which classes can inherit from a certain base?

Question on branch cuts and branch points

When a company launches a new product do they "come out" with a new product or do they "come up" with a new product?

Decision tree nodes overlapping with Tikz

How old can references or sources in a thesis be?

Can a monk's single staff be considered dual wielded, as per the Dual Wielder feat?

Can you really stack all of this on an Opportunity Attack?

Can a vampire attack twice with their claws using multiattack?

Why doesn't H₄O²⁺ exist?

Is it legal for company to use my work email to pretend I still work there?

Why do I get two different answers for this counting problem?

How much of data wrangling is a data scientist's job?

Mutually beneficial digestive system symbiotes

Mortgage Pre-approval / Loan - Apply Alone or with Fiancée?

Was any UN Security Council vote triple-vetoed?

Is it unprofessional to ask if a job posting on GlassDoor is real?

Why can't we play rap on piano?

If human space travel is limited by the G force vulnerability, is there a way to counter G forces?

Can a Cauchy sequence converge for one metric while not converging for another?

Arithmetic with LuaLaTeX

Is it inappropriate for a student to attend their mentor's dissertation defense?

Replacing matching entries in one column of a file by another column from a different file

Calling section via csname [duplicate]

Absolutely basic csname questionparagraph style - how to force line break? paragraph{} \ - make paragraph a header?How do I make a subsection title visible in a header on page with chapter / sectionsubsubsection in a report style documentCreate new section commands (with correct TOC entries) in KOMA-ScriptUsing renewcommand to define sectionsSection Numbering in Table of Contents but NOT in DocumentDifferent subdivision resolution in divisions of same categoryChange color of section heading and text until next sectionFlush section and subsection title in two-column layoutsection in-line numbering and vertical spacing with the titlesec package

2

This question already has an answer here:

• 
  Absolutely basic csname question
  
  2 answers
  
  

I want to make a command that will create a new section or subsection (or subsubsection or...) based on its argument. Why does calling section and subsection via csname not seem to work at all, and how can I fix it? MWE:

documentclass{article}



newcommand{democmd}[2]{%

  csname #1section endcsname{#2}%

}



begin{document}



% Doesn't (visibly, at least) make a subsection.

democmd{sub}{Should Make a Section}



% Also does not make a section.

csname section endcsname{foo}



end{document}

EDIT: The fixed version is csname sectionendcsname{foo}, no space after section. But why do some macros, like textbf, work as csname textbf endcsname{foo} with the space, whereas others, like section and ref, do not?

sectioning csname

share|improve this question

edited 5 hours ago

dsedivec

asked 5 hours ago

dsedivecdsedivec

558412

marked as duplicate by dsedivec, JouleV, Kurt, Raaja, Stefan Pinnow 3 hours ago

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  The problem is the space before endcsname. Thanks, LaTeX! Please, whatever you do, don't give me any hints or helpful error messages. Also, I think there is a universal law that I can't find the helpful TeX.stackexchange post until after I have posted my question.
  
  – dsedivec
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Have you tried @nameuse{#1section}{#2} and of course remember makeatletter/other around the definition because of the @. Though I fail to see where this can be useful.
  
  – daleif
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Actually, I added a question about why csname textbf endcsname works with the space, which really frustrated me figuring this out. Should this still be a duplicate? I would appreciate input from a more experienced member of the community on this question.
  
  – dsedivec
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  Presumably robustness
  
  – daleif
  4 hours ago
  

  
  
  
  

add a comment | 

2

This question already has an answer here:

• 
  Absolutely basic csname question
  
  2 answers
  
  

I want to make a command that will create a new section or subsection (or subsubsection or...) based on its argument. Why does calling section and subsection via csname not seem to work at all, and how can I fix it? MWE:

documentclass{article}



newcommand{democmd}[2]{%

  csname #1section endcsname{#2}%

}



begin{document}



% Doesn't (visibly, at least) make a subsection.

democmd{sub}{Should Make a Section}



% Also does not make a section.

csname section endcsname{foo}



end{document}

EDIT: The fixed version is csname sectionendcsname{foo}, no space after section. But why do some macros, like textbf, work as csname textbf endcsname{foo} with the space, whereas others, like section and ref, do not?

sectioning csname

share|improve this question

edited 5 hours ago

dsedivec

asked 5 hours ago

dsedivecdsedivec

558412

marked as duplicate by dsedivec, JouleV, Kurt, Raaja, Stefan Pinnow 3 hours ago

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  The problem is the space before endcsname. Thanks, LaTeX! Please, whatever you do, don't give me any hints or helpful error messages. Also, I think there is a universal law that I can't find the helpful TeX.stackexchange post until after I have posted my question.
  
  – dsedivec
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Have you tried @nameuse{#1section}{#2} and of course remember makeatletter/other around the definition because of the @. Though I fail to see where this can be useful.
  
  – daleif
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Actually, I added a question about why csname textbf endcsname works with the space, which really frustrated me figuring this out. Should this still be a duplicate? I would appreciate input from a more experienced member of the community on this question.
  
  – dsedivec
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  Presumably robustness
  
  – daleif
  4 hours ago
  

  
  
  
  

add a comment | 

This question already has an answer here:

• 
  Absolutely basic csname question
  
  2 answers
  
  

I want to make a command that will create a new section or subsection (or subsubsection or...) based on its argument. Why does calling section and subsection via csname not seem to work at all, and how can I fix it? MWE:

documentclass{article}



newcommand{democmd}[2]{%

  csname #1section endcsname{#2}%

}



begin{document}



% Doesn't (visibly, at least) make a subsection.

democmd{sub}{Should Make a Section}



% Also does not make a section.

csname section endcsname{foo}



end{document}

EDIT: The fixed version is csname sectionendcsname{foo}, no space after section. But why do some macros, like textbf, work as csname textbf endcsname{foo} with the space, whereas others, like section and ref, do not?

sectioning csname

share|improve this question

edited 5 hours ago

dsedivec

asked 5 hours ago

dsedivecdsedivec

558412

documentclass{article}



newcommand{democmd}[2]{%

  csname #1section endcsname{#2}%

}



begin{document}



% Doesn't (visibly, at least) make a subsection.

democmd{sub}{Should Make a Section}



% Also does not make a section.

csname section endcsname{foo}



end{document}

share|improve this question

edited 5 hours ago

dsedivec

asked 5 hours ago

dsedivecdsedivec

558412

share|improve this question

edited 5 hours ago

dsedivec

asked 5 hours ago

dsedivecdsedivec

558412

asked 5 hours ago

dsedivecdsedivec

558412

asked 5 hours ago

dsedivecdsedivec

558412

1 Answer
1

active

oldest

votes

3

Preliminary note In the sequel, • denotes a space in the code, just for clarity.

The fact that sometimes csname•command•endcsname works is implementation dependent and should not be relied upon.

Of course the first space is ignored, but the second one isn't, see Absolutely basic csname question.

Why does it work for textbf?

This has to do with the protection mechanism for writing to auxiliary files. A command such as textbf wouldn't survive the basic writing mechanism provided by TeX, so a protection mechanism was devised to avoid it being expanded.

If you do

latexdef textbf

from the command line you get

textbf:

macro:->protect textbf  



textbf :

long macro:#1->ifmmode nfss@text {bfseries #1}else hmode@bgroup text@command {#1}bfseries check@icl #1check@icr expandafter egroup fi 

On the other hand, latexdef -s textbf will answer

% latex.ltx, line 4054:

DeclareTextFontCommand{textbf}{bfseries}

showing that the definition of textbf is rather high level.

Basically, textbf is defined to expand to protecttextbf• (where the space is part of the name and, guess what, textbf• is defined by using csname).

The command protect can take several values, depending on the context. During normal typesetting its meaning is relax (do nothing), but during write operations it changes to mean noexpand (well, not really, but for the purpose of this answer this is not so big a lie).

The result is that during the write operation textbf is first expanded to protecttextbf•, which in turn will do noexpandtextbf• and so the token will be written literally. At the end of the game, the auxiliary file will contain

textbf••

(one space for the name and one because of how TeX writes out command names). But, when the auxiliary file is read in, TeX will just see textbf followed by two spaces which will be ignored by rule.

This implementation does what it is thought for, but this fact should not be exploited. Not all commands made robust are treated this way.

Why section isn't made robust? Because it's very unlikely it will appear in code that needs to be written to an auxiliary file. So section• is not defined (under standard settings). Thus if you write

csname•section•endcsname

TeX will silently replace this with relax. To the contrary, section (without a space) is defined, so

csname•sectionendcsname

is equivalent to section.

share|improve this answer

answered 4 hours ago

egregegreg

731k8919303253

add a comment | 

3

Preliminary note In the sequel, • denotes a space in the code, just for clarity.

The fact that sometimes csname•command•endcsname works is implementation dependent and should not be relied upon.

Of course the first space is ignored, but the second one isn't, see Absolutely basic csname question.

Why does it work for textbf?

This has to do with the protection mechanism for writing to auxiliary files. A command such as textbf wouldn't survive the basic writing mechanism provided by TeX, so a protection mechanism was devised to avoid it being expanded.

If you do

latexdef textbf

from the command line you get

textbf:

macro:->protect textbf  



textbf :

long macro:#1->ifmmode nfss@text {bfseries #1}else hmode@bgroup text@command {#1}bfseries check@icl #1check@icr expandafter egroup fi 

On the other hand, latexdef -s textbf will answer

% latex.ltx, line 4054:

DeclareTextFontCommand{textbf}{bfseries}

showing that the definition of textbf is rather high level.

Basically, textbf is defined to expand to protecttextbf• (where the space is part of the name and, guess what, textbf• is defined by using csname).

The command protect can take several values, depending on the context. During normal typesetting its meaning is relax (do nothing), but during write operations it changes to mean noexpand (well, not really, but for the purpose of this answer this is not so big a lie).

The result is that during the write operation textbf is first expanded to protecttextbf•, which in turn will do noexpandtextbf• and so the token will be written literally. At the end of the game, the auxiliary file will contain

textbf••

(one space for the name and one because of how TeX writes out command names). But, when the auxiliary file is read in, TeX will just see textbf followed by two spaces which will be ignored by rule.

This implementation does what it is thought for, but this fact should not be exploited. Not all commands made robust are treated this way.

Why section isn't made robust? Because it's very unlikely it will appear in code that needs to be written to an auxiliary file. So section• is not defined (under standard settings). Thus if you write

csname•section•endcsname

TeX will silently replace this with relax. To the contrary, section (without a space) is defined, so

csname•sectionendcsname

is equivalent to section.

share|improve this answer

answered 4 hours ago

egregegreg

731k8919303253

add a comment | 

3

Preliminary note In the sequel, • denotes a space in the code, just for clarity.

The fact that sometimes csname•command•endcsname works is implementation dependent and should not be relied upon.

Of course the first space is ignored, but the second one isn't, see Absolutely basic csname question.

Why does it work for textbf?

This has to do with the protection mechanism for writing to auxiliary files. A command such as textbf wouldn't survive the basic writing mechanism provided by TeX, so a protection mechanism was devised to avoid it being expanded.

If you do

latexdef textbf

from the command line you get

textbf:

macro:->protect textbf  



textbf :

long macro:#1->ifmmode nfss@text {bfseries #1}else hmode@bgroup text@command {#1}bfseries check@icl #1check@icr expandafter egroup fi 

On the other hand, latexdef -s textbf will answer

% latex.ltx, line 4054:

DeclareTextFontCommand{textbf}{bfseries}

showing that the definition of textbf is rather high level.

Basically, textbf is defined to expand to protecttextbf• (where the space is part of the name and, guess what, textbf• is defined by using csname).

The command protect can take several values, depending on the context. During normal typesetting its meaning is relax (do nothing), but during write operations it changes to mean noexpand (well, not really, but for the purpose of this answer this is not so big a lie).

The result is that during the write operation textbf is first expanded to protecttextbf•, which in turn will do noexpandtextbf• and so the token will be written literally. At the end of the game, the auxiliary file will contain

textbf••

(one space for the name and one because of how TeX writes out command names). But, when the auxiliary file is read in, TeX will just see textbf followed by two spaces which will be ignored by rule.

This implementation does what it is thought for, but this fact should not be exploited. Not all commands made robust are treated this way.

Why section isn't made robust? Because it's very unlikely it will appear in code that needs to be written to an auxiliary file. So section• is not defined (under standard settings). Thus if you write

csname•section•endcsname

TeX will silently replace this with relax. To the contrary, section (without a space) is defined, so

csname•sectionendcsname

is equivalent to section.

share|improve this answer

answered 4 hours ago

egregegreg

731k8919303253

add a comment | 

Preliminary note In the sequel, • denotes a space in the code, just for clarity.

The fact that sometimes csname•command•endcsname works is implementation dependent and should not be relied upon.

Of course the first space is ignored, but the second one isn't, see Absolutely basic csname question.

Why does it work for textbf?

This has to do with the protection mechanism for writing to auxiliary files. A command such as textbf wouldn't survive the basic writing mechanism provided by TeX, so a protection mechanism was devised to avoid it being expanded.

If you do

latexdef textbf

from the command line you get

textbf:

macro:->protect textbf  



textbf :

long macro:#1->ifmmode nfss@text {bfseries #1}else hmode@bgroup text@command {#1}bfseries check@icl #1check@icr expandafter egroup fi 

On the other hand, latexdef -s textbf will answer

% latex.ltx, line 4054:

DeclareTextFontCommand{textbf}{bfseries}

showing that the definition of textbf is rather high level.

Basically, textbf is defined to expand to protecttextbf• (where the space is part of the name and, guess what, textbf• is defined by using csname).

The command protect can take several values, depending on the context. During normal typesetting its meaning is relax (do nothing), but during write operations it changes to mean noexpand (well, not really, but for the purpose of this answer this is not so big a lie).

The result is that during the write operation textbf is first expanded to protecttextbf•, which in turn will do noexpandtextbf• and so the token will be written literally. At the end of the game, the auxiliary file will contain

textbf••

(one space for the name and one because of how TeX writes out command names). But, when the auxiliary file is read in, TeX will just see textbf followed by two spaces which will be ignored by rule.

This implementation does what it is thought for, but this fact should not be exploited. Not all commands made robust are treated this way.

Why section isn't made robust? Because it's very unlikely it will appear in code that needs to be written to an auxiliary file. So section• is not defined (under standard settings). Thus if you write

csname•section•endcsname

TeX will silently replace this with relax. To the contrary, section (without a space) is defined, so

csname•sectionendcsname

is equivalent to section.

share|improve this answer

answered 4 hours ago

egregegreg

731k8919303253

latexdef textbf

textbf:

macro:->protect textbf  



textbf :

long macro:#1->ifmmode nfss@text {bfseries #1}else hmode@bgroup text@command {#1}bfseries check@icl #1check@icr expandafter egroup fi 

% latex.ltx, line 4054:

DeclareTextFontCommand{textbf}{bfseries}

textbf••

csname•section•endcsname

csname•sectionendcsname

share|improve this answer

answered 4 hours ago

egregegreg

731k8919303253

answered 4 hours ago

egregegreg

731k8919303253

answered 4 hours ago

egregegreg

731k8919303253