Tab width oddity

Tab width oddity

[Nate Bargmann]

Although I've used Emacs on and off in the past, this time I decided to 
get serious about using it.  Editing some C source I found that in a 
struct where assignments had been lined up by other contributors and 
other editors that Emacs is making a slight mess of things.  I will try 
to explain and if needed I can post some screenshots.

My tab-stop-list is (8 16 24 32 40 48 56 64 72 80 88 96 104 112 120) and 
I am using CC-mode with indent defaults.

For example, I have a line like:

	.foo =		bar;

For most lines this lines up just fine but for some the '=' is positioned 
at a tab-stop -1 (position 7, 15, 23, etc) and the next character in the 
source file is a tab (0x09).  The character immediately following is also 
a tab.  Editors such as Vim and Midnight Commander only give the tab 
character one blank in this position and give the following tab the 
customary 8 blanks (per my settings).  However, Emacs is expanding the 
first tab to 9 blanks before showing the second tab character.  I do not 
see this occurring when a tab character is two or more characters to the 
left of the tab stop.  I first became aware of this when I found things 
were not lined up in Emacs as I had expected and a 'git diff' showed that 
my changes had moved the assignment operand to the left by one tab stop.

Neither my search of the Emacs documentation nor any amount of searching 
the Web has turned up mention of this.  Hopefully, this is not an FAQ I 
have yet to find.

Thanks,

- Nate

Re: Tab width oddity

[Emanuel Berg]

Nate Bargmann <n0nb.DO.NOT.SPAM@ME.n0nb.us> writes:

> For most lines this lines up just fine but for some
> the '=' is positioned at a tab-stop -1 (position 7,
> 15, 23, etc) and the next character in the source
> file is a tab (0x09). The character immediately
> following is also a tab. Editors such as Vim and
> Midnight Commander only give the tab character one
> blank in this position and give the following tab the
> customary 8 blanks (per my settings). However, Emacs
> is expanding the first tab to 9 blanks before showing
> the second tab character. I do not see this occurring
> when a tab character is two or more characters to the
> left of the tab stop. I first became aware of this
> when I found things were not lined up in Emacs as I
> had expected and a git diff' showed that my changes
> had moved the assignment operand to the left by one
> tab stop.

This is difficult to understand. Can you include the
code that behaves strange so I (we) can try to
reproduce it?

I never thought about tabs in the context of
indentation (or the c-mode), but in general I don't
like tabs and I have made it so they are automatically
replaced by spaces on save-buffer.

This is what I have on tabs:

(setq-default tab-width 3)

(defun untab-all ()
  (if (not (member major-mode '(makefile-gmake-mode
                                makefile-mode) )) ; exceptions
      (untabify (point-min) (point-max)) )
  nil) ; tell 'did not write buffer to disk'

(setq before-save-hook '(untab-all delete-trailing-whitespace))

The reason for the exceptions are that 'make' wants
tabs in Makefiles. And that's the only time I ever use
them.

-- 
underground experts united

Re: Tab width oddity

[Nate Bargmann]

On Wed, 24 Sep 2014 01:20:14 +0200, Emanuel Berg wrote:

> This is difficult to understand. Can you include the code that behaves
> strange so I (we) can try to reproduce it?

I am not certain if the news server I am on will pass the attachment.  
The file is available from:

https://github.com/N0NB/hamlib/blob/master/rotorez/rotorez.c

The interesting segment is from lines 320 through 326, although more 
exist throughout the file.  Lines 322 and 323 show the effect I am only 
seeing in Emacs.

For comparison, I have posted screen shots.  The first is Emacs in a 
terminal window with whitespace-mode on.  In both of the following shots 
the tab highlighting character is in the correct position after the '=' 
character but then nine positions are added instead of one:

http://i197.photobucket.com/albums/aa106/N0NB/Misc/emacs-term.jpg

This is Emacs running in its own X session also with whitespace-mode on:

http://i197.photobucket.com/albums/aa106/N0NB/Misc/emacs-gui.jpg

This is Midnight Commander using its internal editor highlighting the 
white space.  The cursor is on line 322 and only the right arrow of the 
tab highlighting sequence is visible.  The assignment operand is properly 
lined up:

http://i197.photobucket.com/albums/aa106/N0NB/Misc/mc-term.jpg

And Vim (I didn't have the command handy to show white space):

http://i197.photobucket.com/albums/aa106/N0NB/Misc/vim-term.jpg

Finally, the file printed in the terminal window using cat:

http://i197.photobucket.com/albums/aa106/N0NB/Misc/cat-term.jpg


As I see it, Emacs is the one in error here as Midnight Commander, Vim, 
cat, and the GitHub Web interface (along with Git tools) agree on the 
formatting.  Only Emacs seems to be processing the case where the tab 
only occupies one space of screen position incorrectly.

HTH,

- Nate

Re: Tab width oddity

[Yuri Khan]

On Wed, Sep 24, 2014 at 10:13 AM, Nate Bargmann
<n0nb.DO.NOT.SPAM@me.n0nb.us> wrote:

> https://github.com/N0NB/hamlib/blob/master/rotorez/rotorez.c
>
> The interesting segment is from lines 320 through 326, although more
> exist throughout the file.  Lines 322 and 323 show the effect I am only
> seeing in Emacs.

This manner of aligning will break when tab size is changed. You
should not use it.

Tabs work consistently when they are at the start of each line. Within
the line, use spaces exclusively.

> For comparison, I have posted screen shots.  The first is Emacs in a
> terminal window with whitespace-mode on.  In both of the following shots
> the tab highlighting character is in the correct position after the '='
> character but then nine positions are added instead of one:

This is a somewhat known problem[1] with whitespace-mode.

[1]: http://www.emacswiki.org/emacs/WhiteSpace#toc9

Re: Tab width oddity

[Nate Bargmann]

On Wed, 24 Sep 2014 10:35:03 +0700, Yuri Khan wrote:

> This manner of aligning will break when tab size is changed. You should
> not use it.
> 
> Tabs work consistently when they are at the start of each line. Within
> the line, use spaces exclusively.

This thread isn't about editing policy, so I'll continue to focus on the 
technical question at hand.

>> For comparison, I have posted screen shots.  The first is Emacs in a
>> terminal window with whitespace-mode on.  In both of the following
>> shots the tab highlighting character is in the correct position after
>> the '=' character but then nine positions are added instead of one:
> 
> This is a somewhat known problem[1] with whitespace-mode.
> 
> [1]: http://www.emacswiki.org/emacs/WhiteSpace#toc9

That makes sense.  Interestingly, when I had opened Emacs with whitespace-
mode disabled, I saw the misalignment.  When I enabled whitespace-mode 
last night it placed the special characters as shown in the screen shots, 
but the alignment did not change.  Just now I disabled whitespace-mode 
and the buffer was realigned as I expected compared to the other editors 
and cat.  I exited Emacs and restarted and the expected alignment is 
shown.

Perhaps I had exited Emacs with whitespace-mode enabled on that 
particular buffer at some time in the past and since I am saving and 
reloading the desktop, it may have retained the previous display 
alignment from when whitespace-mode was enabled.

At least now I understand what is going on and can take corrective 
action.  Thanks much.

- Nate