GNU bug report logs -
#77326
[PATCH] Add symbol-mode
Previous Next
Full log
Message #20 received at 77326 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 5, 2025 at 10:20 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Sat, Apr 5, 2025 at 10:10 AM Gabriel Santos <
> gabrielsantosdesouza <at> disroot.org> 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.
[Message part 2 (text/html, inline)]
This bug report was last modified 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.