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 14:15:06 -0800 (PST) Message-ID: <3b3217d9-de2f-4bba-a513-d2f6e714ecbf@default> 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 1520374446 29918 195.159.176.226 (6 Mar 2018 22:14:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2018 22:14:06 +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 23:14:01 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 1etKqI-0006Dl-Pz for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 23:13:55 +0100 Original-Received: from localhost ([::1]:58618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etKsL-0000Kk-Cw for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 17:16:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etKrj-0000KK-T3 for emacs-devel@gnu.org; Tue, 06 Mar 2018 17:15:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etKre-0002eV-5F for emacs-devel@gnu.org; Tue, 06 Mar 2018 17:15:23 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:49998) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1etKrd-0002du-UE for emacs-devel@gnu.org; Tue, 06 Mar 2018 17:15:18 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w26MBdQT033154; Tue, 6 Mar 2018 22:15:09 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=5bUIzc6/PuOTrCaThXhQXhd+EVqUZkw7brlu27rBdP0=; b=gAS8JU8Jn5UkPXUE+2Im8UG8msOwD8ItHI0ksdiyW+dBPPdMl3l81XrDO9FJOGKuZrvC FwLWNAn+zdoZ7re8S7j+c6/MyEisKDPemxHS25ohfzQf6VJOxKG0Qh9CvVv4w5J3sSO0 a3M2QkDeEPH45CqbWhWvzfKlFGva77nELAOIUdjPK5OczsjufLGnEXXjEZY3iVV9Grof 6wtvoa9QUUPx3tNfEsMFvVyF+0gJUte5iY1K9TswHb61yUFrtU28NWc/WaZ5K/rexL0z GfMAx7qYFLXNzkPPOZEPryxVOJQ7nkdVBmelIEN/MLjOYsa4OIvsQTJ1jism67fEvcB5 bw== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2gj38h033w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Mar 2018 22:15:09 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w26MF8EQ012973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Mar 2018 22:15:08 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w26MF7XA022815; Tue, 6 Mar 2018 22:15:07 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=855 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803060238 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:223391 Archived-At: Maybe this will clarify my raising of this pasting question: Today, I copy some code from a Lisp file included in Emacs, or from an Info node. Then I modify it, add to it, subtract from it, etc., to come up with something I think might help answer a user question on some web site. It happens sometimes that the code I copied uses tab chars for indentation. I use a nil value of `indent-tabs-mode' for my own use, but the copied code introduces some tab chars (alas). I also use a fixed-width font where I'm working on the copied code. Depending on the particular context where I might end up pasting (outside Emacs) my code that now includes some tab chars, the result might mess up indentation because the paste context handles tab chars differently. This is so even in the common case where the destination expects code and a fixed-width font and handles such input well. So today, I'm in the habit of first using `untabify' to convert such tab chars to SPC. End of story - great and easy solution. In effect, I performed a simple operation before copying. I could just as well have used a custom command that copied the text after converting (perhaps a copy of) it by replacing the tab chars. Without the simple `untabify' function that Emacs provides, or something similar (e.g. `query-replace'), I might have pasted the text with tab chars into the destination, and then have had to manually clean it up using the inferior editor of the destination context. Ugh. Tab chars are, in effect, variable-width text. What we do now to handle tab chars across different environments can perhaps give us some idea of the problem, and perhaps of possible solutions, about variable-width text in general. When using a variable-width font, SPC as well as tab chars have variable width. Other chars do too, of course, but SPC and tab chars are typically used for indentation and alignment. Do we have such a simple solution, analogous to using `untabify' before pasting, for a case where copied code (or other text) is variable-width? And where perhaps the paste destination also handles variable-width text? Should we? If we don't, how much trouble will users have to go through to work around the problem or clean up when they see crazy results from pasting? That's the question I'm suggesting we think about. And this context is likely more complex, as there are different kinds of destinations, which may handle variable-width text differently. IOW, there may not be a single, simple, one-size-fits-all `untabify' analog. We might need more than one approach. Yes, it is the user who knows the destination (better than Emacs knows it, at least). It is the user whom I would want to be able to choose how to handle it. How we can best respond to this question/problem, I don't know. I was only asking that we take it into account while designing an improved-variable-text-indentation-&-alignment approach for use inside Emacs. It's not just about how things look in Emacs. Text copied from Emacs sometimes gets pasted outside Emacs. Let's think about that too; that's all.