Next issue I’m looking at is https://github.com/racket/racket/issues/936

I understand the intention of adding the query string, but looking at racket/scribble it should be reasonable to hack together the behavior I personally want

This is definitely still there, and I wish it was fixed. So I’m excited to have you work on it!

A little prodding at the javascript might be all that’s needed from my cursory skim, but I’m still at work right now so I’ll have to give this a deeper look later on

hopefully my synopsis of the issue and a path toward “expected behavior” makes sense

@sorawee added some context I didn’t account for. The search field will automatically update the results, but not the query string in the url

I think a use of the JS history API should be sufficient here

If it needs to be more advanced, cookies or localstorage should be employed instead of query string.

localStorage is semantically more correct for our purpose, but old browsers wouldn’t support it. So probably cookies?

Oh, JS history API is cool.

But I think older browsers wouldn’t support it, too, right?

https://developer.mozilla.org/en-US/docs/Web/API/History/pushState

Only added in IE 10

https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie

Cookies on the other hand was supported since IE4

History API with a cookie fallback seems reasonable

Ah, setting cookies vi JS could result in XSS attacks. Resolving this “the right way” might require a few layers of changes, but not an insurmountable problem

@jcmdln425 if you want to rewrite the search in reactive style, you can consider doing something similar to https://github.com/racket/racket-lang-org/pull/123/files

Though it could be that this feature is very simple that reactive style wouldn’t simplify your life much

Hmm, interesting. I may need to chew on the possible solutions and dig through some RFCs to make sure I don’t make things worse

I’m free this weekend though, so I’m not scared

server-side, when a search is completed I’d like for an HTTP cookie to be set. This can be handled bidirectionally in JS or Racket, so I’ll see what seems like “the right way”. Coupling that with the History API and invalidating stale cookies, if set, seems to cover most of the cases I can think of.

Something about that doesn’t seem right, so I’ll do some research later

Thank you so much btw for tacking this problem! I think everyone agrees that the current behavior is annoying.

Thanks for helping bounce ideas! I’m mostly driven to solve this one because I also find the behavior odd, but well-intended

Note that there is no server side for the docs

I forgot to replace the link with the HTTP cookie document url, lol

oh

I misunderstood

Hmm, I’ll make a note

Another thing that is worth thinking about: how would this work with raco docs, which opens up the documentation locally in your computer.

I just found that cookies won’t work in that situation: https://stackoverflow.com/questions/12992494/how-to-read-write-cookies-for-local-file-html-document/12992550

But considering that it’s a fallback method, it’s probably fine?

provided I can change the URL and register a dom update, most browsers treat that as a “new page” so forward/backward navigation will work. I’ll test locally with raco docs primarily, later testing on github pages before submitting the PR

I’ll see how some JS frameworks handle this and make some trivial scaffolding to prove a path forward

I think this issue can be closed. The requested functionality is available as a separate package, and I don’t think anyone will work on it to add native support for “cue text”: https://github.com/racket/gui/issues/133

This can also be closed for the same reason: https://github.com/racket/gui/issues/16

This issue should also probably be closed, as the code works as documented. If there are plans to change how snips and snip classes work, it should be done as a separate issue: https://github.com/racket/gui/issues/157

This could also be closed as it is not a Racket GUI Bug (see comments): https://github.com/racket/gui/issues/149

If you don’t mind, I will try to push for your cue text to go into mred. I would need to ask you to relicense the gui-widget-mixins to MIT/Apache 2 to be compatible with Racket though, if you are willing.

thanks for suggesting this. I’ve thought about this occasionally myself, but I just didn’t have the energy to do something

Racket gui already has a cue text mixin, although it works differently (and in my opinion, more complex to use). https://github.com/racket/gui/blob/001c57b86c624ad367354d6bf168f55f82e79c20/gui-lib/embedded-gui/private/cue-text.rkt

If you do the work and have it approved for merge into mred, I will re-license my code so it is compatible with the Racket license.

Now that 7.8 is released, I think we also should go over https://github.com/racket/racket/pulls?q=is%3Aopen+is%3Apr+label%3APR-good-to-merge and try to get them merged before we forget them

Mostly those are waiting for comments from the person I assigned them to

If there are any exceptions, let me know

this issue drives me up a wall, so I’m very excited at the prospect of it getting fixed