> On 2019-08-30, at 1:25 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> 
> On Thu, Aug 29, 2019 at 12:17 PM H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 8/29/19, tim Rowledge <tim at rowledge.org> wrote:
> [snip]
> > I'm not currently very familiar with feeding stuff into
> > the HelpBrowser nicely.
> [snip]
> 
> This might be considered as a request for a tutorial on how to write
> Help browser entries with style and executable code. (within the help
> browser)
> 
> 1.  Open the Help entry in the Help browser.
> 2.  Type the updated text into the Help entry.
>      - Cmd+6 = Colored text,  
>        Cmd+7 = bold,  
>        Cmd+8 = italics,   
>        Cmd+_ = Underline
> 3.  Press Cmd+s to save the entry with the updated text.
> 4.  Note the dirty -Help package in Monticello browser.

This works really nicely in the right sort of help topics - the subclasses of CustomHelp that work with ClassBasedHelpTopic or DirectoryBasedHelpTopic, so far as I can see right now. 

Given that editing works for these sort of entries it would be nice if someone knows how to prevent attempted editing in cases where something can't be edited. 
For example, 
HelpBrowser openOn: self all 
opens a help book on all the classes and comments and methods etc - but you can't save anything even though you can edit. It would avoid a little confusion, which is always nice. 

Even nicer but probably a tad harder would be to make editing work here; I could imagine it working for the class comments but the listed method names & first comments would be a bit odd to edit. Perhaps extend the linking attributes set for the method names to include the comment might help - that way any attempt to edit would open a 'proper' browser?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Bother," said Pooh, reading his bank statement from Barings.