Re: Supporting tabs for indentation, spaces for alignment

[Ergus]

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
> > reply.]
>
> 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
> > <https://www.emacswiki.org/emacs/SmartTabs>.)
>
> 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
> implementation.
>
> > Hope this helps,
>
> Very much so, thanks!
>
> > Davis
>
> --
> 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.