Yes, normalization doesn't deal with those spaces. It does change the
text in ways that are unfriendly and I often tell DrRacket "no" when
it asks about normalization. I just wanted to put that into the mix
for this conversation, since it is a place that has to deal with
similar issues.
Robby
On
20 minutes ago, Robby Findler wrote:
> I'm not sure of the right answer, but there is also a notion of
> normalization of unicode characters that probably fits into whatever
> solution you come up with here (ie the thing DrRacket is doing for
> normalization probably applies to what you're thinking
An hour ago, Danny Yoo wrote:
>
> In all three scenarios, I can see that it's possible the user really
> does want to leave zero-width characters unmolested.
There's an easier scenario to confirm this: pasting/typing some text
strings. The frustration that you'd have when you just can't type
som
I'm not sure of the right answer, but there is also a notion of
normalization of unicode characters that probably fits into whatever
solution you come up with here (ie the thing DrRacket is doing for
normalization probably applies to what you're thinking about).
Robby
On Thu, Apr 12, 2012 at 2:47
On Thu, Apr 12, 2012 at 3:26 PM, Eli Barzilay wrote:
> A few minutes ago, Danny Yoo wrote:
>>
>> I want the behavior of the auto-translator to notify the text has
>> changed, so that if the user opens a file in DrRacket with the zero
>> width space, they can Save the file:
>
> So, this happens on
A few minutes ago, Danny Yoo wrote:
>
> I want the behavior of the auto-translator to notify the text has
> changed, so that if the user opens a file in DrRacket with the zero
> width space, they can Save the file:
So, this happens on any editing? What if I want to have those
strings?
Also, I t
> However, from earlier on the thread, it's clear that zero-width space
> doesn't play by the same rules, so re-instituting the solution from
> nbsp->space for DrRacket might be the right thing to do.
Followup: here's what I've got:
https://github.com/dyoo/racket/commit/ed6570d482acada202798
> Just to note: I did the following git command to trace it:
>
> $ git log -S'nbsp->space' --all
Ah ha! Here's the thread on plt-internal which motivated the change:
http://lists.racket-lang.org/plt-internal/private/2007-March/011601.html
As I understand it, the reason for removal was b
> Traced! Something happened in 2007, and commit
> 8bd72e512da3345d1d3514d2bb3f9148c7a93b39 turned it off. I haven't
> haven't been able to trace the reason why it needed to be removed
> though.
Just to note: I did the following git command to trace it:
$ git log -S'nbsp->space' --all
___
On Wed, Apr 11, 2012 at 8:16 PM, Robby Findler
wrote:
> Thanks for looking into this!
>
> How about just changing the way nbsp->space-mixin so that it just does
> both jobs (perhaps with overridable methods or settable fields that
> provide finer-grained control)?
>
> As for where it is wired in,
Based on some feedback from Robby, I'm trying to improve the way the
Web server's binding exports are documented.
I've been looking at the docs and some examples, but I can't find the
right thing to do and if it is even possible.
Here's the basic setup:
web-sever/http re-exports the bindings pro
11 matches
Mail list logo
