On Sat, Apr 5, 2025 at 10:20 AM Ship Mints 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 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.