bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#77326: [PATCH] Add symbol-mode


From: Ship Mints
Subject: bug#77326: [PATCH] Add symbol-mode
Date: Sat, 5 Apr 2025 11:07:11 -0400

On Sat, Apr 5, 2025 at 10:20 AM Ship Mints <shipmints@gmail.com> wrote:
On Sat, Apr 5, 2025 at 10:10 AM Gabriel Santos <gabrielsantosdesouza@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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]