[racket-dev] DrRacket PF1 Search Bug?

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Fri Nov 21 16:26:08 EST 2014

On Fri, Nov 21, 2014 at 3:13 PM, Eli Barzilay <eli at barzilay.org> wrote:
> On Fri, Nov 21, 2014 at 3:16 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>>
>> Oh, my apologies. I thought you meant something different.
>>
>> Yes, this works.
>
> Ah, in this case, the patch that I sent earlier should work fine.
> (I could do a pull request, but it should really be tested...)
>
>> I don't have a good idea which is the better approach now.
>
> [Bear in mind that I don't really know what the issue with the file
> permissions is (looks more like some security attributes):]
>
> I think that playing with such attributes is a worse option -- it's
> something that I'm not sure would work in all settings (but see above),
> and if there is a way to make it work now, it might not be possible in
> the future.  The trampoline approach is relatively robust and well
> behaved.  There is a minor price of these temporary files, but they do
> get cleaned out (whenever `send-url/contents' is called), so it should
> settle on a small number that will not grow indefinitely[*], so this is
> not a problem.
>
> Also, on the "it's already there" side -- this trampoline approach is
> already there for the windows version, and it's needed for the
> `xdg-open' thing anyway, so abstracting it into a new (internal)
> function makes sense already, so in terms of additional code there's no
> cost for doing the mac version too.
>
>
> ([*] It might be a problem if, for example, your cat sits on the f1 key
> and the os doesn't take the focus away from drracket...  It might be
> useful to change it from using a random temp file to a name based on a
> hash of the forwarded url, which will further minimize the number of
> files.)

Oh, absolutely. The two candidates are the trampoline approach and the
"just move the documentation files over into the user space as if a
package had been installed".

I guess the latter is better because it means there will be more
homogeneity in the sets of files and whatnot, such that these kinds of
bugs will be less likely to be unnoticed by in house folk. That is, I
never noticed this problem because my documentation is already in the
user-specific place because I build from source. The other option will
make our users operate more like how my drracket operates.

Robby

Posted on the dev mailing list.