The point is, we have already that tab-for-logical-indetation-space-for
aligment for our C++ code. People are used to it, and it is known to
accomodate a wide range of personal preferences. People also obviously
have sufficiently capable editors, otherwise they'd be in trouble to
have there patche
On Tue, Jun 27, 2006 at 10:59:24AM -0500, Bo Peng wrote:
> >I still don't get why it should be dangerous, and since that rule exists
> >for
> >C++ already you have to configure your editor anyway, so I don't see the
> >problem. If you have an example where the C++ rule would be dangerous
> >please
Georg Baum wrote:
> Anyway, I think we should call python with the -tt flag. The attached
> patch does that, and is going in tomorrow unless I get objections.
This updated patch is going in now.
Georg
Log:
Call python with the -tt switch to make mixed tab/space indentation an error
So we have a problem if we use spaces only, and a similar one if we use
tabs. Nothing is gained here by the spaces only approach.
You are right, but I can always try to replace \t by spaces if
something suspicious happens. This can not be done for pure \t or
mixed \t and space.
You have not co
Am Dienstag, 27. Juni 2006 17:59 schrieb Bo Peng:
> The danger comes from the editors. There are times that you do not
> know what an editor will put, tab or space, so it is safer to always
> use space. For example, if you use vi to edit a .py file with spaces,
> and allow it to indent for you (wi
Dear all,
To comply to the python format recommendations, and make all lyx
python code consistent regarding indent size, I have just increased
the indent size of all python code from two to four (scons,
lib/configure.py, lib/scripts/*.py. New python code will of course use
this indent size.
Chee
I still don't get why it should be dangerous, and since that rule exists for
C++ already you have to configure your editor anyway, so I don't see the
problem. If you have an example where the C++ rule would be dangerous
please show it.
The danger comes from the editors. There are times that you
Bo Peng wrote:
> 8 is way too large. An indent of 4 will take almost half of the line
> size (<80). I can do 4, but object the idea of mixing tab and spaces.
You demonstrate the problem very well: 8 is way too large for you, but not
for me (I normally use full screen terminals). I don't want to f
Bo Peng wrote:
> Tab and spaces have their own advantages and disadvantages, mixing
> them usually make things worse, especially for python code when spaces
> and tabs are significant. For example, if you have
>
> four spacesb=2
> \ta=1
>
> python will yell and one can not always identify the pr
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > | An indent of 4 will take almost half of the line
| > | size (<80).
| >
| > ??
| > 4 takes only 5%
|
| I meant 4*8/80 = 40%.
I see.
| Take an example, line 114 of TeXFiles.py is at indent level 6,
Whot? level 6? refactor!! :-)
--
Lgb
| An indent of 4 will take almost half of the line
| size (<80).
??
4 takes only 5%
I meant 4*8/80 = 40%.
Take an example, line 114 of TeXFiles.py is at indent level 6, with
indent=2, the line width is 62, with indent=8, the line width will be
98.
Bo
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > The problem I have with space-only indentation is that I am used to a
| > tabwidth of 8, and find 2 difficult to read. With spaces only you force
| > everybody to use your choice of tabwidth.
|
| 8 is way too large.
My claim is that if 8 is to large for
The problem I have with space-only indentation is that I am used to a
tabwidth of 8, and find 2 difficult to read. With spaces only you force
everybody to use your choice of tabwidth.
8 is way too large. An indent of 4 will take almost half of the line
size (<80). I can do 4, but object the idea
One general comment: Right now, we have all sorts of indentation in .py
files (mainly two spaces, four spaces, and tabs).
Tab and spaces have their own advantages and disadvantages, mixing
them usually make things worse, especially for python code when spaces
and tabs are significant. For exampl
Jose' Matos wrote:
> The style that I follow (or that I try to follow) is:
> http://www.python.org/dev/peps/pep-0008/
>
> a lot more pythonic, after all python is not C++.
No, but I think that the concept of "logical indentation" vs. "alignment"
can be used in both languages.
The problem I
On Tuesday 27 June 2006 15:27, Georg Baum wrote:
> One general comment: Right now, we have all sorts of indentation in .py
> files (mainly two spaces, four spaces, and tabs).
>
> IMO we should use the same indentation rule as in C++ files: tabs for
> logical indentation, and spaces for alignment, e
One general comment: Right now, we have all sorts of indentation in .py
files (mainly two spaces, four spaces, and tabs).
IMO we should use the same indentation rule as in C++ files: tabs for
logical indentation, and spaces for alignment, e.g.
def xyz(abc):
if (abc == 0 and some_very_lon
I think that both are correct as both are valid paths on Windows.
However, for consistency with previous behavior and with the internal
representation used by LyX, you should replace \ with /.
I thought so. Committed.
Bo
On Mon, Jun 26, 2006 at 07:50:53PM -0500, Bo Peng wrote:
> Under cygwin, TexFiles.py and TexFiles.sh generate identical files.
You beat me at it...
> Under a dos prompt, using mingw/sh,
>
> sh TexFiles.sh generates
> C:/texmf/bibtex/bib/apacite/apa5ex.bib
> C:/texmf/bibtex/bib/base/test.bib
>
Under cygwin, TexFiles.py and TexFiles.sh generate identical files.
Under a dos prompt, using mingw/sh,
sh TexFiles.sh generates
C:/texmf/bibtex/bib/apacite/apa5ex.bib
C:/texmf/bibtex/bib/base/test.bib
while python TexFiles.py generates
C:/texmf/bibtex/bib\apacite\apa5ex.bib
C:/texmf/bibtex/bi
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Here is the first conversion. Please test if TexFiles.py generates
Bo> the same (after sort) list files under your platform.
I think you can get rid of the version number handling (this lives
inside lyx anyway) and of the weird comment.
JMarc
Bo Peng wrote:
> Here is the first conversion. Please test if TexFiles.py generates the
> same (after sort) list files under your platform.
>
> I will wait for confirmation from win/cygwin. The real 'svn ci' will
> use svn rename.
Please don't forget Makefile.am this time :-)
Georg
Here is the first conversion. Please test if TexFiles.py generates the
same (after sort) list files under your platform.
I will wait for confirmation from win/cygwin. The real 'svn ci' will
use svn rename.
Bo
Index: src/frontends/controllers/tex_helpers.C
=
23 matches
Mail list logo
