[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting tabs for indentation, spaces for alignment

From: Ergus
Subject: Re: Supporting tabs for indentation, spaces for alignment
Date: Sat, 13 Apr 2019 17:56:09 +0200
User-agent: NeoMutt/20180716

On Sat, Apr 13, 2019 at 01:54:46PM +0000, Alan Mackenzie wrote:
Hello, Davis.

On Fri, Apr 12, 2019 at 16:39:16 +0000, Herring, Davis wrote:
[Sent off-list because I don't know whether my DMARC issues have been
addressed.  Feel free to share it there if you'd like to make a public

I'm doing this.  I believe these mail issues, as they interact with
mailing lists, are a Hard Problem.  I'm not sure how much progress has
been made on this by the admins, but they certainly haven't been
disregarding the problem.

> Getting concrete again, my understanding (please correct me if I am
> wrong) of what you are suggesting is: "continuation" CC Mode source
> lines should be indented with tabs up to the indent position of the
> "main" line, and spaces after that.  For some value of
> "continuation" and "main" (see below).

I'm not saying your description in terms of CC Mode internals was
incorrect, but I'd like to provide an implementation-independent
description that can be easily verified.  (Also, in case it hasn't
been posted recently, the Emacs Wiki discusses this idea in some depth

Thanks, I've read that.  I've also downloaded the pertinent Elisp file.
I'm not quite sure how smart-tabs-mode works, yet, so I'm also not sure
what a secific CC Mode implementation could add.

The definition of "continuation" is simply that tabs are used whenever
the user chooses the width of indentation and spaces are used whenever
the editor chooses it (by comparing column positions in the text).

So, roughly speaking, if a CC Mode "offset" is + or ++, then tabs would
be appropriate, otherwise spaces.

There is a tacit assumption here that the amounts of indentation
chosen by the user are expressed in units of tabs.  Conveniently, CC
Mode already defines indentation in terms of levels, so this just
means that a level equals a tab--i.e., that c-basic-offset and
tab-width are not independent.  It probably makes sense to, when this
style is engaged, (setq tab-width c-basic-offset) after computing the
latter from whatever other style information since it is more specific
than any global setting of tab-width.

Yes.  I'll work out the precise details.

But I'm now wondering why I should want to write a CC Mode specific

Hope this helps,

Very much so, thanks!


Alan Mackenzie (Nuremberg, Germany).

I agree that a general implementation could be a better approach,
because other modes could take advantage of it. At least the basic
infrastructure. But also because different modes will need to support
different customizable variants of this in the future and every mode
shouldn't reinvent the well ever time.

Nevertheless CC-mode will require a specific implementation any way
because there is more complexity with syntax analysis, but also because
most of the programming languages that exposes this issue needs cc-mode
in emacs.

Maybe we should first agree about what is the basic functionality that
needs to be added in the emacs core and then we could consider
specializations for cc-mode if they are needed (pretty sure they'll do).

I don't know if the other modes in emacs are implemented like cc-mode,
but the approach you mentioned yesterday is something that maybe fits
for most of them. So a basic infraestructure for the "continuation array"
may be language/mode independent.

Languages like python or julia where mixing tabs with spaced is
dangerous; probably need to assert to use only spaces or tabs (pep 8
recommends spaces only and it is kind of standard now... similar happens
in Fortran, most compilers support to use tabs, but not all). Pascal on
the other hand uses tabs, but the tab-width is usually 3 or 4. So, at
the end, every prog-mode will need a sort of specialization.

reply via email to

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