Re: Variable-width font indentation: pasting outside Emacs

[Yuri Khan <yuri.v.khan@gmail.com>]

On Wed, Mar 7, 2018 at 1:21 AM, Drew Adams <drew.adams@oracle.com> wrote:

> Could we, for example, (optionally) affect copy or paste
> operations, to automatically try to compensate by inserting
> the (more or less) right number of SPC chars of the
> variable-width font (of the first non-whitespace char on the
> line)?

You mean changing the number of spaces used as indentation, depending
on what font the receiving application uses?

> People communicate about code and other text in more and more
> ways, many of which are and will remain outside Emacs.  Can we
> try to DTRT for variable-width text, so that the result of
> pasting into another app gives indentation and alignment that
> at least approximates what one would want/expect?  If so,
> should we try to do that?

Oh please don’t.

Why? Because the widget where the text is going to be pasted from
Emacs is not the widget that will ultimately display the text.

How is that? Imagine a chat application such as Mattermost. Its UI is
a web page with a text input widget on the bottom. That widget
normally uses a variable width font, and accepts Markdown syntax. The
user will normally type three grave accent characters ``` and a hard
newline, then paste a snippet of code from clipboard, then close with
another ```. On the server, Markdown will be interpreted and the
recipient will receive a syntax-highlighted, fixed-width-formatted
fragment of code.

With your suggestion, that fragment will have the wrong amount of
indentation. (Where “wrong” denotes “other than the sender intended or
expected”.)


Relatedly, I have worked with several applications that support
copying and pasting HTML markup. In their striving to make the result
“intuitive”, they introduce abominations on the receiving side.

Example: You are reading a web page. You copy a fragment of text. The
source page is styled with CSS that specifies a blue-black foreground
color and a fancy font for the body text. When you paste that into a
blog post, the receiving widget attempts to preserve that color. But,
since the body text style of the target article specifies dark gray
foreground color and a different fancy font, it applies direct
formatting to the pasted text: <span style="color: rgb(0,51,102);
font-family: Proxima Nova, …">Lorem ipsum…</span>.

Now the post text is tainted. It will appear in blue-black and in
Proxima Nova for every viewer, regardless of their preferred color
scheme and font. A user who prefers green text on a dark gray
background will break his/her eyes trying to read that.

Copying and pasting WYSIWYG formatting: Just say no. Doing things
behind the user’s back on copy/paste: Just say no.