Flex sidebar

[kenbowen]

Please review for search experience quality.

[chuckhoupt]

I'm seeing an jQuery regex error at page-load. I added an onerror handler to make it more visible.

For a while I thought the error was preventing search, but it turned out just to be the test search I had chosen: "cut". Strangely "cut" doesn't match anything, even though "cut" is in !/0's description.

[chuckhoupt]

Here are some ideas on the search experience:

• A search should show each matching predicate, as it does in the old interface (https://alsprolog.com/docs/ref/alshelp.html), rather then just highlight package/group. Because the folding lists hide items, the code will have to open and un-open detail elements (just as it already shows/hides items).
• Because there is a lot of hierarchy, I think unmatched parts of the hierarchy (Package/Group names) should be hidden if they don't contain matching items.

A concrete example of the suggestions above would be a search for "bag", which would display the bagof/3 item and its package and group, but nothing else:

Search: bag

• Core Prolog
  • Control
    • bagof/3

[chuckhoupt]

I'm guessing all the changes to this file are experimental/scratch changes. Should they be removed?

[kenbowen]

No, I just forgot that I needed to clean that up by removing the commented-out block. The point of the change was to avoid having to to first click to the massive table of predicates, and then select something to to click on to reach the search sidebar. Note that the predicates table is available via the View All Predicates link on the sidebar. But I just realized that it makes sense to put a copy of that link on ref-packtoc.html. I was going to check that in, but I keep getting this message: ALSProlog has been updated on https://github.com/AppliedLogicSystems/ALSProlog.git since you last synced. You can try syncing again or run `git pull origin master && git push origin master` from the command line. I’ve performed git pull origin master && git push origin master, but it doesn’t help. Here’s what my ref-packtoc.html looks like now: <ul> {%- for package in site.ref_packages %} <li> <strong><a href=" {% if package == "Core Prolog" %}ref/cut.html"{% endif %} {% if package == "ALS Library" %}ref/arithx1.html"{% endif %} {% if package == "ALSDev" %}ref/Edit_Menu.html"{% endif %} {% if package == "C Interface" %}ref/c_malloc.html"{% endif %}

{{package | escape}}{{package.name}}</a></strong>

</li> {%- endfor %} </ul> <div style="margin-top:-1em;margin-left:1.8em;"><a href="/docs/ref/#control">View All Predicates</a></div> —Ken

…

On Jan 14, 2020, at 7:25 PM, Chuck Houpt ***@***.***> wrote: @chuckhoupt commented on this pull request. In docs/_includes/ref-packtoc.html: > @@ -2,8 +2,14 @@ {%- for package in site.ref_packages %} <li> -<strong>{{package | escape}}</strong> I'm guessing all the changes to this file are experimental/scratch changes. Should they be removed? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kenbowen]

Go ahead & change it back. —Ken

…

On Jan 14, 2020, at 7:00 PM, Chuck Houpt ***@***.***> wrote: @chuckhoupt commented on this pull request. In docs/docs/ref/cut.md: > @@ -13,7 +13,9 @@ FirstGoal, !; SecondGoal ``` ## DESCRIPTION -Discards all choicepoints made since the parent goal started execution, including the choicepoints, if any, created by calling the parent goal. In the following two cases, a cut in `Condition` will remove all choicepoints created by the `Condition`, any subgoals to the left of the `Condition`, and the choicepoint for the parent goal. + +Discards all choice points made since the parent goal started execution, including the choice points, if any, created by calling the parent goal. In the following three cases, a cut in `Condition` will remove all choice points created by the `Condition`, any subgoals to the left of the `Condition`, and the choice point for the parent goal. Minor: this change undid the choicepoint corrections in 186b6da — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kenbowen]

Not unreasonable. However, since the search is incremental as you type, initially there will be huge displays of (partially) matching predicates with each keystroke. E.g., leave the radio button on 'By Both’, and type ’s’. A vast amount (feels like everything, but not quite) matches. The old version didn’t do that because you had to click a Search button, so one normally didn’t click that until some number of chars had been typed. Obviously, if you type quickly in the current version, enough chars get laid down so that you don’t match (almost) everything at once. Maybe we should do something like: Starting at the first typed char, color as now, but do not show the matches; When reaching 3 chars (4?), start expanding the details tabs and show the matches. I’ve just noticed some bad behavior: typing ‘bag’ or typing ‘set’ gets no matches. I’ll look into it. ——Ken

…

On Jan 14, 2020, at 6:57 PM, Chuck Houpt ***@***.***> wrote: Here are some ideas on the search experience: • A search should show each matching predicate, as it does in the old interface (https://alsprolog.com/docs/ref/alshelp.html), rather then just highlight package/group. Because the folding lists hide items, the code will have to open and un-open detail elements (just as it already shows/hides items). • Because there is a lot of hierarchy, I think unmatched parts of the hierarchy (Package/Group names) should be hidden if they don't contain matching items. A concrete example of the suggestions above would be a search for "bag", which would display the bagof/3 item and its package and group, but nothing else: Search: bag • Core Prolog • Control • bagof/3 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kenbowen]

Sigh. Think it’s like, bag,set. I’ll add it to my list.

…

On Jan 14, 2020, at 2:17 PM, Chuck Houpt ***@***.***> wrote: I'm seeing an jQuery regex error at page-load. I added an onerror handler to make it more visible. For a while I thought the error was preventing search, but it turned out just to be the test search I had chosen: "cut". Strangely "cut" doesn't match anything, even though "cut" is in !/0's description. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[chuckhoupt]

Maybe we should do something like: Starting at the first typed char, color as now, but do not show the matches; When reaching 3 chars (4?), start expanding the details tabs and show the matches.

The trouble with having a minimum length requirement is that it will prevent useful searches for things like "!", "gc", ">=", etc.

Another option might be to have a maximum result threshold (in the 20-50 range?). For example, "g" matches 100+ entries, but "gc" only matches 2 -- the search code could delay the display of results until the count falls below the max threshold.

[kenbowen]

On Jan 23, 2020, at 9:42 AM, Chuck Houpt ***@***.***> wrote: The trouble with having a minimum length requirement is that it will prevent useful searches for things like "!", "gc", ">=", etc.

Actually, no. Here’s how ! and gc go: Imagine you are already on any ref page, say for call/1. Set the radio buttons to either By Name or By Both, and clear the search field. Type just ! into the search field. You get this: Then click on the handle in the pink Control details. You get this: And clicking on the LightCyan !/0 link, you get the ref page for cut: If the radio buttons set to either By Name or By Both, then typing cut into the search field produces because “cut” is a substring of the descriptions of all those hits. For gc: Set the radio buttons to either By Name or By Both. Type gc into the search field. For By Name, you get this: While for By Both, you get this: Then clicking on the handle in the pink Control details gives you this: And clicking on the LightCyan gc/0 link, you get the ref page for gc: For longer items. Set the radio buttons to either By Name or By Both. Then type ma into the search field. You get: Now go further and add an x so the search field contains max. You get: The breakpoint for opening the display is controlled by var switchpoint = 2; at the top of assets/searchhelp.js; this test is if (str.length > switchpoint) where str is the contents of the search field. If you set that to 0, you get extremely long sidebars when you type just 1 or 2 chars in the search field. I myself don’t find that so useful. However, if we want to also provide that approach, we an easily add a numeric field (say below the By Name ….. box, defaulting it to 2) which allows the user to set a value for switchpoint. I’ve checked in the current version of flex-sidebar. It passes all tests under unix/make test. ——Ken