Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On 04/20/2014 05:03 PM, Daniel Colascione wrote:
> ------------------------------------------------------------
> revno: 117000
> revision-id: dancol@dancol.org-20140421000344-9mcpbae1prbh1uql
> parent: dancol@dancol.org-20140420232404-fgxzomu1nqu3gi96
> committer: Daniel Colascione <dancol@dancol.org>
> branch nick: trunk
> timestamp: Sun 2014-04-20 17:03:44 -0700
> message:
>   Untabify cl-macs.el

On second thought, I've uncommited this change. It might make it hard to
move changes between emacs-24 and trunk. Let's wait until emacs-24
ships, then untabify everything once.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Eli Zaretskii]

> Date: Sun, 20 Apr 2014 17:28:45 -0700
> From: Daniel Colascione <dancol@dancol.org>
> 
> On 04/20/2014 05:03 PM, Daniel Colascione wrote:
> > ------------------------------------------------------------
> > revno: 117000
> > revision-id: dancol@dancol.org-20140421000344-9mcpbae1prbh1uql
> > parent: dancol@dancol.org-20140420232404-fgxzomu1nqu3gi96
> > committer: Daniel Colascione <dancol@dancol.org>
> > branch nick: trunk
> > timestamp: Sun 2014-04-20 17:03:44 -0700
> > message:
> >   Untabify cl-macs.el
> 
> On second thought, I've uncommited this change. It might make it hard to
> move changes between emacs-24 and trunk. Let's wait until emacs-24
> ships, then untabify everything once.

Why untabify at all?  Using tabs and spaces is the default GNU coding
style, so why should we stray from that?

(It's an uphill battle you'll lose anyway, because many people, yours
truly included, have indent-tabs-mode set non-nil, which will add back
tabs in the portions where changes are made.  So with time, the tabs
creep back again, and it's a maintenance burden to untabify them time
and again.)

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On 04/21/2014 12:10 AM, Eli Zaretskii wrote:
>> Date: Sun, 20 Apr 2014 17:28:45 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>>
>> On 04/20/2014 05:03 PM, Daniel Colascione wrote:
>>> ------------------------------------------------------------
>>> revno: 117000
>>> revision-id: dancol@dancol.org-20140421000344-9mcpbae1prbh1uql
>>> parent: dancol@dancol.org-20140420232404-fgxzomu1nqu3gi96
>>> committer: Daniel Colascione <dancol@dancol.org>
>>> branch nick: trunk
>>> timestamp: Sun 2014-04-20 17:03:44 -0700
>>> message:
>>>   Untabify cl-macs.el
>>
>> On second thought, I've uncommited this change. It might make it hard to
>> move changes between emacs-24 and trunk. Let's wait until emacs-24
>> ships, then untabify everything once.
> 
> Why untabify at all?  Using tabs and spaces is the default GNU coding
> style, so why should we stray from that?

In Lisp code, using tabs makes no sense: code is frequently lined up
precisely, so you get a mixture of tabs and spaces anyway, making it
impossible to use a different tab-width. Why would you want to use tabs
at all?

> (It's an uphill battle you'll lose anyway, because many people, yours
> truly included, have indent-tabs-mode set non-nil,

Don't do that then.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Stephen J. Turnbull]

Daniel Colascione writes:

 > In Lisp code, using tabs makes no sense: code is frequently lined
 > up precisely, so you get a mixture of tabs and spaces anyway,
 > making it impossible to use a different tab-width. Why would you
 > want to use tabs at all?

It's an old (arguably bad) habit dating from the days where it saved
core memory and disk space.  I recall one Lisp for the 8080 whose
lexer removed all nonsyntactic space and compressed syntactic space to
a single SPC when transferring code from the disk read buffer to
program text space.

 > > (It's an uphill battle you'll lose anyway, because many people,
 > > yours truly included, have indent-tabs-mode set non-nil,
 > 
 > Don't do that then.

Emacs Lisp is not Python, more's the pity.  But I digress....  Nobody
is going to change their settings to nil without a pronouncement from
Stefan.  And even that may not work if RMS is non-nil....

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Eli Zaretskii]

> Date: Mon, 21 Apr 2014 00:13:29 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: emacs-devel@gnu.org
> 
> > Why untabify at all?  Using tabs and spaces is the default GNU coding
> > style, so why should we stray from that?
> 
> In Lisp code, using tabs makes no sense: code is frequently lined up
> precisely, so you get a mixture of tabs and spaces anyway, making it
> impossible to use a different tab-width. Why would you want to use tabs
> at all?

Tabs make the file smaller.  But more importantly, as I already said,
this is the Emacs default, always has been.

> > (It's an uphill battle you'll lose anyway, because many people, yours
> > truly included, have indent-tabs-mode set non-nil,
> 
> Don't do that then.

We cannot control what everyone out there does.

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

On 04/21/2014 01:38 AM, Eli Zaretskii wrote:
>> Date: Mon, 21 Apr 2014 00:13:29 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: emacs-devel@gnu.org
>>
>>> Why untabify at all?  Using tabs and spaces is the default GNU coding
>>> style, so why should we stray from that?
>>
>> In Lisp code, using tabs makes no sense: code is frequently lined up
>> precisely, so you get a mixture of tabs and spaces anyway, making it
>> impossible to use a different tab-width. Why would you want to use tabs
>> at all?
> 
> Tabs make the file smaller. 

A minor optimization that doesn't matter in 2014.

> But more importantly, as I already said,
> this is the Emacs default, always has been.

So what? Untabify everything and set dir-locals for Emacs to set
indent-tabs-mode to nil.

>>> (It's an uphill battle you'll lose anyway, because many people, yours
>>> truly included, have indent-tabs-mode set non-nil,
>>
>> Don't do that then.
> 
> We cannot control what everyone out there does.

No, we can only control what code gets into Emacs.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Eli Zaretskii]

> Date: Mon, 21 Apr 2014 01:40:59 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: emacs-devel@gnu.org
> 
> > But more importantly, as I already said,
> > this is the Emacs default, always has been.
> 
> So what? Untabify everything and set dir-locals for Emacs to set
> indent-tabs-mode to nil.

That's just part of the issue.  The other part is applying a patch
that was edited elsewhere, for example.

> >>> (It's an uphill battle you'll lose anyway, because many people, yours
> >>> truly included, have indent-tabs-mode set non-nil,
> >>
> >> Don't do that then.
> > 
> > We cannot control what everyone out there does.
> 
> No, we can only control what code gets into Emacs.

Not really, try looking through the sources to see the real-life mess.

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Juanma Barranquero]

On Mon, Apr 21, 2014 at 10:40 AM, Daniel Colascione <dancol@dancol.org> wrote:

> No, we can only control what code gets into Emacs.

Even so, is not for you alone to decide what goes or doesn't go into
the Emacs repo. This is a long standing issue, and the consensus is,
more or less, that you do what you want with the code you write, and
you try not to change it gratuitously in other code you fix (so, not
(un)?tabifying an entire file just because you commit a fix to it).
Anything else is bound to cause much discussion and grief.

(I prefer untabified code, BTW.)

    J

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Lars Magne Ingebrigtsen]

Daniel Colascione <dancol@dancol.org> writes:

> In Lisp code, using tabs makes no sense: code is frequently lined up
> precisely, so you get a mixture of tabs and spaces anyway, making it
> impossible to use a different tab-width.

Don't use a different tab-width, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Josh]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Mon, Apr 21, 2014 at 12:13 AM, Daniel Colascione <dancol@dancol.org>wrote:

> On 04/21/2014 12:10 AM, Eli Zaretskii wrote:
> > Why untabify at all?  Using tabs and spaces is the default GNU coding
> > style, so why should we stray from that?
>
> In Lisp code, using tabs makes no sense: code is frequently lined up
> precisely, so you get a mixture of tabs and spaces anyway, making it
> impossible to use a different tab-width.


+1, especially since we specify (tab-width . 8) in trunk/.dir-locals.el.

 > (It's an uphill battle you'll lose anyway, because many people, yours
> > truly included, have indent-tabs-mode set non-nil,
>
> Don't do that then.
>

I've sometimes wondered why trunk/.dir-locals.el doesn't also specify
indent-tabs-mode, but I found the rationale in this thread[0] from
several years ago.  Still, it would be nice to find a way to avoid the
battle Eli mentioned so people could C-x h C-M-\ with less risk that
their personal indentation preferences would introduce gratuitous
whitespace changes.

[0] http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00058.html

Josh

[-- Attachment #2: Type: text/html, Size: 2283 bytes --]

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On 04/21/2014 11:17 AM, Josh wrote:
> I've sometimes wondered why trunk/.dir-locals.el doesn't also specify
> indent-tabs-mode, but I found the rationale in this thread[0] from 
> several years ago.  Still, it would be nice to find a way to avoid the
> battle Eli mentioned so people could C-x h C-M-\ with less risk that
> their personal indentation preferences would introduce gratuitous 
> whitespace changes.
> 
> [0] http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00058.html

We could introduce another indent-tabs-mode setting that would tell
Emacs, for each line to be indented, to use tabs if that line is already
indented with tabs, to use spaces if the line is already indented with
spaces when a tab could have been used, and to use spaces (or tabs)
otherwise --- but considering how touchy and particular people have
seemed to be about this issue, I wouldn't expect much support for
anything but the inconsistent status quo.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Stefan Monnier]

> Still, it would be nice to find a way to avoid the
> battle Eli mentioned so people could C-x h C-M-\ with less risk that

It's perfectly fine to change TAB-vs-SPC (in either direction) on a line
that changes for some other reason anyway.

So as long as C-M-\ only changes lines where the indentation is
modified, there's no problem.


        Stefan


PS: But note that C-M-\ will give "wrong" indentation in many Elisp
files, sadly (typically because of lines that start with a single ";"
in column 0), so better not use C-x h C-M-\ either.  Basically, only
touch the code that you touch.

Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el

[Stefan Monnier]

>> Untabify cl-macs.el
> On second thought, I've uncommited this change.

Thanks.

> It might make it hard to move changes between emacs-24 and
> trunk. Let's wait until emacs-24 ships, then untabify everything once.

No, let's refrain from tabifying or untabifying.


        Stefan