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

Some printing code ignores is_unicode_allowed() and prints unicode "wedge" characters #3257

Closed
4 tasks
fingolfin opened this issue Jan 29, 2024 · 11 comments
Closed
4 tasks
Labels
bug Something isn't working

Comments

@fingolfin
Copy link
Member

fingolfin commented Jan 29, 2024

Specifically these places should be fixed

You can just print ^ instead of if unicode is not allowed.

@fingolfin fingolfin added the bug Something isn't working label Jan 29, 2024
@lgoettgens
Copy link
Member

Unfortunately, that is not an easy solution, as the places you pointed out don't print anything. Instead, they just construct the symbol used for a variable/basis element. If I construct an object while allowing unicode and then later disallow it, the previous constructed object will still print using the wedge symbol.

The simplest solution that comes to my mind is to save to vectors of symbols: one using unicode and one without; then the show function can choose with one to use based on Oscar.is_unicode_allowed().

@fingolfin
Copy link
Member Author

@lgoettgens OK.

Perhaps it could also use expressify / show_via_expressify from AA? This helps avoid ugly things like (1)*(e1^e2) + (-1)*(e1^e3) which frequently pop up in GAP.

@lgoettgens
Copy link
Member

Perhaps it could also use expressify / show_via_expressify from AA? This helps avoid ugly things like (1)*(e1^e2) + (-1)*(e1^e3) which frequently pop up in GAP.

It does, but only for pretty-printing the sum of coefficients and basis elements. However, the wedge is part of the basis vector printing, so it would need to do some iterate expressify or something...

@lgoettgens
Copy link
Member

@fingolfin Would you be fine to adapt the docstring of allow_unicode to state that objects may follow the state of the flag at the point of their creation instead of at the point of the printing? For a user, this means that they should decide at the beginning of the session if they want to have unicode or not. But for the above cases it would be way more convenient to implement (cf. my previous comments).

cc @HechtiDerLachs

@fingolfin
Copy link
Member Author

@lgoettgens fine by me.

Going beyond that, I think we discussed at some point to also use Preferences.jl for this? That way a user could globally choose what they prefer once and for all. (We then just should make sure to ignore this in our test suite, e.g. by calling allow_unicode(false) at its starts or so?

@lgoettgens
Copy link
Member

Going beyond that, I think we discussed at some point to also use Preferences.jl for this? That way a user could globally choose what they prefer once and for all. (We then just should make sure to ignore this in our test suite, e.g. by calling allow_unicode(false) at its starts or so?

This already is the case since Nemocas/AbstractAlgebra.jl#1341

@fingolfin
Copy link
Member Author

@lgoettgens great! However, I don't think our test suite does allow_unicode(false), or does it? (OTOH if it does... we wouldn't want the user's defaults to change just because they run the OSCAR test suite... so I guess a version of allow_unicode() that doesn't affect user prefs would be useful?

@lgoettgens
Copy link
Member

@lgoettgens great! However, I don't think our test suite does allow_unicode(false), or does it? (OTOH if it does... we wouldn't want the user's defaults to change just because they run the OSCAR test suite... so I guess a version of allow_unicode() that doesn't affect user prefs would be useful?

I independently had the same thought and just created #3271 for this.

@lgoettgens
Copy link
Member

For the documentation, it would be great if we could enable unicode for some docstrings, but this would need something already wished for by @fingolfin about a year ago in JuliaDocs/Documenter.jl#2058

@ThomasBreuer
Copy link
Member

Concerning the general situation that one creates objects storing data whose printing depends on formats, encodings, etc., one solution would be to store one format that can be converted (easily) into the other supported formats on demand.

For example, Jean Michel's Chevie.jl package takes the approach to store labels in LaTeX format (even in data files), and to define generic conversions that derive other formats from that: The function unicodeTeX creates a unicode approximation of a LaTeX string, and the function TeXstrip creates a plain ASCII version.

@lgoettgens
Copy link
Member

Resolved by #3270 and #3263

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants