Indentation Defaults?
Brought to you by:
drpython
Menu
▾
▴
What do folks think the defaults should be for indentation type, and indentation size?
Right now, it is tabs by default, and the size is 4.
It looks like idle uses spaces by default, and the size is 8.
What thoughts? This can cause python programs with mixed spacing to display either correctly or incorrectly.
Incidently, what should drpy do when it opens a file with mixed spacing?
1. Nothing, it's fine now
2. Alert the user with a dialog.
3. Ignore indentation type throughout the document
I personally don't like indenation with 8.
The source grows to fast to the right side.
I think, it is fine (with the display of mixed in the statusbar)
One thing:
if a line containes only tabs and onle begins with:
.->def ... (space and tab) then mixed is displayed; ok
but if a line begins with
->.def: then still tabs is displayed in the statusbar.
I think, this is not ok.
For the lineendings, it would be also helpful to have
a check in OnPositionChanged as it is with tab.
If it doesn't slow down the editor.
Else in Edit Menu, whitespace a check line endings
menu entry could also be an option.
One thing, I saw: I have a line, with one line, which
ends with crlf, and in the status line, "UNIX" is displayed.
Just now I saw, this happens only, if this file was opened with Last Sessions.
If you open it in the editor, "WIN" is displayed.
I got the indentation bit fixed.
I will have to get around to fixing sessions (I have a bugreport from Dan I still need to get to).
I also got the dialog for find (continue) to close on esc (this was a mess, since two methods for doing this on linux did not work at all on windows, so I opted for the easy way out and just switched to ok/cancel, which handles esc by default).
Have you noticed a situation where you change the line ending type, and it is not reflected in the statustext properly?
Looks like pasting from a win to a unix file does the trick.
I'll look into this.
What I need to do is overhaul the statustext bit entirely.
The slowdown is really unnacceptable, and the line endings are not currently reflected accurately, just the line ending mode (set in stc as eolmode).
I'll go over the code, and hopefully come up with something a bit better (I have an idea for how to cut down the tab code overhead by a lot except in situations where you delete sepcific types of text, and I will probably be able to apply it to the line ending code).
So, it turns out the line ending stuff is one very silly bug in setDocumentTo (when updatePrefsMDI is called).
Fixed, and no need to check eols throughout the document!
Plus, I think I may have an algorithm that will speed up indentation checking considerably.