Re: "Why is emacs so square?"

[Tomas Hlavaty <tom@logand.com>]

Richard Stallman <rms@gnu.org> writes:
> When I write a pamphlet using Libre Office, I need to see how it
> will appear on the page.  I need to see where line breaks and paragraph
> breaks appear.
>
> I want Emacs to be able to do tect processing that way.

What are the missing pieces?

I think there are many and they would be useful for other use-cases.

Some of the use-cases I am interested in:

1) Sometimes, I need to write a letter which does not need to be an art
   work.  I wrote emacs-pdf (see
   <https://logand.com/sw/emacs-pdf/file/emacs-pdf.el.html>) to address
   that.

   It creates a PDF document from an Emacs buffer.  Only plain,
   monospace ASCII text works so far, but it can already break and count
   pages and insert headers and footers.  It is very short (about 400
   lines of elisp including comments) and requires no dependencies and
   no graphics.

   a) The next step will be unicode.

      It seems that there is some code in Emacs dealing with unicode
      fonts in order to generate postscript files.  Any pointers where
      to start with this?
  
   b) After that, emacs-pdf will understand font metrics so it will be
      possible to do layout.

      It should be possible to render HTML for example, and create
      graphical web browser as an alternative to eww.

      It should also be possible to render other formats like abw, odt,
      etc.  At least roughly, depending on how much detail in the
      corresponding spec people want to address.  I have explored simple
      conversion to text in pure elisp in emacs-unoffice
      <https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html>.

      It should be possible to write a direct PDF backend for org-mode
      and maybe enriched-mode.

      Internally, probably some kind of html like sexp based format
      should be used.  I used a sexp based format in emacs-pdf
      (transient cons tree representation) but for document processing,
      the format should not be so low level (e.g. no PDF drawing
      primitives but something like HTML primitives; or maybe mixed).

   c) It should not be difficult to add raster images and vector
      graphics to the PDF drawing code.

   d) It should be possible to add for example SVG backend.  Non-console
      Emacs can already draw SVG.  At least at the beginning, this would
      also avoid the need for image rasterisation if vector format like
      PDF or SVG is used.

      Maybe this could be used for real-time preview, before we get
      WYSIWYG.  Or maybe use pdf-tools to view the generated PDF.

2) Printing is an issue in Emacs.  I will try to implement an
   alternative which will use IPP and PDF.  No PostScript, no CUPS, if
   possible no complex configuration.

3) I use Emacs on the console a lot.  All the above should work there
   too.  In order to view images in console Emacs, I wrote
   <https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html>.
   So far there are a few functions that draw images using w3mimgdisplay
   from the w3m console web browser.  It fits images on the screen,
   unlike graphical Emacs where image display is unuseable.

   a) I would like image-mode just work with this emacs-framebuffer
      image drawing.  Any ideas, how to plug emacs-framebuffer into
      image-mode?

   b) It is a shame, that I need to reimplement such basic functions
      like image-size:

      (image-size (create-image "/tmp/a.jpg"))
      => (error "Window system frame should be used")

      framebuffer-image-size at
      https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html#l95
      does not require any dependencies and computes image size for png,
      jpeg, bmp, gif, tiff and pnm in elisp.

      It would be nice to eliminate or at least reduce the need for such
      dependencies so that many Emacs features are useable in different
      environments, like for example console.

   c) There are functions frame-width and frame-height.  Are there also
      functions something like buffer-width and buffer-height and or a
      way to compute x and y position relative to frame origin, which
      would allow me to position images exactly in the buffer similar to
      what w3m browser does?

4) Emacs is missing some kind of canvas, where things could be drawn and
   which would handle pixel precise input.

   For example, I would like to browse OpenStreetMap in Emacs.  I wrote
   a console based OSM browser osmq
   <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
   <https://osmq.eu/>.  I would prefer an Emacs based map browser.
   However, I have not figured out how to lay out images in Emacs in a
   grid and how to detect which image was clicked.  A bonus would be,
   where exactly was clicked.  Any ideas what should I look into?

   Emacs canvas should probably work like HTML canvas, which is rather
   similar to PDF or PostScript in terms of drawing interface.  I have
   explored this space in the PostScript interpreter in JavaScript
   <https://logand.com/sw/wps/index.html>.

   Not sure how difficult it would be to plug some kind of portable
   canvas into Emacs.  This seems rather low level C work.

It seems to me that these points are precondition for a WYSIWYG document
editor feature in Emacs.

Do these points resonate here?

Is somebody already implementing anything mentioned?

Or what is already implemented?

Would there be an interest in incorporating emacs-pdf, emacs-unoffice
and emacs-framebuffer (the framebuffer-image-size function?) into Emacs?

Regards,

Tomas