Fix faulty cheat sheet editor ID constant

[HeikoKlare]

The constant does not match the actual editor ID (misses a dot).

[laeubi]

@HeikoKlare is it actually used? I'm wondering because it seem no one ever noticed the problem before? Is something not working here?

[eclipse-pde-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

ua/org.eclipse.pde.ua.ui/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 29dc2f4c601353227fb1f13378c3118b4f2b9d77 Mon Sep 17 00:00:00 2001
From: Eclipse PDE Bot <pde-bot@eclipse.org>
Date: Wed, 27 Aug 2025 14:26:56 +0000
Subject: [PATCH] Version bump(s) for 4.37 stream


diff --git a/ua/org.eclipse.pde.ua.ui/META-INF/MANIFEST.MF b/ua/org.eclipse.pde.ua.ui/META-INF/MANIFEST.MF
index 933eef57b4..3c8f5df243 100644
--- a/ua/org.eclipse.pde.ua.ui/META-INF/MANIFEST.MF
+++ b/ua/org.eclipse.pde.ua.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.pde.ua.ui;singleton:=true
-Bundle-Version: 1.4.100.qualifier
+Bundle-Version: 1.4.200.qualifier
 Bundle-Activator: org.eclipse.pde.internal.ua.ui.PDEUserAssistanceUIPlugin
 Require-Bundle: org.eclipse.ui;bundle-version="[3.205.0,4.0.0)",
  org.eclipse.core.runtime;bundle-version="[3.30.0,4.0.0)",
-- 
2.51.0

Further information are available in Common Build Issues - Missing version increments.

[HeikoKlare]

The only official usage is the editor's ID getter:

eclipse.pde/ua/org.eclipse.pde.ua.ui/src/org/eclipse/pde/internal/ua/ui/editor/cheatsheet/simple/SimpleCSEditor.java

Lines 44 to 47 in 379558b

	@Override
	protected String getEditorID() {
	return IConstants.SIMPLE_CHEAT_SHEET_EDITOR_ID;
	}

which in turn only seems to be used for storing dialog settings:

eclipse.pde/ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/editor/PDEFormEditor.java

Lines 521 to 539 in 379558b

	protected void setDialogEditorPageKey(String pageID) {
	// Use one global setting for all files belonging to a given editor
	// type. Use the editor ID as the key.
	// Could use the storage editor input to get the underlying file
	// and use it as a unique key; but, the dialog settings file will
	// grow out of control and we do not need that level of granularity
	IDialogSettings section = getSettingsSection();
	section.put(getEditorID(), pageID);
	}
	protected String getDialogEditorPageKey() {
	// Use one global setting for all files belonging to a given editor
	// type. Use the editor ID as the key.
	// Could use the storage editor input to get the underlying file
	// and use it as a unique key; but, the dialog settings file will
	// grow out of control and we do not need that level of granularity
	IDialogSettings section = getSettingsSection();
	return section.get(getEditorID());
	}

Since there are no other (official) consumers, I guess it did not produce any problems so far and would also not produce issues in the future but just be a bit inconsistent.

I only came across it because we actually use such editors but had no explicit reference/dependency to the bundle providing them (as we just replicate the editor ID) and I wanted to reference the (internal) constant instead to have an explicit dependency to the bundle, such that it gets properly auto-included. But that failed as the ID did not match actual editor ID. But since such references to internals are reasonably discouraged anyway, it's not an argument for actually doing this change.

[github-actions]

Test Results

   765 files  +  147     765 suites  +147   51m 43s ⏱️ + 8m 40s
 3 611 tests ±    0   3 557 ✅ +    1   54 💤 ± 0  0 ❌  - 1 
10 833 runs  +2 650  10 670 ✅ +2 627  163 💤 +24  0 ❌  - 1 

Results for commit 8e983b0. ± Comparison against base commit 276a464.

♻️ This comment has been updated with latest results.

[laeubi]

I was just curious, the change looks ok of course... and if you are aware of the consequences its also fine to reference internal code. In this case the compiler even likely will inline the constant anyways so you won't really reference it at runtime.

Regarding the auto inclusion of such code, I think whenever we find something like this we should try to avoid creating fake references and instead using requirement+capability feature of OSGi, that's a bit more work to setup but often much more suitable on the long term. My plan is to enhance support for this in PDE.