On 2026-02-19T15:16:06+0100, Alejandro Colomar wrote: > Hi Kevin, > > On 2026-02-19T20:49:59+0800, Kevin J. McCarthy wrote: > > On Thu, Feb 19, 2026 at 08:30:56PM +0800, Kevin J. McCarthy wrote: > > > I'm not dead set against it, but I've never thought the macros or naming > > > were confusing. > > > > > > Making the implementation of each the same seems like a good idea, but I > > > think it would be a shame to get ride of the skip_xxx() and is_xxx() > > > macros. To me they make the code more readable, not less. > > > > I will add that veering into needing to implement our own strchrnul() and > > using not-yet standardized C constructs like '?:' feel like it's going a bit > > too far though, for a minor cleanup. Mutt moves slowly, and still is meant > > to work on (somewhat) older systems. > > Sure; I was just floating ideas. We can incorporate them slowly, to > make sure users can still use mutt(1).
Something I'd like to see, though, is explicit mention of the kind of
white space in the names. It'd be good to have
#define MUTT_CTYPE_SPACE_C " \t\n\v\f\r" // [:space:]
#define MUTT_CTYPE_RFC5322_FWS " \t\r\n" // 'FWS' (3.2.2.)
isspace_c() // C-locale white space
isspace_rfc5322_fws() // RFC5322 3.2.2. 'FWS'
...
And similar names for skipws_c(), skipws_rfc5322_fws(), ...
Every time I see a skipws() variant, I wonder what kind of white space
it skips. That would the the most important improvement I'd see in
handling of white space.
Cheers,
Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
