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

Add session settings variables like $OutputStyle #3

Open
rocky opened this issue Nov 17, 2020 · 5 comments
Open

Add session settings variables like $OutputStyle #3

rocky opened this issue Nov 17, 2020 · 5 comments
Labels
enhancement New feature or request

Comments

@rocky
Copy link
Member

rocky commented Nov 17, 2020

It would be nice to be able to set/change setting that can right now only be set at the outset inside a REPL session.

In particular options --style (set Pygments output style) and --full-form (show Full form translation of input)

@mmatera this is something that I could use help on. See https://github.com/Mathics3/mathicsscript/blob/master/mathicsscript/settings.py for what I have so far.

However when I try to set this inside the REPL, I am not able to. I believe the problem lies in Mathics somehwere.

Also I suspect Mathics might be improved somehow to make writing "builtins" that function as settings to be made simpler.

@mmatera
Copy link
Contributor

mmatera commented Nov 17, 2020

According to what I see in main.py,


            if full_form:
                print(fmt(query))
            result = evaluation.evaluate(query, timeout=settings.TIMEOUT)
            if result is not None:
                shell.print_result(result, output_style, debug_pygments=pygments_tokens)

pygments are called by the variable fmt, which is defined out of the main loop. One way to make this dependent on the state of a variable would be to put inside the main loop, and look into the definitions object each time to set the behavior.
Regarding FullForm, you could also charge it to the evaluation object, setting the variable $PrePrint
to FullForm from inside mathics. Then, in main, if the parameter is passed, you can do something

evaluation.execute("$PrePrint=FullForm")

and, from inside the command interface, you can deactivate this by calling

$PrePrint=. 

and reactivate it with

$PrePrint=FullForm 

@mmatera
Copy link
Contributor

mmatera commented Nov 17, 2020

Regarding the Pygment formatting, I would't do in that way, to do not mix the kernel with the user interface. Instead, you can look at the control variables by calling (from Python)

pygmentsstyle = definitions.get_ownvalue("Settings`$PygmentsStyle").get_string_value()

once a suitable context and variables are defined as builtins/user defined variables. This could be done both by something inside mathics builtins, or just in a initialization file defined in mathicsscript.

@rocky
Copy link
Member Author

rocky commented Nov 17, 2020

@mmatera Thanks! Will do the next time I have some free time to work on this.

@rocky
Copy link
Member Author

rocky commented Nov 17, 2020

Regarding FullForm, you could also charge it to the evaluation object, setting the variable $PrePrint
to FullForm from inside mathics. Then, in main, if the parameter is passed, you can do something

evaluation.execute("$PrePrint=FullForm")

I just tried this and this isn't the same thing as what the option --full-form does: the above formats the output in FullForm, while --full-form shows the input translated to full form before it is fed to evaluation.

Recall that for parsing things like /. (ReduceAll) we want to see the input parsed before it is evaluated.

@mmatera
Copy link
Contributor

mmatera commented Nov 17, 2020

Yes, you are right... I tried to get the same behavior with $Pre, but (even in WM) it always evaluates first and then converts the expression to FullForm. In any case, the idea would be then to check the value of a variable in the definitions object and then apply the format according to its value.

@mmatera mmatera mentioned this issue Nov 17, 2020
@GarkGarcia GarkGarcia added the enhancement New feature or request label Jan 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants