On 08/02/2015 22:15, Joseph Wright wrote:
> *Escaping from case changing*
> 
> David Carlisle points out that using the BibTeX-like approach leaves a
> problem with ligatures. Whilst input such as
> 
>     {Text}
> 
> rather than
> 
>     {T}ext
> 
> does help, the alternative route taken by textcase
> 
>     \NoChangeCase{Text}
> 
> allows for the 'escape' mechanism to be entirely transparent at the
> typesetting stage (as the appropriate commands can be equivalent to \use:n).
> 
> Barbara Beeton provides a useful example where a brace group is
> 'trapped' inside a word with the BibTeX-like scheme as for example
> 
>     MacArthur => MacARTHUR
> 
> requires input
> 
>     M{ac}Arthur
> 
> with the current set up and this cannot be done to avoid a ligature break.
> 
> I am therefore minded to alter the approach in this area to follow
> textcase: such a change will if done include adding a sensible set of
> standard commands to the 'ignore list' (\label, \ref, ...).
> 
> Adopting a texcase-like approach also suggests that automatically
> handling math mode might be desirable: a first pass for that might well
> be based on matching single-token delimiters ($...$/\(...\) as standard
> settings) with logic that more complex arrangements will be best covered
> by the \NoChangeCase concept.
> 
> *Expandability*
> 
> One approach suggested (again by David C.) to this area is to start with
> an assumption of e-TeX (\robustify for the etoolbox package for example
> can be used to make existing commands e-TeX protected). With that
> assumption, it is relatively straight-forward to expand 'variable-like'
> macros and leave 'command-like' ones alone. (I already have code that
> does much the same in siunitx.)
> 
> Retaining an expandable approach does seem sensible as it allows what
> many other languages do: case changing in a 'functional' sense (or
> rather as a macro language in an x-type expansion sense). As already
> noted, the need for contextual case mappings means that using the TeX
> primitives directly still requires a separate mapping phase and so
> performance issues are not so significant.
> 
> *LICR/Non-native input*
> 
> As the code here is being developed primarily for use to support future
> work, and that will increasingly mean Unicode-native engines, comments
> here suggest sticking to the 'ASCII/Unicode' line taken to date. As
> such, pdfTeX use with non-ASCII input will need pre-processing via
> \protected@edef as suggested to produce LICR data which can be handled
> correctly.
> 
> Depending on other feedback, I will likely implement the above changes
> over the coming days and then look to update the release code.

Based on the above I have reworked parts of the logic for these
functions. The logic is now that case changing happens for all content
except where excluded either by being in math mode or by being given as
the argument to a list of special 'exclude' functions. This approach is
closely modelled on David Carlisle's textcase package. As such,
something like

    \ExplSyntaxOn
    \tl_put_right:Nn \l_tl_case_change_exclude_tl { \NoCaseChange }
    \cs_new_eq:NN \NoCaseChange \use:n
    \cs_new_eq:NN \MakeTextUppercase \tl_upper_case:n
    \ExplSyntaxOff
    \MakeTextUppercase
      {%
        abc\ae\ \( a = b \)  and $\alpha \neq a$
        or even \ensuremath{x=y} and $\ensuremath{x=y}$%
      }

will yield

    ABC\AE \ \( a = b \) AND $\alpha \neq a$ OR EVEN \ensuremath {x=y}
    AND $\ensuremath {x=y}$

(example taken verbatim from textcase manual).

The functions remain x-type expandable and will expand any content in
the argument in non-protected macros. (Note: e-TeX protection is
required for this.)

I will update CTAN shortly to allow wider testing of the new code.
--
Joseph Wright