Warning (emacs): No valid mimetype found (:text/html)

[Yevgnen]

When I'm using emacs-jupyter in org babel, I found that :display plain does not always work as expected. For example, the following two images describe the issue.

The first one, without setting :display plain, two blocks seems output html as expected.

The second one, setting both to :display plain, the first block seems fine, while the second issues a warning and some output is missing

The minimal setting I tested is

(package-initialize)

(require 'org)
(setq org-confirm-babel-evaluate nil)
(require 'jupyter)

(org-babel-do-load-languages 'org-babel-load-languages
                                 '((emacs-lisp . t)
                                   (python . t)
                                   (shell . t)
                                   (latex . t)
                                   (jupyter . t)))

(require 'virtualenvwrapper)
(venv-workon "general")

with

• Emacs version: GNU Emacs 26.2.90 (build 1, x86_64-apple-darwin18.6.0, Carbon Version 158 AppKit 1671.5) of 2019-06-19

• Org version: Org mode version 9.2.4 (release_9.2.4-386-gb855ac @ /Users/user/.emacs.d/straight/build/org/)

[nnicandro]

The :display header is meant to select a particular mimetype if many are returned by a kernel. So specifying :display plain means to only consider mimetypes that end with the stringplain and filter out all other mimetypes from consideration.

The kernel seems to only return text/html results for that second source block which is why you get the warning. Maybe a better warning can be given, something along the lines of Requested mimetype(s) not returned by kernel, or we can disregard the :display header argument completely, use one of the available mimetypes, and output a message to the user saying what happened?

The :pandoc header argument may be of use to you. It will convert export blocks into org-mode format using a pandoc process (so you need to have pandoc installed), see jupyter-org-pandoc-convertable. But I think the fix for this particular situation would be to ask the maintainers of the packages you are using to output text/plain results along with text/html, or if its tabular data you are trying to look at, do something along the lines of what I mentioned in #88 (comment).

[Yevgnen]

Thanks for the clarification.

I've already using the trick mentioned in #88 for pandas data frames. Maybe with little tweak, it works for h2o frames.

The pandoc way work well, although there's a bit latency for the process call.

One thing super confused me is, about the second block

• when I set :display plain, a Warning (emacs): No valid mimetype found (:text/html) is displayed,
• while I manually set :display html, a Warning (emacs): No valid mimetype found (:text/plain) is displayed!

[nnicandro]

Can you show the messages shown in the *Messages* buffer when you evaluate (setq jupyter--debug t) and then try the code block again. You will be able to tell exactly what mimetypes the kernel is sending.

[Yevgnen]

When I set :display plain, the message buffer is

executing Jupyter-Python code block...
SENDING: :execute-request 44842e8c-9b7e-417f-ac73-2fed02895869 (:code data = pd.DataFrame({
'A': [None, 'a', np.nan, 'b', 'f', np.nan],
'B': [1, 2, np.nan, 3, 4, 5]
}) 
h2o.H2OFrame(data, column_types={'A': 'enum', 'B': 'enum'}, na_strings=['None', 'nan']) :silent :json-false :store_history t :user_expressions #s(hash-table size 1 test eql rehash-size 1.5 rehash-threshold 0.8125 data ()) :allow_stdin t :stop_on_error :json-false)
SENT: (:shell 44842e8c-9b7e-417f-ac73-2fed02895869)
MESSAGE: (:iopub :status (:execution_state busy))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :execute-input (:code data = pd.DataFrame({
'A': [None, 'a', np.nan, 'b', 'f', np.nan],
'B': [1, 2, np.nan, 3, 4, 5]
}) 
h2o.H2OFrame(data, column_types={'A': 'enum', 'B': 'enum'}, na_strings=['None', 'nan']) :execution_count 3))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :stream (:name stdout :text Parse progress: |█████████████████████████████████████████████████████████| 100%))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :stream (:name stdout :text 
))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :display-data (:data (:text/html <table>
<thead>
<tr><th>A  </th><th>B  </th></tr>
</thead>
<tbody>
<tr><td>   </td><td>1.0</td></tr>
<tr><td>a  </td><td>2.0</td></tr>
<tr><td>   </td><td>   </td></tr>
<tr><td>b  </td><td>3.0</td></tr>
<tr><td>f  </td><td>4.0</td></tr>
<tr><td>   </td><td>5.0</td></tr>
</tbody>
</table>) :metadata nil :transient nil))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:shell :execute-reply (:status ok :execution_count 3 :user_expressions nil :payload []))
RUN-HOOK: jupyter-shell-message-hook
Code block evaluation complete.
MESSAGE: (:iopub :execute-result (:data (:text/plain ) :metadata nil :execution_count 3))
RUN-HOOK: jupyter-iopub-message-hook
Error running timer ‘jupyter-event-handler’: (args-out-of-range "" 0)
MESSAGE: (:iopub :status (:execution_state idle))
RUN-HOOK: jupyter-iopub-message-hook
DROPPING-REQ: 15e96b4c-417f-4f3f-8452-87c93e2bca45
Quit
Mark set [2 times]
Quit

When I set :display html, the message buffer is

executing Jupyter-Python code block...
SENDING: :execute-request 7d25efd5-adba-4d37-ae16-2bfc6ed775f8 (:code data = pd.DataFrame({
'A': [None, 'a', np.nan, 'b', 'f', np.nan],
'B': [1, 2, np.nan, 3, 4, 5]
}) 
h2o.H2OFrame(data, column_types={'A': 'enum', 'B': 'enum'}, na_strings=['None', 'nan']) :silent :json-false :store_history t :user_expressions #s(hash-table size 1 test eql rehash-size 1.5 rehash-threshold 0.8125 data ()) :allow_stdin t :stop_on_error :json-false)
SENT: (:shell 7d25efd5-adba-4d37-ae16-2bfc6ed775f8)
MESSAGE: (:iopub :status (:execution_state busy))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :execute-input (:code data = pd.DataFrame({
'A': [None, 'a', np.nan, 'b', 'f', np.nan],
'B': [1, 2, np.nan, 3, 4, 5]
}) 
h2o.H2OFrame(data, column_types={'A': 'enum', 'B': 'enum'}, na_strings=['None', 'nan']) :execution_count 4))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :stream (:name stdout :text Parse progress: |█████████████████████████████████████████████████████████| 100%))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :stream (:name stdout :text 
))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :display-data (:data (:text/html <table>
<thead>
<tr><th>A  </th><th>B  </th></tr>
</thead>
<tbody>
<tr><td>   </td><td>1.0</td></tr>
<tr><td>a  </td><td>2.0</td></tr>
<tr><td>   </td><td>   </td></tr>
<tr><td>b  </td><td>3.0</td></tr>
<tr><td>f  </td><td>4.0</td></tr>
<tr><td>   </td><td>5.0</td></tr>
</tbody>
</table>) :metadata nil :transient nil))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:iopub :execute-result (:data (:text/plain ) :metadata nil :execution_count 4))
RUN-HOOK: jupyter-iopub-message-hook
MESSAGE: (:shell :execute-reply (:status ok :execution_count 4 :user_expressions nil :payload []))
RUN-HOOK: jupyter-shell-message-hook
Code block evaluation complete.
MESSAGE: (:iopub :status (:execution_state idle))
RUN-HOOK: jupyter-iopub-message-hook
DROPPING-REQ: 44842e8c-9b7e-417f-ac73-2fed02895869
Quit

like this image (left: :display :plain, right: :display :html)

---

By the way, an off topic issue is ... as you can see in the left buffer, there's an error: Error running timer ‘jupyter-event-handler’: (args-out-of-range "" 0). I see this error quite often occasionally although it's not a big one.

[nnicandro]

OK I see the issue here. There are two different kinds of messages that Jupyter kernels can emit which produce a result, :display-data and :execute-result messages. In this case the kernel is emitting both of these messages. The :display-data has a mimebundle that contains text/html only while the :execute-result contains a mimebundle that contains text/plain only.

When handling these messages, both go through the same code path that produces the warning. So when you specify :display plain you get the warning when handling the :display-data message that only has text/html and when you specify :display html you get the warning when handling the :execute-result which only has text/plain.

It looks like those h2o frames only produce HTML results so I don't think the :display plain is going to help in this situation.

We do need to do something about those warnings in this kind of a situation since it would be confusing to see those warnings especially when a user does not know about the kinds of Jupyter messages.

there's an error: Error running timer ‘jupyter-event-handler’: (args-out-of-range "" 0)

Thanks, it looks like the kernel is sending an empty string as the value for the text/plain mimetype and I'm assuming that there is at least one character in the string.

[nnicandro]

Error running timer ‘jupyter-event-handler’: (args-out-of-range "" 0)

Should be fixed by 7c1689e

[nnicandro]

To summarize the problem pertaining to this issue, if a user specifies a :display html header argument and both a :display-data message (only containing a text/html mimetype) and an :execute-result message (only containing a text/plain mimetype) are emitted by the kernel for a request then a warning will be produced by jupyter-org-result when handling the :execute-result message complaining that it does not contain a text/html mimetype and will not add the the content of the :execute-result to the buffer.

Having the :display header argument work for both :display-data and :execute-result messages is useful since a single source block can cause the kernel to emit either or both kinds of messages so it wouldn't make sense to restrict :display to only handle one of the message types.

One option would be to extend the semantics of the :display header argument to also allow supplying mimetypes for each type of message, but I think the best outcome here is to have a more detailed warning that both shows the type of message, either :display-data or :execute-result, and the list of mimetypes that are considered valid.