User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.28)
            Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
References: <533473A9.3020401@residenset.net>           
            <53387AD3.4060902@morningstar2.co.uk>           
            <533965E4.2060205@residenset.net>
            <53398E5F.8020507@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-ID:  <53399A18.9040401@residenset.net>
Date:         Mon, 31 Mar 2014 18:38:48 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: =?ISO-8859-1?Q?Lars_Hellstr=F6m?= <Lars.Hellstrom@RESIDENSET.NET>
Subject: Re: harmless package public beta
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <53398E5F.8020507@morningstar2.co.uk>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Joseph Wright skrev 2014-03-31 17.48:
> On 31/03/2014 13:56, Lars Hellstr=F6m wrote:
[snip]
>>>    - \__harmless_quat_split- (etc) - all missing an arg spec, which
>>>      looks w-type to me
>>
>> My thinking was that these are "constants" rather than "functions", an=
d
>> for that reason have no argspec part. Even if one considers them
>> functions, they don't take any arguments, so why would they have a w?
>
> If they are constants then  \c__harmless_ ...

Now there's a point I missed!

>>> I'd also suggest the 'sheep and goats' separation of all commands int=
o
>>> fully expandable or \protected.
>>
>> Not sure there could only be those two, but I can certainly change som=
e
>> \newcommand's into \DeclareRobustCommand's.
>
> There are very few commands that don't seem to fall into one of the two
> categories. (I've perhaps got one set for siunitx, but in a very unusua=
l
> use case.) Most commands either:
>
>   - Should/can work inside \edef =3D>  expandable
>   - Don't (assignments, ...) =3D>  \protected

Well, I wonder how that would interact with \harmless_secure_expand:w.

> Note this is nothing to do with \DeclareRobustCommand, as those are not
> engine-robust.

For the time being, I still support TeX 3.

>>> (Note: moving the code to expl3 would require quite a bit of work, bu=
t
>>> that's a different question.)
>>
>> Beyond the rote substitution of l3names for primitives and 2e core
>> macros, is there something particular you think about? (I suspect the
>> unimperative coding style could be one issue. ;-)
>
> A general impression, not least in that you've coded things by hand tha=
t
> would be done using expl3 kernel functions. The other very obvious one
> is that we don't use toks :-)

Not at all?! Or just not the likes of \newtoks?

> A full analysis would take some time!

Understandable.

> I forgot one thing before: as you are using the expl3 namespace in a
> deliberate way, am I OK to add "harmless" to the prefix list with a not=
e
> about the use?

Yes.

>>> More broadly, there are big open questions that
>>> some of this is linked to. One is LICR-type input. As you'll see when=
 we
>>> land our 'new' case changing functions, the team feeling on input
>>> methods for *new* code is to stick close to the engines rather than t=
o
>>> the LaTeX2e approach.
>>
>> You mean a token with character code 229 (U+00E5) is more canonical th=
an
>> \r{a} as encoding of that character? That's actually close to the way
>> harmless would do it (under the \HighCharsUnicode setting). For
>> typesetting, there is conversely \UnicodeCharUsesChar.
>
> In that area, yes. Thinking is currently as follows: for UTF-8 work,
> there are two engines which can do the job. Supporting non-UTF-8 input
> for chars outside of the 8-bit range is something that 'new' code reall=
y
> should avoid. That doesn't negate use of inputenc, etc., for 'real
> world' cases now but does suggest that for new code we might want to
> take a different take. For example, the current thinking is that for
> 'text level' case-changing functions we will support only 'engine
> native' input, which implies that at some stage we'd want to as you say
> do mappings for UTF-8 engines going in the \r{a} =3D>  U+00E5 direction.
> (At a user level, things like \r{a} for a 'one-off' accent remain usefu=
l
> even with a UTF-8 engine.)

As a data-point here, I should perhaps mention that I have for some years=
=20
been using the \r and \" accents even when I write swedish text in LaTeX =
--=20
the reason being that I've remapped the =C5=D6=C4 keys to \{} since the l=
atter are=20
more frequently needed. And when you don't have a character conveniently=20
available on the keyboard, it doesn't make that much difference that UTF-=
8=20
can encode it prefecty fine, if you cannot conveniently type it!

Lars Hellstr=F6m