GNU bug report logs - #66614
29.1.50; Support not capitalizing words inside symbols

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#66614: closed (29.1.50; Support not capitalizing words inside
 symbols)
Date: Sun, 29 Oct 2023 11:44:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 29 Oct 2023 13:42:03 +0200
with message-id <83msw1bqpg.fsf <at> gnu.org>
and subject line Re: bug#66614: 29.1.50; Support not capitalizing words inside symbols
has caused the debbugs.gnu.org bug report #66614,
regarding 29.1.50; Support not capitalizing words inside symbols
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
66614: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66614
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1.50; Support not capitalizing words inside symbols
Date: Wed, 18 Oct 2023 12:32:04 -0400

Quick definitions:
- word: a sequence of characters whose syntax is word constituent
- symbol: a sequence of characters whose syntax is either word
constituent or symbol constituent

In some programming languages and styles, a symbol (or every symbol in a
sequence of symbols) might be capitalized, but the individual words
making up the symbol should never be capitalized.

For example, in OCaml, type names Look_like_this and variable names
look_like_this, but it is basically never correct for something to
Look_Like_This.  And one might have "aa_bb cc_dd ee_ff" or "Aa_bb Cc_dd
Ee_ff", but never "Aa_Bb Cc_Dd Ee_Ff".

Currently, case handling in casefiddle.c and Freplace_match always
capitalizes individual words, which has undesirable effects when
programming in these styles.  Three examples:

- If I have a variable "hash_set" and a type name "Hash_set", and I type
  "Ha" and dabbrev-expand, then depending on the context Ha may expand
  to Hash_Set instead of hash_set.  But it is never correct to
  caplitalize internal words in this style, so we could avoid this.

- If I have a variable foo and Foo, and I query-replace foo with
  bar_baz, the replacements will be bar_baz and Bar_Baz.  But again it
  is never correct to capitalize internal words in this style.

- More concretely,
  (progn 
    (string-match "az" "Az")
    (replace-match "az_bz" nil nil "Az"))
  yields Az_Bz, but in this programming style it should always yield
  Az_bz.

A naive solution is to change the syntax class of symbol constituents so
that they are treated as part of words.  Or, equivalently, to use
superword-mode.  This solution is incorrect, though: the distinction
between symbols and words is still useful for word and symbol navigation
commands, and other purposes besides.  Changing the syntax class will
break those other use cases.  The only thing that needs to be changed is
the case behavior.

This is straightforwardly solvable by supporting a behavior where symbol
constituents are treated as part of words only for case operations.

A patch follows which adds a variable which allows that.


In GNU Emacs 29.1.50 (build 11, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-10-18 built on

Repository revision: 9163e634e296435aa7a78bc6b77b4ee90666d2ac
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: sbaugh <at> janestreet.com, 66614-done <at> debbugs.gnu.org
Subject: Re: bug#66614: 29.1.50; Support not capitalizing words inside symbols
Date: Sun, 29 Oct 2023 13:42:03 +0200

> From: sbaugh <at> catern.com
> Date: Sat, 21 Oct 2023 15:11:08 +0000 (UTC)
> Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 66614 <at> debbugs.gnu.org
> 
> > You don't have to add it to the buffer structure, you could call
> > Fmake_variable_buffer_local instead.  We already do that for some
> > variables.
> 
> Oh, of course.  Done.

Thanks, installed on master, and closing the bug.

Btw, I consistently need to make minor fixups in your commit log
messages.  Please try to follow our style better, as indicated by my
changes.

Previous Next

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