Document ExtendedHelp_Blog.txt Author Carlo Hogeveen TODO MUST - Implement searching across all configured tsehelp files. - More syntax checking for .ehelp files. - Determine how eHelp can coexist with GetHelp. - More testing. - Improve eHelp's documentation. - Relaese v1. - Continuous task: Improve and maintain tsehelp_eCarlo.ehelp. SHOULD - Possibly move some start-up logic from loading to executing eHelp. This would improve TSE's start-up time and resources a bit by only performing eHelp initializations if help is requested. - Some indicator how many .ehelp files there are for the current topic. This is expensive, but at least should be looked into. - Implement "<\" as escape-syntax for reserved tags. Or something else: TSE's own help codes might need escaping too. COULD - Real bold and italic text in Help for Windows (GUI only?) TSE. - Generate an HTML version of the help from the .ehelp files. - Fix those help links for menu options, where Semware changed the menu option text without changing the corresponding help redirect. For example, in the "After Find, Do" menu, option "Copy Append" was changed to "Copy Append found text", but its help redirect was not changed, resulting in the help text no longer being found. - Implement displaying code page 437 for help text. Based on character use TSE's help was originally written for code page 437. Against: In GUI TSE there is no user-friendly input method for code page 437 characters, so users will not have a logical way to enter new ones. Against: Development cost vs small display benefit. WONT - WYSIWYG editing of .ehelp files. The currently available method of using browse mode to switch between an edit-display and a help-display of a .ehelp file works so well, that it does not need improvement or a WYSIWYG alternative. - Extending TSE's Help's character set. Doing so would require a Help system that is independent of TSE, which is outside my intended scope. ( Exception: eHelp makes GUI TSE's invisible bullet character visible when editing a .ehelp file. Use the HelpRepair extension for the same fix when viewing the Help the ordinary way. ) - Enable other Help domains than "tsehelp", and enable invoking them extension-sensitively. This would be a cool gimmick, but I guesstimate that in practice this feature would not be used. 15 Oct 2023 I have downgraded eHelp's priority. It keeps taking more time than foreseen, it is blocking more useful projects, and TSE's usage and support seems to be declining again. 8 Oct 2023 Started on eHelp's reorganization. 7 Oct 2023 eHelp_SyntaxCheck is now consistent with the latest design, namely making the parts for checking for errors, warnings and notes independent of each other where possible, thus also enabling to run just the errors checking part in the foreground. Aside: Only the error checking part is implemented, not the warning and note checking parts yet, but since the latter are not essential, that is OK for now. Next step: Make eHelp consistent with the latest design. 30 Sep 2023 Linux RGB compatibility and improving the CursorLine extension intervened. Now where was I? On the bright side, this "break" is great for getting a fresh perspective on previous assumptions and choices. One choice that stands out is the elaborate mechanism around error checking. The assumption was that error checking will be so slow that it will pay to do it as few times as possible, so that therefore the overhead would be negligible for checking for errors in the background as well as the overhead of a fingerprint (a checksum) to check if a .ehelp file was changed. In practice error-checking is fast. So I did some measurements on the big .ehelp_SyntaxCheck file: Error-check: 0.95 seconds Fingerprint: 0.43 seconds Background-overhead: 1.00 second (a chosen avarage) Conclusions: - Yes, the fingerprint overhead to avoid an error-check is still worth it, especially because additional error checks might need to be added in the future. - It would be a significant time-saver to move the error-check part to the foreground, making the overhead for checking a background process zero. [ Added note, 8 Oct 2023: While time-wise this is a significant improvement for error-checking from eHelp, in practice such error checks are only done in exceptional situations, and saving a few seconds in rarely occurring situations is a tiny benefit. The bigger benefit turns out to be the improved maintainability of eHelp's and eHelp_SyntaxCheck's code. ] The latter will require a redesign, again. 14 - 17 Sep 2023 Examined eHelp's internal dependencies. ehelp supports functionalities that are not always dependent on each other. This allows their just-in-time initialization when they are needed. Since initializations takes time, this improves eHelp's response times. Functionalities: - Link eHelp.syn if it is not yet. eHelp needs to be loaded. - Syntax check when saving a .ehelp file. eHelp needs to be loaded. - Special read-only mode for edited .ehelp file. eHelp needs to be loaded. - Display Help with eHelp. This does have a dependency on: - The configured .ehelp files having been loaded. - Search the Help. This does have a dependency on: - The configured .ehelp files having been loaded. - Loading the configured .ehelp files. This does have a dependency on: - Each .ehelp file having been syntax-checked for errors. 11 Sep 2023 Started on moving eHelp's initialization from WhenLoaded() to Main(). This will achieve that eHelp does not slightly slow down TSE's start-up, but instead will slightly slow down a TSE session's first request for help. 23 Aug 2023 - 11 Sep 2023 (Here a "+" prefix indicates a task is done.) New plan to rewrite parts of eHelp and eHelp_SyntaxCheck: 3 Sep 2023, rethought eHelp_SyntaxCheck aborts for the Nth time: - eHelp_SyntaxCheck needs a way to tell eHelp if it aborts, so that eHelp can stop waiting for syntax check results. Typically these aborts will happen in the first fraction of a second and will not be caused by the content of the syntax-checked file. For example, a directory might not be writable or the syntax-checked file might not be a .ehelp file. Therefore the .ehelp_errors file is not a fitting place to report aborts. I decided on using a TSE_eHelp_SyntaxCheck.abort file in the system's directory for temporary files. This solution's benefit is, that it is simple and typically good enough. I accept its flaws: - If the user starts a syntax check and does an within a second, then it might happen that it will not be reported if it aborts. eHelp will ignore an in the first second to avoid this flaw. - If on the same computer two concurrent TSE sessions start concurrent syntax checks within the same second, then possibly one can report the other's abort while the other does not report its abort. This is an extremely unlikely scenario. - If someone writes a tool that starts concurrent syntax checks within a second of each other, then each syntax check either might report another one's abort or might not report its own abort. I will add a warning to eHelp_SyntaxCheck's documentation to not do that. eHelp: If a user saves a .ehelp file successfully, or eHelp at start-up loads a configured .ehelp file that in the same directory has no same-named .ehelp_ok file that contains the .ehelp file's fingerprint, then eHelp: + Deletes any eHelp_SyntaxCheck.abort file in the system's directory for temporary files. - Deletes any .ehelp's same-named .ehelp_ok, .ehelp_errors, .ehelp_warnings and .ehelp_notes files from the .ehelp's directory. - Starts eHelp_SyntaxCheck in the background with the current file as its parameter. - Locks the foreground with a "Checking saved .ehelp file ..."-like pop-up until a same-named .ehelp_ok or .ehelp_errors file is created in the same directory. After a second to allow aborts to be reported back, the user can the pop-up, which skips the following steps. - If eHelp_SyntaxCheck created an eHelp_SyntaxCheck.abort file, then eHelp closes the pop-up and shows a warning with the abort file's content. - If eHelp_SyntaxCheck created a same-named .ehelp_ok file, then eHelp closes the pop-up and briefly shows an "OK"-like message. - If eHelp_SyntaxCheck created a same-named .ehelp_errors file, then eHelp closes the pop-up and either shows the .ehelp_errors file (1), or errors are shown using TSE's compiler framework (2). I will first implement (1) and then see if (2) can be implemented. A configured .ehelp file that has errors will not be used for Help. A .ehelp_ok file contains a fingerprint of the same-named .ehelp file, because if a user replaces a .ehelp file, for example because its author updated it, then eHelp needs a way to find out that the new .ehelp file has not been syntax checked yet. eHelp_SyntaxCheck: Given a .ehelp file: + Deletes any TSE_eHelp_SyntaxCheck.abort file in the system's directory for temporary files. + If eHelp_SyntaxCheck aborts, then it reports the reason as follows and stops: + If it (as usual) runs in the background, then it reports to a TSE_eHelp_SyntaxCheck.abort file in the system's directory for temporary files. + If it (for example for debugging) runs in the foreground, then it reports a warning on-screen. + Deletes any same-named .ehelp_ok, .ehelp_errors, .ehelp_warnings and .ehelp_notes files in the same directory. + Creates a new preliminary same-named .ehelp_notes file in the same directory, the new file-date-time of which from then on will determine whether a new eHelp_SyntaxCheck was started after the current one. + Checks for syntax errors: + If after checking for errors a newer eHelp_SyntaxCheck was started, then the current one just stops without doing anything else. + If no errors were found, then a same-named .ehelp_ok file containing the .ehelp file's fingerprint is created in the same directory. + If errors were found, then a same-named .ehelp_errors file is created in the same directory, and all the following steps are skipped. - Checks for warnings: - If after checking for warnings a newer eHelp_SyntaxCheck was started, then the current one just stops without doing anything else. - If warnings were found, then a same-named .ehelp_warnings file is created in the same directory. - Creates notes: - If after preparing notes a newer eHelp_SyntaxCheck was started, then the current one just stops without doing anything else. - Otherwise the .ehelp_notes file is overwritten with a new one. eHelp_SyntaxCheck aborts typically happen within the first fraction of a second after its start, and are typically not for a reason that is related to a .eHelp file and therefore should not be stored with the current file. The above processes may make just loading each configured .ehelp files take a second. I consider this acceptable, given that in the finished eHelp this will not happen when a TSE session starts, but only the first time TSE's Help is accessed (and eHelp is enabled). 21 Aug 2023 [Flawed idea deleted.] 20 Aug 2023 [Flawed idea deleted.] 09 Aug 2023 [Flawed plan deleted.] 08 Aug 2023 Still improving eHelp_SyntaxCheck. I am thinking about changing the single result file with extension .ehelp_syntacxcheck to three files with extension .ehelp_errors .ehelp_warnings .ehelp_notes This has two perceived advantages: - Then the presence of a .ehelp_errors file can be a simple test to indicate the usability of the according .ehelp file. - That the current syntax check happens in the background and pops up "during editing" when it is ready is annoying. The errors-part is currently 30 seconds (on my computer), while the non-essential (future) warnings and notes will take much longer. I am thinking of: - Moving the errors-part to the foreground, which would make saving a .ehelp file take those 30 seconds. - If there are errors, then ask whether to actually save the file. (Save the .ehelp_errors file if the answer is no?) - Create a "soft" pop-up or no pop-up when the non-critical warnings and notes are ready. Perhaps via the Status macro if present. User experience decisions are the hardest. On the other hand, I might end up as the main user. 28 Jul 2023 Edited tsehelp_eCarlo.ehelp a bit. Tested eHelp_SyntaxCheck's current state regarding cursor positioning, which is non-existed and highly improvable. 27 Jul 2023 Converted my tsehelp_eCarlo.ehelp to the new syntax, which now compiles ok again. 1 Jul 2023 To fix the structural .ehelp syntax problem concerning redirects and links, the following files and programs need adjusting: - Done: eHelp.syn - Done: eHelp_CreateIndex.s - Done: eHelp_Hlp2eHelp.s - Todo: eHelp_SyntaxCheck.s - Done: It now knows "" and "" instead of "^". - Done: tsehelp and the tsehelp_index now use the same tags, which simplifies syntax checking. - Todo: I want to add to eHelp_SyntaxCheck, that when applicable it will position on the first error in the .ehelp file. - Todo: eHelp.s 28 Jun 2023 To fix the structural .ehelp syntax problem concerning redirects and links, the following files and programs need adjusting: - Done: eHelp.syn - Done: eHelp_CreateIndex.s - Done: eHelp_Hlp2eHelp.s - Todo: eHelp_SyntaxCheck.s - Todo: eHelp.s 27 Jun 2023 To fix the structural .ehelp syntax problem concerning redirects and links, the following files and programs need adjusting: - Todo: eHelp.syn - Done: eHelp_CreateIndex.s - Done: eHelp_Hlp2eHelp.s - Todo: eHelp_SyntaxCheck.s - Todo: eHelp.s 26 Jun 2023 To fix the structural .ehelp syntax problem concerning redirects and links, these four programs need adjusting: - Done: eHelp_CreateIndex.s - Todo: eHelp_Hlp2eHelp.s - Todo: eHelp_SyntaxCheck.s - Todo: eHelp.s 25 Jun 2023 (2) Well, I ran into a structural .ehelp syntax problem. On the bright side, it was pointed out to me by the .ehelp syntax checker! In a .ehelp file currently the character "^" is used in the syntax of redirects and links. My assumption was that TSE's help text nowhere uses this character. As it turns out it is for example used in the menu option: System/File Options -> File Termination String -> ^Z Only This in turn causes the help to use it in a redirect. I should have done better research. Just replacing it with another character does not appeal to me. Currently one of the characters of "!$%+=@\`j{}~" could be used as a replacement in redirects, but that would preclude the use of the new character in future menus. Another consideration is, that for consistency's sake I also need to make a replacement for the use of "^" in help links. For redirects I plan to replace "^" with "". Nice and short and to the point. For links I plan to replace "^" with "". Semantically "" would be a better choice, but that would make already long help lines even longer. These changes might not be small, but I favor a better structural solution now over one asked for later when eHelp is out in general use. 25 Jun 2023 The messages are done. They occur as a Windows pop-up instead of a TSE pop-up. That is good enough for now. It might or might not be an issue down the road, and can easily enough later be improved if needed. Next steps: - A tsehelp_eCarlo.ehelp file with full topic descriptions instead of just the changes and errata for each topic. Initially I thought the new tsehelp_eCarlo.ehelp would need to describe all topics. However, just fully describing the changed topics seems a good compromise that accomplishes these goals: - It would make it obvious for which topics new descriptions exist. The user would then know when they can switch to the old Semware description. - Searching the help would not first give an errata-like description from which the user would HAVE TO switch to Semware's description in order to deduce the full information from both descriptions. This currently means I will have to manually merge about 159 topic descriptions. And that is just the beginning of course. - New eHelp release. 24 Jun 2023 An eHelp search now finds all occurrences one at a time across all help files, and positions and highlights each found occurrence to my satisfaction. Positioning and highlighting are even slightly better than TSE's. Next steps: - A message if no (further) occurrence is found. - A message if a not-yet-implemented search option is used. - A full tsehelp_eCarlo.ehelp file with all existing TSE topics instead of an "errata file" with just the changes. - New eHelp release. 21 Jun 2023 "Find Next" after an initial search with the "a" option now finds all occurrences, but sometimes scrolls an occurrence out of the window (and highlights a different word). I have tried to implement showing each found occurrence as TSE does, but obviously there is a difference somewhere. 19 Jun 2023 The "Find Next" mostly works. Despite providing the "a" search option, it does not search across .ehelp files yet. That said, testing it already revealed an inconvenience: When searching across .ehelp files, only when a .ehelp file has been completely searched will eHelp start searching in the next .ehelp file. Default the first .ehelp file is tsehelp_eCarlo.ehelp, which currently is not intended to provide all topics, but only topics with new content. Therefore eHelp's search will first search the "incomplete" tsehelp_eCarlo.ehelp file, and only then tsehelp.ehelp, the copy of TSE's old documentation. One solution would be to also copy tsehelp.ehelp's unchanged topics to tsehelp_eCarlo.ehelp. The small downside would be, that it would no longer be immediately obvious which topics in tsehelp_eCarlo.ehelp were enhanced and which were not. We would need to run a compare of the .ehelp files. All things considered I think this would be a good solution. New plan: After finishing with "Find Next" I will create a tsehelp_eCarlo.ehelp according to the above solution, after which it will be time for a new eHelp.zip development release. 18 Jun 2023 Did some more renaming of global and local variables and shifted some code to make eHelp better maintainable by future me. I think I am done for now. Still next: Implement "Find next". 16 Jun 2023 Resolving confusion regarding global variable names: Unavoidably the eHelp macro needs a fair amount of global variables. TSE's language needs global variables to pass information to hooks, and to maintain state information across calls to the macro and across searches. Now that the number of global variables has grown, it is clear that they need better names to differentiate their function, and it is clearer what names can best achieve this. 13 Jun 2023 Aside: eHelp's searching the help completely bypasses TSE's Help engine. TSE's Help engine only responds if it sees one of its own keys that scroll screen, select a link, exit the Help or perform another Help action. eHelp overrules the keys that perform "another Help action". So for those keys, as far as TSE's Help engine is concerned, it just keeps showing its help topic buffer, and it is oblivious to what help information is in it. In conclusion, TSE's Help engine simply does not notice an eHelp help search. 12 Jun 2023 Progress: A found string is now highlighted. Nice side-benefit: Selecting a subtopic from the index now also highlights the subtopic in the target text. I consider this a tiny improvement on TSE's old help. 09 Jun 2023 Progress: I did my first bug-free "find first occurrence". I discovered that the found string needs hiliting. TSE's Help supports hiliting strings it found itself, so I will have to find out how to trigger or reproduce that. 08 Jun 2023 Fixed bugs and ran into a user experience issue that I had designed deliberately to mimic TSE's regular search command. The UX issue was, that I searched the help for "browse mode" with the "gi" search options and did not find it. This is technically correct: Since the "a" search option was not specified, only the first configured non-index help file was searched, which was tsehelp_eCarlo.ehelp, which does not contain the string "browse mode". (tsehelp.ehelp does contain the string "browse mode".) With even myself as an example, apparently a user must be guided to acquaint themselves with the concept of multiple help files. To alleviate the UX issue "agi" is now always put onto the search option's history, which also makes it the default for the very first help search. 03 Jun 2023 Progress. I just got my first search result of the first kind, a search without the "v" option. I searched for a string, found it in the first topic it occurred in, and TSE's Help engine displayed it. There were minor display errors, but after writing lots of complex code, this first result confirmed that most of it does actually work. Phew! 15 May 2023 Just reporting progress again. If the programming of searching TSE's extended help is a deep dive, then I am now on the way up. All the search logic is done, now its results need to be displayed. A help search can have two kinds of display results: 1. A help topic to be displayed with a found string. 2. An "index" of found strings to be displayed. I think I am just below the surface regarding the first search result. Its scary part is, whether TSE's help will understand the result. 08 May 2023 I am changing one of my implementation choices for help search options. Here are two possibilities (with the not changing "t" option for context): Old: Default a search is across all non-index help files. The "f" option limits a search to the current or first non-index help file. The "t" option limits a search to the current topic; stops if no topic. New: Default a search is limited to the current or first non-index help file. The "a" option searches across all non-index help files. The "t" option limits a search to the current topic; stops if no topic. I started implementing the first possibility, but now favor the second one. My ultimate goal is to provide a tse_eCarlo.ehelp file that is a full help file, not just a file for errata and extra help. If there is such a full help file alternative, then it makes sense to not make "a" a default search option, but one that must be provided explicitly. And of course there is the strong argument, that the explicit "a" search option is what TSE's non-help search already does, and that it is user-friendly to provide a consistent user experience. 04 May 2023 Just reporting progress. I am implementing the help search. It turns out, that this requires some elaborate data structures and coding to be able to search efficiently, and implementing that took redesign and rewrites. It looks like it is going well at the moment, and that the capabilities of the end result will be worth it. 16 Apr 2023 Wrestling with the details. The old Help can search within a topic. The new eHelp gets a "t" search option to do the same for the current topic in the current .ehelp file. There are arguments for and against "t" searching the topic across .ehelp files. For now I decided against it. The new eHelp will default search all .ehelp files. It therefore will allow but ignore TSE's standard "a" search option. I want to be able to search in one specific .ehelp file. For that the new eHelp search options will also accept a .ehelp file's name, without extension and separated from the other search options by a space, as such a search limitation. For example, "giv tsehelp_eCarlo" will be valid eHelp search options. 28 Mar 2023 I decided on three things. TSE's old "Search menu" is too fixed to deal with the circumstance, that searching across Help files adds another search dimension. A Find-like command with search options will be a more flexible basis to deal with that. That I want Help search results displayed with detail lines and that Help can display Help's bullet and line-drawing characters, are deciding factors for me to choose a Help Index-like search results window instead of a "View Finds"-like search results window. I wondered if I should implement eHelp's search as a separate macro. Being able to develop, test and maintain it as a separate macro would by itself be an advantage. But my guesstimate says there would be a significant amount of duplicate code in displaying the results. I considered putting only the search-part in a separate macro, but that would not be sizable enough to warrant a separate macro. A test says, that the eHelp macro is still far from a macro's debugging size limit, and I foresee no other big additions to the eHelp macro. I do foresee a lot of little ones, but how big their code size will be is too nebulous at this stage to base any decisions on. So, going forward, searching will be implemented in the eHelp macro itself. 27 Mar 2023 I ponder on two things. The menu options in TSE's Help's "Search menu" resemble the options of TSE's Find command a lot. They are not exactly the same, but in my opinion the many extra Find command options are more beneficial than the Help's single extra option to search limited to the current topic. In both cases the user needs to do two interactions to get search results. I am therefore considering to replace TSE's Help's "Search menu" menu plus prompt by two Find-like prompts in eHelp, perhaps with an additional "t" option to limit the search to the current topic. I was planning to show a requested list of results like a Find's "View Finds" list, and I still might, but I am also considering showing the list like a help index with detail lines. The latter might look nicer, especially since it could show the detail lines help-formatted; with bold and italic text, with working links, and with non-ASCII characters (like bullet and line-drawing characters) not shown as weird characters. 26 Mar 2023 Made some nice progress on searching the Help. I replaced TSE's Help's "Search menu" menu with an eHelp version. Default the menu's options still use their old TSE Help functions. I started on replacing the "Search & View Topics" option, and decided to implement it like a ViewFinds list. When searching for "_3D_BUTTONS_", it currently generates a buffer that looks like this: File: c:\users\carlo\tse\help\tsehelp_ecarlo.ehelp Topic: _USE_3D_BUTTONS_ If TSE's _USE_3D_CHARS_ and _USE_3D_BUTTONS_ display configuration settings Topic: _USE_3D_CHARS_ See _USE_3D_BUTTONS_. File: c:\users\carlo\tse\help\tsehelp.ehelp Topic: SpecialEffects _USE_3D_BUTTONS_ - The editor uses 3D buttons for the drawing I am hoping that with ViewFinds-hiliting applied this will look OK, otherwise I will need to come up with something better. I thought of and for now discarded using indentation, because that would shift the right-side search result columns out of view-windows on TSE instances with minimalistic window widths. 23 Mar 2023 Released eHelp v0.22. Fixed: - If going back to the help index twice in a row with , you got the error "' ... \tsehelp_index.ehelp' is not a valid help file". - Configuring eHelp's "Internal status" to "Disabled" did not disable eHelp. I am pleased with how eHelp is shaping up. Next is taking over the Help's search actions, so that all help files are searched. As far as I currently know, this should be the last big functional change. 22 Mar 2023 Released eHelp v0.21. Fixed: eHelp kept setting all TSE's picklist settings to Off. 21 Mar 2023 I have been noticing for some time, that all TSE's PickList settings were being set to "Off" at each restart of TSE. Surprisingly this turned out to be an eHelp bug. To be solved. 19 Mar 2023 Released eHelp v0.20. Fixed: After selecting an index entry and then going back to the index using the help's "back" function, the index lost its special browsing style. 18 Mar 2023 Released eHelp v0.19. Fixed: For a subtopic request, help often positioned at the top line of its topic. The help title was sometimes not just the topic, but also the subtopic. 15 Mar 2023 Fixing what initially looked like a minor problem in the generated index, led to not just correcting it, but also to extending it with comments. In the generated index: A topic link gets no comment. A subtopic link is commented with its topic between parentheses. A redirected link will based on its type be commented with just the topic between parentheses or both its topic and suntopic separated by a ";". This sometimes leads to useful "double" links in the index, one to the topic and one or more to same-named subtopics. For example, "AddLine" exists as its own topic and as a subtopic of the topic "Commands to add text". TSE's "old" index only has a link to the topic "AddLine". TSE's "new" index has both and clarifies the difference with a comment. I like it! During testing I discovered that for those TSE menu options, for which the text of the option line changed, pressing F1 for help no longer works. For example, in the "After Find, Do" menu, the menu option "Copy Append" was changed to "Copy Append found text" (sometime from 2012 to 2016) while the old Help still has help for the menu option "Copy Appand". TSE's read.me file does not document a related change in this period. I made a note in the COULD part of the above TODO list. Still not fixed the positioning error, and I got a new, very minor title error, so no new release yet. 14 Mar 2023 Selecting some subtopic links in the index does not result in positioning the screen on the subtopic, but on its topic. This for example happens for the subtopic "15 levels of precedence for expressions" in the topic "Statements". eHelp positions this subtopic correctly, but then TSE overrules it for reasons unknown. I have spent considerable time on trying to convince TSE to not overrule it, but to no avail. So next I will try to let TSE overrule the subtopic positioning, and then overrule TSE. Hopefully this will work and not lead to an too annoying second screen update. 08 Mar 2023 Released eHelp v0.18. That eHelp installed an empty help index has been fixed. For better and for worse: The new help index lists everything that can be linked to: - Of course everything from old help index. - Info topics. ( See help entries like "Info->...". ) - Menu help topics. ( Topics selected by pressing F1 on a menu option. For example "CompilerSetupMenu->Rules". ) - Whatever else Semware defined as a subtopic. - Whatever else Semware defined as an alternative search phrase for a topic or subtopic. There have been lots of "under the hood" improvements that make it easier for me to test and maintain the eHelp* macros, for example: - All eHelp* macros now (need to) have the same version. - eHelp_CreateIndex and eHelp_Hlp2eHelp now run interactively if started without parameters. 06 Mar 2023 Still no new published version, but I am getting there. Insight: If index files are also just .ehelp files, then they must be placed above non-index files in the list of configured .ehelp files. Otherwise requesting eHelp for "index" will find a same-named subtopic in a non-index file. Design decision: eHelp will recognize formal index files by them case-insensitively having "index" in their names, and will automatically sort such index files above non-index files. 25 Feb 2023 There are currently 4 different ehelp*.s files that depend on each other and can have different versions. While technically a change in one often does not mandate a change in one of the others, maintenance-wise their different version numbers are very confusing to this human! So going forward I will give all eHelp*.s files the same version number, even if only one of them changes. In the next release all eHelp*.s files will have version v0.18. The HelpHelp.s extension will remain to have its own version. 11 Feb 2023 I created but not yet published a user-friendlier version of the eHelp_Hlp2eHelp helper tool, that creates a new tsehelp.ehelp file. It is now interactive when no parameters are supplied, and it now supports parameters to update tsehelp.ehelp always or only when it is outdated. 06 Feb 2023 As a work-around for the new index "tsehelp_Index.ehelp" not being generated properly, I made a proper version available as a separate download. For now it has to be configured manually. 31 Jan 2023 I found out, that creating the eHelp index does not work in a clean install of TSE, and looking into that I also found some minor inconsistencies in how I implemented creating tsehelp.ehelp and in auto-configuring the default .ehelp files. So I will solve this bug and these inconsistencies before moving on. 11 Jan 2023 I found no other topics than "Index" which use Index-like browsing in TSE's Help. I proposed and submitted a new bindhelp.si to Semware to build into the next TSE release. 10 Jan 2023 Found out, that TSE's Help engine handles browsing "index_style" topics differently, but currently it views an externally generated Index like any other help topic. I fixed this for the "Index" topic in the Help engine's bindhelp.si macro, after which browsing the Index works nicely. I have not published this yet, because the name "index_style" suggests, that there might be other topics for which this property must be set. 09 Jan 2023 Released eHelp v0.17. Implemented adding topics and subtopics to the index file. Made eHelp auto-configure tsehelp_Index.ehelp. Yet to solve: In usage the new Index works with significant quirks. 08 Jan 2023 Implemented determining what the index file's path and name are going to be, and whether the index file needs to be (re)created. Implemented adding the redirects from the configured .ehelp files to the tsehelp_Index.ehelp file. 03 Jan 2023 Semware installed my new version for bindhelp.si in TSE 4.49! This makes TSE's Help history (the key) work with eHelp topics too. 02 Jan 2023 Creating a new Index that covers all configured .ehelp files. I have described its intended functionality as follows: This tool creates a tsehelp_Index.ehelp file, containing only one topic, "Index", which is an index of all other configured .ehelp files, usually including tsehelp.ehelp, the copy of TSE's own help. Default eHelp will install tsehelp_Index.ehelp as its bottom .ehelp file, so that another .ehelp file can override it with its own "Index" topic if it wants to. 27 Dec 2022 Initialized tsehelp_eCarlo.ehelp from the TSE_Pro_Undocumented_Features document, filling it with 159 topics. The initialization was done with a rough conversion. I expect there will be formatting errors. And I know this help still refers to "its Unicode context", which in TSE's Help context it does not have any more. These errors will be fixed manually in future versions. Its source currently makes it an errata-type document, only describing what is wrong and new in the latest TSE version's documentation compared to TSE's own documentation, which mostly is still the one from TSE 4.4's 2005 release. My intention is, to maintain new errata and new features in it too, and to over time merge the TSE documentation into it, making the document a primary resource. 24 Dec 2022 My existing "TSE Pro Undocumented Features" document contains additional descriptions for 180 TSE topics. In theory I can create two types of Help from that: - A quick & dirty errata-type Help that contains the same info. - An updated version of TSE's Help. Here is my plan. Because eHelp now facilitates easy switching from my to Semware's Help, it seems practical to me to first create a quick & dirty errata-version of tsehelp_eCarlo.ehelp, and to over time change that to an updated version of TSE's Help. Step one is easier said than done. The "quick" part has to take the hurdle of converting HTML formatting to TSE Help formatting. 23 Dec 2022 When viewing a topic from a .ehelp file in the Help, you can now switch between those .ehelp files that provide help for that topic. Use the Alt key with (Grey)CursorLeft, (Grey)CursorRight, N or P. 18 Dec 2022 A new eHelp.zip is available! It is a major upgrade with many improvements. Note, that it is still a test product, not a real one. 17 Dec 2022 I worked on the next eHelp.zip release, and greatly simplified the installation of its parts. It works by compiling and executing eHelp, and the rest is done automatically. The concept works exceptionally well, except for a weird bug: from "Macro -> Compile -> Execute" the Main procedure of eHelp.s is not called, but it is called in any other circumstance. (18 Dec 2022: TSE's compile macro cannot be called recursively.) 14 Dec 2022 eHelp now creates the association between syntax hiliting language "ehelp" and file extension ".ehelp" if it does not exist. It does this structurally, in TSE's configuration. I implemented this action as one proc which can associate a syntax hiliting language with a list of file extensions. (The proc edits TSE's binary configuration file tsesynhi.dat.) If HelpHelp receives a Help request when it has no configuration yet, and the eHelp.mac file is present, then HelpHelp configures itself to use eHelp. 12 Dec 2022 Added a configuration menu to HelpHelp. Its first option enables/disables HelpHelp. This is a quick way to disable/enable all the configured auxiliary help systems. Its second option allows managing a list of these auxiliary help systems and their order. Their top-down order determines which help system gets to look for a help entry first. The list is not limited to known help systems. It facilitates new ones too. 10 Dec 2022 eHelp now auto-configures default .ehelp files if none are configured. namely tsehelp_eCarlo.ehelp and tsehelp.ehelp, in that order. 9 Dec 2022 Added a nice user interface to eHelp to configure which .ehelp files to use and their order of use. 6 Dec 2022 Fixed "Table of Contents" looking mangled and its links not working. And thereby probably fixed some other topics as well. 5 Dec 2022 Got eHelp working with multiple .ehelp files, that for now need(ed) to be manually configured in tse.ini. Solved intermediate bugs regarding inconvenient event behavior. Remaining: Adding a UI for configuring the .ehelp files. Added as a high prio bug: tsehelp.ehelp's "Table of Contents" is mangled, and lots of its links do not work. 18 Nov 2022 At start-up both helper macros are now checked for, and if needed recompiled. Next task: Start on configuring selection and precedence of .ehelp files. Finally tsehelp.ehelp will be used, namely as an integratable version of the old Help. All configured .ehelp files need to be known before further syntax checking can be implemented. 17 Nov 2022 Implemented a fast syntax check of "^" and ";" usage between same-line tags. The advantage of this superficial check is, that it can return an error to the user almost immediately, while all following syntax checks will be long-running. 16 Nov 2022 When editing a .ehelp file, now non-ASCII characters are shown as the user's version of TSE's Help will show them. This includes drawing-characters, like lines, shades and blocks. Note that the Help's characters will vary depending on the TSE version and variant (GUI, Console, Linux), and for the Console version also depending on the command prompt's code page, which can be queried by typing "chcp". None of TSE's Help's character flaws are repaired: When editing you need to see characters WYSIWYG. Exception: If the HelpRepair extension is loaded at start-up, then eHelp will reproduce HelpRepair's bullet character outside the Help for the .eHelp file, otherwise eHelp will only display a bullet character for the GUI version of TSE to repair its invisibility there. I will later document but not solve TSE's Help's lack of full character compatibility across the TSE versions and variants (GUI, Console, Linux). 15 Nov 2022 Removed the _DISPLAY_HELP_ mode when editing a .ehelp file. Added a eHelp.syn file to eHelp.zip. To correct an earlier remark: It turns out that turning _DISPLAY_HELP_ mode off does NOT enable the "Line Drawing" menu option. I am considering, when editing a .ehelp file in GUI or Linux TSE, to overlay those letters, that are shown instead of line drawing characters, with line drawing characters. 14 Nov 2022 Breaking change: Tag should now be , and tag should now be . New syntax checks: Check opening and closing tags that must be in the same line. Check single tags that must be alone in their line. Check opening and closing tag pairs that must be alone in their line. When a .ehelp file is saved, a syntax check is now automatically spawned in the background, and the result file appears when it is done. In theory you can continue editing durring the syntax check. Currently that makes no sense yet, as the current very rough check is too fast. I am not at all sure whether this capability will be handy in the future. Editing a .ehelp file in _DISPLAY_HELP_ mode is still annoying. This is caused by tags making lines longer, and _DISPLAY_HELP_ mode blocking scrolling horizontally. I am therefore contemplating abandoning editing in _DISPLAY_HELP_ mode in favor of editing .ehelp files normally: Disadvantage: - During editing the bullet characters and the occasional line drawing characters will be shown as letters. Advantages: - Horizontal scrolling. - Fast block marking. - Syntax hiliting! A bit of both: - Line drawing on/off becomes available in TSE's menu, but it will draw letters instead of lines. - Toggling read-only mode will still toggle the help file's preview mode too. 5 Nov 2022 Started on the syntax checker. Built that it can stop prematurely if a newer check has been started. Built a checker for the hierarchy of tags. It ignores unknown tags inside DOC and TEXT tags. This by itself is too unfinished to upload, so eHelp.zip has not been updated. 3 Nov 2022 About the choices I posted on 31 Oct. I decided on choice 2, but to not take away the user's choices in this. I added a todo task to provide a configuration option to standardize a .ehelp file partially or completely based on user choices. This implies that eHelp will offer to standardize/limit TSE's Help to TSE's existing capabilities, and will not enhance them otherwise. So I also added a not-todo task about enhancing the Help's character set. Plan for next task: eHelp's menu will provide a syntax check for the current file. I will look into making it available through TSE's compile framework too, but a .ehelp file's _DISPLAY_HELP_ mode might obstruct it. The syntax check will always produce a .ehelp_errors file. When and where appropriate it will contain errors, warnings and notes: Errors point out syntax that will cause eHelp to malfunction. For example, a link to a non-existing (sub)topic. Warnings point out syntax that makes no sense, which will hamper maintaining the .ehelp file. For example, a subtopic that is not linked to. (TSE's Help contains these.) Notes relay syntax check information. For example, lines longer than 80 characters, which make .ehelp files less fit for sharing, and statistics. I think errors should disable a .ehelp file from being used. Secondary, I also plan to automatically start a syntax check for each new .ehelp file as a parallel process. Saving a .ehelp file also makes it new: The save succeeds immediately, any consequences are postponed. I am not sure about, that, when the syntax check is finished, there needs to be a pop-up that reports the consequences and offers to view the results. Would that be handy or get annoying? I think I will have to try it out. 2 Nov 2022 _DISPLAY_HELP_ mode does not allow horizontal scrolling. Unfortunately, if the current column position is moved to the right and outside of the window, as shown by its status line indicator, TSE keeps the visible cursor blinking at the window's right-most side, which is confusing to someone editing a .ehelp file. Therefore eHelp now turns the visible cursor off in that situation. 1 Nov 2022 Making line drawing work when editing a .ehelp file. This already works because eHelp turns _DISPLAY_HELP_ on for .ehelp files. The rub is, that in the Util menu turning Line Drawing on is inaccessible. But a user can e.g. toggle line drawing on/off by defining their own key: Toggle(LineDrawing) Or use a menu trick: Select line type "ASCII", turn line drawing on, and select line type "Single". Likewise for turning line drawing off. I should document this, but that is it for line drawing. 31 Oct 2022 I am contemplating implementing my own _DISPLAY_HELP_ mode with my own PutOEMstrXY() function. Limiting it to OEM would keep it small, it could use a standard OEM, it might simplify some desired features, it will solve TSE not using a standard OEM in the Console version leading to odd bullet points for Windows default code page 850, and it will solve Semware breaking OEM in the GUI version of TSE. In TSE's Help, characters from code page 437 occur the most, so code page 437 would become TSE's Help's standard OEM. The problems are: - I do not know how to make this work for the Linux version, for which OEM is almost equivalent to code page 850, but not perfectly. - To my current knowledge, switching code pages would introduce a flash for Windows TSE's Console version when eHelp would switch to and from code page 437. - Typing in GUI TSE and Linux TSE would insert ANSI characters, which for the Help would need converting to OEM as the user types. This is a big decision, without a possibility for a happy solution. I am not happy with this. An alternative I am therefore contemplating, is for eHelp to convert the Help to TSE's variants' smallest common character set: ASCII + some control characters + single-line-drawing characters. E.g. replace double-line-drawing characters by single-line-drawing ones. E.g. replace the bullet character, that is invisible in GUI TSE and shown as two barely visible dots in code page 850, by an asterisk. This would work across TSE variants and thereby satisfy eHelp's purpose of exchangable Help, and would not burden me with replacing TSE's Help mess with a new solution. I am going to take my time thinking about this. 30 Oct 2022 Fixed the error in invoking the help's history to go back to a user-topic. Fixed a seeming harmless error in the Help's Control buffer. An infinite redirect now "succeeds" in retrieving a "help screen" that reports the infinite redirection with the guilty .ehelp file as an error, rather than moving on to querying the next Help source. Buffer strings now use the Help's topic buffer instead of its control buffer. If the help topic's source is not TSE itself and it fits before the topic title, then the help topic's source is displayed in the top left help border. If it fits and is not TSE itself, then the top left help border now indicates the external help's source. Marked text is now shown if you edit a .ehelp file. 28 Oct 2022 Error: now does not jump back to my own Help any more but to TSE's Help. This did work correctly, so what did I do? 26 Oct 2022 Implemented getting help for specific subtopic in specific topic. Implemented redirects. In theory this completes all (redirected) topic/subtopic combinations of help retrieval. 25 Oct 2022 Implemented getting help for a bare subtopic. Added the "Statements" topic to tsehelp_eCarlo.ehelp, so I could test requesting help for "for". 23 Oct 2022 The TSE Help sources compiled, but are part of an integrated collection of macros that is too big to be debugged. After hours of monotonous work, for which in hindsight I could have tried to create a macro, I was able to create a debuggable version of TSE's Help by extracting only the Help-related code from the collection. I have implemented a working Help history for the simplest use case: a bare topic starting at line 1 column 1 without a subtopic and without redirection. To be continued. 22 Oct 2022 I know that Semware's Help is implemented as a macro, so I offered to try to repair/finish its support for extended Help, and Semware agreed and sent me the relevant sources. 21 Oct 2022 I am stuck on integrating eHelp's help pages in TSE's Help's history. TSE's Help has this mechanism to allow external macros to provide a Help page, but when it gets it, it does not show its title and does not add it to the Help history. Being stuck, I published what I have, despite it being a mess. I requested Semware's wisdom on how to proceed. 20 Oct 2022 Ugh, apparently I also have to maintain the Help's history in the Help's control buffer. Luckily I have an ancient Help.si file from Semware, which helps me to understand the binary part of the buffer. But, but, but, ... eHelp returns a Help buffer filled with topic text to TSE, and it is TSE that handles the user browsing around in it, so how can eHelp maintain history for which line, column and link the user last accessed in the topic? Ugh! ... From studying the various sources I deduced, that, while TSE has a mechanism for getting Help text from external Help sources, that mechanism is half-baked: when external Help is retrieved, its topic is not shown as the inner window title, and it is not added to the Help history. eHelp itself updating the inner window title was easily done. I expect, that eHelp itself updating the Help history will partially work, but might cause problems too. Rather than waste more time on trying to predict what TSE's Help will do, I am going to start by making eHelp do just a basic Help history update, and see in practice if the drawbacks are manageble. ... It turned out worse than expected. No aborts, but most of the time using to go back in the Help's history does do nothing or goes to the wrong topic. Manipulating the Help's control buffer does not work, probably because it keeps getting overruled by recent topic history in TSE's Help's internal variables. 19 Oct 2022 (2) Great progress, but none of it is available on the website yet, because it is too preliminary, crude and undocumented yet to publish, even as a development version. I can now configure eHelp with a user name, which makes eHelp consult the file for tsehelp_.ehelp to return help for a topic. I manually created tsehelp_eCarlo.eHelp and after every edit and restart of TSE, TSE shows Help for my edited topic instead of TSE's own one. When showing eHelp's Help, TSE does not update the inner window's title with the topic. So now eHelp displays the topic title itself, and displays the user name to its utter left in blend-in menu border colors. That has the disadvantage that very long topic names are cut off on small TSE windows, which I think is a good-ish trade-off for knowing which Help we are looking at. 19 Oct 2022 Reversed the date order in this blog file to "new down to old". The eHelp extension now toggles preview mode for a .ehelp file when read-only mode is toggled. If you are a user of the ControlChars extension, then it overwrites the screen for TSE's Help display of the "black right-pointing triangle" with the invertedly colored "P" that is its control character representation. 17 Oct 2022 But ... Semware not displaying non-ASCII characters in the Help is a recent thing, and it only happens in the Windows GUI version, which does not make sense. Semware started doing this in GUI TSE beta v4.40.98 or v4.40.99, which according to the read.me is between 13 Sep 2017 and 28 Apr 2018. I did some more research. Summarized, I proposed to Semware to start using code page 850 for the Help in all three TSE variants, independent of the outside environment's code page, so we can share the Help we create without having to worry about recepients seeing distorted characters. 16 Oct 2022 Today I found out, that GUI TSE's Help does not support diacritics at all. In _DISPLAY_HELP_ display mode, which TSE's Help uses too, any non-ASCII characters except these are shown as a space in GUI TSE: - single-line-only drawing characters, - double-line-only drawing characters, - two shade-like characters, light and dark, - a checkmark character. In hindsight I understand why Semware made the GUI choice to leave the OEM mess behind. But no diacritics at all? The Terminal font does show diacritics, so I assumed the Help would support them too, albeit at different byte locations. I assumed wrongly. I am trying to create a tool here, in which we can add our own Help. TSE has a significant amount of non-English users, including me, so diacritics matter. On the other hand, introducing them would add a huge amount of work, would almost certainly exclude TSE's Console version, and would possibly exclude TSE's Linux version depending on how far I would want to take this. Although this gives me a deja-vu feeling, I am going to reconsider and rethink this (again). ... Actually, thinking upon this, I know exactly how to make the Help Unicode-compatible. It would take a significant chunk of time, but would totally be doable. That said, given TSE's small user base, given TSE now receives limited maintenance, given TSE's current Help is already English-limited, and given that, while TSE's built-in Help is a critical part of it, diacritics are not, I am going to be smart for once, and limit my time. No diacritics it is. 15 Oct 2022 Hmm, not all is roses in display mode _DISPLAY_HELP_ land. It grays out the line drawing tool, in GUI and Linux TSE the ASCII menu logically still shows ANSI not OEM characters to insert, and block marking happens but is not visible. On the other hand, switching to Terminal font is ugly and does not work in Linux. I will have to ponder this some more. On the bright side, I did get (re)generating tsehelp.ehelp from eHelp working in a very robust way. 14 Oct 2022 I realized, that eHelp should not temporarily switch the font "Terminal" when viewing a .ehelp file, but that it should temporarily switch the display mode to _DISPLAY_HELP_. Its first advantage is that it works in Linux too. Its second advantage is that this makes it easy to switch between a view-mode and an edit-mode, where the view-mode will show the .help content as the Help will show it. I am contemplating making the view/edit-mode being dependent on and switched by the file's .ehelp extension AND its browse mode. 13 Oct 2022 I saw no further flaws and weaknesses, so I decided to go forward with the latest plan. As the first step I built the tool eHelp_Hlp2eHelp, that will be a helper tool for eHelp, and generate a readable copy "tsehelp.ehelp" out of TSE's "tsehelp.hlp" and "compile.hlp" files. I published both the tool and its output just below the blog. Next steps: - Build an eHelp extension, that initially will do just three things: - Check if tsehelp.ehelp exists unmodified, otherwise call eHelp_Hlp2eHelp. - Temporarily switch to the font "Terminal" when viewing a .ehelp file. - When called from HelpHelp, then show the requested (sub)topic if it exists in tsehelp_eCarlo.ehelp or return that it does not. There is no reason not to start building up tsehelp_eCarlo.ehelp to gain practical experience. - Build a dumb HelpHelp, that tries eHelp first, and the TSE Help if eHelp has no answer. This is to first gain experience with how extending TSE's Help is supposed to work, before trying to add the option to include the too aggressive GetHelp in a way that will not break the coexistence of Help systems. 11 Oct 2022 A weakness of the previous solution is, that it introduces the need to consider which file is the "source of truth": the encoded or the decoded eHelp file. My first reaction is: the newest one. But what if the newest one contains syntax errors? This rub makes me reconsider storing the encoded file at all. How long would it take to encode the not-encoded file just to memory when the Help is first consulted in a TSE session? Tested it: currently 1.1 seconds. That might go up a bit. My user experience is that this feels acceptable. This assumes a blind conversion, without checking for syntax errors. Checking for syntax errors will presumably take to much time to do every time the Help is consulted for the first time in a TSE session, but is a solid requirement before using an eHelp file. An eHelp file with syntax errors will not be used. My plan is to resolve this by storing the time the eHelp file syntax-checked correctly in TSE's .ini file. This allows for a fast check at the file's attempted usage. 19 Sep 2022 I am leaning towards eHelp using TSE's existing Help system to interact with the user, because of its familiarity and fast speed, and because it is very easy to program an automatic conversion from say a readable and correct .eHelp file to a coded .eHelp_encoded file. The new extension names are provisional. It should be doable to additionally program a .eHelp_errors conversion result file. I like that this can be dealt with as a separate concern. The above choice reduces the work significantly. Given GetHelp's tiny usage, user input, and my own experience with users and Semware, I might end up making this just for myself, and I like this solution. It does shift the new bulk of the work to HelpHelp's configuration and to adding additional functionality to TSE's built-in Help system. Functionally these things needed to be built anyway, so this this does not add new work. The "downside" of this choice is an extra .eHelp_encoded file per .eHelp file. I am growing to be fine with this, and am even contemplating allowing them to be used by themselves. Hmm, I would like a(n automatic?) reverse conversion for that, but I am contemplating that anyway for Chris Antos' .hlp files, which have the same encoding as eHelp's .eHelp_encoded files will have. I have a very good feeling about the above as the way to go forward, so now I need to let it lay for at least a day to pick at its flaws and weaknesses. 16 Sep 2022 I finally solved a GetHelp mystery. GetHelp was calling HelpHelp back without using Help(). When I ran GetHelp in the debugger it did use Help(). I still cannot explain that debugger difference. But I debugged GetHelp old-school, without the debugger, and found out that GetHelp's use of TSE's undocumented InsertTopic() function also invokes HelpHelp. 15 Sep 2022 I have stumbled upon a logic/usability problem. HelpHelp assigns handling of a requested topic to either GetHelp or eHelp. But once the topic is assigned to GetHelp the user has no way to switch to eHelp. I really, really, really do not want to modify GetHelp. How to solve this in the least intrusive and most user-friendly way? Aha, we need a "switch key" anyway, to switch between the eHelp descriptions for a topic, and an _after_getkey_ hook can be programmed to make that key escape from GetHelp as well. Unfortunately, due to GetHelp's assumptions, HelpHelp needs to be made very GetHelp-aware. 12 Sep 2022 Research indicates that it MIGHT be possible to program a new HelpHelp, that can sequentially call GetHelp and the new Help in a configurable order, and not call the second one if the first one found the requested Help topic. One problem is that GetHelp has an unfortunate piece of logic that might escape HelpHelp's capability to control. I need to test it to find out. Another problem is that GetHelp agressively redefines Help keys, which is not acceptable if it is configured as the secondary macro. There might be an acceptable work-around, but testing needs to prove that too. The planned name for the new Help macro is "eHelp". So the new version of the HelpHelp macro needs configurably to be able to call GetHelp, eHelp, or a second one if a first one fails. I have been testing a hardcoded version of such a new HelpHelp, and it works OK-ish. I still have trouble fully understanding GetHelp. 10 Sep 2022 I discovered that TSE's Help uses "redirect" syntax (my term). For example, the subtopic "for" occurs in the topic "Statements", and a redirect definition exists, that says that a link to "for" should jump to subtopic "for" in the "Statements" topic. For another example, pressing F1 in a TSE menu automagically generates a help request for "ParentMenu->ChildMenu", which does not exist as a (sub)topic, but a redirect is defined that says which (sub)topic that help query should return. So the new Help, in generating TseHelp.help from tsehelp.hlp and compile.hlp, includes generating a list of redirect definitions in TseHelp.help. TSE's full syntax for a Help address is HelpFile|TopicOrSubtopicOrRedirect;Subtopic "HelpFile|" and ";Subtopic" are optional. "HelpFile" is "tsehelp" or "compile", optionally with path and extension. ";Subtopic" can only be used if "TopicOrSubtopicOrRedirect" refers to a topic. TSE's syntax for a link consists of an address part and optionally of a display part. For example, the address of a link in the Table of Contents is "Listing All Occurrences of a Specified Text String;CompressView" while the link is displayed in the Help as "Compress View" A fully XML-tagged .help file would be too unreadable for links and redirects. I compromised - by giving them only outside XML-tags, - by separating their non-address parts with "^", - and by not expanding their address-parts "|" and ";" to XML-tags. For example: for^Statements;for Marking And Manipulating A Block Of Text;SaveAs^SaveAs Listing All Occurrences of a Specified Text String;CompressView^Compress View The price for that use of 3 special characters ("|",";", and "^") is a steeper syntax learning curve. I tried a fully XML-tagged syntax, and while its meaning was clearer, too many Help lines became so long, that it was no longer user-friendly to work on them a in a normal editing window. The generated TseHelp.help file necessarily has TSE's OEM character encoding. For now the least-bad solution is to edit it using the Terminal font. In my opinion this is not a happy solution, because the Terminal font looks bad, and switching back and forth between fonts is not user-friendly. A better solution would be to make the new Help implicitly view .help files with OEM characters without the need to switch fonts. There are two ways to facilitate this: - Convert the readable .help to and from an intermediate Help format that is supported by TSE's DisplayMode(_DISPLAY_HELP_) command. The work goes into the logic when to trigger the simple conversions. - Write our own Help viewer for .help files with TSE's HookDisplay() and PutOemStrXY() commands. There are no conversions; the work goes into the viewer. The first way discards the need to program a viewer. The second way simplifies the design by not needing an intermediate format, it runs faster, and it could facilitate future capabilities better by not locking us in to DisplayMode(_DISPLAY_HELP_)'s limitations, but it would require me to program my own viewer. Either solution requires a TSE extension, which needs to be initiated by the HelpHelp extension, which means we first need to solve the HelpHelp problem. The HelpHelp problem: TSE allows its Help engine to be intercepted by a macro named "HelpHelp". There can be only one. On Semware's old website Chris Antos' gethlp40.zip from 2002 can be found, which includes a "HelpHelp" macro, which means there already is an existing one out there. My impression is that GetHelp has extremely few users. My extended Help solution needs to intercept TSE's Help engine too, so it needs to employ a HelpHelp macro too. Can this be resolved?