SciTE language(s) to retire

87 views
Skip to first unread message

chris.d...@gmail.com

unread,
Mar 17, 2022, 6:34:13 AMMar 17
to scite-interest
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

unread,
Mar 19, 2022, 5:41:47 PMMar 19
to scite-interest
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

unread,
Mar 22, 2022, 6:04:03 AMMar 22
to scite-i...@googlegroups.com
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

unread,
Mar 22, 2022, 7:07:12 AMMar 22
to scite-interest
If anyone is interested in this question, please have a look at the following form:


Thanks

David

unread,
Mar 22, 2022, 9:11:28 PMMar 22
to scite-i...@googlegroups.com, chris.d...@gmail.com
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

unread,
Mar 23, 2022, 12:29:32 AMMar 23
to scite-i...@googlegroups.com
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

unread,
Mar 23, 2022, 3:10:09 AMMar 23
to scite-interest
>  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.

chris.d...@gmail.com

unread,
May 12, 2022, 4:44:59 AMMay 12
to scite-interest
Answers so far: 7.

Neil Hodgson

unread,
May 12, 2022, 6:11:41 PMMay 12
to scite-interest
chris.d…:
   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

unread,
May 13, 2022, 12:12:11 AMMay 13
to scite-interest
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

unread,
May 13, 2022, 3:53:49 AMMay 13
to scite-interest
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

answers.xlsx

Neil Hodgson

unread,
May 13, 2022, 6:46:05 PMMay 13
to scite-interest
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

unread,
May 14, 2022, 7:34:32 AMMay 14
to scite-i...@googlegroups.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

unread,
May 14, 2022, 5:32:47 PMMay 14
to scite-i...@googlegroups.com
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

unread,
May 15, 2022, 7:55:40 AMMay 15
to scite-i...@googlegroups.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

unread,
May 27, 2022, 12:31:36 AMMay 27
to scite-interest
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

Reply all
Reply to author
Forward
0 new messages