Subject: Re: bug#77326: [PATCH] Add symbol-mode

From: Ship Mints <[email-masked]>
Date: Sat, 5 Apr 2025 11:07:11 -0400

On Sat, Apr 5, 2025 at 10:20 AM Ship Mints <[email-masked]> wrote:

> On Sat, Apr 5, 2025 at 10:10 AM Gabriel Santos <
> [email-masked]> wrote:
>
>> >One nice feature this patch could have is to cycle among symbol naming
>> >conventions: CamelCase, snakeCase, hyphen-case, underscore_case (any
>> >others?) and that would make it convenient when a variable name with the
>> >same components are used across modalities; e.g. in config files, json,
>> >xml, protobufs, C/C++ vs. python, and in emacs-lisp-mode and Emacs C
>> code,
>> >cycling among to Fsymbol_name or Ssymbol_name?
>>
>> There are multiple packages like this[1, 2, 3, 4, 5, 6].
>>
>> Despite that, I think I could give it a try, I just have to
>> avoid looking into them because of copyright.
>>
>> So a comnand that changes between different symbol naming conventions,
>> Like how the capitalization commands work?
>>
>> Point is "|":
>>
>> >M-x cycle-convention-symbol
>> >|this-is-a-symbol
>> >thisIsASymbol|
>>
>
> It would be most convenient if point could be anywhere in or around a
> symbol when cycling.
>
>
>> >cycle among symbol naming conventions:
>>
>> So subsequent calls would switch to another convention? I think this
>> would be ok if the point didn't move.
>>
>
> I'd think the default cycling options would be mode specific as I
> mentioned.  In Python mode, for example, kebabs aren't tasty as
> identifiers, unless they're in a quoted string or comment so some context
> would be helpful.  The code would not have to know what constitutes a valid
> identifier, though, so if in Python I want to convert my/tasty-kebab to
> my/tasty_kebab, it would fail as a Python identifier unless we also offer
> some kind of character or syntax-table driven kind of trickery?  Not an
> expert with the syntax tables so I'm just guessing.
>
>
>> >M-x mark-sexp
>> >this-is-a-symbol
>> >M-x cycle-convention-symbol
>> >thisIsASymbol
>> >M-x cycle-convention-symbol
>> >this_is_a_symbol
>> >M-x cycle-convention-symbol
>> >ThisIsASymbol
>>
>> Besides cycling, maybe choosing a convention with
>> completion?
>>
>> >CamelCase, snakeCase, hyphen-case, underscore_case
>>
>> This could be another issue. The names I know these as
>> are, respectively:
>>
>> - PascalCase
>> - camelCase
>> - kebab-case (yes, really)
>> - snake_case
>
>
A very quick perusal of code within easy reach suggests these styles in
varying degrees across languages and configuration files:

PascalCase
camelCase
snake_case
kebab-case
dot.case
[conf.case]
[conf_case]
slash/case (also /slash/case, slash/case/ and /slash/case/ variants)
CONSTANT_CASE

And a few upcase/downcase variants of which CONSTANT_CASE is an obvious
variant of snake.

I also see various symbol embraces that could be useful to cycle; e.g.,
name, $(name), ${name}, $name.

I'm sure there are a bunch more but this seems like a good taxonomy to
start with.  What else do people use that are worth implementing?

Names that embed case-runs need to be handled: is DOMError DOME-rror or
DOM-error or domerror?  I can imagine offering simple cycling to convert
repeated case streak as DOMError -> DomError (knowing where the case change
is) -> Domerror -> domerror, etc.  (I have a convention on my teams that
this is illegal for names we control; it's "DomError" never "DOMError".)

Binding the cycling command to a single key would make cycling feel natural
and generally "free."  I'd likely bind this to C-\\ since I don't use
multiple input methods or <f9> merely moving a finger up from the home
row.  It would also be great to invoke the function on a region, cycling
all the symbols it found.