Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BSL decimal number values paste as non-textual #134

Open
rxg opened this issue Feb 12, 2021 · 6 comments
Open

BSL decimal number values paste as non-textual #134

rxg opened this issue Feb 12, 2021 · 6 comments

Comments

@rxg
Copy link

rxg commented Feb 12, 2021

When BSL is set to display rational numbers as decimal, evaluating them produces a non-textual value that is easily mistaken for being textual. Then if a student copies and pastes such a value into their racket file, the value pastes as non-textual and the file becomes non-textual. This breaks course infrastructure that depends on receiving textual files, and is quite difficult for course staff, let alone students, to understand, and they are far more difficult to find than images or comment boxes since they look exactly like text.

@rxg rxg changed the title BSL decimal numbers paste as non-textual BSL decimal number values paste as non-textual Feb 12, 2021
@rfindler
Copy link
Member

I think it would make sense to have the ones that are in decimal "mode" and have a finite decimal representation to turn back into text when they are inserted into a buffer. One way to do this is to get some cooperation from the text% they are pasted into (or, in other words, the existing APIs make this a change that has to go into several places with this approach). But it might also work for the copy method and the read methods to detect this situation and actually produce string-snip%s. I'm not sure if that will break other invariants that rely on, say, copy's result having the same class as the input but it seems like it might be worth a try.

This is the relevant code.

@samth
Copy link
Member

samth commented Feb 13, 2021

Do we still think the snip-based decimal printing provides enough value to keep it in general? Is there some aspect of a textbook or course that relies on it?

@mfelleisen
Copy link
Contributor

Backwards compatibility :-) !!

@samth
Copy link
Member

samth commented Feb 13, 2021

Well, if there are things that rely on that printing, then I would want to keep it.

@rfindler
Copy link
Member

I played around with this a little bit and it seems like the best approach is to make the definitions window specifically replace number snips that look like ascii with actual ascii, when the snips are inserted. I tried various tricks with the write method of the snipclass or the copy method of the snip and they didn't seem to work very well. It would mean we'd lose the snips when they are in the REPL.

It might also work to try to do something specific to the definitions window when saving but I didn't try that.

@rfindler
Copy link
Member

The latest snapshots from northwestern (and maybe the Utah ones too, didn't check) have these changes in them.

Also, @dvanhorn maybe be interested in this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants