bug#24603: [PATCH 0/3] Case table updates

[Michal Nazarewicz <mina86@mina86.com>]

On Tue, Oct 18 2016, Eli Zaretskii wrote:
>> From: Michal Nazarewicz <mina86@mina86.com>
>> Cc: eliz@gnu.org
>> Date: Tue, 18 Oct 2016 00:03:42 +0200
>> 
>> As I continue working on the patchset, it keeps on growing.  To
>> somewhat limit that, I’ll start applying the patches.
>
> This is up to you to some degree, but I'd like to point out that it is
> not necessary to apply patches piecemeal.  You can merge to, or rebase
> on, master everything in one go when you are done, there should be no
> technical difficulties with that whatsoever.

Correct.  It’s more of a personal issue than technical one.  The
patchset keeps growing and it’s getting somewhat harder for me to keep
of it.

> Another potential issue I'd like us to avoid is to modify the same
> parts of the code several times in related commits.  If that happens,
> I'd prefer a single commit that changes them only once.
>
> That said, separate pushes are justified if the parts you push provide
> self-contained significant features or improvements.

The second patch does add missing entries to case-table which is
self-contained.

The first patch is somehow more tricky in that regard since it has a lot
of FIXME comments and it’s commit message mentions future patches.

>> The first two map to the first two from original sumbission.  The
>> first gained tests for byte-8 characters and the second includes
>> changes requested by Eli.
>> 
>> The third is a new patch.
>> 
>> Michal Nazarewicz (3):
>>   Add tests for casefiddle.c
>>   Generate upcase and downcase tables from Unicode data
>>   Don’t generate ‘X maps to X’ entries in case tables
>
> Can't the 3rd patch break some code which assumes the current state of
> affairs, i.e. that the case-table entries for characters with no case
> variants are identical to the character itself?  IOW, this sounds like
> an incompatible change, so it should be mentioned as such in NEWS, and
> perhaps we should make sure we don't break too much code out there,
> not sure if that is possible.

I don’t think it can.  The only place where I could find case-table’s
being used directly (as in values stored in it read) were functions in
buffer.h and those have explicit path for missing entries:

    /* Downcase a character C, or make no change if that cannot be done.  */
    INLINE int
    downcase (int c)
    {
      Lisp_Object downcase_table = BVAR (current_buffer, downcase_table);
      Lisp_Object down = CHAR_TABLE_REF (downcase_table, c);
      return NATNUMP (down) ? XFASTINT (down) : c;
    }
    
    /* Upcase a character C known to be not upper case.  */
    INLINE int
    upcase1 (int c)
    {
      Lisp_Object upcase_table = BVAR (current_buffer, upcase_table);
      Lisp_Object up = CHAR_TABLE_REF (upcase_table, c);
      return NATNUMP (up) ? XFASTINT (up) : c;
    }

> What kind of memory savings does this produce, in terms of memory
> footprint of a running Emacs process?

Actually the more I think about it, the less I’m sure the savings are
there.  Since char tables allocate memory in batches, the space may
still be allocated but simply unused.  I’ll drop the patch for now.
Maybe I’ll have time to investigate further at some future date.

> I have no objections or comments to the other 2 patches.

So yeah, I dunno how strongly you feel about it.  I certainly can wait
once the whole patchset is ready, but that may take a while.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»