GNU bug report logs - #54804
29.0.50; zap-to-char: case sensitive for upper-case letter

Previous Next

Full log

Message #17 received at 54804 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Tino Calancha <tino.calancha <at> gmail.com>
Cc: 54804 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, uyennhi.qm <at> gmail.com
Subject: Re: bug#54804: 29.0.50; zap-to-char: case sensitive for upper-case
 letter
Date: Mon, 09 May 2022 09:17:13 -0700

Hello Tino,

Any progress on this?  I would like this functionality.  Thanks.

On Sat 16 Apr 2022 at 02:33pm +03, Eli Zaretskii wrote:

>> From: Tino Calancha <tino.calancha <at> gmail.com>
>> Cc: 54804 <at> debbugs.gnu.org,  uyennhi.qm <at> gmail.com
>> Date: Sat, 16 Apr 2022 12:58:06 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > but why does the implementation have to be so complicated?
>> > Isn't this just about turning off case-fold-search while searching for
>> > the character?  What am I missing?
>> 
>> The patch is moving the shared code in zap-to/zap-up-to in a
>> helper function.  This has 2 motivations:
>> - reduce the code duplication.
>> - define these two related functions close each other.
>> - separate the logic of the function to calculate the region to kill.
>> 
>> If you prefer, we can keep the functions in their current
>> locations (simple.el/misc.el) with a patch like this one:
>
> What I'd prefer is to have a single function (in subr.el) that
> determines whether a character is an upper- or lower-case, and then
> use that function in a simple condition in these two commands.
>
> The function to check whether a character is upper-case doesn't have
> to make a string from the character and then use the "heavy artillery"
> of string-match-p, it could instead use something like
>
>    (characterp (get-char-code-property CHAR 'uppercase))
>
> (But beware of the situation where the Unicode tables are not yet
> available during bootstrap -- in those cases the function should IMO
> punt and return nil no matter what the character is, or maybe support
> just the ASCII characters.  To test whether the 'uppercase table is
> available, see if unicode-property-table-internal returns non-nil.)
>
>> +  ;; Avoid "obsolete" warnings for translation-table-for-input.
>> +  (with-no-warnings
>> +    (if (char-table-p translation-table-for-input)
>> +	(setq char (or (aref translation-table-for-input char) char))))
>
> translation-table-for-input is obsolete for a reason, so adding it to
> a new function is not something we want to do.  If anything, we should
> remove it from the old function.
>
>
>

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.