jed-users mailing list

[2006 Date Index] [2006 Thread Index] [Other years]
[Thread Prev] [Thread Next]      [Date Prev] [Date Next]

Re: Looking for Python programmers for testing.


On  7.09.06, Jörg Sommer wrote:

> this patch tries to address the problem that python forbids mixing up
> spaces and tabs as indention characters. It should select the right
> character for each file. Please test it and report all problems and
> success.


Separate Tab Use and Indent Level
---------------------------------

Currently, the Indentation is governed by one custom variable
  
  custom_variable("Py_Indent_Level", 4);

The question "Tabs or Spaces?" is solved by a flawed concept mixing the
Indent_Level and the "Indent_Means":

> -   if (Py_Indent_Level == 8)

use Tabs, else use Spaces.
The proposed patch continues to mix these two (to keep consistency?)

> +   set_blocal_var(Py_Indent_Level == TAB, "py_use_tab");

My suggestion would be a separation of these two settings by introducing a

  custom_variable("Py_Use_Tabs", -USE_TABS);

with the three possible settings:

  -1   guess from file
   0   never use Tabs
   1   always use Tabs

The default would depend on the global variable USE_TABS, assuming that if a
user sets USE_TABS = 0 in his/her jed.rc, tabs should not be used in pymode
either.

(Another option would be 
   custom_variable("Py_Use_Tabs", 0);
 in line with the `Style Guide for Python Code`_ 
 However, there are also strong arguments for Tabs (see below). 
)


Clean up existing code
----------------------

The "Style Guide for Python Code"
http://www.python.org/dev/peps/pep-0008/ says:

  Code indented with a mixture of tabs and spaces should be converted to
  using spaces exclusively. 

Therefore, the python mode might force consistent use also on existing
code. However, I would propose to honour the Py_Use_Tabs setting for the
conversion. 

As the conversion could in rare cases lead to problems, it should issue a
warning and prompt before changing anything.

Another option would be to provide a function for the cleanup, 
maybe together with another coding scheme for Py_Use_Tabs:

  "Do you like Tabs for python code indention?"

   -2 never          force spaces
   -1 no	     use spaces
    0 indifferent    auto-detect
    1 yes            use tabs
    2 always	     force tabs


Flag mix
--------

The following dfa rules might help detect mixed indentation (but might
also confuse the unaware):

   % Flag mix of Spaces and Tab in code indention
   dfa_define_highlight_rule("^ +\t+[^ \t#]", "error", mode);
   dfa_define_highlight_rule("^\t+ +[^ \t#]", "error", mode);


Auto-detect
-----------

The Tab-detecting in the proposed patch makes sure it only looks for
code-indenting but skips other places (strings, comments).

However, it favours Tabs in the case of an unconsistent file:
one single Tab will turn "py_use_tab" on. I propose the opposite: a
single space in the indentation should turn Tab use off. This is 
in line with the Style Guide. Also, if there are lines with an
indentation that is not a multiple of TAB, a mixture of Tabs and Spaces
would remain.

% find out whether code indenting uses Tabs only
define py_guess_tab_use()
{
   do
     {
	bol_skip_white();
	% skip multi-line strings
	if ( looking_at("\"\"\"") )
	  {
	     go_right_1();
	     () = fsearch("\"\"\"");
	     continue;
	  }
	% skip empty lines, comments, and non-indented lines
	if (orelse {eolp()} {looking_at_char('#')} {what_column() == 1})
	  continue;
	bol;
	skip_chars("\t");
	if (looking_at_char(' '))
	  return 0;
     }
   while (down(1));
   return 1;
}


Simple is better than complex 
-----------------------------

(from "The Zen of Python" http://www.python.org/dev/peps/pep-0020/)

The blocal variable "py_use_tab" could be replaced by TAB (also blocal)

 + the indentation routines could be left as-is
 
 + remaining Tabs (e.g. in strings or comments) are easy to spot
 
 - a subsequent untab() will probabely not bring the desired result.
   (a function py_untab() could take care of this by temprarily setting
   TAB to TAB_DEFAULT).

Sincerely

Günter



References
----------

The "Style Guide for Python Code" (http://www.python.org/dev/peps/pep-0008/)

Pro Tab arguments:

From http://www.oreillynet.com/onlamp/blog/2005/10/python_bashing_on_geekmuse.html

   Tabs vs. Spaces
   
   All the above comments about problems with white space in Python prove
   just one thing: the author is wrong. All Python programmers should use
   tabs and only tabs for indentation.
   
   One tab, one indent. Three benefits arise:
   
     1) code can be cut and pasted between programs, 
     2) the individual programmer can set his display
        preferences any way he wants (to display a tab as three, four,
        eight, whatever spaces) and 
     3) the indentation throughout his
        program will always be regular.
   
   My team does this, and we have no white space problems at all, at all. :-)

   john_betelgeuse
   
The now disfunctional page http://wiki.chad.org/wiki?IndentationUsingTabs
quoted on 
http://www.gungfu.de/facts/archives/2006/05/02/to-tab-or-not-to-tab-whitespace-in-python/

   Like the Newline, Tabs also have special meaning. Using Spaces to get
   to the next level of indention is no more acceptable than using Spaces
   to advance the cursor to the beginning of the next visual line. Tabs
   and Newlines contain metainformation about the code that using an
   arbitrary amount of spaces to get the same visual effect does not
   have.




--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.


[2006 date index] [2006 thread index]
[Thread Prev] [Thread Next]      [Date Prev] [Date Next]