Reindenting the C code base?
Hello, I remember there were some talks of reindenting the C code base (from tabs to 4-space indents) after py3k is released, but I can't find the discussion thread again. Was a decision ever taken about it? Regards Antoine.
On Sat, Dec 13, 2008 at 1:22 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I remember there were some talks of reindenting the C code base (from tabs to 4-space indents) after py3k is released, but I can't find the discussion thread again. Was a decision ever taken about it?
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented. If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back. There's also the issue of merging between the 2.x and 3.x branches, which we still do. As far as a decision, I think the de facto decision is to keep the status quo, and I'm all for sticking with that. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time. Perhaps a graceful policy would be to mandate that all new edits be made with spaces without touching other functions in the file. Then hopefully the code base would gradually converge to a tabless scheme. Regards Antoine.
On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
That's a shame. We used to have more rigorous standards than allowing that.
Perhaps a graceful policy would be to mandate that all new edits be made with spaces without touching other functions in the file. Then hopefully the code base would gradually converge to a tabless scheme.
I don't think so. I find local consistency more important than global consistency. A file can become really hard to read when different indentation schemes are used in random parts of the code. If you have a problem configuring your editor, just say so and someone will explain how to do it. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum <guido@python.org> wrote:
On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
That's a shame. We used to have more rigorous standards than allowing that.
Perhaps a graceful policy would be to mandate that all new edits be made with spaces without touching other functions in the file. Then hopefully the code base would gradually converge to a tabless scheme.
I don't think so. I find local consistency more important than global consistency. A file can become really hard to read when different indentation schemes are used in random parts of the code.
If you have a problem configuring your editor, just say so and someone will explain how to do it.
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent. I always try to get it right anyway, but it'd be a lot more convenient if my editor did it for me. If there are such instructions, perhaps they should be added to PEPs 7 and 8? Thanks, Jeffrey
Jeffrey Yasskin <jyasskin <at> gmail.com> writes:
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent.
Same question for Kate! Although I guess that if emacs isn't able to do it, Kate won't do it either... (Kate allows configuring on a directory basis, on a file extension basis, but not on a filename basis) Regards Antoine.
Same question for Kate! Although I guess that if emacs isn't able to do it, Kate won't do it either...
(Kate allows configuring on a directory basis, on a file extension basis, but not on a filename basis)
I guess it would be possible to write a Kate plugin that does that. Regards, Martin
On Sun, Dec 14, 2008 at 12:43 PM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent. I always try to get it right anyway, but it'd be a lot more convenient if my editor did it for me. If there are such instructions, perhaps they should be added to PEPs 7 and 8?
I know python-mode is able to detect indent configuration of python code automatically, but I don't know if c-mode is able to. Personally,
On Sun, Dec 14, 2008 at 12:57 PM, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
On Sun, Dec 14, 2008 at 12:43 PM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent. I always try to get it right anyway, but it'd be a lot more convenient if my editor did it for me. If there are such instructions, perhaps they should be added to PEPs 7 and 8?
I know python-mode is able to detect indent configuration of python code automatically, but I don't know if c-mode is able to. Personally,
[sorry, <tab><space> in gmail made it send my unfinished email] Personally, I use auto-mode-alist to make Emacs choose the indent configuration to use automatically. Here's how it looks like for me: (defmacro def-styled-c-mode (name style &rest body) "Define styled C modes." `(defun ,name () (interactive) (c-mode) (c-set-style ,style) ,@body)) (def-styled-c-mode python-c-mode "python" (setq indent-tabs-mode t tab-width 8 c-basic-offset 8)) (def-styled-c-mode py3k-c-mode "python" (setq indent-tabs-mode nil tab-width 4 c-basic-offset 4)) (setq auto-mode-alist (append '(("/python.org/python/.*\\.[ch]\\'" . python-c-mode) ("/python.org/.*/.*\\.[ch]\\'" . py3k-c-mode)) auto-mode-alist))
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent.
If it is now official policy that different files use different styles, then I think it would be helpful to put Emacs variables at the end of each file. See the end of Objects/unicodeobject.c for an example. I'm not aware of a builtin function that adjusts c-mode automatically; I could fine a package that does some basic guessing, though: http://members.iinet.net.au/~bethandmark/elisp/mst-guess-indentation.el http://www.emacswiki.org/cgi-bin/emacs/guess-offset.el I've tried the second one briefly. It guesses c-basic-offset fairly well, but doesn't attempt to guess indent-tabs. This one does; I haven't tried it yet: https://savannah.nongnu.org/projects/dtrt-indent/ http://git.savannah.gnu.org/gitweb/?p=dtrt-indent.git;a=blob_plain;f=dtrt-in... Regards, Martin
Jeffrey Yasskin schrieb:
On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum <guido@python.org> wrote:
On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
That's a shame. We used to have more rigorous standards than allowing that.
Perhaps a graceful policy would be to mandate that all new edits be made with spaces without touching other functions in the file. Then hopefully the code base would gradually converge to a tabless scheme.
I don't think so. I find local consistency more important than global consistency. A file can become really hard to read when different indentation schemes are used in random parts of the code.
If you have a problem configuring your editor, just say so and someone will explain how to do it.
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent. I always try to get it right anyway, but it'd be a lot more convenient if my editor did it for me. If there are such instructions, perhaps they should be added to PEPs 7 and 8?
I use this little hack to detect indentation in Python's C files: (defun c-select-style () "Hack: Select the C style to use from buffer indentation." (save-excursion (if (re-search-forward "^\t" 3000 t) (c-set-style "python") (c-set-style "python-new")))) (add-hook 'c-mode-hook 'c-select-style) -- where "python" and "python-new" are two appropriate c-mode styles. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Mon, Dec 15, 2008 at 00:20, Georg Brandl <g.brandl@gmx.net> wrote:
Jeffrey Yasskin schrieb:
On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum <guido@python.org> wrote:
On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
That's a shame. We used to have more rigorous standards than allowing that.
Perhaps a graceful policy would be to mandate that all new edits be made with spaces without touching other functions in the file. Then hopefully the code base would gradually converge to a tabless scheme.
I don't think so. I find local consistency more important than global consistency. A file can become really hard to read when different indentation schemes are used in random parts of the code.
If you have a problem configuring your editor, just say so and someone will explain how to do it.
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent. I always try to get it right anyway, but it'd be a lot more convenient if my editor did it for me. If there are such instructions, perhaps they should be added to PEPs 7 and 8?
I use this little hack to detect indentation in Python's C files:
(defun c-select-style () "Hack: Select the C style to use from buffer indentation." (save-excursion (if (re-search-forward "^\t" 3000 t) (c-set-style "python") (c-set-style "python-new"))))
(add-hook 'c-mode-hook 'c-select-style)
-- where "python" and "python-new" are two appropriate c-mode styles.
Anyone have something similar for Vim? -Brett
please unsubscribe me On Tue, Dec 16, 2008 at 12:51 AM, Brett Cannon <brett@python.org> wrote:
Jeffrey Yasskin schrieb:
On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum <guido@python.org> wrote:
On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
That's a shame. We used to have more rigorous standards than allowing
Perhaps a graceful policy would be to mandate that all new edits be
made with
spaces without touching other functions in the file. Then hopefully
On Mon, Dec 15, 2008 at 00:20, Georg Brandl <g.brandl@gmx.net> wrote: that. the code
base would gradually converge to a tabless scheme.
I don't think so. I find local consistency more important than global consistency. A file can become really hard to read when different indentation schemes are used in random parts of the code.
If you have a problem configuring your editor, just say so and someone will explain how to do it.
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent. I always try to get it right anyway, but it'd be a lot more convenient if my editor did it for me. If there are such instructions, perhaps they should be added to PEPs 7 and 8?
I use this little hack to detect indentation in Python's C files:
(defun c-select-style () "Hack: Select the C style to use from buffer indentation." (save-excursion (if (re-search-forward "^\t" 3000 t) (c-set-style "python") (c-set-style "python-new"))))
(add-hook 'c-mode-hook 'c-select-style)
-- where "python" and "python-new" are two appropriate c-mode styles.
Anyone have something similar for Vim?
-Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/bharat.satsangi%40gmail.co...
-- Thanks and Regards Bharat +91-9888674137
On Mon, Dec 15, 2008 at 11:21 AM, Brett Cannon <brett@python.org> wrote:
Jeffrey Yasskin schrieb:
On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum <guido@python.org> wrote:
On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
That's a shame. We used to have more rigorous standards than allowing
Perhaps a graceful policy would be to mandate that all new edits be
made with
spaces without touching other functions in the file. Then hopefully
On Mon, Dec 15, 2008 at 00:20, Georg Brandl <g.brandl@gmx.net> wrote: that. the code
base would gradually converge to a tabless scheme.
I don't think so. I find local consistency more important than global consistency. A file can become really hard to read when different indentation schemes are used in random parts of the code.
If you have a problem configuring your editor, just say so and someone will explain how to do it.
I've never figured out how to configure emacs to deduce whether the current file uses spaces or tabs and has a 4 or 8 space indent. I always try to get it right anyway, but it'd be a lot more convenient if my editor did it for me. If there are such instructions, perhaps they should be added to PEPs 7 and 8?
I use this little hack to detect indentation in Python's C files:
(defun c-select-style () "Hack: Select the C style to use from buffer indentation." (save-excursion (if (re-search-forward "^\t" 3000 t) (c-set-style "python") (c-set-style "python-new"))))
(add-hook 'c-mode-hook 'c-select-style)
-- where "python" and "python-new" are two appropriate c-mode styles.
Anyone have something similar for Vim?
-Brett
Something along the lines of: :fu Select_c_style() : if search('^\t') : set noet " etc. : el : set et " etc. : en :endf :au BufRead *.[ch] call Select_c_style() -Kirk McDonald
On Sat, Dec 13, 2008 at 5:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
Personally, I think the indentation of, at least, Objects/unicodeobject.c should be fixed. This file has become so mixed-up with tab and space indents that I have no-idea what to use when I edit it. Just to give an idea how messy it is, they are 5214 lines indented with tabs and 4272 indented with spaces (out the 9733 of the file). -- Alexandre
Personally, I think the indentation of, at least, Objects/unicodeobject.c should be fixed. This file has become so mixed-up with tab and space indents that I have no-idea what to use when I edit it. Just to give an idea how messy it is, they are 5214 lines indented with tabs and 4272 indented with spaces (out the 9733 of the file).
As an Emacs variables block is present in the file, I would consider this normative, and declare that the official indenting is 4 spaces for the file, no tabs. Regards, Martin
On 2008-12-14 21:43, Martin v. Löwis wrote:
Personally, I think the indentation of, at least, Objects/unicodeobject.c should be fixed. This file has become so mixed-up with tab and space indents that I have no-idea what to use when I edit it. Just to give an idea how messy it is, they are 5214 lines indented with tabs and 4272 indented with spaces (out the 9733 of the file).
As an Emacs variables block is present in the file, I would consider this normative, and declare that the official indenting is 4 spaces for the file, no tabs.
All the Unicode C code I wrote at the time used 4 space indents. I would welcome this being restored. It got diluted over time. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 15 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2008-12-02: Released mxODBC.Connect 1.0.0 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
Aha! A specific file. I'm supportive of fixing that specific file. Now if you can figure out how to do it and still allow merging between 2.6 and 3.0 that would be cool. --Guido van Rossum (home page: http://www.python.org/~guido/) On Sun, Dec 14, 2008 at 9:54 AM, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
On Sat, Dec 13, 2008 at 5:11 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time.
Personally, I think the indentation of, at least, Objects/unicodeobject.c should be fixed. This file has become so mixed-up with tab and space indents that I have no-idea what to use when I edit it. Just to give an idea how messy it is, they are 5214 lines indented with tabs and 4272 indented with spaces (out the 9733 of the file).
Guido van Rossum wrote:
Aha! A specific file. I'm supportive of fixing that specific file. Now if you can figure out how to do it and still allow merging between 2.6 and 3.0 that would be cool.
Like "svn blame", you can use "svn merge -x -w" to avoid merging whitespace changes. However, svnmerge.py does not support any of these command-line flags being passed along to the svn command-line. It should be pretty easy to hack in, if it was desirable. -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
Aha! A specific file. I'm supportive of fixing that specific file. Now if you can figure out how to do it and still allow merging between 2.6 and 3.0 that would be cool.
In the specific case, I think it's best to fix the 2.7 source, and then merge the changes into 3k. The 3.x version is still similar to the 2.x version, except for a number of additions (such as interning). The changes should probably then also merged into the 2.6 and 3.0 branches, to allow easy merging in the future. Backporting to 2.5 will become difficult; it will also become unnecessary. Regards, Martin
On Mon, Dec 15, 2008 at 3:59 PM, Guido van Rossum <guido@python.org> wrote:
Aha! A specific file. I'm supportive of fixing that specific file. Now if you can figure out how to do it and still allow merging between 2.6 and 3.0 that would be cool.
Here's the simplest solution I thought so far to allow smooth merging subsequently. First, fix the 2.6 version with 4-space indent. Over a third of the file is already using spaces for indentation, so I don't think losing consistency is a big deal. Then, block the trunk commit with svnmerge to prevent it from being merged back to the py3k branch. Finally, fix the 3.0 version. -- Alexandre
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented. If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back.
I believe "svn blame -x -w" ignores whitespace changes. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net
Miguel Lobo wrote:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented. If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back.
I believe "svn blame -x -w" ignores whitespace changes.
Sounds like Uncle Timmy's whitespace management needs to become a little more draconian. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
On Sat, 13 Dec 2008, Guido van Rossum wrote:
If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back.
I am not a subversion specialist, but it appears this part can be handled gracefully by passing -b (ignore space change) to an external diff command svn blame can rely on (svn blame -x -ub ...). At least, it seems to work on my station (GNU Diffutils, Subversion 1.5.1)! -- Sylvain
On Sat, Dec 13, 2008 at 11:26 PM, Guido van Rossum <guido@python.org> wrote:
I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented. If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back. There's also the issue of merging between the 2.x and 3.x branches, which we still do.
"svnadmin dump" produces pretty munchable text file to pretend that there were no tabs at all. The problem may be to sync working copies with old new repository. http://svnbook.red-bean.com/en/1.5/svn.ref.svnadmin.c.dump.html svn pre-commit hook can be used to avoid any unescaped tabs in future commits. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.pre-commit.html Adding pre-commit hook is better than adding editor-specific comments, because it doesn't require your editor to support the syntax - regardless of editor you will have to convert tabs file to spaces anyway. -- --anatoly t.
participants (15)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
anatoly techtonik -
Antoine Pitrou -
bharat satsangi -
Brett Cannon -
Georg Brandl -
Guido van Rossum -
Jeffrey Yasskin -
Kirk McDonald -
M.-A. Lemburg -
Miguel Lobo -
Scott Dial -
Steve Holden -
Sylvain Fourmanoit