RE: Variable-width font indentation: pasting outside Emacs

[Drew Adams]

> > 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?

Perhaps.  If the design chosen for solving this inside Emacs were
just to add lots of variable-width SPC chars, and if that were
totally inappropriate in some paste context (fixed-width, for
example), a user should be able to copy the text in a way that
pasting it didn't produce something awful.  I said "optionally".
(And I'm not supposing that that would be the design choice for
Emacs.)

But _I'm not proposing_ any design or implementation.  I just
wanted to mention that we might want to think ahead to the fact
that users will want to paste text, including code, into other
apps.  Knowing that fact might affect decisions for how we deal
with the indentation and alignment inside Emacs.

> > 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”.)

I didn't suggest any such thing.  You've gone off half-cocked.
Try reading what I wrote again, please.

There are any number of different paste contexts.  Clearly it is
the _user_ who should be able to control what the paste operation,
which really means the Emacs copy operation, does.

Obviously, if an HTML text input box accepts input that is then
displayed in some particular way (using a markup convention or
whatever), the user is the one to know about that and choose the
right kind of copy from Emacs.  Emacs itself cannot know about
the paste context.  But the user can, if anyone can.

If Emacs doesn't offer a user any control over this then the
result will mostly be bad, not good, I'm afraid.  One size does
not fit all.

> 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.

I didn't suggest trying to make the result intuitive or automatic.
Just the opposite.

Here are two limited/bad approaches, neither of which I'd like to
see: (1) do something in Emacs that makes display great but makes
copy+paste to other apps awful, and (2) do something in Emacs that
tries to provide a one-size-fits-all "intuitive" guess about what
the paste needs might be.

We can imagine other problematic designs, when it comes to their
effect on pasting.  If _all_ indentation is realized in Emacs
only by, say, a `display' property, what will that give when the
text is pasted somewhere?  There are any number of designs that
might have negative consequences for pasting.  Let's keep pasting
in the back of the mind when thinking about designing display of
indentation and alignment in Emacs.  That's all I wanted to say.

Only the user will know (might know) what is needed wrt pasting.
The question I'm raising is whether we can give users some control
over that.

And even if it's decided that we cannot or should not try, I expect
that ignoring the fact that people will paste copied text may lead
to a pretty indentation and alignment display inside Emacs but may
make pasting outside it problematic.  Users will then need to do a
fair amount of manual whitespace cleanup after pasting, and such
cleanup is a bother in most contexts outside Emacs.

I'm contrasting that with the case we have today with fixed-width
fonts and using only SPC (not tab chars) for indentation.  Piece
of cake, in general.

If we don't offer some control over this then providing pretty
display inside Emacs may make pasting outside Emacs so bad that
some users will just stick with fixed-width fonts.  (I may be one
of them.)

> 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.

You have misread me completely, I'm afraid.  I am 100% against
doing any such thing, especially behind the user's back.

Ignoring the paste problem (like ignoring the serialization problem,
which is similar) won't help Emacs find the right design for solving
the problem of displaying text with proper indentation and alignment.