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 tabwidth of 4.
>
[snip]
>
> The '''-quoted doc strings are still also a problem for Emacs.
Psuedo-radical thoughts:
- Since emacs' auto-tab-detection almost works except when tabwidth is
4, would it be possible to fix 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?
Presumably, open source can be fixed. I know it's not easy, but there
are a lot of Pythoneers using emacs, so getting emacs to deal with the
full range of the Python language seems worthwhile. Given that emacs is
_almost_ working, I'd like to imagine that getting it to work wouldn't
be insane.
Who's that guy with the cold hands clutching emacs? ;-) Wouldn't he
like to be able to brag that emacs can handle any Python you throw at
it?
BTW here's the example I found just for reference.
<!--
# This is for Emacs' benefit:
# Local Variables: ***
# mode: fundamental ***
# tab-width: 3 ***
# End: ***
-->
No, I don't want to add stuff like that to every file. I was hoping
DIR/.emacs was read, but I confirmed with the emacs docs that it's not.
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 proclamation
because I'm curious how pydoc deals with different looking doc strings.
> * Absolutely wrap lines before 90 (particularly docstrings). The
> current codebase is absolutely full of run on lines.
Hmm, I'm inclined to let code lines run a little longer, say 130. We
presumably all have wide windows when doing serious development and
most editors allow wrapping or non-wrapping as you like.
> * Always """ instead of ''' for docstrings.
See my earlier comment.
> * Include a blank line before and after every docstring. This makes
> it much easier to re-wrap the docstrings when the content changes.
Do you mean:
def foo(self):
'''
Returns the foo of the bar.
'''
return math.sqrt(bar())
? I have a big distaste for this.
My pref is:
def foo(self):
'''
Returns the foo of the bar.
'''
return math.sqrt(bar())
> * If a method of function has lots of args list them one or two
> per-line, instead of having a huge run-on line.
Does "lots of args" mean past a certain column number or what?
> If these conventions were followed religously, and there was an
> automatic test to make sure a file was all tabs or all spaces upon
> CVS checkin, I'd shut up about SpacesNotTabs and happily work with
> whatever the original author of the module used. In fact, we really
> should be dealing with the line-wrapping rather than about tabs ;)
We'll get there. Let's keep the conversation going.
> That would be much easier than adding editor specific comments to
> every single file and remembering to do it on new files as well.
But should we cater to editors that can't handle the full range of
Python? Particularly when they're open source? (You know where I stand
on that one.)
-Chuck
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
