Space before dash in \directory{}

[foreachthing]

Whenever I got a path with a dash (-) in it, like c:\temp\dir-dir, menukeys puts a space before the -. So, it comes out like this: c:\temp\dir -dir This is not correct, since a reader will assume a space before the dash.

This only occurs when using the [bslash] option. ->\directory[bslash]{c:\temp\dir-dir}

[tweh]

Idee, this is a bug. Unfortunately I have no idea, why this happens. I guess it has to to with the heavy cat-code fiddling when using a backslash. I postet a (question on TeX.SX)[https://tex.stackexchange.com/q/391393/4918], to see if someone has a solution.

As a workaround you could chang to another separator for your paths, since this only happens with \.

\documentclass{article}

\usepackage{menukeys}

\begin{document}
this: \directory[bslash]{c:\temp\dir-dir} (extra space before \verb|-|)

should be the same as this: \directory[/]{c:/temp/dir-dir}
\end{document}

[cgnieder]

The reason is that \detokenize adds spaces after control sequences:

\documentclass{article}
\begin{document}

\ttfamily
+\detokenize{\foo\bar\baz}+

\end{document}

This happens in the definition of \tw@define@menu@macro.

A solution might be something like this:

\documentclass{article}
\begin{document}

\makeatletter
\def\q@stop{\q@stop}
\def\@stringify#1{%
  \ifx#1\q@stop
  \else
    \string#1%
    \expandafter\@stringify
  \fi
}

\ttfamily
\@stringify\foo\bar\baz\q@stop

\makeatother

\end{document}

[Skillmon]

The solution pointed out by @cgnieder could really be used in this case, but it would require a bit more work (the proposed \@stringify would mistreat spaces and braces). While braces might really seldomly be an issue, spaces seem like important to keep (just as important as not to introduce superfluous spaces).

[Skillmon]

Since there is no real fool-proof way to know whether there is a space following a macro without making category code changes (something which again can't be done in a fool-proof way, because we can't be sure that the argument is not yet tokenized), this will not get fixed.

I'm inclined to drop the support for a backslash as the parsing delimiter in future versions. There really is no way to distinguish \dir-dir from \dir -dir, and we can't just assume that there is never a space there. One could make the guess that if the following token isn't of category 11 there is no space and else there is, but again that would be a wild guess, something I'd like to avoid.

[marijnschraagen]

Another option might be to use the v argument specifier for the path string and not use \detokenize at all. Around https://github.com/tweh/menukeys/blob/master/menukeys.dtx#L1643 something like

#1#2{+O{#3}+v}% +v specifier here
{%
   \leavevmode
   \begingroup
   \def\tw@current@color@theme
      {\csname tw@style@#4@color@theme\endcsname}%
      \@nameuse{tw@style@#4@pre}%
      \tw@mk@test@input@sep{##1}
      {%
         \edef\tw@menu@list{##2}% no \detokenize
         \edef\tw@mk@tempa{\@backslashchar}%
      }
      {%
         \edef\tw@menu@list{##2}% no \unexpanded
         \edef\tw@mk@tempa{\tw@mk@trimspaces{##1}}%
      }%
% ...

I don't know if this has unwanted side effects, at least for \directory it seems to work. See https://tex.stackexchange.com/questions/369361/using-menukeys-to-typeset-paths-containing-hyphens for more context.

[Skillmon]

@marijnschraagen thanks for the suggestion, this would indeed be possible, but this way you couldn't use any macros in the argument (\detokenize does only happen for bslash currently, but this would read verbatim in every case), also the behaviour of consecutive spaces would be altered (currently TeX's normal parsing rules apply here). And (perhaps the most limiting aspect) no menukeys macro could be used as the argument to another macro (as that's the rule of v/+v).

All in all this has too many unwanted side effects that would be too expensive to solve, especially considering that the current parsing for bslash is poor enough but at least foreseeable (and I'm really not in favour of further supporting it -- see my above comment's reasoning as well).

I'm planning to rewrite menukeys from scratch making extensive use of expl3. Once this rewrite is done, I'll step the version up to 2.x and drop the bslash syntax entirely (there will be a backwards compatibility mode, but that will only use a frozen version 1.x).