(some time ago), the loading of files with commandline didn't work.
"C:\eigene dateien\python\drpython\drpython.py" --preferencesbasepath=c:/
it is ok argv [0] (C:\eigene dateien\python\drpython\drpython.py), argv [1] --preferencesbasepath=c:/
but if i make a shortcuts on the desktop:"C:\eigene dateien\python\drpython\drpython.py" --preferencesbasepath=c:/
then argv[0](C:\eigene dateien\python\drpython\drpython.py)
!!!!argv[1](C:\eigene dateien\python\drpython\drpython.py) !!!!
argv[2] --preferencesbasepath=c:/
strange
Uncomment for cpp files don't work:
I found the line:
if not ((not (prestyle == wx.stc.STC_P_COMMENTLINE) and not (prestyle == wx.stc.STC_P_COMMENTBLOCK)) and ((style == wx.stc.STC_P_COMMENTLINE) or (style == wx.stc.STC_P_COMMENTBLOCK))):
newtext += line
but in cpp there is
wx.stc.STC_C_COMMENTLINE, wx.stc.STC_C_COMMENTBLOCK ...
(it is only queried for Python Styles)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I could not replicate any problems with the command line.
As for commenting, I fixed this. However this leads to a new question:
How well should drpython support other languages?
Aside from the fact that there are other editors infinitely more suited to working in c/c++ (cough emacs cough),
Many things, such as the source browser, are keyed just to python.
On the other hand, editing c/c++ can be a vital part of python programming (writing modules).
In addition, mixing python with html/xml is also quite important.
What thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, my mistake, I haven't seen in the link, that
this was actually two times there.
>How well should drpython support other languages?
Hmm, I could imagine to reserve a template function
for instance for the source browser (If ever someone needs this).
If this is a non python file, then there could be
a plugin for example for cpp files.
I, for me, it is actually enough support for C++ now.
I don't and didn't expect a c++ editor of course.
Although I think to let the door open to add
(easy) another language would be fine.
(to set a lexer, and the things, which you have
already built in in "filetype", which one could
make it, that the user can add new fileextesnsions and lexer; if ever needed).
I think, C, Python und HTML/XML covers the most
wanted languages for people, who want a python
editor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1)to not query the style (in the uncomment), and simply query for the comment char?
2) in comment and uncomment: remember the pos of
selection start or end, or if no selection, of the current
cursor pos, and after the (un)comment, to jump
to the oldpos back?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(some time ago), the loading of files with commandline didn't work.
"C:\eigene dateien\python\drpython\drpython.py" --preferencesbasepath=c:/
it is ok argv [0] (C:\eigene dateien\python\drpython\drpython.py), argv [1] --preferencesbasepath=c:/
but if i make a shortcuts on the desktop:"C:\eigene dateien\python\drpython\drpython.py" --preferencesbasepath=c:/
then argv[0](C:\eigene dateien\python\drpython\drpython.py)
!!!!argv[1](C:\eigene dateien\python\drpython\drpython.py) !!!!
argv[2] --preferencesbasepath=c:/
strange
Uncomment for cpp files don't work:
I found the line:
if not ((not (prestyle == wx.stc.STC_P_COMMENTLINE) and not (prestyle == wx.stc.STC_P_COMMENTBLOCK)) and ((style == wx.stc.STC_P_COMMENTLINE) or (style == wx.stc.STC_P_COMMENTBLOCK))):
newtext += line
but in cpp there is
wx.stc.STC_C_COMMENTLINE, wx.stc.STC_C_COMMENTBLOCK ...
(it is only queried for Python Styles)
I could not replicate any problems with the command line.
As for commenting, I fixed this. However this leads to a new question:
How well should drpython support other languages?
Aside from the fact that there are other editors infinitely more suited to working in c/c++ (cough emacs cough),
Many things, such as the source browser, are keyed just to python.
On the other hand, editing c/c++ can be a vital part of python programming (writing modules).
In addition, mixing python with html/xml is also quite important.
What thoughts?
Oops, my mistake, I haven't seen in the link, that
this was actually two times there.
>How well should drpython support other languages?
Hmm, I could imagine to reserve a template function
for instance for the source browser (If ever someone needs this).
If this is a non python file, then there could be
a plugin for example for cpp files.
I, for me, it is actually enough support for C++ now.
I don't and didn't expect a c++ editor of course.
Although I think to let the door open to add
(easy) another language would be fine.
(to set a lexer, and the things, which you have
already built in in "filetype", which one could
make it, that the user can add new fileextesnsions and lexer; if ever needed).
I think, C, Python und HTML/XML covers the most
wanted languages for people, who want a python
editor.
It would be cool, if the cursor stays after uncomment on the first column (as it is in comment)
I would simply add at the end of uncommentregion:
self.txtDocument.CmdKeyExecute(wx.stc.STC_CMD_HOMEDISPLAY)
Would it make sense:
1)to not query the style (in the uncomment), and simply query for the comment char?
2) in comment and uncomment: remember the pos of
selection start or end, or if no selection, of the current
cursor pos, and after the (un)comment, to jump
to the oldpos back?
Could we add into CopyCurrentFilename.py, so
there are all C Styles available?
stc.StyleSetSpec(wx.stc.STC_C_IDENTIFIER, frame.prefs.txtDocumentStyleDictionary[0])
stc.StyleSetSpec(wx.stc.STC_C_COMMENTLINEDOC, frame.prefs.txtDocumentStyleDictionary[6])
stc.StyleSetSpec(wx.stc.STC_C_GLOBALCLASS, frame.prefs.txtDocumentStyleDictionary[0])
stc.StyleSetSpec(wx.stc.STC_C_COMMENTDOCKEYWORD, frame.prefs.txtDocumentStyleDictionary[6])
stc.StyleSetSpec(wx.stc.STC_C_COMMENTDOCKEYWORDERROR, frame.prefs.txtDocumentStyleDictionary[6])
oops, in drKeywords.py I meant.