Random Thoughts

While using the Emacs WordPress interface on various screens here, it became clear that the sloppy way I was laying out various tables just didn’t really work. I was using the `variable-pitch’ font and sort of eyeballing how much space each column would take and then using `display ‘(space :align-to 100))’ to line stuff up.

But the size of fonts varies wildly from computer to computer, and what looked nice on my HiDPI laptop didn’t line up at all on my LoDPI screen.

So I switched to using fixed-width fonts:

And I just thought, *sigh*.

It just looks so oldz. I spend a lot of time in Emacs in eww which does nice fonts, so I’ve grown less used to the er starkness of tables like this.

Surely there has to be a way to do tables with proportional fonts, and of course there is: eww/shr lays stuff out without a problem, so I just had to take a similar approach here.

And behold:

The package is on Microsoft Github now.

This also allowed me to implement table headings that you can click on to sort the table on the different columns. And I wanted to keep the interface really simple, because I have to say that I hate working with the tabulated-list.el interface, which is a mess of buffer-local variables and magic always happening wherever you’re not looking in the code.

So the interface is one simple function that takes obvious parameters: A list of column names and max widths, and then a list of row contents:

(variable-pitch-table
 '((:name "First" :width 10)
   (:name "Second" :width 5))
 '(("A thing" "Yes")
   ("A wide thing that needs chopping" "And more")
   ("And the last one" "Foo")))

But you’d normally pass in strings that are made with something like

(propertize "At thing" 'face 'variable-pitch)

to get whatever proportional font you want on each element.

In the previous episode of this blog, I mused about how Emacs should perhaps handle non-text yanking (i.e., HTML and images).

I didn’t really want to write a mode to examine the clipboard and the selections, but I did anyway just now, and I discovered something kinda interesting.

Well I never!

Anyway, this is basically what the mode looks like:

It just lists all the types of selection that exist under the primary/secondary selections, as well as the clipboard. In this instance, I’ve done a “Copy image” in Firefox. So I can inspect the text/html “version” the image…

Which turns out to be the <img;> bit, logically enough.

And the image/png is the image itself, even more logically enough.

But here’s the slightly interesting bit: If you mark some text in Firefox (i.e., put the text into the primary selection in nerd speak), you get these selection types:

And the TEXT bit is as you’d expect…

But what’s that text/x-moz-url-priv?

It’s the URL of the page you marked the text on! This can obviously be used for UX purposes, like providing a function that’d simultaneously quote something and do the link at the same time. Like this:

So something like:

  (when-let ((url (x-get-selection-internal 'PRIMARY 'text/x-moz-url-priv)))
    (insert (format "On <a href="%S">somebody</a> wrote:\n\n"
                    (ewp-decode-text-selection url))))
  (insert "<blockquote>\n")
  (insert (substring-no-properties (current-kill 0)))
  (insert "</blockquote>\n\n")

You can find this stuff on Microsoft Github.

Chrome isn’t as helpful as Firefox here, you just get a very minimal selection list when marking some text there:

(Oh, yeah, I added a command to do screenshots directly from the ewp composition buffer. Otherwise this blog would have taken me HOURS and HOURS to make.)

Of course, how useful this stuff is outside of a writing-for-the-web context is debatable…

PERSON A: It’s not useful!

PERSON B: Oh, OK.

Well, that was a short debate!

After writing the package to edit WordPress articles in Emacs, I started thinking about doing something about non-text X selections in Emacs.

Emacs has all the required low-level support it needs to be able to yank HTML and images into Emacs, but nobody’s mainstreamed more high-level support into Emacs. Mostly because nobody really knew what it would look like, I think. (And because most Emacsens don’t really blog that much.)

Let’s have a look at what’s available here.

Let’s mark a word in an xterm, and then let’s see what Emacs gets:

(gui-get-selection 'PRIMARY 'TARGETS)
[TIMESTAMP TARGETS MULTIPLE UTF8_STRING
COMPOUND_TEXT TEXT STRING text/plain\;charset=utf-8
text/plain]

and compare when marking a word in Firefox:

(gui-get-selection 'PRIMARY 'TARGETS)
[TIMESTAMP TARGETS MULTIPLE text/html
text/_moz_htmlcontext text/_moz_htmlinfo
UTF8_STRING COMPOUND_TEXT TEXT STRING
text/x-moz-url-priv]

See? When marking words in an xterm, you get at text/plain thing you can yank in Emacs (and that’s what normally happens), but you mark something in Firefox, you get a text/html (among other things) in addition).

The same thing is the case in Chrome, although there you have to say “Copy” first to get the text/html part, and it lands on the CLIPBOARD and not in PRIMARY.

But that should be OK, anyway. Let’s look at the output from the text/html selection from Firefox.

Er, OK, that’s… little-endian utf-16. Er, OK… So that’s a thing?

Let’s look at the selection from Chrome, then:

So that’s a UTF-8 string? With… a nul at the end?

*sigh*

Well, OK, it’s easy enough to recognise one or the other forms, as long as there’s only two. *crosses fingers*

That means that the function for yanking HTML ends up being something like:

(defun ewp-yank-html ()
  "Yank the contents of the current X text/html selection, if any."
  (interactive)
  (let ((data (loop for type in '(PRIMARY CLIPBOARD)
                    for data = (x-get-selection-internal type 'text/html)
                    when data
                    return data)))
    (if (not data)
        (message "No text/html data in the current selection")
      (set-mark (point))
      (insert
       (if (and (> (length data) 2)
                (= (aref data 0) 255)
                (= (aref data 1) 254))
           ;; Somehow the selection is UTF-16 when selecting text in
           ;; Firefox.
           (decode-coding-string data 'utf-16-le)
         ;; But some sources add a nul to the end of the data.
         (decode-coding-string
          (replace-regexp-in-string (string 0) "" data)
          'utf-8))))))

Or should it look at the TIMESTAMP from the selections and then yank the newest one? By testing, it seems to be doing the right thing when not doing that…

Yanking images into buffers works along the same line, but there’s differences between where the images originate, of course. If doing a “Copy image” from Firefox, I can yank them as any format (image/png, image/jpeg), but from Chrome doesn’t support transcoding, so you have to loop a bit to find what the format really is. Or… I could look at the output from `gui-get-selection’? Yes, that seems like a better idea.

Let me try to yank a random image from Google…

Yup, that works. So you end up with something like:

(loop for type in '(PRIMARY CLIPBOARD)
      for st = (loop for st across
                     (gui-get-selection type 'TARGETS)
                     when (equal (car (split-string
                                       (symbol-name st) "/"))
                                 "image")
                     return st)
      when st
      return (x-get-selection-internal type st))

But just yanking an image into Emacs isn’t very useful: You have to be able to do something with it. In an HTML-like mode as this Postpress editing mode makes that kinda easy: Just represent it as an <img> element… and stash the entire image in the src=”data:image/jpeg;base64,FKJDSHJF…” bit. Since I’m showing the image as the `display’ bit on top, having a few megabytes of noise in the buffer doesn’t make any difference.

I was worried that this might somehow slow Emacs down, but nope. Displaying very long lines is something that Emacs doesn’t like, but as long as it’s hidden, it doesn’t seem to make any difference.

And it autosaves nicely, too.

OK, making it that easy to insert images into blog posts perhaps isn’t a good idea, but why should all ideas be good?

Anyway, I think something like this is something that Emacs should have, and I think I’ll pursue that further when I get time to do some more real Emacs work (which probably won’t be until like February).

I was originally pondering whether to offer an interface to a detailed view of the selection/clipboard, so that you can journey into all the different selection types, but after using this stuff for a couple of days, I think I’ve reached the conclusion that the only other two yanking types that makes sense (other than plain text, which we have now) are HTML and images. At least in a WYSIWYG-ish context…

Finally! Emacs is going to catch up with 90s editors! At least on this minor point! Amazing!