emacs-devel
[Top][All Lists]
Advanced

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

the overloading of `tab-width'


From: Colin Walters
Subject: the overloading of `tab-width'
Date: 15 Jun 2002 13:38:20 -0400

So, I've been doing a lot of work on another project, whose authors
start out every file with: 

/* -*- Mode: C; indent-tabs-mode: t; c-basic-offset: 8; tab-width: 8 -*- */

Now, personally, I find this irritating in the extreme.  If I nest about
four blocks, with a long function name or two, the lines begin to wrap
very quickly.  One thing I do like about the GNU Coding style is that it
says to perform indentation by 2 columns. 

Unfortunately, believe it or not, Emacs gives me no way to deal with
this.  You may say, "You can just change `tab-width'", but in fact I
can't.  If I set `tab-width' to 2, then everything shrinks nicely to the
left.  However, I can't just hit TAB anymore to do indentation, because
CC mode decides it has to insert *four* tabs in order to make up to the
`c-basic-offset' value of 8. 

Now, your next response might be, "Why can't you just set *both*
c-basic-offset and tab-width to 2"?  And the answer is because that can
change the buffer's representation on disk.  For example, in the
following code: 

static char *
get_file_content (EMsgComposer *composer, const char *file_name, gboolean 
want_html, guint flags, gboolean warn)
{
[...]
        if (fd == -1) {
[...]
                if (warn) {
                        msg = g_strdup_printf (_("Error while reading file 
%s:\n%s"),
                                               file_name, g_strerror (errno));
If I hit TAB on the last line while `c-basic-offset' and `tab-width' are
both 8, everything is fine.  However, If I set them both to 2, then hit
TAB, CC mode will insert a bunch of tab characters to try to line it up
with the end of function name, which is wrong.  Really, I don't want to
change the representation on disk at all. 

I think this problem came about because packages started using
`tab-width' to convert between actual TAB and space characters. 
According to its docstring, it is only for display purposes, but CC mode
and functions like `tabify' use it for other purposes. 

So I finally got fed up enough with this situation to write the
following patch.  It should basically be self-explanatory. 

The final question is probably "What's the disadvantage?".  Given that
the tab/space problem has plagued programmers for decades, one would
have every right to be surprised if this patch could make things Just
Work the way each person wants it to.  And indeed, there is a
disadvantage:  If I keep the (awful) settings of `c-basic-offset' and
`tab-width' => 8, which I must do in order to prevent spurious conflicts
and bloated patches, but I set `display-tab-width' => 2, then in the
above situation, the parameters no longer line up with the function name
(in display terms). 

But I'm willing to live with that disadvantage, in order to get much
less line wrapping. 

Another solution we should pursue is giving some way to tell CC mode to
*only* insert tabs when performing indentation.



Attachment: disptabwidth.patch
Description: Text Data


reply via email to

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