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 - Some indicator how many .ehelp files there are for the current topic. - Implement "<\" as escape-syntax for reserved tags. Or something else: TSE's own help codes might need escaping too. COULD - Real bold and italic Help for Windows GUI TSE. - Generate an HTML version from the .ehelp files. - WYSIWIG editing of .ehelp files. WONT - Enhance TSE's Help's character set. ( Exception: eHelp makes GUI TSE's invisible bullet character visible when editing a .ehelp file. Use the HelpRepair extension for the same effect in the Help. ) - Enable other Help domains than "tsehelp", and enable invoking them extension-sensitively. I think that in practice this feature would not be used. 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. 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 Implemented adding topics and subtopics to the index file. Made eHelp auto-configure tsehelp_Index.ehelp. Released this as eHelp.zip v0.17. 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?