From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Variable-width font indentation: pasting outside Emacs Date: Tue, 6 Mar 2018 11:52:00 -0800 (PST) Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1520365833 16378 195.159.176.226 (6 Mar 2018 19:50:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2018 19:50:33 +0000 (UTC) Cc: =?utf-8?B?Q2zDqW1lbnQgUGl0LUNsYXVkZWw=?= , Paul Eggert , Emacs developers To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 06 20:50:29 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etIbM-0002gO-Pq for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 20:50:21 +0100 Original-Received: from localhost ([::1]:57822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etIdP-00020l-IY for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 14:52:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etIdD-0001xv-2B for emacs-devel@gnu.org; Tue, 06 Mar 2018 14:52:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etId9-0004Se-U3 for emacs-devel@gnu.org; Tue, 06 Mar 2018 14:52:15 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:48196) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1etId9-0004S1-Ks for emacs-devel@gnu.org; Tue, 06 Mar 2018 14:52:11 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w26JlT2D053590; Tue, 6 Mar 2018 19:52:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=Z+YC9fobQgkXU9lS24tPrEpGIfGz7T62AUiogiMsukk=; b=FTkT2AysPkASj2pFT/fjLij2rdDBgr5j/iKbbTIuzrEpfTodpgYQKNwBzi9yIWKj+iDL cIaevCxUu/8/YnQV7SHWkvLKmYcPMcrHTDJCRVkLEGrFB8WvBumZV72ugW8IiWKBU2FV +NiVKm9+v+Gpa/GthfmmWoCoUK57xF0ieU7mk3ORwMgtJrAGDKw3t/B/635WnEzefEj8 9crguaSx+NjahKAipReCv5zQZeTXSXc93gjLBeGhGqg+rdlgAUc+kw5ZXsJJRTNdFcdC N4dh7pSatV+foP1vMg8b4wls4Zmq1ot9/vL6zyWb3EjJnwI1VJgU03mME9Gjkus2vf9u UQ== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2gj1f1r0qr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Mar 2018 19:52:03 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w26Jq2mw002140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Mar 2018 19:52:02 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w26Jq1VR017514; Tue, 6 Mar 2018 19:52:02 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4654.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8824 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=983 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803060213 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223361 Archived-At: > > 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)? >=20 > 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? >=20 > Oh please don=E2=80=99t. >=20 > Why? Because the widget where the text is going to be pasted from > Emacs is not the widget that will ultimately display the text. >=20 > 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. >=20 > With your suggestion, that fragment will have the wrong amount of > indentation. (Where =E2=80=9Cwrong=E2=80=9D denotes =E2=80=9Cother than t= he sender intended or > expected=E2=80=9D.) 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 > =E2=80=9Cintuitive=E2=80=9D, 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: font-family: Proxima Nova, =E2=80=A6">Lorem ipsum=E2=80=A6. >=20 > 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=E2=80=99s 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.