From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.bugs Subject: bug#21492: 25.0.50: Make untabify work nicely with write-file-functions Date: Wed, 16 Sep 2015 08:55:54 -0400 Message-ID: References: <2ufv2edb68.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e014954acad34b2051fdcd111 X-Trace: ger.gmane.org 1442408185 15427 80.91.229.3 (16 Sep 2015 12:56:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 12:56:25 +0000 (UTC) Cc: 21492@debbugs.gnu.org, warren ferguson To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 16 14:56:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ZcCFy-0003FM-HE for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Sep 2015 14:56:14 +0200 Original-Received: from localhost ([::1]:50552 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCFx-0000ww-Ra for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Sep 2015 08:56:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCFt-0000wS-5c for bug-gnu-emacs@gnu.org; Wed, 16 Sep 2015 08:56:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcCFn-0008Hb-1J for bug-gnu-emacs@gnu.org; Wed, 16 Sep 2015 08:56:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCFm-0008HV-UE for bug-gnu-emacs@gnu.org; Wed, 16 Sep 2015 08:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZcCFm-0003za-DG for bug-gnu-emacs@gnu.org; Wed, 16 Sep 2015 08:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kaushal Modi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2015 12:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21492 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21492-submit@debbugs.gnu.org id=B21492.144240815915334 (code B ref 21492); Wed, 16 Sep 2015 12:56:02 +0000 Original-Received: (at 21492) by debbugs.gnu.org; 16 Sep 2015 12:55:59 +0000 Original-Received: from localhost ([127.0.0.1]:34267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcCFi-0003zF-Be for submit@debbugs.gnu.org; Wed, 16 Sep 2015 08:55:59 -0400 Original-Received: from mail-oi0-f51.google.com ([209.85.218.51]:33198) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcCFf-0003z4-KP for 21492@debbugs.gnu.org; Wed, 16 Sep 2015 08:55:56 -0400 Original-Received: by oixx17 with SMTP id x17so124744918oix.0 for <21492@debbugs.gnu.org>; Wed, 16 Sep 2015 05:55:54 -0700 (PDT) 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=wYWSs9gnGNXkoMpibOi1n/F4hCBpgzJZMIyMlZv0Z/o=; b=Mo+4HdOpfF+DJVsHSdixjdE7y/0EWKjPKLscVixdCQ41F8YV0T2ab8ymtJd5xEP16i vZ9IAPxvnLS2DO6YW9kXrrNhf9IRW3w+6zvy8McRgvEINARS8vN3NpOKGFR+5MksW6GM ajfI0y450+1Mn4khhOOf9N4XDn41X5Gd5PkThQQHuxa9QCM1vjfRN35drjmDkDOuKolC iZ7F0CXtii26OWmKYudcda/8oa1XDSs0CYUeCEqblM83q6kdOxn2sp/QC0AvMBffdRuR w1BiyAAcEuPv4EukH/YJpCNc+KKZ/KPN3RLAu8RF/IAPhdYTYrpG9JoihvP8e6zdJQcE kGMA== X-Received: by 10.182.105.231 with SMTP id gp7mr23378764obb.81.1442408154594; Wed, 16 Sep 2015 05:55:54 -0700 (PDT) Original-Received: by 10.202.172.205 with HTTP; Wed, 16 Sep 2015 05:55:54 -0700 (PDT) Original-Received: by 10.202.172.205 with HTTP; Wed, 16 Sep 2015 05:55:54 -0700 (PDT) In-Reply-To: <2ufv2edb68.fsf@fencepost.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106640 Archived-At: --089e014954acad34b2051fdcd111 Content-Type: text/plain; charset=UTF-8 > which not consulting the return value indicates I reviewed the code of untabify and it is not designed to return any value, so setting the return value to nil does not hurt. > Eg hope you like silently breaking every makefile you ever edit I agree. The user needs to use their due diligence when they add untabify to write-file-functions. They need to know how and when the hooks work and the exact outcomes of the functions they add to the hooks. So I do NOT add untabify to this hook globally. > and irritating any other users of a shared VCS with whitespace changes. - I am using Verilog code almost 95% of the time. For that, tabs don't serve any special intent as in the Makefiles (also, in my career, I have come across Makefile as the only "language" that needs tabs). - The version control system we use does not care about white space diffs. - Other team mates would unknowingly use tabs instead of spaces (they wouldn't have cared if they used tabs or spaces or knew what difference that makes). But that caused a lot of visual indentation annoyances and trouble using stuff like multiple cursors. If you have a column of contiguous white space stretching multiple lines, with some lines having spaces and some having tabs, you won't be able to get a straight column of multiple cursors through that. So in the end, adding untabify locally only for verilog-mode-hook was a transparent action.. No one realized that untabification was happening and I also got to improve my coding experience. That said, if making untabify returning nil does not break its functionality when using alone or in correspondence with other functions, is there any opposition to this commit. As for the "issue" of vcs white space pollution, the user simply should not add this function to the hook if they care about the whitespace pollution. -- Kaushal Modi On Sep 16, 2015 4:24 AM, "Glenn Morris" wrote: > Kaushal Modi wrote: > > > I personally have dealt with the issue where I cannot add untabify > directly > > to write-file-functions hook, because untabify does not return nil. > > > > I need some sort of custom wrapper that runs untabify and then returns > nil. > > I'm pretty sure this has come up before. > IMO it's a feature. :) > Simply adding untabify to write-file-functions without thinking about it > (which not consulting the return value indicates) is a recipe for trouble. > Eg hope you like silently breaking every makefile you ever edit, > and irritating any other users of a shared VCS with whitespace changes. > --089e014954acad34b2051fdcd111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> which not consulting the return value indicates

I reviewed the code of untabify and it is not designed to re= turn any value, so setting the return value to nil does not hurt.

> Eg hope you like silently breaking every makefile you e= ver edit

I agree. The user needs to use their due diligence when they= add untabify to write-file-functions. They need to know how and when the h= ooks work and the exact outcomes of the functions they add to the hooks. So= I do NOT add untabify to this hook globally.

> and irritating any other users of a shared VCS with whi= tespace changes.

- I am using Verilog code almost 95% of the time. For that, = tabs don't serve any special intent as in the Makefiles (also, in my ca= reer, I have come across Makefile as the only "language" that nee= ds tabs).
- The version control system we use does not care about white space diffs. =
- Other team mates would unknowingly use tabs instead of spaces (they would= n't have cared if they used tabs or spaces or knew what difference that= makes). But that caused a lot of visual indentation annoyances and trouble= using stuff like multiple cursors. If you have a column of contiguous whit= e space stretching multiple lines, with some lines having spaces and some h= aving tabs, you won't be able to get a straight column of multiple curs= ors through that.

So in the end, adding untabify locally only for verilog-mode= -hook was a transparent action.. No one realized that untabification was ha= ppening and I also got to improve my coding experience.

That said, if making untabify returning nil does not break i= ts functionality when using alone or in correspondence with other functions= , is there any opposition to this commit.

As for the "issue" of vcs white space pollution, t= he user simply should not add this function to the hook if they care about = the whitespace pollution.

--
Kaushal Modi

On Sep 16, 2015 4:24 AM, "Glenn Morris"= ; <rgm@gnu.org> wrote:
Kaushal Modi wrote:

> I personally have dealt with the issue where I cannot add untabify dir= ectly
> to write-file-functions hook, because untabify does not return nil. >
> I need some sort of custom wrapper that runs untabify and then returns= nil.

I'm pretty sure this has come up before.
IMO it's a feature. :)
Simply adding untabify to write-file-functions without thinking about it (which not consulting the return value indicates) is a recipe for trouble.<= br> Eg hope you like silently breaking every makefile you ever edit,
and irritating any other users of a shared VCS with whitespace changes.
--089e014954acad34b2051fdcd111--