[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] TTY Support for ECMA-48 strike-through graphic rendition
From: |
Robert Pluim |
Subject: |
Re: [PATCH] TTY Support for ECMA-48 strike-through graphic rendition |
Date: |
Wed, 12 Aug 2020 18:19:51 +0200 |
>>>>> On Wed, 12 Aug 2020 17:23:38 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Mike Hamrick <mikeh@muppetlabs.com>, emacs-devel@gnu.org
>> Date: Wed, 12 Aug 2020 11:36:29 +0200
>>
>> >>>>> On Tue, 11 Aug 2020 22:17:08 +0300, Eli Zaretskii <eliz@gnu.org>
said:
>>
Eli> Please use our style of indentation in C source files (basically, make
Eli> sure indent-tabs-mode is non-nil).
>>
>> That is not reflected in our .dir-locals.el for C files (for elisp it
>> sets indent-tabs-mode to nil)
Eli> Because it's the default, I believe. Also because we couldn't agree
Eli> on a mandatory setting at the time this setting in .dir-locals.el was
Eli> discussed.
The same is true for tab-width, sentence-end-double-space and
fill-column, yet we set those.
>> I thought it was 'you can use tabs or spaces, but try match the usage
>> of existing code when making changes' (which since Iʼm pro-space means
>> that when making additions or when the lines Iʼm changing have a mix,
>> I use spaces).
Eli> That would also indicate that the change in question should have used
Eli> mixed TABs and SPACEs.
I was unclear: I meant if there was a mix of lines with TAB + SPACEs
and lines with SPACEs only, I tend to normalize towards SPACEs.
Itʼs a constant battle between "try to match the surrounding style"
and "my indentation prejudices are *right*, dammit" :-)
Anyway, I have no wish to reignite a TABs vs SPACEs
discussion. Perhaps Iʼll just stick to elisp, where SPACEs rule.
Robert