On Sunday 09 December 2001 02:40 pm, Tavis Rudd wrote:
> I'd forgotten about that pystats module, but I was planning to use
> checksrc.
>
> > Regarding new components, I was planning on making an EmptyKit that
> > people could just duplicate and then fill out.
>
> Same idea, but I'd like to made t
On Sun, 2001-12-09 at 15:18, Chuck Esterbrook wrote:
> On Sunday 09 December 2001 02:24 pm, Tavis Rudd wrote:
> > On Sunday 09 December 2001 12:58, Chuck Esterbrook wrote:
> > > I wish editors would pick up a .foorc in the directory of the
> > > edited file. This would pay off much larger.
> >
> >
On Sunday 09 December 2001 13:24, Chuck Esterbrook wrote:
> On Sunday 09 December 2001 02:28 pm, Tavis Rudd wrote:
> > Do you think such a tool would be worthwhile? Each command would
> > be implemented as separate class that parses its own options and
> > args, etc. The main script would just d
On Sunday 09 December 2001 02:28 pm, Tavis Rudd wrote:
> Do you think such a tool would be worthwhile? Each command would be
> implemented as separate class that parses its own options and args,
> etc. The main script would just dispatch the commands.
Sure. Please visit Webware's bin/checksrc.p
On Sunday 09 December 2001 02:24 pm, Tavis Rudd wrote:
> On Sunday 09 December 2001 12:58, Chuck Esterbrook wrote:
> > I wish editors would pick up a .foorc in the directory of the
> > edited file. This would pay off much larger.
>
> I wish we had an extensible editor written in Python and Qt. Th
On Sunday 09 December 2001 12:47, you wrote:
> I wasn't aware of this. We're not supposed to be mixing tabs and
> spaces at all. I'll run checksrc.py soon and at least fix that.
BTW, I've started working on a little command line tool, called
"/usr/bin/webware" for the time-being, that will give
On Sunday 09 December 2001 12:58, Chuck Esterbrook wrote:
> I wish editors would pick up a .foorc in the directory of the
> edited file. This would pay off much larger.
I wish we had an extensible editor written in Python and Qt. Then
we'd just be able to configure to our hearts extent! With Q
On Sunday 09 December 2001 12:42 pm, Mike Orr wrote:
> Regarding tabs vs spaces, I don't know, there's no one ideal answer.
> Universal compatibility argues for using tabs--that is what the tab
> key and \t are for anyway---with tabstops at 8 columns. On the other
> hand, this encourages mixing t
On Saturday 08 December 2001 12:27 pm, Clark C . Evans wrote:
> So. If you set your tab-stop every 4 columns, it
> can cause you no end of grief. Some of the
> recent webware code i've used relies on above
> rules..., there are numerous "\n \t" lines.
> If you do a tab expansion
On Sun, Dec 09, 2001 at 11:00:11AM -0800, Chuck Esterbrook wrote:
> Also, instead of changing how I code in Python, shouldn't editors like
> emacs do the right thing? Python is the first language I've used where
> I was expected to cater to a single editor (and one with source)
> instead of exp
On Sun, 2001-12-09 at 13:00, Chuck Esterbrook wrote:
> Scaling everything down to the most extreme people (the guy using an 80
> column terminal who prints and e-mails all of his code) hurts for those
> who aren't (those with the space, the friendly editor and the
> inclination to use them). Wh
---> I'd be happy to settle for 90 columns.
On Sunday 09 December 2001 11:28, Chuck Esterbrook wrote:
> On Sunday 09 December 2001 11:57 am, Tavis Rudd wrote:
> > On Sunday 09 December 2001 08:13, Chuck Esterbrook wrote:
> > > On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote:
> > > > Th
On Sunday 09 December 2001 11:57 am, Tavis Rudd wrote:
> On Sunday 09 December 2001 08:13, Chuck Esterbrook wrote:
> > On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote:
> > > That's the whole point, many tools are designed on this
> > > assumption and have dockbars down the left side or use
On Sunday 09 December 2001 10:36 am, Ian Bicking wrote:
> And why should I? And not just me, but everyone else? There's
> *nothing wrong* with standard Python conventions! Why can't we just
> use those?
>
> I am going to keep writing my code pretty much to Python coding
> standards, because I t
On Sunday 09 December 2001 08:13, Chuck Esterbrook wrote:
> On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote:
> > That's the whole point, many tools are designed on this
> > assumption and have dockbars down the left side or use multiple
> > vertical frames. 80 might be a bit zealous, but c
On Sun, 2001-12-09 at 10:13, Chuck Esterbrook wrote:
> In general, I'm not seeing that tools are designed around the
> assumption that text files stop at 80 columns.
>
> In all three products, sizing the window to be wide enough for 130
> characters actually felt excessive to me, but 110-120 fe
On Saturday 08 December 2001 10:03 am, Ian Bicking wrote:
> tell that there were semantic differences in some instances. In the
> case of Emacs, wrapped lines get cut off at exactly 80 (or whatever
> width your window is), without any attention to word boundaries. I
> imagine lots of editors are
I have $.02 to contribute:
1. According to the python spec, a TAB moves the column
to the nearest multiple of 8. Therefore,
"\n \t" and "\n\t" and "\n \t" and
"\n" are all considered equivalent under
the python parse rules.
So. If you set your tab-stop ev
On Saturday 08 December 2001 06:26, Geoffrey Talvola wrote:
> On Friday December 07, 2001 09:38 pm, Tavis Rudd wrote:
> > Yes, but narrow columns are easier to read and 80 columns is
> > easier to deal with on terminals and in source code listings
> > (i.e. pydoc)
>
> I agree with Chuck on this on
On Fri, 2001-12-07 at 18:58, Chuck Esterbrook wrote:
> On Friday 07 December 2001 02:30 pm, Ian Bicking wrote:
> > I've also found that as long as I leave the tabwidth at 8, the
> > auto-tab-detection works correctly -- i.e., Emacs inserts tabs in
> > files that use tabs, and spaces in files that
On Friday December 07, 2001 09:38 pm, Tavis Rudd wrote:
> On Friday 07 December 2001 16:58, Chuck Esterbrook wrote:
> > On Friday 07 December 2001 05:06 pm, Tavis Rudd wrote:
> > > * Try to wrap lines at 80 columns (1 tab = 8 columns)
> >
> > I'm amenable to that. I was just procrastinating on a p
On Friday 07 December 2001 16:58, Chuck Esterbrook wrote:
> > The '''-quoted doc strings are still also a problem for Emacs.
> - Since emacs already handles multi-line strings with double
> quotes, would it be possible to fix it to handle multi-line strings
> with single quotes?
As far as I know
On Friday 07 December 2001 04:08 pm, Darryl VanDorp wrote:
> -Original Message-
> what editor do you guys use when programming python?
> Linux preferred...
http://webware.colorstudy.net/twiki/bin/view/Webware/TextEditors
___
Webware-devel maili
On Friday 07 December 2001 02:30 pm, Ian Bicking wrote:
> I've also found that as long as I leave the tabwidth at 8, the
> auto-tab-detection works correctly -- i.e., Emacs inserts tabs in
> files that use tabs, and spaces in files that use spaces. I don't
> know why it doesn't work with a tabwid
-Original Message-
what editor do you guys use when programming python?
Linux preferred...
Thanks
-darryl
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
Chuck,
like Ian said it works fine if you set the tab width to 8 instead of
4. This is the default, in fact. The problem then, however, is that
the line wrapping is totally screwed up.
This wouldn't be such a problem (and we wouldn't complain so much) if
several other conventions were foll
On Friday 07 December 2001 14:30, Ian Bicking wrote:
> The '''-quoted doc strings are still also a problem for Emacs.
Those and the unwrapped lines (usually docstrings) actually bother me
much more than the tabs.
___
Webware-devel mailing list
[EMAI
On Fri, Dec 07, 2001 at 01:38:52PM -0800, Chuck Esterbrook wrote:
> Okay, on more positive note without getting into flamewars again, I
> have been thinking the following, but need help from emacs users in the
> answers:
>
> - Recently, I saw a text file where someone included special comments
On Thursday 06 December 2001 08:16 pm, Tavis Rudd wrote:
> It seems we're not the only ones having this debate:
>
> http://groups.google.com/groups?hl=en&threadm=pan.2001.12.06.13.23.30
>.752127.1733%40uchicago.edu&prev=/groups%3Fhl%3Den%26group%3Dcomp.lang
>.python
>
> ;)
Okay, on more positive
Google has changed their interface -- that new tree view is quite
nice. Especially the little orange bar to indicate where in the
thread you are. I haven't seen that before.
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge
30 matches
Mail list logo
