emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]