Is there already a ScintillaMessageName class/function

[seasoned_geek]

All,

Just starting with Example5 and wanted to find out if there as already a ScintillaMessageName class/function that would return the English language message name.

That is autogenerated. Is there another autogenerated thing I'm not seeing in C++ land like a standard map

Message::AddText, "Add Text"

Message::InsertText, "Insert Text"

etc. or is this something everyone has to roll their own on to allow users to override keys?

Just thought I would ask before going deep into the weeds re-inventing the wheel.

[Mitchell]

Hi,

You will need to roll your own.

Cheers,
Mitchell

[seasoned_geek]

Thanks for the reply Mitchell. Can I ask a follow up stupid question?

Was this a conscious decision or did it "just happen?" It could have been some conscious decision to not add a std::string  stdENName to the KeyMap class. Not wanting every other language to demand their own entry for you to maintain.

https://tvtropes.org/pmwiki/pmwiki.php/Recap/DoctorWhoS28E4TheGirlInTheFireplace

• Translator Microbes: Rose, Mickey and the audience all hear the French characters speaking English. The Doctor, however, can tell what language they're actually speaking (and recognises what period it's from).
  Rose: That's the TARDIS. Translates for you.
  Mickey: Even French?

[Mitchell]

Hi,

On Mon, 27 Sep 2021 13:05:18 -0700 (PDT)
"'seasoned_geek' via scintilla-interest" <scintilla...@googlegroups.com> wrote:

> Thanks for the reply Mitchell. Can I ask a follow up stupid question?
>
> Was this a conscious decision or did it "just happen?" It could have been
> some conscious decision to not add a std::string stdENName to the KeyMap
> class. Not wanting every other language to demand their own entry for you
> to maintain.

I cannot speak for Neil, but I suspect it was out of scope. The SCI_* constants are how clients use Scintilla, so string representations are meaningless in that context.

Cheers,
Mitchell

[Lex Trotman]

IIUC Scintilla started out having a similar API to what was then a
standard Windows editing component, which used the enum constants to
interface as Mitchell said. As no strings were used in its interface
there was no point in generating them.

Different language bindings use different methods to map the constants
to language components, and even if they use strings they are likely
to use the language implementation of a string, and the language
implementation of a map similar to that you mentioned, so its unlikely
that they would benefit from a table of C++ strings.

Cheers
Lex

>
> Cheers,
> Mitchell
>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/20210928002721.13992e671632a3b07e5f7c84%40triplequasar.com.

[Neil Hodgson]

Mitchell:

> I cannot speak for Neil, but I suspect it was out of scope. The SCI_* constants are how clients use Scintilla, so string representations are meaningless in that context.

It never really occurred to me. Reflecting the API is more than just providing a name for each call. Which arguments are valid and their types would also be useful and this information is available from include/Scintilla.iface.

Neil

[Roland Hughes]

On 9/27/2021 11:56 PM, Lex Trotman wrote:
> On Tue, 28 Sept 2021 at 14:27, Mitchell <li...@triplequasar.com> wrote:
>> Hi,
>>
>> On Mon, 27 Sep 2021 13:05:18 -0700 (PDT)
>> "'seasoned_geek' via scintilla-interest" <scintilla...@googlegroups.com> wrote:
>>
>>> Thanks for the reply Mitchell. Can I ask a follow up stupid question?
>>>
>>> Was this a conscious decision or did it "just happen?" It could have been
>>> some conscious decision to not add a std::string stdENName to the KeyMap
>>> class. Not wanting every other language to demand their own entry for you
>>> to maintain.
>> I cannot speak for Neil, but I suspect it was out of scope. The SCI_* constants are how clients use Scintilla, so string representations are meaningless in that context.
> IIUC Scintilla started out having a similar API to what was then a
> standard Windows editing component, which used the enum constants to
> interface as Mitchell said. As no strings were used in its interface
> there was no point in generating them.
>
> Different language bindings use different methods to map the constants
> to language components, and even if they use strings they are likely
> to use the language implementation of a string, and the language
> implementation of a map similar to that you mentioned, so its unlikely
> that they would benefit from a table of C++ strings.

Thanks. I'm not thinking about this from an API level. I'm thinking
about this from the perspective of programmers becoming lazy at
convenient times and some level of consistency in final products.

When one is adding a key mapping override dialog it's rather easy in
most UI libraries that I've used over the years to just loop through a
map dynamically building the dialog. No knowledge about the mappings is
then required. For the English language editors Scintilla can add/remove
key mappings at will without it cascading out. Those who have
translations would need to catch the additions, but they wouldn't have
to make much in the way of coding changes. (Yes, the KeyMap is probably
pretty stable by now.)


Perhaps I've just hit the cranky old man stage of life and nothing will
ever make me happy again so I have to focus on making things less
annoying. Depending on which project at which client site I have to use
the given project editor. I don't even know if they all use Scintilla
and it isn't worth researching. I just get tired of the mystery word
search when configuring each of them.

Erase Line

Delete Line

Rub Line

Expunge Line

Clear Line  (I think one of them just had clear and you had to use it to
figure out what it did)

Nuke Line

etc.

Providing "standard" text names for the KeyMap could help with
consistency given developers tend to be lazy on personal projects when
working on the "non-cool" code.

Just my 0.0002 cents.

[Lex Trotman]

...

> Thanks. I'm not thinking about this from an API level. I'm thinking
> about this from the perspective of programmers becoming lazy at
> convenient times and some level of consistency in final products.
>
> When one is adding a key mapping override dialog it's rather easy in
> most UI libraries that I've used over the years to just loop through a
> map dynamically building the dialog.

A "map" thats usable in more than one language doesn't exist, so a C++
std::map in Scintilla isn't going to be used in (for eg) Geany in C.

> No knowledge about the mappings is
> then required. For the English language editors Scintilla can add/remove
> key mappings at will without it cascading out. Those who have
> translations would need to catch the additions, but they wouldn't have
> to make much in the way of coding changes. (Yes, the KeyMap is probably
> pretty stable by now.)

Not really, "normal" keymaps can vary between systems, Windows vs Mac
vs Linux (and that has several). Scintilla's may be stable but it
only applies to Scintilla based tools, there are a number of other
editing widgets available, eg GTKSourceView. And on the Geany project
we get a slow but steady drip of requests for Vi or emacs keybindings
in a project using Scintilla.

>
>
> Perhaps I've just hit the cranky old man stage of life and nothing will

Welcome to the club :-)

> ever make me happy again so I have to focus on making things less
> annoying. Depending on which project at which client site I have to use
> the given project editor. I don't even know if they all use Scintilla
> and it isn't worth researching. I just get tired of the mystery word
> search when configuring each of them.

Well depending on the editor's age, in some cases the keybinding was
named back in the dark ages when there was less of a standard and now
can't be changed for "backward compatibility"

But if you are using Scintilla to make your own editor you will know
all the keybinding names :-)

>
> Erase Line
>
> Delete Line
>
> Rub Line
>
> Expunge Line
>
> Clear Line (I think one of them just had clear and you had to use it to
> figure out what it did)
>
> Nuke Line
>
> etc.
>
> Providing "standard" text names for the KeyMap could help with
> consistency given developers tend to be lazy on personal projects when
> working on the "non-cool" code.

Several of the above come from editors not using Scintilla I think, so
anything in Scintilla isn't going to help.

Cheers
Lex

>
> Just my 0.0002 cents.

>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/29230045-9581-4ccd-c010-57cbb7fc1bd9%40logikalsolutions.com.

[seasoned_geek]

On Tuesday, September 28, 2021 at 7:22:45 PM UTC-5 Lex Trotman wrote:

A "map" thats usable in more than one language doesn't exist, so a C++
std::map in Scintilla isn't going to be used in (for eg) Geany in C.

True, but KeyMap.cpp already exists.

Why would anyone use C when there is C++? 🤩

Sorry, couldn't resist that one.

 And on the Geany project
we get a slow but steady drip of requests for Vi or emacs keybindings
in a project using Scintilla.

Ah, vi.

Vi is from a time when programmers lived in caves and ate their young.

Vim is from the time when programmers left the caves yet still ate their young.

Emacs is from the time when programmers moved back into caves and really tried to stop eating their young.

I use Emacs a lot lately, but I use it in EDT mode. If I didn't have to MOD the terminal definition to use NumLock for the GOLD key, I probably wouldn't be writing this editor which lead me to the porting of Scintilla to CopperSpice. Down to the last three example programs then just have to finish porting/creating the RPM and Debian scripts. Yes, I came up through computer operations. I like one & done command files.