Hooking prolog_help from swipl-win

In a qt console, an user issuing

?- help(append).

is ‘greeted’ by a laconic true. Info has gone in background…
I’ve found 2 ways to correct this, either setting the help_pager flag to false, or hooking into the win_html_write/1 that’s sleeping in ConsoleEdit.cpp.

Would be just matter of

prolog_help:show_html_hook(HTML) :- win_html_write(HTML).

but if I do before the first help user call, I get

?- help(append).
Warning: /home/carlo/lib/swipl/library/help.pl:35:
Warning:    Loading module prolog_help abolished: [prolog_help:show_html_hook/1]
true.

and my hook is reset.
Background initialization will slowdown REPL startup though, more or less the same experienced after putting in ~/.swiplrc

:- use_module(library(help)).
prolog_help:show_html_hook(HTML) :- win_html_write(HTML).

So, is there a lighter way to hook win_html_write?

The first fix, setting help_pager to false, needs a fix of the ANSI escape sequence translator, otherwise output is almost unreadable. Well, I will fix it anyway, but would prefer a lot the hook based solution.

Thanks, Carlo

I think simply add a multifile declaration before your definition should do. I think this is the right route, but probably requires some more work. If I recall well I tried this and it looked pretty ugly. Possibly that is merely a matter of getting the CSS loaded.

P.s. Using the HTML help hook is also what is used by SWISH if you run ?- help(Something).

Thanks Jan.
I missed the module qualification on multifile declaration. Putting in ~/.swiplrc

:- multifile prolog_help:show_html_hook/1.
prolog_help:show_html_hook(HTML) :- win_html_write(HTML).

I get

If you think it’s worth, I will attempt to fix the weird left margin setting. Otherwise, will follow the help_pager route.

I think it is. I guess we can push some CSS there using a <script> element? If the HTML embedding is robust we can borrow more good stuff from SWISH.

I’ve experimented a little with help/1 hooked by win_html_write.
The html seen by the console seems it’s all covered, and style is a mix of inlined and stylesheet specification (let’s say ~/lib/swipl/library/pldoc/pldoc.css content).

While inline styles seems to work, my attempt using QTextDocument::setDefaultStyleSheet so far has been unsuccessful. From docs, CSS 2.1 selectors are implemented, and styles coverage could be enough for our purpose, so I don’t really know why it’s not working right now, but overall pushing too far Qt rich text framework seems like over engineering right now.

I would consider it again if would be possible to use Qt WebEngine in our Qt bindings. That of course would open a lot of possibilities, as I had, a lot of years ago, before Qt switched from WebKit to Chromium, a CodeMirror editing with basic debugging interface working (set breakpoint, single step, etc). I think I should make it again available, but as you know, I critically depend from your support for the Mac.

Thanks for your invaluable help.

It is not a big problem to send the style sheet as a <style> element along with the help page.

Getting a full browser in there opens some interesting possibilities. It also makes the relation to SWISH a bit unclear. Possibly it is a great replacement of the current IDE mode where you have both your terminal and a browser running on the same Prolog instance. That approach surely suffers from some security issues as it hard to prevent other users on the same machine from stealing your SWISH session.

So far the Mac version builds fine. One day the issues with locale handling of swipl-win should be resolved. I briefly looked into that, but the relation between MacOS locale handling and POSIX locale handling is unclear to me.

Alas, <style> tags are not accepted. Rich text framework has a rich :slight_smile: API, half declarative. But I used QTextDocument::setDefaultStyleSheet on purpose.