Closed Datseris closed 3 years ago
I disagree to an extend. The main utility of UnicodePlots is for working in the REPL; particularly over SSH on some remote server. While I am sad to hear that doesn't work properly on windows, it does work perfectly on OSX and Linux, which are the main systems when considering terminal work in general. I would alsoargue that for things like Jupyter and Markdown documents, one is better served using a graphical plotting package.
That all said, I am sympathetic to finding a better solution for those failure cases. My main point in this reply is that I don't think making DotCanvas the default is the solution to go for.
To answer your question
why aren't the plots of the README plain text but they are linked images?
The last point (which is very valid) is what I guess you are hinting at, but even if that worked perfectly I would still use images.
UnicodePlots is not advertised as a general purpose plotting library that plots in text, it explicitly says in its description and readme:
Unicode-based scientific plotting for working in the terminal
Advanced Unicode plotting library designed for use in Julia's REPL.
While I am happy to see people using it in other avenues as well, the use case of working in a terminal is first priority and should yield the best possible experience
Alright, thanks for clarifying.
Well, I've reconsider this. This issue should be open. Even if the initial scope of UnicodePlots is REPL-based plotting, mainly for Linux and Mac, this shouldn't stop anyone from expanding and improving this.
In the first comment I've added the code I currently use to have better platform-dependent defaults for my scatter plots.
As you can see, this code should be generally useful and you should consider using it as the code that decides what the defaults should be. The code I attach uses Braille in Linux/Mac REPL and in Juno but uses ASCII elsewhere.
That seems like a sensible solution to me
Although i am not sure what exactly asciidef = (canvas = DotCanvas)
is supposed to accomplish, why not simply chose one variable name such as asciidef = DotCanvas
?
note that (foo = 1)
is not the same as (foo = 1,)
if thats what you were going for
julia> (foo = 1)
1
julia> (foo = 1,)
(foo = 1,)
Haha no sorry, I sloppyly re-formed my actual code that has more than one keyword argument. I pass asciidef...
to scatterplot.
In our discussion I think the best is to simply define a function:
function defcanvas()
if isdefined(Main, :IJulia) && Main.IJulia.inited
# Always use ASCII in IJulia until this issue is fixed:
# https://github.com/jupyter/notebook/issues/4354
DotCanvas
elseif isdefined(Main, :Juno) && Main.Juno.isactive()
BrailleCanvas
else # If not Juno or Jupyter, it is REPL
if Sys.iswindows()
DotCanvas
else
BrailleCanvas
end
end
(or maybe you want to modify it further so that it gives AsciiCanvas
for lineplots)
Note that this is no longer a problem on Windows with the new terminal.
Note that this is no longer a problem on Windows with the new terminal.
Which "new terminal"? Powershell?
This one: https://github.com/microsoft/terminal
Closing, as there is nothing more we can do here, see the latest spacing fixes (https://github.com/JuliaPlots/UnicodePlots.jl/pull/167).
For IJulia
, use the border=:dotted
trick on a BrailleCanvas
.
Windows seems to work (https://github.com/JuliaPlots/UnicodePlots.jl/issues/98#issuecomment-640058854), not tested.
For reference: https://github.com/JuliaPlots/UnicodePlots.jl#know-issues.
Platforms that Braille plotting works:
Platforms that fail:
I urge you to consider using this piece of code:
to use platform-dependent defaults for e.g. scatterplots. Here the argument
asciideff
in my case is given to scatterplot.(EDIT: I've just tested:
border = :solid
works in every platform. It is the canvas that messes up things)