[zile-devel] [ zile-Bugs-1889859 ] indent_relative always uses spaces

[SourceForge.net]

Bugs item #1889859, was opened at 2008-02-08 21:49
Message generated for change (Comment added) made by rrt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=117089&aid=1889859&group_id=17089

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: indent_relative always uses spaces

Initial Comment:
In line.c, the function indent_relative always inserts spaces, regardless of 
how the previous line is indented or indent-tabs-mode.  As a result, with 
indent-tabs-mode t, this input:

<TAB>foo
<TAB>bar

produces this output:

<TAB>foo
<SPACE><...><SPACE>bar

Obviously, this could break any file with syntactically significant whitespace. 
 Even when whitespace is used only for formatting, nobody wants inconsistent 
indentation.  (Anyone who doesn't care wouldn't need to set indent-tabs-mode.)

Fortunately, the most flexible solution is also the simplest: indent_relative 
should replicate exactly the indentation of the previous line, as its name 
implies.

----------------------------------------------------------------------

>Comment By: Reuben Thomas (rrt)
Date: 2008-02-13 00:43

Message:
Logged In: YES 
user_id=50145
Originator: NO

"tab_width" is what it should use.

As for Emacs compatibility, Zile is meant to be a strict subset. You'll
find that the Emacs developers understand the difference between a tab and
a series of spaces very well: programming language-specific modes will
almost certainly work correctly in Emacs. Unfortunately, Zile doesn't
support modes.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-12 20:39

Message:
Logged In: NO 

2.2.54 appears to do what you describe, apart from using tab_width instead
of 8, but I didn't test it thoroughly.

Is Zile meant to be compatible with Emacs or a strict subset?  In other
words, would you be willing to include the behavior I described with a
different name, or would I first have to get the Emacs developers to
understand the semantic difference between a tab and a series of spaces?

----------------------------------------------------------------------

Comment By: Reuben Thomas (rrt)
Date: 2008-02-09 02:46

Message:
Logged In: YES 
user_id=50145
Originator: NO

Should now be fixed. If you could try CVS I'd be most grateful. I have
gone a little further than simply fixing the bug: I have also exposed
indent-relative as a command, since the C function indent_relative already
performed it, and fixed indent-for-tab-command, which was simply doing the
wrong thing (and updated its docstring from Emacs 22.1).

If you'd rather test a tarball than CVS, then simply wait a bit and
download a nightly tarball of CVS. Either way, it would be nice to know if
you *don't* want to test again, as I can simply release a new version, and
you can test that.

----------------------------------------------------------------------

Comment By: Reuben Thomas (rrt)
Date: 2008-02-08 22:50

Message:
Logged In: YES 
user_id=50145
Originator: NO

I'm afraid that while you're right that Zile should not just use spaces,
and I'll fix that, you're wrong that it should (or could) copy the
indentation of the previous line, as that is not what indent-relative does
in Emacs, and it is more important that Zile behave exactly like Emacs than
that it fix design bugs. Emacs's indent-relative indents by calling
indent-to, which indents a given amount using spaces and tabs. So if you've
used anything other than tabs up to a multiple of 8 followed by <8 spaces,
you lose, sorry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=117089&aid=1889859&group_id=17089