Implement an interface for displaying objects in HTML from the command line

[AndrewMathas]

Description says it all. "Large" objects, such as large matrices, cannot be displayed properly on the screen or latex, but they can be displayed better in HTML.

EXAMPLE:

sage: ct=CoxeterGroup("B5").character_table()
sage: ct.html_display()

to display the character table in your favourite browser.

Preliminary patch added. See #14103 for a "real" application.

CC: @kcrisman

Component: user interface

Keywords: days45

Author: Andrew Mathas

Issue created by migration from https://trac.sagemath.org/ticket/14104

[williamstein]

comment:3

There is a similar command "html.table" in sage already. I was recently reading it since I guess I have to rewrite it for salvus... and I didn't like it. Could your code somehow address the existence of that code? (This could be for another ticket, of course.)

IN the sage notebook now putting '..." in output makes it display as html.
In salvus there is a completely different way of doing this, which involves sending messages... From a code point of view there is a function "html", which does the right thing for any notebook client.

[AndrewMathas]

comment:4

Replying to @williamstein:

There is a similar command "html.table" in sage already. I was recently reading it since I guess I have to rewrite it for salvus... and I didn't like it. Could your code somehow address the existence of that code? (This could be for another ticket, of course.)

IN the sage notebook now putting '..." in output makes it display as html.
In salvus there is a completely different way of doing this, which involves sending messages... From a code point of view there is a function "html", which does the right thing for any notebook client.

As I understand it, html.table is intended to be used from the notebook whereas this command is aimed at the command line. Also html.table seems to only take lists whereas my motivation for writing this was to display labelled tables/matrices. I'm not really sure what you mean by "addressing the existence" of html.table, but the code could (and possibly should) be made to work together.

My patch provides a few classes for interactively constructing a web page, section by section, using the format of the sage documentation. Currently it only has hooks for displaying tables, because this is what I care about at the moment, but I have tried to make the framework easily extendible. In addition to displaying data pages on the fly, my plan is to use it for displaying databases -- such as, for example, all of the decomposition matrices for the symmetric groups in a fixed characteristic for n\le 30.

Inside the notebook I could just output a string '...' for the notebook to interpret -- although, for this to work the links would need to be updated and some of the formatting stripped out. This would be easy to do provided that there is a way for sage to determine whether or not it is running inside the notebook -- I'm afraid that I don't know much about the notebook:)

The main reason that I wrote this is because I to be able to scroll the entries of a table whilst keeping its column and row headers fixed. Via some open source javascript, I have the scrolling feature working although I'm not happy with the output yet -- in the next day or so I will add examples to the patch which illustrates this, but first I need to rearrange my code a little since my current examples depend on the patches #14103, #13605 and some other code not yet on trac.

[jhpalmieri]

comment:5

Could your code somehow address the existence of that code? (This could be for another ticket, of course.)

See also #13131.

[williamstein]

comment:6

Replying to @AndrewAtLarge:

Replying to @williamstein:

There is a similar command "html.table" in sage already. I was recently reading it since I guess I have to rewrite it for salvus... and I didn't like it. Could your code somehow address the existence of that code? (This could be for another ticket, of course.)

IN the sage notebook now putting '..." in output makes it display as html.
In salvus there is a completely different way of doing this, which involves sending messages... From a code point of view there is a function "html", which does the right thing for any notebook client.

As I understand it, html.table is intended to be used from the notebook whereas this command is aimed at the command line. Also html.table seems to only take lists whereas my motivation for writing this was to display labelled tables/matrices. I'm not really sure what you mean by "addressing the existence" of html.table, but the code could (and possibly should) be made to work together.

Sorry, I wrote that in a hurry during a talk.

I mean, e.g., you could replace html.table by a much shorter function that (1) calls your code to generate html, then (2) calls the html(...) function to display it in a notebook.

My patch provides a few classes for interactively constructing a web page, section by section, using the format of the sage documentation. Currently it only has hooks for displaying tables, because this is what I care about at the moment, but I have tried to make the framework easily extendible. In addition to displaying data pages on the fly, my plan is to use it for displaying databases -- such as, for example, all of the decomposition matrices for the symmetric groups in a fixed characteristic for n\le 30.

Inside the notebook I could just output a string '...' for the notebook

Please call the function sage.misc.html.html instead. It just wraps the output in '...' by default, but for other notebook environments (e.g., Salvus), I can replace it by a function that sends the right JSON message.

to interpret -- although, for this to work the links would need to be updated and some of the formatting stripped out. This would be easy to do provided that there is a way for sage to determine whether or not it is running inside the notebook -- I'm afraid that I don't know much about the notebook:)

There is a "lame" way to check:

sage: sage.plot.plot.EMBEDDED_MODE                                              
False     # not running in notebook -- if true, is running in notebook

The main reason that I wrote this is because I to be able to scroll the entries of a table whilst keeping its column and row headers fixed. Via some open source javascript, I have the scrolling feature working although I'm not happy with the output yet -- in the next day or so I will add examples to the patch which illustrates this, but first I need to rearrange my code a little since my current examples depend on the patches #14103, #13605 and some other code not yet on trac.

[AndrewMathas]

Attachment: trac_14104--html_display-am.patch.gz

More doctests and better examples

[AndrewMathas]

comment:8

[Sorry for the last post - trac keeps on logging me out before I can submit a comment...]

Replying to @williamstein:

I mean, e.g., you could replace html.table by a much shorter function that (1) calls your code to generate html, then (2) calls the html(...) function to display it in a notebook.

Yes, this wold be easy to do -- compare with the wrapped for character tables in the revised patch (or look at the slightly more function version in #14103 when I upload the patch for it tomorrow).

Btw, John Palmieri's patch #13131 already improves html.table. In fact, his command line display is more powerful than what I do in #14103 because it can cope with entries spanning more than one row, whereas I am mostly interested i being able to index the matrix/table entries by different sage objects.

[seblabbe]

comment:9

At the LMFDB workshop in Edimbourg last January, we had those kind of discussions about the fact that each SageObject could/should have html representation (see for instance the thread on Sage Explorer on sage-devel). At the time, I was thinking the interface could be the same as it is now for latex, or string representation :

def _repr_(self):
    r"""
    Returns string representation.
    """
def _latex_(self):
    r"""
    Returns latex representation.
    """
def _html_(self):
    r"""
    Returns html representation.
    """

These methods do not show up on tab completion without the first underscore but html(s) could work... The problem here may be that html can be defined as just returning the code without opening a browser. Then, html_display would be the name for that? Just saying here that the choice of the name of this method should be the same for all SageObject, so we should make sure there is no better choice!

---

Related to this, the documentation of a function can be consulted in the browser and opened from the command-line (works in the notebook as well):

    sage: browse_sage_doc(factor)

It works also for methods of an object::

    sage: m = matrix(2, range(4))
    sage: browse_sage_doc(m.inverse)

[AndrewMathas]

comment:10

Replying to @seblabbe:

def html(self):
r"""
Returns html representation.
"""
}}}

Yes, I was thinking of this as being a fairly generic interface even though it is overkill for most objects. In the related tables patch #14103 I do have an _html_ method for returning the HTML but it doesn't seem to be in this patch so I should add it.

If there is interest in putting this into sage (and I hope there is:) then I agree that finding the right syntax is important. The existing html() already returns html for the object if it has an _html_ method, and in the notebook this html is displayed. One option possibility is to piggy-back off te current function and have html(), by default, open a browser from the command line and also give it the option of writing to a file or simply printing the html -- and leave he default behaviour in the notebook unchanged except that these extra options would be provided there as well.

Another possibility would be to use view() or show(). Arguably there are already too many commands for displaying sage objects in slightly different ways so it is worth thinking this through properly.
The html_display method currently wraps its contents into a sectioned web page in the format of the manuals...s that too much?

I didn't know about the browse_sage_doc method. I will have a look with it.

[jhpalmieri]

comment:11

Note that #13131 adds the processing of an _html_ method (in a naive way) to the existing html() command.

[AndrewMathas]

Changed keywords from none to sage45

[AndrewMathas]

comment:13

Replying to @jhpalmieri:

Note that #13131 adds the processing of an _html_ method (in a naive way) to the existing html() command.

Hi John, I still have not had time to look at your patch properly. It seems to me that they serve different functions. It is not clear to me whether they should be kept separate or merged - since your patch is being reviewed if the consensus was that they should be merged this would presumably be my problem:) Not sure if you have had time to look at my patch either, but do you have any thoughts on this?

Andrew

[jhpalmieri]

comment:14

I think I agree that they serve different functions. I was addressing the point in [comment:10] that "The existing html() already returns html for the object if it has an _html_ method" -- I don't think this is accurate, I think that the _html_ method was introduced in #13131.

I will try to look at your patch in detail. Meanwhile, you should know that the entire directory devel/sage/doc/output is not part of the Sage distribution, so you shouldn't put any files there. Maybe your files should instead go into devel/sage/doc/common/themes/sage/static? I'm not sure...

[kcrisman]

comment:15

Just wanted to put in my two cents that probably #13131 should go in first, as it is pretty ready, and then we could build on that to add _html_ code for other objects, one of which would be the type of thing at #14103.

Should this js go in the extcode repository? Just wondering.

Sebastien is right that html() would give the html, and html_display (or show or view or something) would actually display it. I also like the idea of figuring out what each of these commands should do. Currently it's silly that sometimes my LaTeX engine is fired up to view stuff; why should I be compiling to view it if there is something easier?

[AndrewMathas]

comment:16

Replying to @kcrisman:

Just wanted to put in my two cents that probably #13131 should go in first, as it is pretty ready, and then we could build on that to add _html_ code for other objects, one of which would be the type of thing at #14103.

Definitely. I still neeed to write quite a lot of documentation and iron out a few bugs. On the table side I'd like to do better than the javascript that I am currently using.

Sebastien is right that html() would give the html, and html_display (or show or view or something) would actually display it. I also like the idea of figuring out what each of these commands should do. Currently it's silly that sometimes my LaTeX engine is fired up to view stuff; why should I be compiling to view it if there is something easier?

Firing up MathJax also takes time before you're cooking, especially when looking at a big table for example. The main benefit that I see with html is that you can use it to navigate through large objects. Working out the best framework is important, however. I didn't know about view or show until this week...

[AndrewMathas]

comment:17

Replying to @jhpalmieri:

I think I agree that they serve different functions. I was addressing the point in [comment:10] that "The existing html() already returns html for the object if it has an _html_ method" -- I don't think this is accurate, I think that the _html_ method was introduced in #13131.

Oops, sorry, for some reason I thought that html() already called html() if it existed. It definitely should, so it's good you've done this!

[AndrewMathas]

Changed keywords from sage45 to days45