[enhancement] update list of default language modes

[tksoh]

The list of language mode supported by nedit is very dated. We should update the list to include the new/popular programming languages and utilities/scripts.

Also, perhaps a new mechanism is needed to facilitate user contributed lang modes, instead of having them coded into the core, in order to speed up adoption of new modes.

[eteran]

No offence, but if we get too hung up about changing old config files, then nothing will move forward :-P

I of course agree. Have to be willing to make progress for progress to happen.

[tksoh]

BTW, while we continue to discuss the topic of config files, I think we should also set some direction on adding the new languages, perhaps for 6.0?

I have worked on some of the new ones, namely Diff, JSON & CMake. I am sure they might not be perfect, but should be usable, based on the samples that I tested. I've even drafted for Lua, but since I don't know the language, it's merely based on the syntax info I found on google.

If anyone already has anything sitting in their local drive, perhaps you can bring them up for discussion?

[anjohnson]

I would be reluctant myself to delete old config files when upgrading them in case the user shares their home directory between different systems over NFS, and doesn't upgrade the software on all their systems at once. For example my home directory at work is used on RHEL-6, RHEL-7 and RHEL-8 systems. Installing and running a new version on one machine shouldn't break the older versions running on other machines IMHO, which deleting older config files would do.

Regarding new languages, I can offer language modes for these, with varying degrees of sophistication:

• diff/patch
• PHP+HTML (it's for an older PHP but I'm pretty sure I added the HTML part myself)
• MediaWiki
• Test Anything Protocol (TAP)
• GitHub Flavored Markdown
• INI files

I have a few others that are mostly slight modifications to Nedit's built-in originals; it's a bit tricky to tell how much I've changed them though.

[eteran]

@anjohnson so the issue you describe is kinda almost unavoidable. If we migrate the settings, the most sensible thing to do is not have them in the old location anymore (so we know that there's nothing to migrate next time around).

This would be a difficulty if we deleted the old files, or simply removed the data from them.

[tksoh]

@eteran how should we handle the updates on the lang modes?

[tksoh]

I have a few others that are mostly slight modifications to Nedit's built-in originals; it's a bit tricky to tell how much I've changed them though.

@anjohnson Perhaps copy them into src/res/DefaultPatternSets.yaml, and git diff?

[eteran]

@tksoh diffing against th built in versions seems like a sensible way to handles changes 👍

[tksoh]

@eteran do you intend to update the lang modes as part of 6.0 milestone?

[eteran]

I think it's reasonable to do so, but I don't have a specific goal for the 6.0 release regarding language modes.

I'm happy to get in any amount of improvements to them, but also not gonna have them hold up the release of it otherwise looks ready

[tksoh]

in that case, perhaps it should wait until after 6.0

[tksoh]

@anjohnson so the issue you describe is kinda almost unavoidable. If we migrate the settings, the most sensible thing to do is not have them in the old location anymore (so we know that there's nothing to migrate next time around).

Just a thought. I wonder if the config files could be versioned.

[anjohnson]

I wonder if the config files could be versioned.

I considered suggesting that but wasn't sure if/how it might help. Another idea I thought about was to somehow mark a config file that has already been imported to avoid redoing the import every time you launch NG. Trying to reimport it every time it gets changed is probably a bridge too far.

[eteran]

Versioning is actually completely viable and probably will be part of the solution here.

I can add a top level key to track the version to all the relevant files. And I can have a rule that says something like "if languages.yaml is version 6.0, it will have unified data, so don't load the other files".

If it's < 6.0, load everything like we do now, bit migrate the settings to a version 6.9 format.

Of course older versions of NG will simply ignore the version key since they were never coded to care in the first place.