When you create a package or class, it is conventional for internal
(non-user) command names to be prefixed with an abbreviation as well as
the '@' sign, to try and avoid clashes with other packages, eg in my
recent symbats3 package I used \SY@... for all the internal command
names. Two letters is probably too short, and a long name for an
internal command is not a user usability issue, so \SYMBATS3@... is
probably better.

For the user commands, however, there is no prefix in the current
version of the symbats3 package, and Karl Berry has reminded me that
there will be other packages defining similar names (a quick look at the
Comprehensive Symbols list shows at least two other packages defining
\pentagram, for example).

How long should a prefix be on user commands in such circumstances? I
see that FontAwesome, which probably defines more symbols than anything
else in a single package, just uses \fa and then capitalises the name,
resulting in a camelCase command. I can see a problem, obviously, for
packages of symbols to use \sy because of conflicts with others. The
prefix \bat would be misleading for the symbats3 package, so perhaps
\sb? Or should it be like the twemoji package and insist on a
command-and-argument, eg \symbat{...}

(I may have missed this dicsussion if it has occurred before)

Peter

Peter Flynn wrote:
> I can see a problem, obviously, for
> packages of symbols to use \sy because of conflicts with others.

I believe a prevalent frequently used custom would be to use your own
initials, perhaps capitalized. So in this case
\PFsomething

It's what I tend to do in similar cases using FAB.

--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

On 08/07/2022 15:32, Axel Berger wrote:
> Peter Flynn wrote:
>> I can see a problem, obviously, for
>> packages of symbols to use \sy because of conflicts with others.
>
> I believe a prevalent frequently used custom would be to use your
> own initials, perhaps capitalized. So in this case \PFsomething
>
> It's what I tend to do in similar cases using FAB.

Very useful, thanks.

I did a little digging into my TeX Live installed base of .sty files and
found the following distribution of prefix lengths ("prefix" being all
caps between backslash and at-sign, so \BAR@ would be length=3):

N length
909 3
544 2
170 4
38 5
24 6
13 7
8 8
3 12

Between 2 and 4 characters is probably sufficient. The data on the most
common prefixes was interesting: identifying the meanings of the
acronyms is left as an exercise to the reader :-) but I wouldn't want to
be an author with the initials TMP. Now that I am more aware of this,
it's probably something intending package authors should be aware of.

451 LWR
52 KV
35 NCC
35 XKV
28 LT
27 TMP
24 FP
22 ZREF
20 NAT
18 CT
17 NC
16 FV
15 ESKD
14 FN
13 HAP
13 HAPR
13 KOMA
13 SK
13 TX
11 FB
11 NR
11 XC
10 CJK
10 TE
10 TPT
[with a long tail]

Peter

Peter Flynn wrote:

> When you create a package or class, it is conventional for internal> (non-user) command names to be prefixed with an abbreviation as well> as the '@' sign, to try and avoid clashes with other packages, eg in> my recent symbats3 package I used \SY@... for all the internal> command names. Two letters is probably too short, and a long name for> an internal command is not a user usability issue, so \SYMBATS3@...> is probably better.>
> For the user commands, however, there is no prefix in the current
> version of the symbats3 package, and Karl Berry has reminded me that
> there will be other packages defining similar names (a quick look at
> the Comprehensive Symbols list shows at least two other packages
> defining \pentagram, for example).> > How long should a prefix be on user commands in such circumstances?
> I see that FontAwesome, which probably defines more symbols than
> anything else in a single package, just uses \fa and then capitalises
> the name, resulting in a camelCase command. I can see a problem,
> obviously, for packages of symbols to use \sy because of conflicts
> with others. The prefix \bat would be misleading for the symbats3
> package, so perhaps \sb? Or should it be like the twemoji package and
> insist on a command-and-argument, eg \symbat{...}
How about providing a package-option so that the user can specify a
prefix and/or a suffix her-/himself, e.g., with \usepackage /
\RequirePackage or \PassOptionsToPackage ?

On the side of the package programmer the need of taking prefix/
postfix into account might make things a bit more cumbersome.

But it should be feasible.

Using expl3, even an interface based on a property-list might be
feasible so that the user can specify prefixes/postfixes/replacements
of names of specific user-level-commands/environments only via
a package-option.

Of course a lot of stuff under the hood would need to be done via
\csname..\endcsname, expl3's c-expansion and - for names of
environments and the like - things like \cs_to_str:N .
> (I may have missed this dicsussion if it has occurred before)
E.g., at de.comp.tex.tex a discussion took place in February 2020:
Stilfrage "command already defined"

URL <https://groups.google.com/g/de.comp.text.tex/c/-q-TGo8chbc/m/nbHGwcumBQAJ>

Sorry, I currently am not in the condition to translate to English language -
pain and tinnitus are too distracting.

Sincerely

Ulrich

Axel Berger wrote:

> Peter Flynn wrote:
>> I can see a problem, obviously, for
>> packages of symbols to use \sy because of conflicts with others.
>
> I believe a prevalent frequently used custom would be to use your own
> initials, perhaps capitalized. So in this case
> \PFsomething
>
> It's what I tend to do in similar cases using FAB.

The Additional Information for CTAN Uploaders
says in section "More requirements on your upload …",
item "2 Conditions on package ids".
url: <https://ctan.org/file/help/ctan/CTAN-upload-addendum#noauthornames> :

| e. New packages and bundles should not be named after their authors
| but after the purpose they are serving, because they may later be
| taken over by other maintainers. (We know that there are a few
| well established CTAN packages that do not fulfill this rule; but
| that comes under “protection of vested rights”, and we have now
| learned from history.)

Probably the same practice should apply for names of macros/environments
as well.

Sincerely

Ulrich

Am Fri, 8 Jul 2022 12:13:00 +0100 schrieb Peter Flynn:

> For the user commands, however, there is no prefix in the current
> version of the symbats3 package, and Karl Berry has reminded me that
> there will be other packages defining similar names (a quick look at the
> Comprehensive Symbols list shows at least two other packages defining
> \pentagram, for example).
>

I wouldn't setup such a dingbats font with fontspec: claiming that
it is TU encoded looks wrong. I also wouldn't define hundreds of
user commands but use an interface similar to the pifont package.
(Sadly its \Pifont commands forces the series to m, so it isn't
directly suitable for your use case where three weights exist):

\documentclass{article}
\DeclareFontFamily{U}{symbats}{}
\DeclareFontShape{U}{symbats}{m}{n}{<->\UnicodeFontFile{Symbats-Regular}{}}{}
\DeclareFontShape{U}{symbats}{l}{n}{<->\UnicodeFontFile{Symbats-Light}{}}{}
\DeclareFontShape{U}{symbats}{b}{n}{<->\UnicodeFontFile{Symbats-Bold}{}}{}
\DeclareFontShape{U}{symbats}{bx}{n}{<->\UnicodeFontFile{Symbats-Bold}{}}{}

\usepackage{pifont}

%allow the series to change
\renewcommand{\Pifont}[1]{\fontfamily{#1}\fontencoding{U}\fontshape{n}\selectfont}

\begin{document}
\Pisymbol{symbats}{"57} \Pisymbol{symbats}{"62}
\bfseries
\Pisymbol{symbats}{"57} \Pisymbol{symbats}{"62}
\fontseries{l}\selectfont
\Pisymbol{symbats}{"57} \Pisymbol{symbats}{"62}

\mdseries
\Pifill{symbats}{"48}
\end{document}

Users that need more speaking commands can then easily define them.

--
Ulrike Fischer
http://www.troubleshooting-tex.de/

On 08/07/2022 22:23, Ulrich D i e z wrote:
[snip]
> How about providing a package-option so that the user can specify a
> prefix and/or a suffix her-/himself, e.g., with \usepackage /
> \RequirePackage or \PassOptionsToPackage ?

Very interesting idea. \usepackage[prefix=FOO]{something}

> Of course a lot of stuff under the hood would need to be done via
> \csname..\endcsname,

Time for some experimentation.

>> (I may have missed this dicsussion if it has occurred before)
> E.g., at de.comp.tex.tex a discussion took place in February 2020:
> Stilfrage "command already defined"
> URL <https://groups.google.com/g/de.comp.text.tex/c/-q-TGo8chbc/m/nbHGwcumBQAJ>

Thank you.

> Sorry, I currently am not in the condition to translate to English
> language - pain and tinnitus are too distracting.

Tut mir leid zu hören. Versorg Dich selbst gut.

Peter

On 08/07/2022 22:23, in comp.text.tex Ulrich D i e z wrote:
[snip]
> [...]at de.comp.tex.tex a discussion took place in February 2020:
> Stilfrage "command already defined"
> URL <https://groups.google.com/g/de.comp.text.tex/c/-q-TGo8chbc/m/nbHGwcumBQAJ>

[I have translated a little of this and set the References to include
the original thread.]

An interesting thread on what to do with command-name conflicts when
writing a package, suggesting four possibilities:

On 18/02/2020 11:11, Ekkart Kleinod wrote:

> 1. do nothing and let it crash
>
> 2. see if the command is already defined, issue a warning, and don't
> define my command
>
> 3. see if the command is already defined, issue a warning, and overwrite
> it with my command
>
> 4. see if the command is already defined, issue a warning, and pick
> another name for my command

The thread ends with a good summary of the internal vs external naming
options:

On 21/02/2020 14:24, eu_angelion@web.de wrote:

> Option 5
>
> - _Internal_ macros: always use a prefix separated by "@", which
> establishes a namespace for the internal macros of your package,
> and chosen to reduce the chances another package using the same
> prefix.
>
> - use kvoptions or similar to provide a package option
> "NamespacePrefix" which is null by default, but provides user
> control over the naming prefix for the user-level commands of
> your package.
>
> - when defining user-level commands in your package, first check
> to see if such a macro is already defined [elsewhere]. If yes,
> issue an error message and draw attention to the NamespacePrefix
> option that will resolve the problem.
>
> - In documentation, make it clear that package authors who use the
> user-level commands of your package should not call those
> commands direct, but using a method that takes the
> NamespacePrefix into consideration.

[followed by an extensive worked example].

On 18/02/2020 13:35, Axel Berger wrote:

> I seem to remember that someone (Markus Kohm), somewhere, made a
> start on a list of all commands defined somewhere.
Does anyone know if this is ongoing?

Peter

On 09/07/2022 10:09, Ulrike Fischer wrote:
[snip]
> I wouldn't setup such a dingbats font with fontspec: claiming that
> it is TU encoded looks wrong. I also wouldn't define hundreds of
> user commands but use an interface similar to the pifont package.

Thank you, this is a neater solution, but it makes the user interface
use numbers instead of names. The objective of the package was to
provide descriptive names. There seem to be four ways:

1. unshielded names, eg \pentagram
(deprecated because of widespread conflicts)

2. prefixed names with camelcase, like fontawesome does, eg
\faPentagram

3. command-and-name, like twemojis does, eg \twemoji{name}
(also provided by fontawesome, eg \faicon{name})

4. command-and-number, using an established index (twemojis
also provides this)

Peter

Peter Flynn: wrote:

> On 09/07/2022 10:09, Ulrike Fischer wrote:
> [snip]
>> I wouldn't setup such a dingbats font with fontspec: claiming that
>> it is TU encoded looks wrong. I also wouldn't define hundreds of
>> user commands but use an interface similar to the pifont package.
>
> Thank you, this is a neater solution, but it makes the user interface use numbers instead of names. The objective of the package was to provide descriptive names.

If using expl3 is an option for you, you can probably use \str_case:nnTF
for implementing mapping from a string to a number and this way add some
"descriptiveness" to a pifont-like interface which uses numbers - you can
even map more than one description to a number if you like:

\documentclass{article}
\usepackage{pifont}

\ExplSyntaxOn
\cs_generate_variant:Nn \str_case:nnTF {enTF}
\cs_new:Npn \MapDescriptionToDingbatsNumber #1 {
\str_case:enTF {#1}{
{space}{32}
{upper~blade~scissors}{33}
{black~scissors}{34}
%...
{open~outlined~rightwards~arrow}{254}
}{}{-1} % in case mapping not available give -1 as a bad character-code
} \ExplSyntaxOff

\begin{document}

\ding{33}=%
\ding{\MapDescriptionToDingbatsNumber{upper blade scissors}}=%
\def\temp{upper blade scissors}%
\ding{\MapDescriptionToDingbatsNumber{\temp}}

\ding{34}=%
\ding{\MapDescriptionToDingbatsNumber{black scissors}}=%
\def\temp{black scissors}%
\ding{\MapDescriptionToDingbatsNumber{\temp}}

\ding{254}=%
\ding{\MapDescriptionToDingbatsNumber{open outlined rightwards arrow}}=%
\def\temp{open outlined rightwards arrow}%
\ding{\MapDescriptionToDingbatsNumber{\temp}}

\end{document}

If you wish you can split the mapping of descriptions to numbers across
several macros:

\documentclass{article}
\usepackage{pifont}

\ExplSyntaxOn
\cs_generate_variant:Nn \str_case:nnTF {enTF}
\cs_new:Npn \MapDescriptionToDingbatsNumber #1 {
\str_case:enTF {#1}{
{space}{32}
{upper~blade~scissors}{33}
%...
}{}{\MapDescriptionToDingbatsNumberBlockB{#1}} % in case mapping not available in this block, look at the next block
} \cs_new:Npn \MapDescriptionToDingbatsNumberBlockB #1 {
\str_case:enTF {#1}{
{black~scissors}{34}
%...
{open~outlined~rightwards~arrow}{254}
}{}{-1} % in case mapping not available give -1 as a bad character-code
} \ExplSyntaxOff

\begin{document}

\ding{33}=%
\ding{\MapDescriptionToDingbatsNumber{upper blade scissors}}=%
\def\temp{upper blade scissors}%
\ding{\MapDescriptionToDingbatsNumber{\temp}}

\ding{34}=%
\ding{\MapDescriptionToDingbatsNumber{black scissors}}=%
\def\temp{black scissors}%
\ding{\MapDescriptionToDingbatsNumber{\temp}}

\ding{254}=%
\ding{\MapDescriptionToDingbatsNumber{open outlined rightwards arrow}}=%
\def\temp{open outlined rightwards arrow}%
\ding{\MapDescriptionToDingbatsNumber{\temp}}

\end{document}

Sincerely

Ulrich

I wrote:

> If using expl3 is an option for you, you can probably use \str_case:nnTF
> for implementing mapping from a string to a number and this way add some
> "descriptiveness" to a pifont-like interface which uses numbers - you can
> even map more than one description to a number if you like:

Here is what interface3.pdf says about \str_case:nnTF :

| \str_case:nnTF {⟨test string⟩}
| {
| {⟨string case 1⟩} {⟨code case 1⟩}
| {⟨string case 2⟩} {⟨code case 2⟩}
| ...
| {⟨string case n⟩} {⟨code case n⟩}
| }
| {⟨true code⟩}
| {⟨false code⟩}
|
| Compares the ⟨test string⟩ in turn with each of the ⟨string cases⟩ (all token lists are
| converted to strings). If the two are equal (as described for \str_if_eq:nnTF) then the
| associated ⟨code⟩ is left in the input stream and other cases are discarded. If any of
| the cases are matched, the ⟨true code⟩ is also inserted into the input stream (after the
| code for the appropriate case), while if none match then the ⟨false code⟩ is inserted. The
| function \str_case:nn, which does nothing if there is no match, is also available.

Sincerely

Ulrich

I wrote:

> Here is what interface3.pdf says about \str_case:nnTF :
>
> | \str_case:nnTF {⟨test string⟩}
> | {
> | {⟨string case 1⟩} {⟨code case 1⟩}
> | {⟨string case 2⟩} {⟨code case 2⟩}
> | ...
> | {⟨string case n⟩} {⟨code case n⟩}
> | }
> | {⟨true code⟩}
> | {⟨false code⟩}
> |
> | Compares the ⟨test string⟩ in turn with each of the ⟨string cases⟩ (all token lists are
> | converted to strings). If the two are equal (as described for \str_if_eq:nnTF) then the
> | associated ⟨code⟩ is left in the input stream and other cases are discarded. If any of
> | the cases are matched, the ⟨true code⟩ is also inserted into the input stream (after the
> | code for the appropriate case), while if none match then the ⟨false code⟩ is inserted. The
> | function \str_case:nn, which does nothing if there is no match, is also available.

What is not said in interface3.pdf is that only the ⟨code⟩
associated to the first match is left in the input stream.

E.g., if you do

\str_case:nnTF {match}
{
{match} {code of first match}
{something else} {code if something else}
...
{match} {code of second match}
}
{there was a match}
{there was no match}

you don't get

code of first matchcode of second matchthere was a match

but you get

code of first matchthere was a match

Sincerely

Ulrich

Peter Flynn wrote:

> On 08/07/2022 22:23, Ulrich D i e z wrote:
> [snip]
>> How about providing a package-option so that the user can specify a
>> prefix and/or a suffix her-/himself, e.g., with \usepackage /
>> \RequirePackage or \PassOptionsToPackage ?
>
> Very interesting idea. \usepackage[prefix=FOO]{something}
>
>> Of course a lot of stuff under the hood would need to be done via
>> \csname..\endcsname,
>
> Time for some experimentation.

By means of expl3 I can offer an interface for replacing control-sequence-tokens
by other control-sequence-tokens:

Via \prop_gset_from_keyval:Nn define a property list where the keys are
control sequences and the values are control sequences that shall replace the
control-sequences denoted by the keys.

Have some commands which look up whether things are in the property-list and if
so use the replacements defined in the property-list and if not so use the
things directly.

Due to \romannumeral/\exp:w-expansion each command requires two expansion steps
to deliver the result.

Each command is of pattern

\command <stuff not in braces> {<stuff that might be replaced>}

<stuff not in braces> can be empty.

I.e., the first argument of \command is delimited by a curly opening brace,
"#{"-notation in the TeXbook.

The argument in curly braces with \ReplaceCsToken/\ReplaceCsTokenInBraces
contains a single control sequence token, which, depending on the "settings"
in the property-list, is to be replaced/is not to be replaced.

The argument in curly braces with \ReplaceCsName/\ReplaceCsNameInBraces
contains a csname which, depending on the "settings" in the property-list
is to be replaced/is not to be replaced. The tokens forming the csname
are expanded via c-expansion/via \csname..\endcsname and afterwards
stringified via \cs_to_str:N.

E.g., if you wish \foo to be replaced by \WHOOZLE and thus (e.g., via package-option)
did

\prop_gset_from_keyval:Nn \g_mymodule_macroname_replacement_prop { \foo = \WHOOZLE }

, then

- \ReplaceCsToken STUFF{\foo} yields STUFF\WHOOZLE .
- \ReplaceCsTokenInBraces STUFF{\foo} yields STUFF{\WHOOZLE} .
- \ReplaceCsName STUFF{foo} yields STUFFWHOOZLE .
- \ReplaceCsNameInBraces STUFF{foo} yields STUFF{WHOOZLE} .

If you did not do this, then

- \ReplaceCsToken STUFF{\foo} yields STUFF\foo .
- \ReplaceCsTokenInBraces STUFF{\foo} yields STUFF{\foo} .
- \ReplaceCsName STUFF{foo} yields STUFFfoo .
- \ReplaceCsNameInBraces STUFF{foo} yields STUFF{foo} .

With \ReplaceCsToken STUFF can, e.g., be "\newcommand*" or "\show" or "\meaning".
With \ReplaceCsTokenInBraces STUFF can, e.g., be "\NewDocumentCommand".
\ReplaceCsName might be useful inside \csname..\endcsname-expressions.
With \ReplaceCsNameInBraces STUFF can, e.g., be "\newenvironment" or the like.

\ReplaceCsToken etc are macro-based, thus they are not of any use if it is
about tokens defined in terns of \outer.

Sincerely

Ulrich

Here comes the code - no warranties, just a starting-point.

E.g., no error-catching is implemented with the initialization of the property-list in
case either a key or a value is not a control sequence token.

\documentclass{article}
\ExplSyntaxOn
% Establish the property-list:
\prop_new:N \g_mymodule_macroname_replacement_prop
% Define the commands described in the text of the usenet-posting
% for doing the replacement:
\cs_new:Npn \ReplaceCsToken #1# {\exp:w \_mymodule_ReplaceCsToken:nnn {#1}{\use:nn} }
\cs_new:Npn \ReplaceCsTokenInBraces #1# {\exp:w \_mymodule_ReplaceCsToken:nnn {#1} {\use:n} }
\cs_new:Nn \_mymodule_ReplaceCsToken:nnn {
\exp_args:Nnf #2 {\exp_end: #1} {
\exp_args:Nno
\use:n
{\prop_if_in:NnTF \g_mymodule_macroname_replacement_prop}
{\tl_to_str:n {#3} }
{\exp_args:Nno \use:n { \prop_item:Nn \g_mymodule_macroname_replacement_prop} {\tl_to_str:n{#3}}}
{\exp_stop_f: #3}
}
} \cs_new:Npn \ReplaceCsName #1# {\exp:w \exp_args:Nnc \use:n { \_mymodule_ReplaceCsName:nnn {#1}{\use:nn}} }
\cs_new:Npn \ReplaceCsNameInBraces #1# {\exp:w \exp_args:Nnc \use:n { \_mymodule_ReplaceCsName:nnn {#1}{\use:n}} }
\cs_new:Nn \_mymodule_ReplaceCsName:nnn {
\exp_args:Nnf \use:n { \exp_args:Nno \use:n { \exp_args:Nno \use:n { #2 {\exp_end: #1} } } }
{
\exp_args:Nno \use:n { \exp_args:Nno \use:nn { \exp_stop_f: \cs_to_str:N } } {\ReplaceCsToken {#3}}
}
} %
% Initialize the property-list according to pattern
% <control-sequence>=<replacement-control-sequence>, ...
% This initialization could be done by a package during processing of options;
% the need of nested key=value-list and thus the proper brace-nesting might be
% tricky:
% \prop_gset_from_keyval:Nn \g_mymodule_macroname_replacement_prop {
\foo = \prefixfoo , % <- Replace control-sequence \foo by \prefixfoo
\bat = \otherprefixbat, % <- Replace control-sequence \bat by \prefixbat
} % Map over the property-list for prepending \exp_stop_f: with each value,
% ensuring proper termination of expansion-based extraction-routines:
\prop_map_inline:Nn \g_mymodule_macroname_replacement_prop {
\prop_gput:Nnn \g_mymodule_macroname_replacement_prop {#1} {\exp_stop_f: #2}
} \ExplSyntaxOff

\begin{document}

% This defines \prefixfoo:
\ReplaceCsToken\newcommand*{\foo}[1]{foo's definition with argument #1}

% This is undefined:
\show\foo

% This is defined:
\show\prefixfoo

% This also shows \prefixfoo:
\ReplaceCsToken\show{\foo}

% This redefines \prefixfoo:
\ReplaceCsTokenInBraces\RenewDocumentCommand{\foo}{m}{foo's re-definition with argument #1}

% This shows the xparse-underlying macro \prefixfoo<space>code:
\expandafter\show\csname\ReplaceCsName{foo} code\endcsname

% These show \Textprefixfoo which is undefined and thus by \csname is defined to \relax:
\expandafter\show\csname \ReplaceCsName Text{foo}\endcsname
\expandafter\show\csname Text\ReplaceCsName{foo}\endcsname

% This displays what \ReplaceCsNameInBraces does
\message{^^J\detokenize\expandafter\expandafter\expandafter{\ReplaceCsNameInBraces Text{foo}}}

\message{^^J--------------------------------------}

% These show defining environments

\ReplaceCsNameInBraces\newenvironment{bat}{env bat begin}{env bat end}

\ReplaceCsToken\show{\bat}

\show\endotherprefixbat

\show\endbat

\message{^^J--------------------------------------}

% These show the effect if no replacement is to be done:

\ReplaceCsToken\newcommand*{\hoo}[1]{hoo's definition with argument #1}

\show\hoo

\show\prefixhoo

\ReplaceCsToken\show{\hoo}

\ReplaceCsTokenInBraces\RenewDocumentCommand{\hoo}{m}{hoo's re-definition with argument #1}

\expandafter\show\csname\ReplaceCsName{hoo} code\endcsname

\expandafter\show\csname \ReplaceCsName Text{hoo}\endcsname
\expandafter\show\csname Text\ReplaceCsName{hoo}\endcsname

\message{^^J\detokenize\expandafter\expandafter\expandafter{\ReplaceCsNameInBraces Text{hoo}}}

\end{document}

I wrote:

> \bat = \otherprefixbat, % <- Replace control-sequence \bat by \prefixbat

The comment is wrong. It should be:

\bat = \otherprefixbat, % <- Replace control-sequence \bat by \otherprefixbat

Sincerely

Ulrich

Peter Flynn wrote:

> On 18/02/2020 13:35, Axel Berger wrote:
>
>> I seem to remember that someone (Markus Kohm), somewhere, made a
>> start on a list of all commands defined somewhere.
> Does anyone know if this is ongoing?

There seems to be a perl-script available at
<https://komascript.de/texcommands>
--the site is written in German language--which searches the
latex- and the generic-branch of a TeX Live Installation and
creates a database which lists in which files definitions of
which commands can be found.

I did not test it. ;-)

Sincerely

Ulrich