Description

Describe the bug...

Steps to reproduce

Create a C file (for example) with standard 8-character tab width. Add it to a page with inline:file.c. Observe odd formatting of resulting page.

Example

   1 #include <stdio.h>
   2 
   3 int main (int argc, const char *argv) {
   4 
   5   printf("Hello world!\n");
   6   printf("Using default indent of C Abrev mode in Emacs\n");
   7 
   8   return 0;
   9 }

main.c

   1 #include <stdio.h>
   2 
   3 int main (int argc, const char *argv) {
   4 
   5 	printf("Hello world!\n");
   6 	printf("Using tabs\n");
   7 
   8 	return 0;
   9 }

main-tabs.c

   1 #include <stdio.h>
   2 
   3 int main (int argc, const char *argv) {
   4 
   5         printf("Hello world!\n");
   6         printf("Using (stupid) 8 spaces indent\n");
   7 
   8         return 0;
   9 }

main-8.c

Details

Workaround

Edit utils/ParserBase.py to replace 4 by 8 in two calls to expandtabs

Discussion

The better solution is to make the value of the tab width an option in wikiconfig.

Python uses 4 spaces per level indentation standard. So I don't think this is a bug.

• But 8 spaces is the standard.
  • That might be true for a typewriter, but I don't think many programmers use such a big tab distance.
    • I do not know any environment besides Python et al. which does not expect "8".

I'm sorry, I don't see any bug here, see examples. -- NirSoffer 2005-02-15 22:39:39

• The bug is that file 2 does not look like file 3.
  • No bug here, there is no standard that say that tab equal 8 spaces. The current 4 spaces value gives very good results. If one want have exactly 8 spaces, he/she should use spaces, not tabs.
    • How about having a no-non-sense solution that has sensible standards per parser? 8 for C, 4 for Python etc.? Just show me a single C file thats in wide use which uses 4 characters per tab.

      • Any Apple file does. -- JohannesBerg 2008-03-18 19:08:09

---

The above discussion mixes up "indentation" with "tabs" a bit too freely. It is common practice to use four spaces for indenting, but a tab character (ASCII 9) is always 8 spaces wide in Python when used at the start of the line. Check the language reference on indentation, second paragraph, for this. The reference also rightfully indicates that this is a standard for Unix. However, Python behaves like this on all platforms, not just on Unix. For example, consider this Python program:

   1 if True:
   2     if False:
   3         pass
   4 	print "Hello"

example.py.

Now consider the same program, but not marked as a Python program by its file extension:

   1 if True:
   2     if False:
   3         pass
   4 	print "Hello"

example.c.

Note that this is physically the same file. I've uploaded it twice, choosing different remote names. It looks different because one line uses eight spaces, while the other uses one tab, and the C and Python formatters of MoinMoin treat this differently. The C formatter uses four spaces, while the Python formatter uses 8 spaces. If you download the second program from the attachments section and execute it with python example.c, then it will not print anything, because the print statement is at the same logical indentation level as the line above it. The interesting thing here is that the Python formatter for MoinMoin is smart enough to replace one tab with eight characters, rather than four as the earlier comment would suggest. Having the C formatter use four spaces instead seems somewhat inconsistent to me, and also diverges from Unix. In any case, one should not argue for it by mentioning Python as a four-space example, since Python clearly and unambiguously defines the tab width to be 8. (C does not need to make such a definition because whitespace is not used for structuring.)

So any reasonable Python formatter must interpret a tab as eight spaces or it will mess up the logical program structure. MoinMoin respects this standard and works correctly for Python files. However, given that it uses a tab as eight spaces in Python, a language where the typical indentation width is four, it seems inconsistent to have a tab be four spaces in other cases. It would be much easier for users to understand a simple rule: "tab width = 8" rather than "tab width = 8 for Python, tab width = something else in other cases". So I'd say it's best to always have a tab be eight spaces. As Nir says, this is very wide indentation, so the reasonable thing is to do as he says: If you want an indentation width of k, type k spaces and don't use tabs at all.

To recap: Keep the concepts indentation and tab apart. One tab is eight spaces. If you want one indentation level to represent four spaces, which is indeed the recommended style for Python, use four space characters per level of indentation. Actually, you could also legally use four spaces for one level of indentation, one tab for two levels, and one tab plus four spaces for three levels of indentation. Of course you shouldn't do this; that way lies madness. It just shows that Python indeed interprets one tab as eight spaces in these contexts.

Addition: If you go to the AttachFile page and click "view" for any of the two attachments, you also see that it is displayed with a tab width of 8. That's an additional inconsistency if a tab width of 4 is used in pretty-printed displays of C code.

--

About language reference on indentation - this is only an implementation detail of the python parser, used to parse text into python code, and has nothing to do with the way code should be rendered, which is a graphic design issue. If the file contain tabs, you will get those tabs when you download the file, and it will be displayed by your text editor according to your preferences.

• I strongly disagree. Code should be rendered in such a way that the block structure is clear. Rendering two lines with different logical indentation identically is a bad flaw of a renderer. No editor claiming Python support should do this. (I don't know one that does.)
  • You miss the point here - you mixed tabs with spaces! There is no correct way to display that file - If you use 8 spaces, It will render my files in a wrong way, because my preferences is 4 spaces, and if you use 4 spaces you will complain about it because your preferences is 8 spaces. The C file is legal, because white space does not matter in C, but this file is bad formatted, it will look different on your editor and my editor. Here, look how mixed tab and spaces look in my editor. Try the same file at yours:

       1 def mixing_tabs_and_spaces():
       2     print 'with spaces'
       3 	print 'with tab'
    

    • dont_mix.py

      Note I was talking about Python in my example, not about C. For C this is indeed purely a formatting issue -- I think I said as much further above. For Python however, tabs have a semantic meaning defined by the language definition, and one must be somewhat more careful.

      I know and understand your viewpoint, which is valid for the systems you work with. You must believe me and Alexander though, that on Unix, the common viewpoint is "chr(9) is 8 spaces", which is valid for Unix. Discussions of this kind often arise in news:comp.lang.python when people from different backgrounds clash. Usually neither side agrees to the viewpoint of the other, so it's mostly fruitless. I'll keep out of this and let you developers decide among yourselves. Just in case you wonder how Unix people can live with such wide indentation: They don't. Instead, they indent with spaces, not with tab characters. This might seem painful to type, but it is well supported by the editors they use, which makes it bearable. For example, if I type tab at the beginning of the line with my editor, it inserts four spaces. If I then type backspace, it removes four spaces. There are no tab characters in the files at all, but within the editor, it looks as if there were.

The test example.c/py test files are examples of bad usage of tabs and spaces. You should not mix them - because each editor might use different value for tab, as its a user preferences, not a standard.

• Indeed, you should not mix them. Hence the "madness" comment I made about it. I just wanted to explain the way Python behaves, since for displaying Python code, using 8 spaces for a tab is the only setting where you are guaranteed to get code whose look corresponds the block structure. This has no bearing on C code, of course. For C code, I just indicated that it would be good to use the same setting as for Python for consistenty purposes. But I'm repeating myself, all's been said, I'll go away now.

From a design point of view, we should not use 8 spaces for expanding because it leads to too wide texts. We should not waste our time on stuff like this, we have real bugs to fix.

• I agree somewhat here: There are more important issues. However, this would be easy to fix and consistent indentation is certainly preferable to inconsistent behaviour. MoinMoin represents tabs in Python displays as 8 spaces. It represents tabs in file attachments as 8 spaces. This is also how the Python standard library behaves (see the textwrap module and the expand_tabs method of the str and unicode classes) and what the Python parser does. The Python project also mandates tabs as 8 spaces for C code (PEP 7), although this is of course not binding for C code from other projects. From what I gather from the page diffs, the original anonymous reporter, Alexander and myself consider this a bug. You consider it a feature. Thomas has not spoken up for some time. Maybe we should let him make the final decision and then move on?

  • I agree that we should use a consistent rendering, use 4 spaces for tabs in all cases. Again, what the parser does is not related, we are talking here about how to render tabs in MoinMoin, not how to parse text as Python code. This is just the same decision you do in your editor when you set yours tabs to be 4 spaces, its just the way tabs look.

-- NirSoffer 2005-02-16 00:44:39

I said I would not write more on this, but I had a new idea: Don't expand tabs at all, just send tab characters as tab characters. For OSes that have standard widths for tabs, browsers on those OSes should follow those standards and display it correctly. For OSes where tabs are seen as configurable-width, browsers should include a setting to configure tab width. (If they don't do it yet, manufacturers can be pestered. ) Of course this means that if you want to rely on a particular indentation width, you must use spaces, but in environments with configurable tab widths, this is the case anyway, so no harm done. I have suggested this to Nir in e-mail first to check if this fits "both worlds" and he considers it a reasonable solution, so maybe everyone can agree on this.

Attached is a test file from Nir to see if this works well with all browsers: tabs-test.html. It should, because tab characters are perfectly ordinary ASCII, but a test won't hurt. Everything looks as expected under Firefox and Safari (tested by Nir), and under Mozilla and Internet Explorer (tested by Malte).

-- MalteHelmert 2005-02-17 01:55:05

• I like that idea.

  • Now I have a stupid question: How do I tell my browser to display tabs as 4 spaces? Or is that not the goal? I would rather like to give the editor the power to format his tabs (i.e. add a tabwidth option to control tab expansion). -- OliverGraf 2005-03-11 12:06:12

    • My goal is to leave the tab rendering to the browser vendors and use the time for wiki related stuff :-). Specially when there is no correct way to render tabs, as you can see in the examples on this page.
      • Adding this option is a no-pain thing. And who knows better how to render tabs in his own document? The guy who placed it here or the folks hacking opera, firefox or internet exploder?

        • It make sense, we can't render tabs magically, but the person who put his code here know exactly how he like his tabs. It should work on all code parsers though in a consistent way. So if you use tab-width=int we will expand tabs, otherwise, we render tabs as tabs?

Plan

Check if its possible to don't expand tabs for display, tabs will display as tabs.

• Priority:
• Assigned to:
• Status:

CategoryMoinMoinBug