From: Eli Zaretskii <eliz@gnu.org>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 66614@debbugs.gnu.org
Subject: bug#66614: 29.1.50; Support not capitalizing words inside symbols
Date: Wed, 18 Oct 2023 21:34:55 +0300 [thread overview]
Message-ID: <831qdrok34.fsf@gnu.org> (raw)
In-Reply-To: <ierlebz50g8.fsf@janestreet.com> (message from Spencer Baugh on Wed, 18 Oct 2023 13:01:43 -0400)
> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 18 Oct 2023 13:01:43 -0400
>
> --- a/doc/lispref/strings.texi
> +++ b/doc/lispref/strings.texi
> @@ -1510,7 +1510,9 @@ Case Conversion
>
> The definition of a word is any sequence of consecutive characters that
> are assigned to the word constituent syntax class in the current syntax
> -table (@pxref{Syntax Class Table}).
> +table (@pxref{Syntax Class Table}), or if @var{case-symbols-as-words} is
> +non-nil, also characters assigned to the symbol constituent syntax
> +class.
>
> When @var{string-or-char} is a character, this function does the same
> thing as @code{upcase}.
> @@ -1542,7 +1544,9 @@ Case Conversion
>
> The definition of a word is any sequence of consecutive characters that
> are assigned to the word constituent syntax class in the current syntax
> -table (@pxref{Syntax Class Table}).
> +table (@pxref{Syntax Class Table}), or if @var{case-symbols-as-words} is
> +non-nil, also characters assigned to the symbol constituent syntax
> +class.
These two hunks use @var incorrectly: case-symbols-as-words is a
literal symbol, so it should have the @code markup.
> ++++
> +** New variable 'case-symbols-as-words' to change case behavior for symbols.
"Case behavior" is confusing. I think you mean
New variable 'case-symbols-as-words' affects case operations for symbols.
> +If this is set to non-nil, then case operations such as
> +'upcase-initials' or 'replace-match' (with nil FIXEDCASE) will treat
> +symbol constituents as if they were part of words.
Don't you mean
will treat the entire symbol name as a single word
? I find the text you used confusing, FWIW.
> This is useful for
> +programming languages and style where words in the middle of symbols
> +are never capitalized.
Likewise here: instead of talking about "words in the middle of
symbols", wouldn't it be better to say something like
...style where only the first letter of a symbol's name is ever
capitalized.
?
Also, please say here that the default of this new variable is nil.
> + DEFVAR_BOOL ("case-symbols-as-words", case_symbols_as_words,
> + doc: /* If non-nil, case functions treat symbol syntax as part of words.
> +
> +Functions such as `upcase-initials' and `replace-match' check or modify
> +the case pattern of sequences of characters. Normally, these operate on
> +sequences of characters whose syntax is word constituent. If this
> +variable is non-nil, then they operate on sequences of characters who
> +syntax is either word constituent or symbol constituent.
> +
> +This is useful for programming styles which wish to capitalize the
> +beginning of symbols, but not capitalize individual words in a symbol.*/);
Similar comments about this doc string.
Also, shouldn't this variable be buffer-local? You want certain major
modes to set it, right?
> - if (SYNTAX (prevc) != Sword)
> + if (SYNTAX (prevc) != Sword
> + && (!case_symbols_as_words || SYNTAX (prevc) != Ssymbol))
I think the code will be more clear if you use
&& !(case_symbols_as_words && SYNTAX (prevc) == Ssymbol))
> else if (uppercasep (c))
> {
> some_uppercase = 1;
> - if (SYNTAX (prevc) != Sword)
> + if (SYNTAX (prevc) != Sword
> + && (!case_symbols_as_words || SYNTAX (prevc) != Ssymbol))
Same here.
> /* If the initial is a caseless word constituent,
> treat that like a lowercase initial. */
> - if (SYNTAX (prevc) != Sword)
> + if (SYNTAX (prevc) != Sword
> + && (!case_symbols_as_words || SYNTAX (prevc) != Ssymbol))
> some_nonuppercase_initial = 1;
And here.
Thanks.
next prev parent reply other threads:[~2023-10-18 18:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 16:32 bug#66614: 29.1.50; Support not capitalizing words inside symbols Spencer Baugh
2023-10-18 17:01 ` Spencer Baugh
2023-10-18 18:24 ` Eli Zaretskii
2023-10-18 18:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-18 18:34 ` Eli Zaretskii [this message]
2023-10-18 19:38 ` Spencer Baugh
2023-10-19 4:35 ` Eli Zaretskii
2023-10-21 15:11 ` sbaugh
2023-10-29 11:42 ` Eli Zaretskii
2023-10-19 10:54 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-21 15:13 ` sbaugh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831qdrok34.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=66614@debbugs.gnu.org \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).