---- Reported by danw@gnome.org 2005-08-23 16:53:33 MST ----

MD's default treatment of ASCII TAB as having 4-character tab stops
betrays its Windows ancestry. Tabs are always assumed to be 8 characters
by default in traditional Unix apps. This mismatch makes it awkward to
read/edit MD-developed code in terminals, vi, emacs, etc, because if you
end up with a mix of spaces and tabs (which is very easy to do), then
the lines will end up indented differently for you than they are in MD.
(Eg, look at the source to banshee in a terminal.)

The easiest fix is probably to just turn on the "convert tabs to
spaces" option by default. Or maybe the reverse: convert
line-initial indentation to always use tabs rather than spaces.
Some guy on MSDN suggests a hybrid approach
(http://blogs.msdn.com/cyrusn/archive/2004/09/14/229474.aspx)
where the indentation corresponding to curly-braces is done with
tabs, but indentation done to line up corresponding parts of a
multi-line statement is done with spaces, so that it still lines up
right regardless of how the tabs are interpreted.



---- Additional Comments From tberman@off.net 2005-08-24 05:18:51 MST ----

The hybrid approach you speak of is in fact the one-true-method as it
makes sane sense for all involved. Tab for indentation, Space for
formatting. Good luck selling it to people using vim or emacs. When MD
supports a smart auto-indenter, it will by default use tabs + spaces.
However, a smart auto-indenter is not possible until the gtksourceview
that releases with gnome 2.12 is the standard, as catching the enter
keypress is impossible except under that release or later.

And the tab size is customizable via the Text Editor -> Behavior
property page.

I am not 100% sure what this bug is about.

Is it to change the default from 4 to 8? or is it to add an
auto-indenter. If it is the latter, I believe we have pre-existing
bugs about smart indentation, and if it is the former, I don't see
that as something we should do.

C# sucks for indentation, and an 8 character tab makes most people's
code start 16 characters in. If anything, I'd rather see the default
go to a 2 character tab instead of be at a 4, but thats just me. 4
seems like a good compromise.





---- Additional Comments From danw@gnome.org 2005-08-24 10:19:34 MST ----

> I am not 100% sure what this bug is about.

It is currently very easy for people using MD (or any other
editor for that matter) to end up with source files that use a mix
of tabs and spaces for indentation. Eg:

  ....public class Foo {
  ........public Foo ()
          {
  ............bar = 5;
              baz = 12;
  ........}

(where "    " means 4 spaces and "...." means 1 tab). This is fine
if you only look at the file in MD, but if you (or someone else)
looks at it in a terminal/vi/emacs, they'll see:

          public class Foo {
                  public Foo ()
          {
                          bar = 5;
              baz = 12;
                  }

This sucks. That's what the bug is about: IMHO, MD should try to
avoid having this happen, by whatever means seems appropriate.
Changing the default indent to 8 would do the trick, but so would
always turning on "Convert tabs to spaces" if the indent level was
*not* 8. (In fact, that would be a better solution than changing
the default indent level, because it would still DTRT if the user
chose some other indent level like 2.)

I claim that this is MD's bug, not terminals/vi/emacs, because
they were here first, and there's a long tradition of tabs stops
always being 8 characters in UNIX (regardless of whether or not
your code is indented to 8 characters), and because even if you
could convince all the emacs and vi users who are sharing code
with MD users that they should tweak their tab stops, the code
still wouldn't display right in gnome-terminal/xterm/kterm/etc.
And even if you put a comment at the top of each file with vt100
escape codes to change the tab stops in the terminal, (a) I'd
kill you, and (b) it would still mess up other things that assume
8-character tab stops, like viewcvs (though I can't prove this at
the moment because cvs.gnome.org seems to be misconfigured so as
to be unable to display .cs files).




---- Additional Comments From tberman@off.net 2005-08-24 16:30:20 MST ----

Hahaha, well, the fear of (a) will suffice.

The problem is that it is not actually a bug. It is an issue with (in
this case) aaron bockover not being able to figure out how to use his
space and tab keys. MD can't work around people who can't use their
keyboard properly. And setting the tabstop to 8 by default would work
fine for 1) new banshee code but still fail for 1) existing banshee
code and 2) tons of other people who are sharing code at 2, or 4, or
12 space tabstops. The right thing to do for this instance is to get
Aaron to use a 8 tabstop, and get him to reformat his badly formatted
code.

While I understand the desired behaviour that you are interested in,
it is not possible to implement this behaviour without requiring gnome
2.12, so until that is a dependency we can easily depend 'hard' on,
there is nothing that can be done.

And as I said before, I won't change the default tabstop to 8
characters for MonoDevelop, as the MD code, and plenty of other C#
code becomes very much un-editable on a reasonably sized screen and
window.

Like I said initially, the "proper" way to fix this is to implement a
smart auto-indenter that uses (by default) tabs for indentation and
spaces for formatting, with the option of using spaces for everything.
And as I said before, and here, that is not an option until a hard
dependency on gnome 2.12 is possible.



*** This bug has been marked as a duplicate of https://bugzilla.novell.com/show_bug.cgi?id=MONO59499 ***


Unknown operating system unknown. Setting to default OS "Other".
This bug was marked DUPLICATE in the database it was moved from.
    Changing resolution to "MOVED"