From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Le Wang Newsgroups: gmane.emacs.devel Subject: Re: Electric indentation sub-optimality and resolution Date: Sat, 20 Dec 2014 19:36:35 -0500 Message-ID: References: <87wq5ovmbb.fsf@wanadoo.es> <86388chgci.fsf@yandex.ru> <87oar0v431.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d0444808f5954c2050aaf22ac X-Trace: ger.gmane.org 1419122209 19933 80.91.229.3 (21 Dec 2014 00:36:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Dec 2014 00:36:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 21 01:36:44 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y2UVo-0000fW-4L for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2014 01:36:44 +0100 Original-Received: from localhost ([::1]:36155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2UVn-00009p-76 for ged-emacs-devel@m.gmane.org; Sat, 20 Dec 2014 19:36:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2UVi-00009g-Ao for emacs-devel@gnu.org; Sat, 20 Dec 2014 19:36:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2UVh-0007Lf-0m for emacs-devel@gnu.org; Sat, 20 Dec 2014 19:36:38 -0500 Original-Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:42270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2UVg-0007LI-Ki for emacs-devel@gnu.org; Sat, 20 Dec 2014 19:36:36 -0500 Original-Received: by mail-wg0-f47.google.com with SMTP id n12so4107382wgh.6 for ; Sat, 20 Dec 2014 16:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pSb2Jo4s49/waMvDrf9mNpsgxv8RQpjl7otUVqf93gA=; b=rCIncP3nDdUfs5t5HBFhAHuJeKkCBeWZlrUec9N/nRGLs5f+AnNlHe0kJOUh8syFsW 9b4trcPMIsoZv1dB5CRJFktnZgY5M7bLoktnFGvb7pxslXeghMreXb3aKFY8Fs+YL0Xs 8Mb3pzONHW9OYMZcR97hbGlDhFlVuK20rY6JA+TJzkNb17FncCfripUl1e2nl4OanAkx UMCXKa5o9pYzXXiYvBq/wa4H+v8Q7+1safgt8EJrW+aFI8ZhSco9q4GxwJZuRXRTS9Wk K3NLk4Gky2aX9FEi3UGqzYSZ1WjvJkPW2fIO9P3xYPiPWesxwnga7zv9OZO4e7m/KCGw xBRA== X-Received: by 10.180.96.67 with SMTP id dq3mr18685074wib.51.1419122195385; Sat, 20 Dec 2014 16:36:35 -0800 (PST) Original-Received: by 10.217.45.2 with HTTP; Sat, 20 Dec 2014 16:36:35 -0800 (PST) In-Reply-To: <87oar0v431.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180411 Archived-At: --f46d0444808f5954c2050aaf22ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 18, 2014 at 8:08 PM, =C3=93scar Fuentes wrote: > > > I actually really like the behavior of the code I posted. It has an > added > > small bonus. Normally it does not cleanup pre-existing whitespace. > When I > > modify a line with trailing whitespace it does cleanup that one line, > > something my projects' guidelines allow. > If you work on large projects with a mishmash of participants, this feature is essential. It's really distracting from the actual work to always have your diffs show unrelated edits. That's what ws-butler does. > Indeed. OTOH, your code is ok for adding it to the user's personal .emacs, but > not for incorporation into Emacs. The code should be made into a minor > mode or an optional feature of electric-indent-mode. Creating a new > minor mode makes more sense, IMO. > "ws-trim" also takes the post-command-hook approach, and it's a full minor-mode. I found this more active whitespace cleanup distracting. For example, if I page-up to read some contextual code and page-down, my indentation is gone if I was on a blank line. > Anyways, we need to hear the opinion of the author of ws-butler package. > AFAIK he tried a similar approach to yours and found problems with it. > Let's get some historical context by reading this thread: https://lists.gnu.org/archive/html/emacs-devel/2003-02/msg00018.html ws-trim was proposed there, and apparently it didn't go forward. ws-butler was made as a quick experiment to see if less obtrusive whitespace management was possible by reusing the highlight-changes-mode mechanisms. If, it was to be included in Emacs, maybe the feature should be rewritten to independent of highlight-changes-mode. As it stands, one glaring deficiency is that you cannot use highlight-changes-mode when using ws-butler-mode. --=20 Le --f46d0444808f5954c2050aaf22ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 18, 2014 at 8:08 PM, =C3=93scar Fuentes <ofv@wanadoo.es> wrote:
> I actually really like the b= ehavior of the code I posted.=C2=A0 It has an added
> small bonus.=C2=A0 Normally it does not cleanup pre-existing whitespac= e.=C2=A0 When I
> modify a line with trailing whitespace it does cleanup that one line,<= br> > something my projects' guidelines allow.

If you work on large projects with a mishmash of particip= ants, this feature is essential.=C2=A0 It's really distracting from the= actual work to always have your diffs show unrelated edits.

=
That's what ws-butler does.

Indeed. =C2=A0=C2=A0

OTOH, your code is ok for adding it to the user's personal .emacs, but<= br> not for incorporation into Emacs. The code should be made into a minor
mode or an optional feature of electric-indent-mode. Creating a new
minor mode makes more sense, IMO.

"= ;ws-trim" also takes the post-command-hook approach, and it's a fu= ll minor-mode.=C2=A0 I found this more active whitespace cleanup distractin= g.=C2=A0 For example, if I page-up to read some contextual code and page-do= wn, my indentation is gone if I was on a blank line.
=C2=A0
=
Anyways, we need to hear the opinion of the author of ws-butler package. AFAIK he tried a similar approach to yours and found problems with it.
<= /blockquote>

Let's get some historical context by re= ading this thread: https://lists.gnu.org/archive/html/emacs-devel/200= 3-02/msg00018.html

ws-trim was proposed there,= and apparently it didn't go forward.

ws-butle= r was made as a quick experiment to see if less obtrusive whitespace manage= ment was possible by reusing the highlight-changes-mode mechanisms.=C2=A0 I= f, it was to be included in Emacs, maybe the feature should be rewritten to= independent of highlight-changes-mode.=C2=A0 As it stands, one glaring def= iciency is that =C2=A0you cannot use highlight-changes-mode when using ws-b= utler-mode.



=C2=A0


--
Le
--f46d0444808f5954c2050aaf22ac--