SciTE language(s) to retire

[chris.d...@gmail.com]

Hi,

SciTE supports a lot of languages. Because the list is very long, several languages are excluded by default.

I would like to add 'Markdown' to the default include list, but as Neil stated: SciTE’s menus should be kept to a reasonable length by limiting the default language set. So in order to achieve this, some other language has to retire from inclusion.

Below a short list of languages that are included, but of which I believe are ranked 'lower' in popularity:

- ada
- caml
- d
- fortran
- lisp
- matlab
- tcl

Maybe it is worth while to remove 1 or maybe more of these languages?
Personally I would say, leave 'ada' or 'tcl' out, but that's my opinion.

I would like to hear what other users of SciTE think about this.

Thanks

[Neil Hodgson]

chris.d:

> Maybe it is worth while to remove 1 or maybe more of these languages?
> Personally I would say, leave 'ada' or 'tcl' out, but that's my opinion.

More people may be interested in responding to a lower-commitment process like a survey.

Neil

[Lorenzo Donati]

Hi Neil,

I'd like to suggest an enhancement, instead.

I usually use SciTE for a dozen different file formats, and the standard
language menu length would be OK.

However, from time to time, I have to open some other file type and
having to switch on its parsing manually is a hassle.
Therefore I ended up with a huge language menu.

I would suggest to change SciTE interface to allow submenus in the
language menu, so that often-used languages can stay in the main menu
and lesser-used ones could go in one or more submenus.

This could be implemented using some extra config keys, for example like
this:

menu.language.submenu1.name=<submenu #1 name>
menu.language.submenu1=<submenu #1 definition>
...
menu.language.submenu9.name=<submenu name>
menu.language.submenu9=<submenu #9 definition>


Defining up to 9 submenus should suffice for any reasonable use (I can
think of people having 3 or 4 submenus for alphabetic ordering of all
languages and the other used for some other classification - BTW,
duplicated entries should be allowed).

If a submenuN.name key is not defined, the UI should not create the
corresponding submenu, to reduce clutter and so that by not defining any
submenuN.name keys you could have the current "unified" menu layout.

What do you think?

Best regards,

Lorenzo

[chris.d...@gmail.com]

If anyone is interested in this question, please have a look at the following form:

https://forms.gle/nG8Vc6SjU1oRj2n4A

Thanks

[David]

On Tue, 22 Mar 2022 at 22:07, chris.d...@gmail.com
<chris.d...@gmail.com> wrote:
>
> If anyone is interested in this question, please have a look at the following form:
>
> https://forms.gle/nG8Vc6SjU1oRj2n4A

Hi,

I had a look, but FYI, I think this survey ask the question backwards.

I don't have any opinion about which languages might be candidates
for retirement. That would be require me to make a judgement on
something that I do not use, which seems inconsiderate towards
the people who do use it.

However I definitely do have an opinion about which languages
should NOT be retired. The ones that I use. Unfortunately the
survey does not allow me to express this, so I was unable to
contribute.

[Neil Hodgson]

Lorenzo Donati:

> I would suggest to change SciTE interface to allow submenus in the language menu, so that often-used languages can stay in the main menu and lesser-used ones could go in one or more submenus.

Extra levels of menus become progressively more difficult to use. The file type pull-down in the Open dialog is even more of a problem than the Language menu. It can’t (without unreasonable effort) be made hierarchical.

> This could be implemented using some extra config keys, for example like this:
>
> menu.language.submenu1.name=<submenu #1 name>
> menu.language.submenu1=<submenu #1 definition>

This also requires activating each language module (by changing imports.exclude or imports.include) as the modules are needed to provide the styles and keywords, etc. for each language. Otherwise the menu items will have no effect.

Currently, all active languages are scanned for their ‘*language.’ properties which are collected into the Language menu with "menu.language=$(star *language.)”. For this scheme to be useful, it needs a simple mechanism to exclude items from the main Language menu. All the language extensions from menu.language.submenu? could be collected and removed from the main language menu but that goes against

> BTW, duplicated entries should be allowed

Neil

[chris.d...@gmail.com]

>  I don't have any opinion about which languages might be candidates for retirement. That would be require me to make a judgement on something that I do not use, which seems inconsiderate towards the people who do use it.

Thanks for your input.

You're right though, I've adjusted the poll so you can now select the languagues you use the most.

https://docs.google.com/forms/d/e/1FAIpQLSfkBhx-RkfAhqddEB-iqy9gprCM-L5qkJRiL4bkpYB9kJBA3g/viewform?usp=sf_link

[chris.d...@gmail.com]

Answers so far: 7.

For more details:  Frequently used languages (google.com)

[Neil Hodgson]

chris.d…:

For more details:  Frequently used languages (google.com)

   That does indicate “markdown” is popular so should be included. Can you present the data as an ordered ranking to make it easier to understand - I can’t see how to get the raw data as CSV or similar to manipulate in a spreadsheet:

9 python

8 lua

…

   Neil

[John Yeung]

On Wed, Mar 23, 2022 at 3:10 AM chris.d...@gmail.com
<chris.d...@gmail.com> wrote:
>
> You're right though, I've adjusted the poll so you can now select the languagues you use the most.
>
> https://docs.google.com/forms/d/e/1FAIpQLSfkBhx-RkfAhqddEB-iqy9gprCM-L5qkJRiL4bkpYB9kJBA3g/viewform?usp=sf_link

I think I would call that not an adjustment but a completely new poll.
;) Especially as the old one still exists.

Sorry I didn't mention this until now: maxima through nim are repeated.

And a quibble: matlab should appear after markdown, not before.

John Y.

[chris.d...@gmail.com]

Hi Neil,

The export function does not work as expected. I've made some calculations in a spreadsheet and you can find the results attached.

Regards,

Chris

[Neil Hodgson]

chris.d…:

> I've made some calculations in a spreadsheet and you can find the results attached.

From that, it appears that the least used from the current inclusion set are:

ada
caml
d
fortran

It would be reasonable to exclude these languages from the default set.

“caml” was included to have an “ML” family language available that could be used by related languages but it appears these are still a niche case.
https://en.wikipedia.org/wiki/ML_(programming_language)

The most popular additions with 4 and 3 users would be

markdown
powershell

There is also “latex” at 3 but it is excluded as it clashes with “tex” - only one of these should get to own the “.tex” and “.sty” extensions.

There are also several excluded languages with 2 participating users: fsharp, hex, rust, spice, verilog, vhdl.

“sql” is quite popular at 7 participating users but it is based on Oracle’s SQL dialect and some of these users may be better served by the other SQL lexers “mysql” (MySQL) and “mssql” (Microsoft SQL Server) which do not currently have properties files.

Language inclusion is currently all-or-nothing and there could be an intermediate step where languages do not add to menus but are available when one of their files is opened. This would require some new mechanism to mark the “semi-included” languages and the properties which are inactive from these languages. The properties that are joined into the menus start with “*” like “*filter.ada”, “*source.patterns.ada", “*language.ada” so there could be an “imports.suppress” similar to “imports.exclude” but which discards properties that start with “*” in that module.
imports.suppress=ada au3 rust vhdl

This wouldn’t help for cases where languages conflict over file extensions. There would also be questions about how this is implemented and whether it is hardcoded or amenable to more properties - a user might want to have a short list of patterns in the file open dialog (I personally find it unwieldy) but more languages listed in the Language menu.

Neil

[rhkr...@gmail.com]

On Thursday, May 12, 2022 06:11:35 PM 'Neil Hodgson' via scite-interest wrote:
> chris.d…:
> > For more details: Frequently used languages (google.com)

> > <https://docs.google.com/forms/d/1GKWQ8C9gGENLPOrp9kyCCZ8pLwxCfGfR1Tr1Tu
> > eKrWo/viewanalytics>

>
> That does indicate “markdown” is popular so should be included. Can you
> present the data as an ordered ranking to make it easier to understand - I
> can’t see how to get the raw data as CSV or similar to manipulate in a
> spreadsheet: 9 python
> 8 lua

I thought about making this suggestion earlier, but then I forgot.

I'd like to suggest (unless someone has already), that provision be made
(slots reserved on the language menu) for some number of user selected
languages.

(Iirc), this is not such a big deal for a user of SciTe / Scintilla, but more
for someone who might be (slowly) developing a lexer for a new (to Scintilla)
language.

The idea is that anyone developing a lexer (or working on a less popular
lexer) can consistently assign the same "slot" to his language as he "pulls"
updated versions of Scintilla (or Lexer) to keep up to date as his work
progresses.

(Slowly is a good word for my progress -- I've been working on it (or wishing
for it) for on the order of 15 years ;-)

[Neil Hodgson]

rhkramer:

> I'd like to suggest (unless someone has already), that provision be made
> (slots reserved on the language menu) for some number of user selected
> languages.

The language menu is controlled by the menu.language property which can be set in user properties. Changes will only take effect after a restart.

This example uses the standard set with $(star *language.) but adds ‘Geode’ at the start of the menu and ’NuLang’ at the end:

menu.language=Geode|ge|Alt+F6|$(star *language.)N&uLang|new||

There must be exactly three pipes ‘|’ in each entry.

Neil

[rhkr...@gmail.com]

Thanks for the reply!

I'll have to see if that solves my problem when I get back into working on my
lexer, which I hope to do later this year.

<nothing new below this line>

[Neil Hodgson]

A change has been pushed that adds markdown and powershell to the default language set.

ada, caml, d, and fortran were dropped. They can be restored by adding an edited version of imports.exclude to your user properties.

https://sourceforge.net/p/scintilla/scite/ci/515db293b054bdb4f3a799d82c57db9f20694486/

Neil