all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
       [not found] <E1Wc1iD-0005Z5-Tb@vcs.savannah.gnu.org>
@ 2014-04-21  0:28 ` Daniel Colascione
  2014-04-21  7:10   ` Eli Zaretskii
  2014-04-21 12:49   ` Stefan Monnier
  0 siblings, 2 replies; 13+ messages in thread
From: Daniel Colascione @ 2014-04-21  0:28 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  0:28 ` [Emacs-diffs] trunk r117000: Untabify cl-macs.el Daniel Colascione
@ 2014-04-21  7:10   ` Eli Zaretskii
  2014-04-21  7:13     ` Daniel Colascione
  2014-04-21 12:49   ` Stefan Monnier
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2014-04-21  7:10 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

> 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.)



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  7:10   ` Eli Zaretskii
@ 2014-04-21  7:13     ` Daniel Colascione
  2014-04-21  8:03       ` Stephen J. Turnbull
                         ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Daniel Colascione @ 2014-04-21  7:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  7:13     ` Daniel Colascione
@ 2014-04-21  8:03       ` Stephen J. Turnbull
  2014-04-21  8:38       ` Eli Zaretskii
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Stephen J. Turnbull @ 2014-04-21  8:03 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Eli Zaretskii, emacs-devel

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....






^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  7:13     ` Daniel Colascione
  2014-04-21  8:03       ` Stephen J. Turnbull
@ 2014-04-21  8:38       ` Eli Zaretskii
  2014-04-21  8:40         ` Daniel Colascione
  2014-04-21 16:28       ` Lars Magne Ingebrigtsen
  2014-04-21 18:17       ` Josh
  3 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2014-04-21  8:38 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  8:38       ` Eli Zaretskii
@ 2014-04-21  8:40         ` Daniel Colascione
  2014-04-21  8:48           ` Eli Zaretskii
  2014-04-21 12:03           ` Juanma Barranquero
  0 siblings, 2 replies; 13+ messages in thread
From: Daniel Colascione @ 2014-04-21  8:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  8:40         ` Daniel Colascione
@ 2014-04-21  8:48           ` Eli Zaretskii
  2014-04-21 12:03           ` Juanma Barranquero
  1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2014-04-21  8:48 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  8:40         ` Daniel Colascione
  2014-04-21  8:48           ` Eli Zaretskii
@ 2014-04-21 12:03           ` Juanma Barranquero
  1 sibling, 0 replies; 13+ messages in thread
From: Juanma Barranquero @ 2014-04-21 12:03 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Eli Zaretskii, Emacs developers

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  0:28 ` [Emacs-diffs] trunk r117000: Untabify cl-macs.el Daniel Colascione
  2014-04-21  7:10   ` Eli Zaretskii
@ 2014-04-21 12:49   ` Stefan Monnier
  1 sibling, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2014-04-21 12:49 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

>> 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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  7:13     ` Daniel Colascione
  2014-04-21  8:03       ` Stephen J. Turnbull
  2014-04-21  8:38       ` Eli Zaretskii
@ 2014-04-21 16:28       ` Lars Magne Ingebrigtsen
  2014-04-21 18:17       ` Josh
  3 siblings, 0 replies; 13+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-04-21 16:28 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Eli Zaretskii, emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21  7:13     ` Daniel Colascione
                         ` (2 preceding siblings ...)
  2014-04-21 16:28       ` Lars Magne Ingebrigtsen
@ 2014-04-21 18:17       ` Josh
  2014-04-21 18:22         ` Daniel Colascione
  2014-04-21 21:27         ` Stefan Monnier
  3 siblings, 2 replies; 13+ messages in thread
From: Josh @ 2014-04-21 18:17 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Eli Zaretskii, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21 18:17       ` Josh
@ 2014-04-21 18:22         ` Daniel Colascione
  2014-04-21 21:27         ` Stefan Monnier
  1 sibling, 0 replies; 13+ messages in thread
From: Daniel Colascione @ 2014-04-21 18:22 UTC (permalink / raw)
  To: Josh; +Cc: Eli Zaretskii, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Emacs-diffs] trunk r117000: Untabify cl-macs.el
  2014-04-21 18:17       ` Josh
  2014-04-21 18:22         ` Daniel Colascione
@ 2014-04-21 21:27         ` Stefan Monnier
  1 sibling, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2014-04-21 21:27 UTC (permalink / raw)
  To: Josh; +Cc: Eli Zaretskii, Daniel Colascione, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2014-04-21 21:27 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E1Wc1iD-0005Z5-Tb@vcs.savannah.gnu.org>
2014-04-21  0:28 ` [Emacs-diffs] trunk r117000: Untabify cl-macs.el Daniel Colascione
2014-04-21  7:10   ` Eli Zaretskii
2014-04-21  7:13     ` Daniel Colascione
2014-04-21  8:03       ` Stephen J. Turnbull
2014-04-21  8:38       ` Eli Zaretskii
2014-04-21  8:40         ` Daniel Colascione
2014-04-21  8:48           ` Eli Zaretskii
2014-04-21 12:03           ` Juanma Barranquero
2014-04-21 16:28       ` Lars Magne Ingebrigtsen
2014-04-21 18:17       ` Josh
2014-04-21 18:22         ` Daniel Colascione
2014-04-21 21:27         ` Stefan Monnier
2014-04-21 12:49   ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.