On 5/28/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Brett Cannon schrieb:
> Unfortunately the pre-commit hook
> does not specify what line a change was made on so I have no clue where
> it is failing (maybe this should be added?).
It creates a reindent.Reindenter on the new contents, then
Martin v. Löwis schrieb:
>> As I said before, you don't really need that when you can (and should!) just
>> run
>> reindent.py over the source file yourself, not care about any diffs and just
>> resubmit.
>
> Right. So I withdraw my offer to do anything about the hook.
I think printing something
> As I said before, you don't really need that when you can (and should!) just
> run
> reindent.py over the source file yourself, not care about any diffs and just
> resubmit.
Right. So I withdraw my offer to do anything about the hook.
Regards,
Martin
___
Scott Dial schrieb:
> Martin v. Löwis wrote:
>> Brett Cannon schrieb:
>>> Unfortunately the pre-commit hook
>>> does not specify what line a change was made on so I have no clue where
>>> it is failing (maybe this should be added?).
>>
>> It creates a reindent.Reindenter on the new contents, then
Martin v. Löwis wrote:
> Brett Cannon schrieb:
>> Unfortunately the pre-commit hook
>> does not specify what line a change was made on so I have no clue where
>> it is failing (maybe this should be added?).
>
> It creates a reindent.Reindenter on the new contents, then invokes
> .run() on it, and
Brett Cannon schrieb:
> Unfortunately the pre-commit hook
> does not specify what line a change was made on so I have no clue where
> it is failing (maybe this should be added?).
It creates a reindent.Reindenter on the new contents, then invokes
.run() on it, and complains if that returns true. If
On 5/26/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
On 5/26/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>
> On 5/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Neal Norwitz schrieb:
> > > On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > >> In my bcannon-objcap branch I am trying to
On 5/26/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>
> On 5/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Neal Norwitz schrieb:
> > > On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > >> In my bcannon-objcap branch I am trying to check in a change that
> involves a
> > >> soft symlink
On 5/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
Neal Norwitz schrieb:
> On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> In my bcannon-objcap branch I am trying to check in a change that
involves a
>> soft symlink from Lib/controlled_importlib.py to
>> ../importlib/controlled_importlib
On 5/25/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> In my bcannon-objcap branch I am trying to check in a change that
involves a
> soft symlink from Lib/controlled_importlib.py to
> ../importlib/controlled_importlib.py through ``ln -s
> ../co
Neal Norwitz schrieb:
> On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> In my bcannon-objcap branch I am trying to check in a change that involves a
>> soft symlink from Lib/controlled_importlib.py to
>> ../importlib/controlled_importlib.py through ``ln -s
>> ../controlled_importlib.py contr
On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> In my bcannon-objcap branch I am trying to check in a change that involves a
> soft symlink from Lib/controlled_importlib.py to
> ../importlib/controlled_importlib.py through ``ln -s
> ../controlled_importlib.py controlled_importlib.py`` while i
In my bcannon-objcap branch I am trying to check in a change that involves a
soft symlink from Lib/controlled_importlib.py to
../importlib/controlled_importlib.py through ``ln -s
../controlled_importlib.py controlled_importlib.py`` while in the Lib
directory. I have done this before in this branc
> Just a little FYI, python-mode (the one Barry and I manage - dunno
> about the one distributed w/ GNU Emacs these days) is one of those
> tools that leaves trailing whitespace behind when advancing to the
> next line..
Okay, I figured this out. The dangling whitespace turds are
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Stripping trailing whitespace on saving wouldn't be
> so bad, though. Is there an option for that in python-mode?
I've got thje following in my ~/.emacs:
(if (fboundp 'delete-trailing-whitespace)
(add-hook 'write-file-hooks 'delete-trailing-whitespace
Martin v. Löwis schrieb:
>> Okay, attached is a pre-commit hook script for that purpose.
>
> How does that deal with deletions?
Ah, you'd have to look at the first two chars of every lines that
I cut away.
> What do you think about
> the attached alternative?
I'd say it's better since it uses t
> Okay, attached is a pre-commit hook script for that purpose.
How does that deal with deletions? What do you think about
the attached alternative?
Regards,
Martin
#!/usr/bin/env python
from svn import repos, fs, core
import sys
from StringIO import StringIO
from reindent import Reindenter
repos
>> Just a little FYI, python-mode (the one Barry and I manage - dunno
>> about the one distributed w/ GNU Emacs these days) is one of those
>> tools that leaves trailing whitespace behind when advancing to the
>> next line..
(See my earlier retraction...)
Greg> I get extremel
[EMAIL PROTECTED] wrote:
> Just a little FYI, python-mode (the one Barry and I manage - dunno about the
> one distributed w/ GNU Emacs these days) is one of those tools that leaves
> trailing whitespace behind when advancing to the next line..
I get extremely annoyed with editors that *don't* leav
[Skip]
> Just a little FYI, python-mode (the one Barry and I manage - dunno about the
> one distributed w/ GNU Emacs these days) is one of those tools that leaves
> trailing whitespace behind when advancing to the next line..
Shouldn't be -- unless the behavior of the Emacs newline-and-indent
has
On 08:15 pm, [EMAIL PROTECTED] wrote:
;; untabify and clean up lines with just whitespace
(defun baw-whitespace-normalization ()
Looks a lot like (whitespace-cleanup), if you've got the right
configuration. A function I've used many times :).
___
Py
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On 4/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
| > Well, there are editors that don't intelligently strip whitespace, so
that
| > people using them would be constantly pained by such a hook.
|
| And they should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 25, 2007, at 2:37 PM, [EMAIL PROTECTED] wrote:
>>> Well, there are editors that don't intelligently strip
>>> whitespace, so
>>> that people using them would be constantly pained by such a hook.
>
> Guido> And they should. There really is
[EMAIL PROTECTED] schrieb:
> skip> Just a little FYI, python-mode (the one Barry and I manage - dunno
> skip> about the one distributed w/ GNU Emacs these days) is one of those
> skip> tools that leaves trailing whitespace behind when advancing to the
> skip> next line..
>
> At lea
skip> Just a little FYI, python-mode (the one Barry and I manage - dunno
skip> about the one distributed w/ GNU Emacs these days) is one of those
skip> tools that leaves trailing whitespace behind when advancing to the
skip> next line..
At least so I thiought. I know I've seen th
On 4/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> Well, there are editors that don't intelligently strip whitespace, so
> >> that people using them would be constantly pained by such a hook.
>
> Guido> And they should. There really is no excuse for letting one
> Guido> d
[Skip]
> Maybe \s should expand to a single space by the lexer so people who want to
> rely on trailing spaces can be explicit about it. There already exists
> non-whitespace escape sequences for tabs and newlines.
Trailing whitspace is never significant on a code line, only inside a
multiline st
Tim> ... but only when the code mysteriously
Tim> relied on significant trailing whitespace in the .py file.
Maybe \s should expand to a single space by the lexer so people who want to
rely on trailing spaces can be explicit about it. There already exists
non-whitespace escape sequences
>> Well, there are editors that don't intelligently strip whitespace, so
>> that people using them would be constantly pained by such a hook.
Guido> And they should. There really is no excuse for letting one
Guido> developer's poor choice of tools cause later grief for all other
Guido van Rossum schrieb:
On 4/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
Well, there are editors that don't intelligently strip whitespace, so that
people using them would be constantly pained by such a hook.
And they should. There really is no excuse for letting one developer's
poor choi
> Well, there are editors that don't intelligently strip whitespace, so that
> people using them would be constantly pained by such a hook.
Those users can run reindent.py before checking in, or switch editors.
Regards,
Martin
___
Python-Dev mailing li
Neal Norwitz schrieb:
> I just checked in a whitespace normalization change that was way too
> big. Should this task be automated?
>
> Assuming the answer is yes, these are the questions should be answered:
> 1) Which branches should this occur on: trunk, 2.5 (last release), 3k
> 2) Should the
[Neal Norwitz]
> ...
> The way to fix the files is to run: python ./Tools/scripts/reindent.py -r Lib
I apply it to everything in the checkout. That is, I run reindent.py
from the root of my sandbox, and use "." instead of "Lib". The goal
is that every .py file (not just under Lib/) that eventua
On 4/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Well, there are editors that don't intelligently strip whitespace, so that
> people using them would be constantly pained by such a hook.
And they should. There really is no excuse for letting one developer's
poor choice of tools cause later gr
Steve Holden schrieb:
> Duncan Booth wrote:
>> "Neal Norwitz" <[EMAIL PROTECTED]> wrote in
>> news:[EMAIL PROTECTED]:
>>
>>> I just checked in a whitespace normalization change that was way too
>>> big. Should this task be automated?
>>
>> IMHO, changing whitespace retrospectively in a version
Facundo Batista schrieb:
> Georg Brandl wrote:
>
>> Of course, we could also setup a svn pre-commit hook that rejects trailing
>> whitespace >:->
>
> I was about to suggest a mail to python-checkins when a bad whitespace
> is detected, but had no idea that a pre-commit check existed in SVN.
>
>
Georg Brandl wrote:
> Of course, we could also setup a svn pre-commit hook that rejects trailing
> whitespace >:->
I was about to suggest a mail to python-checkins when a bad whitespace
is detected, but had no idea that a pre-commit check existed in SVN.
It'd be great if the system won't let yo
On Wed, Apr 25, 2007 at 08:40:22AM +0100, Duncan Booth wrote:
> IMHO, changing whitespace retrospectively in a version control system is a
> bad idea.
In my experience Duncan's assertion is absolutely true, and all the more
so in a project that maintains a large body of pending patches, as
Python
On Wednesday 25 April 2007, Steve Holden wrote:
> Duncan Booth wrote:
> > That way the whitespace ought to stay normalized so you shouldn't need a
> > separate cleanup step and you won't be breaking diff and blame for the
> > sources (and if the reindent does ever break anything it should be mo
Duncan Booth wrote:
> "Neal Norwitz" <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
>> I just checked in a whitespace normalization change that was way too
>> big. Should this task be automated?
>
> IMHO, changing whitespace retrospectively in a version control system is a
> bad idea
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> I just checked in a whitespace normalization change that was way too
> big. Should this task be automated?
IMHO, changing whitespace retrospectively in a version control system is a
bad idea.
How much overhead would it be t
Neal Norwitz schrieb:
> I just checked in a whitespace normalization change that was way too
> big. Should this task be automated?
>
> Assuming the answer is yes, these are the questions should be answered:
> 1) Which branches should this occur on: trunk, 2.5 (last release), 3k
> 2) Should the
I just checked in a whitespace normalization change that was way too
big. Should this task be automated?
Assuming the answer is yes, these are the questions should be answered:
1) Which branches should this occur on: trunk, 2.5 (last release), 3k
2) Should there be a special user for these che
43 matches
Mail list logo
