Hello list,
I think I found a bug or two othree . . ., but am not sure. So I first write to the list. I hope this is the right place.
I have an apt-get install of Geany 0.19.1 and installed a theme from here:
http://www.barryvan.com.au/2009/01/geany-ide-tango-dark-colour-scheme/
I did this more or less before I really used geany. But I think some of the issues started first after the theme was applied. I also created a filetype.common as mentioned in the comments of the link above.
I installed a Virtual Machine Ubuntu 10.10 (same as my workstation) and tested the 'fresh' version against the one I use:
1. Issue
In an Editor such as gedit or Editra as well as in Geany you can mark a text and replace it with anything you have in your clipboard. The usual linux behavior would be to copy the marked text to the clipboard, so ctrl+v-ing would simply replace the marked text with itself. After installing the above theme however, the behavior changes from Editor like to usual. Which is quite inconvenient.
2. Issue
I have some issues with indentation while coding. I code in python. Pressing Enter after a colon results in the next line being indented using tabs. But my settings are to use spaces. Pressing Enter after a 'regular' line, the indentation is done using spaces. So I guess there is some problem with the implementation for python/colon. Python sometimes really get's finicky about mixing spaces and tabs.
3. Issue
Is again related to the theme, after testing this in the VM. Auto completing/adding for parenthesis does not work with the theme. With the 'fresh' Geany closing parenthesis is added just as it should be, with the theme it's not. Curly and square braces are added without difficulty.
4. Issue
Might be related to no.2. Though the settings are set to use spaces, pressing tab inserts a tab and even converts preceding spaces in groups of $tabwidth into tabs Moving multiple lines at once with tab, also inserts and converts spaces to tabs. This seems not to be related to the theme as well.
So I don't know if these are 'bugs', so if someone know's anything about it, please let me know. Especially if it is a bug, that might already been filed as one.
Regards Phil
On 20 January 2011 21:36, Philipp Kalder pkalder@googlemail.com wrote:
Hello list, I think I found a bug or two othree . . ., but am not sure. So I first write to the list. I hope this is the right place. I have an apt-get install of Geany 0.19.1 and installed a theme from here: http://www.barryvan.com.au/2009/01/geany-ide-tango-dark-colour-scheme/ I did this more or less before I really used geany. But I think some of the issues started first after the theme was applied. I also created a filetype.common as mentioned in the comments of the link above. I installed a Virtual Machine Ubuntu 10.10 (same as my workstation) and tested the 'fresh' version against the one I use:
- Issue
In an Editor such as gedit or Editra as well as in Geany you can mark a text and replace it with anything you have in your clipboard. The usual linux behavior would be to copy the marked text to the clipboard, so ctrl+v-ing would simply replace the marked text with itself. After installing the above theme however, the behavior changes from Editor like to usual. Which is quite inconvenient.
Don't know how the theme affects this?? What does a fresh version on the actual workstation do? After all a VM may not have tweaks you added to your normal environment and certainly does not have same GUI drivers.
- Issue
I have some issues with indentation while coding. I code in python. Pressing Enter after a colon results in the next line being indented using tabs. But my settings are to use spaces. Pressing Enter after a 'regular' line, the indentation is done using spaces. So I guess there is some problem with the implementation for python/colon. Python sometimes really get's finicky about mixing spaces and tabs.
This works for me, did you force the preference to apply to already open documents? Just setting the preference won't change the setting for already open documents unless you force it (see note at top of preference page)
- Issue
Is again related to the theme, after testing this in the VM. Auto completing/adding for parenthesis does not work with the theme. With the 'fresh' Geany closing parenthesis is added just as it should be, with the theme it's not. Curly and square braces are added without difficulty.
Again don't see how this is to do with the theme, more likely system configuration being different to the VM.
- Issue
Might be related to no.2. Though the settings are set to use spaces, pressing tab inserts a tab and even converts preceding spaces in groups of $tabwidth into tabs Moving multiple lines at once with tab, also inserts and converts spaces to tabs. This seems not to be related to the theme as well.
See comment above, behaves as you describe even with pref changed unless the change is applied to the open file.
Cheers Lex
So I don't know if these are 'bugs', so if someone know's anything about it, please let me know. Especially if it is a bug, that might already been filed as one. Regards Phil _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hello,
thanks for the quick reply:
On Thu, Jan 20, 2011 at 12:21 PM, Lex Trotman elextr@gmail.com wrote:
On 20 January 2011 21:36, Philipp Kalder pkalder@googlemail.com wrote:
Hello list, I think I found a bug or two othree . . ., but am not sure. So I first
write
to the list. I hope this is the right place. I have an apt-get install of Geany 0.19.1 and installed a theme from
here:
http://www.barryvan.com.au/2009/01/geany-ide-tango-dark-colour-scheme/ I did this more or less before I really used geany. But I think some of
the
issues started first after the theme was applied. I also created a filetype.common as mentioned in the comments of the link above. I installed a Virtual Machine Ubuntu 10.10 (same as my workstation) and tested the 'fresh' version against the one I use:
- Issue
In an Editor such as gedit or Editra as well as in Geany you can mark a
text
and replace it with anything you have in your clipboard. The usual linux behavior would be to copy the marked text to the
clipboard,
so ctrl+v-ing would simply replace the marked text with itself. After installing the above theme however, the behavior changes from
Editor
like to usual. Which is quite inconvenient.
Don't know how the theme affects this?? What does a fresh version on the actual workstation do? After all a VM may not have tweaks you added to your normal environment and certainly does not have same GUI drivers.
The thing is, if I copy away the filetypes.python I use, or copy one from /usr/share/geany to .config/geany/filedefs and restart Geany, it behaves as expected, what I labled 'Editor'-Style.
So even considering the differences between a VM and the actual workstation, I can change the behavior even on the workstation alone. And the trigger seems to be using a different filetypes.python. So let me rephrase:
When changing the filetypes.python I use, the behavior changes. I always quit Geany before I make changes like that and start it only after it's finished. the identifiers attribute was not set as well as the lexer_properties section was not defined. I took those from the /usr/share/geany file and added them. I also changed certain colors, to have a more dark blue background. But again, the behavior is 'usual' style.
- Issue
I have some issues with indentation while coding. I code in python.
Pressing
Enter after a colon results in the next line being indented using tabs. But my settings are to use spaces. Pressing Enter after a 'regular' line, the indentation is done using spaces. So I guess there is some problem with the implementation for
python/colon.
Python sometimes really get's finicky about mixing spaces and tabs.
This works for me, did you force the preference to apply to already open documents? Just setting the preference won't change the setting for already open documents unless you force it (see note at top of preference page)
Do you refer to http://www.geany.org/manual/current/index.html#preferences
and the statement about changes under the 'Document' Tab?
Anyway, I restarted Geany after changing settings. They showed up as I set there.
Preferences Dialog -> Editor TAB Indentation: Type Spaces
But don't seem to apply. Just to be sure, we are talking about the same: A sample, I have 'Show whitespaces' active at all times:
. . . . if xmldoc.getElementsByTagName('ns3:message') == 'broken symlink': <hitting enter results in> ----->---->print "The symlink is broken"
However, I've just had a look at the options under the Documents Tab and found that
Indent Type
was set to Tabs and space although my Settings in the Preferences Dialog show it as spaces. Changing it there, solves this. It also keeps this set after restarting Geany. Though this is the opposite of what it say's in the Geany manual:
"The settings under the Document menu, however, are only for the current document and revert to defaults when restarting Geany."
So I'm not sure whether this is a bug or just a 'glitch', but changing the filetypes.python changed this behavior as well.
- Issue
Is again related to the theme, after testing this in the VM. Auto completing/adding for parenthesis does not work with the theme. With the 'fresh' Geany closing parenthesis is added just as it should be, with the theme it's not. Curly and square braces are added without difficulty.
Again don't see how this is to do with the theme, more likely system configuration being different to the VM.
Also again, any suggestions on which system config element could possibly influence the behavior of the editor? I purged and reinstalled Geany, put the filetypes.* back in place and started the Editor, same picture. Though I have to admit, that the purging seems not to have been as thorough as I wished. After starting the editor, the last opened files reappeared.
- Issue
Might be related to no.2. Though the settings are set to use spaces, pressing tab inserts a tab and even converts preceding spaces in groups
of
$tabwidth into tabs Moving multiple lines at once with tab, also inserts and converts spaces
to
tabs. This seems not to be related to the theme as well.
See comment above, behaves as you describe even with pref changed unless the change is applied to the open file.
I'll gibe the version 0.20 a try. Lets see what this brings.
Thanks again. Phil
Cheers Lex
So I don't know if these are 'bugs', so if someone know's anything about
it,
please let me know. Especially if it is a bug, that might already been filed as one. Regards Phil _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Same thing with version 0.20. But I guess this might be related to the fact that it uses the same preferences.
Regards Phil
On Thu, Jan 20, 2011 at 2:40 PM, Philipp Kalder pkalder@googlemail.comwrote:
Hello,
thanks for the quick reply:
On Thu, Jan 20, 2011 at 12:21 PM, Lex Trotman elextr@gmail.com wrote:
On 20 January 2011 21:36, Philipp Kalder pkalder@googlemail.com wrote:
Hello list, I think I found a bug or two othree . . ., but am not sure. So I first
write
to the list. I hope this is the right place. I have an apt-get install of Geany 0.19.1 and installed a theme from
here:
http://www.barryvan.com.au/2009/01/geany-ide-tango-dark-colour-scheme/ I did this more or less before I really used geany. But I think some of
the
issues started first after the theme was applied. I also created a filetype.common as mentioned in the comments of the link above. I installed a Virtual Machine Ubuntu 10.10 (same as my workstation) and tested the 'fresh' version against the one I use:
- Issue
In an Editor such as gedit or Editra as well as in Geany you can mark a
text
and replace it with anything you have in your clipboard. The usual linux behavior would be to copy the marked text to the
clipboard,
so ctrl+v-ing would simply replace the marked text with itself. After installing the above theme however, the behavior changes from
Editor
like to usual. Which is quite inconvenient.
Don't know how the theme affects this?? What does a fresh version on the actual workstation do? After all a VM may not have tweaks you added to your normal environment and certainly does not have same GUI drivers.
The thing is, if I copy away the filetypes.python I use, or copy one from /usr/share/geany to .config/geany/filedefs and restart Geany, it behaves as expected, what I labled 'Editor'-Style.
So even considering the differences between a VM and the actual workstation, I can change the behavior even on the workstation alone. And the trigger seems to be using a different filetypes.python. So let me rephrase:
When changing the filetypes.python I use, the behavior changes. I always quit Geany before I make changes like that and start it only after it's finished. the identifiers attribute was not set as well as the lexer_properties section was not defined. I took those from the /usr/share/geany file and added them. I also changed certain colors, to have a more dark blue background. But again, the behavior is 'usual' style.
- Issue
I have some issues with indentation while coding. I code in python.
Pressing
Enter after a colon results in the next line being indented using tabs. But my settings are to use spaces. Pressing Enter after a 'regular'
line,
the indentation is done using spaces. So I guess there is some problem with the implementation for
python/colon.
Python sometimes really get's finicky about mixing spaces and tabs.
This works for me, did you force the preference to apply to already open documents? Just setting the preference won't change the setting for already open documents unless you force it (see note at top of preference page)
Do you refer to http://www.geany.org/manual/current/index.html#preferences
and the statement about changes under the 'Document' Tab?
Anyway, I restarted Geany after changing settings. They showed up as I set there.
Preferences Dialog -> Editor TAB Indentation: Type Spaces
But don't seem to apply. Just to be sure, we are talking about the same: A sample, I have 'Show whitespaces' active at all times:
. . . . if xmldoc.getElementsByTagName('ns3:message') == 'broken symlink':
<hitting enter results in> ----->---->print "The symlink is broken"
However, I've just had a look at the options under the Documents Tab and found that
Indent Type
was set to Tabs and space although my Settings in the Preferences Dialog show it as spaces. Changing it there, solves this. It also keeps this set after restarting Geany. Though this is the opposite of what it say's in the Geany manual:
"The settings under the Document menu, however, are only for the current document and revert to defaults when restarting Geany."
So I'm not sure whether this is a bug or just a 'glitch', but changing the filetypes.python changed this behavior as well.
- Issue
Is again related to the theme, after testing this in the VM. Auto completing/adding for parenthesis does not work with the theme. With the 'fresh' Geany closing parenthesis is added just as it should
be,
with the theme it's not. Curly and square braces are added without difficulty.
Again don't see how this is to do with the theme, more likely system configuration being different to the VM.
Also again, any suggestions on which system config element could possibly influence the behavior of the editor? I purged and reinstalled Geany, put the filetypes.* back in place and started the Editor, same picture. Though I have to admit, that the purging seems not to have been as thorough as I wished. After starting the editor, the last opened files reappeared.
- Issue
Might be related to no.2. Though the settings are set to use spaces, pressing tab inserts a tab and even converts preceding spaces in groups
of
$tabwidth into tabs Moving multiple lines at once with tab, also inserts and converts spaces
to
tabs. This seems not to be related to the theme as well.
See comment above, behaves as you describe even with pref changed unless the change is applied to the open file.
I'll gibe the version 0.20 a try. Lets see what this brings.
Thanks again. Phil
Cheers Lex
So I don't know if these are 'bugs', so if someone know's anything about
it,
please let me know. Especially if it is a bug, that might already been filed as one. Regards Phil _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Another note:
I just discovered that I have another file open in which adding ) works. But not adding ] . . . Just another python script. Maybe If I . . .
(away, checking something . . . .)
Ok, not so. I thought closing all open files, then closing geany. Restarting it and then reopen the files would do the trick.
But this remains a mystery, sorry. I don't think any system settings result in a behavior like this. One script has closing parenthesis not auto added, though set, the other has, but the other misses this for square brackets.
Regards Phil
On Thu, Jan 20, 2011 at 2:47 PM, Philipp Kalder pkalder@googlemail.comwrote:
Same thing with version 0.20. But I guess this might be related to the fact that it uses the same preferences.
Regards Phil
On Thu, Jan 20, 2011 at 2:40 PM, Philipp Kalder pkalder@googlemail.comwrote:
Hello,
thanks for the quick reply:
On Thu, Jan 20, 2011 at 12:21 PM, Lex Trotman elextr@gmail.com wrote:
On 20 January 2011 21:36, Philipp Kalder pkalder@googlemail.com wrote:
Hello list, I think I found a bug or two othree . . ., but am not sure. So I first
write
to the list. I hope this is the right place. I have an apt-get install of Geany 0.19.1 and installed a theme from
here:
http://www.barryvan.com.au/2009/01/geany-ide-tango-dark-colour-scheme/ I did this more or less before I really used geany. But I think some of
the
issues started first after the theme was applied. I also created a filetype.common as mentioned in the comments of the link above. I installed a Virtual Machine Ubuntu 10.10 (same as my workstation) and tested the 'fresh' version against the one I use:
- Issue
In an Editor such as gedit or Editra as well as in Geany you can mark a
text
and replace it with anything you have in your clipboard. The usual linux behavior would be to copy the marked text to the
clipboard,
so ctrl+v-ing would simply replace the marked text with itself. After installing the above theme however, the behavior changes from
Editor
like to usual. Which is quite inconvenient.
Don't know how the theme affects this?? What does a fresh version on the actual workstation do? After all a VM may not have tweaks you added to your normal environment and certainly does not have same GUI drivers.
The thing is, if I copy away the filetypes.python I use, or copy one from /usr/share/geany to .config/geany/filedefs and restart Geany, it behaves as expected, what I labled 'Editor'-Style.
So even considering the differences between a VM and the actual workstation, I can change the behavior even on the workstation alone. And the trigger seems to be using a different filetypes.python. So let me rephrase:
When changing the filetypes.python I use, the behavior changes. I always quit Geany before I make changes like that and start it only after it's finished. the identifiers attribute was not set as well as the lexer_properties section was not defined. I took those from the /usr/share/geany file and added them. I also changed certain colors, to have a more dark blue background. But again, the behavior is 'usual' style.
- Issue
I have some issues with indentation while coding. I code in python.
Pressing
Enter after a colon results in the next line being indented using tabs. But my settings are to use spaces. Pressing Enter after a 'regular'
line,
the indentation is done using spaces. So I guess there is some problem with the implementation for
python/colon.
Python sometimes really get's finicky about mixing spaces and tabs.
This works for me, did you force the preference to apply to already open documents? Just setting the preference won't change the setting for already open documents unless you force it (see note at top of preference page)
Do you refer to http://www.geany.org/manual/current/index.html#preferences
and the statement about changes under the 'Document' Tab?
Anyway, I restarted Geany after changing settings. They showed up as I set there.
Preferences Dialog -> Editor TAB Indentation: Type Spaces
But don't seem to apply. Just to be sure, we are talking about the same: A sample, I have 'Show whitespaces' active at all times:
. . . . if xmldoc.getElementsByTagName('ns3:message') == 'broken symlink':
<hitting enter results in> ----->---->print "The symlink is broken"
However, I've just had a look at the options under the Documents Tab and found that
Indent Type
was set to Tabs and space although my Settings in the Preferences Dialog show it as spaces. Changing it there, solves this. It also keeps this set after restarting Geany. Though this is the opposite of what it say's in the Geany manual:
"The settings under the Document menu, however, are only for the current document and revert to defaults when restarting Geany."
So I'm not sure whether this is a bug or just a 'glitch', but changing the filetypes.python changed this behavior as well.
- Issue
Is again related to the theme, after testing this in the VM. Auto completing/adding for parenthesis does not work with the theme. With the 'fresh' Geany closing parenthesis is added just as it should
be,
with the theme it's not. Curly and square braces are added without difficulty.
Again don't see how this is to do with the theme, more likely system configuration being different to the VM.
Also again, any suggestions on which system config element could possibly influence the behavior of the editor? I purged and reinstalled Geany, put the filetypes.* back in place and started the Editor, same picture. Though I have to admit, that the purging seems not to have been as thorough as I wished. After starting the editor, the last opened files reappeared.
- Issue
Might be related to no.2. Though the settings are set to use spaces, pressing tab inserts a tab and even converts preceding spaces in groups
of
$tabwidth into tabs Moving multiple lines at once with tab, also inserts and converts
spaces to
tabs. This seems not to be related to the theme as well.
See comment above, behaves as you describe even with pref changed unless the change is applied to the open file.
I'll gibe the version 0.20 a try. Lets see what this brings.
Thanks again. Phil
Cheers Lex
So I don't know if these are 'bugs', so if someone know's anything
about it,
please let me know. Especially if it is a bug, that might already been filed as one. Regards Phil _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hi Phil,
Indentation is a tricky subject, there are so many standards that we can each have one...
... so to summarize as much for my benefit as anyones.
Document->indent type
Shows and sets the indent type which is currently being used for the current file, this is per file and is not saved when the file is closed since there is nowhere to save it per file. It is saved and restored with the session if Geany is closed with the file open.
Edit->preferences->editor
This sets the type to use with a new file or when opening a file if "detect from file" is not set. If "detect from file" is set then Geany tries to decide from what it finds in the first part of the file when it is first opened. This value becomes the Document->indent type for the new/opened file. There is a menu item to apply this default to all open files under project. I might suggest moving this under tools, its not really project related.
AFAICT this seems to be working properly in 0.20 for Python.
As for your other problems, can you post your magical mystery filetypes.python and examples of the files where other problems occur with step by step what to do, what you expect to happen and what happens I've kind of lost the plot :-)
Cheers Lex
On 21 January 2011 02:31, Philipp Kalder pkalder@googlemail.com wrote:
Another note: I just discovered that I have another file open in which adding ) works. But not adding ] . . . Just another python script. Maybe If I . . . (away, checking something . . . .) Ok, not so. I thought closing all open files, then closing geany. Restarting it and then reopen the files would do the trick. But this remains a mystery, sorry. I don't think any system settings result in a behavior like this. One script has closing parenthesis not auto added, though set, the other has, but the other misses this for square brackets. Regards Phil
On Thu, Jan 20, 2011 at 2:47 PM, Philipp Kalder pkalder@googlemail.com wrote:
Same thing with version 0.20. But I guess this might be related to the fact that it uses the same preferences. Regards Phil
On Thu, Jan 20, 2011 at 2:40 PM, Philipp Kalder pkalder@googlemail.com wrote:
Hello, thanks for the quick reply:
On Thu, Jan 20, 2011 at 12:21 PM, Lex Trotman elextr@gmail.com wrote:
On 20 January 2011 21:36, Philipp Kalder pkalder@googlemail.com wrote:
Hello list, I think I found a bug or two othree . . ., but am not sure. So I first write to the list. I hope this is the right place. I have an apt-get install of Geany 0.19.1 and installed a theme from here: http://www.barryvan.com.au/2009/01/geany-ide-tango-dark-colour-scheme/ I did this more or less before I really used geany. But I think some of the issues started first after the theme was applied. I also created a filetype.common as mentioned in the comments of the link above. I installed a Virtual Machine Ubuntu 10.10 (same as my workstation) and tested the 'fresh' version against the one I use:
- Issue
In an Editor such as gedit or Editra as well as in Geany you can mark a text and replace it with anything you have in your clipboard. The usual linux behavior would be to copy the marked text to the clipboard, so ctrl+v-ing would simply replace the marked text with itself. After installing the above theme however, the behavior changes from Editor like to usual. Which is quite inconvenient.
Don't know how the theme affects this?? What does a fresh version on the actual workstation do? After all a VM may not have tweaks you added to your normal environment and certainly does not have same GUI drivers.
The thing is, if I copy away the filetypes.python I use, or copy one from /usr/share/geany to .config/geany/filedefs and restart Geany, it behaves as expected, what I labled 'Editor'-Style. So even considering the differences between a VM and the actual workstation, I can change the behavior even on the workstation alone. And the trigger seems to be using a different filetypes.python. So let me rephrase: When changing the filetypes.python I use, the behavior changes. I always quit Geany before I make changes like that and start it only after it's finished. the identifiers attribute was not set as well as the lexer_properties section was not defined. I took those from the /usr/share/geany file and added them. I also changed certain colors, to have a more dark blue background. But again, the behavior is 'usual' style.
- Issue
I have some issues with indentation while coding. I code in python. Pressing Enter after a colon results in the next line being indented using tabs. But my settings are to use spaces. Pressing Enter after a 'regular' line, the indentation is done using spaces. So I guess there is some problem with the implementation for python/colon. Python sometimes really get's finicky about mixing spaces and tabs.
This works for me, did you force the preference to apply to already open documents? Just setting the preference won't change the setting for already open documents unless you force it (see note at top of preference page)
Do you refer to http://www.geany.org/manual/current/index.html#preferences and the statement about changes under the 'Document' Tab? Anyway, I restarted Geany after changing settings. They showed up as I set there. Preferences Dialog -> Editor TAB Indentation: Type Spaces But don't seem to apply. Just to be sure, we are talking about the same: A sample, I have 'Show whitespaces' active at all times: . . . . if xmldoc.getElementsByTagName('ns3:message') == 'broken symlink': <hitting enter results in> ----->---->print "The symlink is broken" However, I've just had a look at the options under the Documents Tab and found that Indent Type was set to Tabs and space although my Settings in the Preferences Dialog show it as spaces. Changing it there, solves this. It also keeps this set after restarting Geany. Though this is the opposite of what it say's in the Geany manual: "The settings under the Document menu, however, are only for the current document and revert to defaults when restarting Geany." So I'm not sure whether this is a bug or just a 'glitch', but changing the filetypes.python changed this behavior as well.
- Issue
Is again related to the theme, after testing this in the VM. Auto completing/adding for parenthesis does not work with the theme. With the 'fresh' Geany closing parenthesis is added just as it should be, with the theme it's not. Curly and square braces are added without difficulty.
Again don't see how this is to do with the theme, more likely system configuration being different to the VM.
Also again, any suggestions on which system config element could possibly influence the behavior of the editor? I purged and reinstalled Geany, put the filetypes.* back in place and started the Editor, same picture. Though I have to admit, that the purging seems not to have been as thorough as I wished. After starting the editor, the last opened files reappeared.
- Issue
Might be related to no.2. Though the settings are set to use spaces, pressing tab inserts a tab and even converts preceding spaces in groups of $tabwidth into tabs Moving multiple lines at once with tab, also inserts and converts spaces to tabs. This seems not to be related to the theme as well.
See comment above, behaves as you describe even with pref changed unless the change is applied to the open file.
I'll gibe the version 0.20 a try. Lets see what this brings. Thanks again. Phil
Cheers Lex
So I don't know if these are 'bugs', so if someone know's anything about it, please let me know. Especially if it is a bug, that might already been filed as one. Regards Phil _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hello,
sorry for the delay.
The indentation is not a problem anymore. As I stated in one of my previous emails, there seems to have been a problem with 'detecting from file'. Every indentation I do now works as I want it to.
Only thing that remains is the behavior for parenthesis. But I guess I'll just cope with it. I can post the filetypes.python, as well as the filetypes.common if you still like to see them. As for the code I'm sorry to say that can't post even parts of it. I use Geany at work and the code is for our internal systems.
Thanks so far Phil
On Thu, Jan 20, 2011 at 11:42 PM, Lex Trotman elextr@gmail.com wrote:
Hi Phil,
Indentation is a tricky subject, there are so many standards that we can each have one...
... so to summarize as much for my benefit as anyones.
Document->indent type
Shows and sets the indent type which is currently being used for the current file, this is per file and is not saved when the file is closed since there is nowhere to save it per file. It is saved and restored with the session if Geany is closed with the file open.
Edit->preferences->editor
This sets the type to use with a new file or when opening a file if "detect from file" is not set. If "detect from file" is set then Geany tries to decide from what it finds in the first part of the file when it is first opened. This value becomes the Document->indent type for the new/opened file. There is a menu item to apply this default to all open files under project. I might suggest moving this under tools, its not really project related.
AFAICT this seems to be working properly in 0.20 for Python.
As for your other problems, can you post your magical mystery filetypes.python and examples of the files where other problems occur with step by step what to do, what you expect to happen and what happens I've kind of lost the plot :-)
Cheers Lex
On 21 January 2011 02:31, Philipp Kalder pkalder@googlemail.com wrote:
Another note: I just discovered that I have another file open in which adding ) works.
But
not adding ] . . . Just another python script. Maybe If I . . . (away, checking something . . . .) Ok, not so. I thought closing all open files, then closing geany.
Restarting
it and then reopen the files would do the trick. But this remains a mystery, sorry. I don't think any system settings
result
in a behavior like this. One script has closing parenthesis not auto added, though set, the other has, but the other misses this for square brackets. Regards Phil
On Thu, Jan 20, 2011 at 2:47 PM, Philipp Kalder pkalder@googlemail.com wrote:
Same thing with version 0.20. But I guess this might be related to the fact that it uses the same preferences. Regards Phil
On Thu, Jan 20, 2011 at 2:40 PM, Philipp Kalder <pkalder@googlemail.com
wrote:
Hello, thanks for the quick reply:
On Thu, Jan 20, 2011 at 12:21 PM, Lex Trotman elextr@gmail.com
wrote:
On 20 January 2011 21:36, Philipp Kalder pkalder@googlemail.com
wrote:
Hello list, I think I found a bug or two othree . . ., but am not sure. So I
first
write to the list. I hope this is the right place. I have an apt-get install of Geany 0.19.1 and installed a theme from here:
http://www.barryvan.com.au/2009/01/geany-ide-tango-dark-colour-scheme/
I did this more or less before I really used geany. But I think some of the issues started first after the theme was applied. I also created a filetype.common
as
mentioned in the comments of the link above. I installed a Virtual Machine Ubuntu 10.10 (same as my workstation) and tested the 'fresh' version against the one I use:
- Issue
In an Editor such as gedit or Editra as well as in Geany you can
mark
a text and replace it with anything you have in your clipboard. The usual linux behavior would be to copy the marked text to the clipboard, so ctrl+v-ing would simply replace the marked text with itself. After installing the above theme however, the behavior changes from Editor like to usual. Which is quite inconvenient.
Don't know how the theme affects this?? What does a fresh version on the actual workstation do? After all a VM may not have tweaks you added to your normal environment and certainly does not have same GUI drivers.
The thing is, if I copy away the filetypes.python I use, or copy one from /usr/share/geany to .config/geany/filedefs and restart Geany, it behaves as expected,
what
I labled 'Editor'-Style. So even considering the differences between a VM and the actual workstation, I can change the behavior even on the workstation alone. And the trigger seems to be using a different filetypes.python. So let me rephrase: When changing the filetypes.python I use, the behavior changes. I
always
quit Geany before I make changes like that and start it only after it's finished. the identifiers attribute was not set as well as the lexer_properties section was not defined. I took those from the /usr/share/geany file and added them. I also changed certain colors, to have a more dark blue background. But again, the behavior is 'usual' style.
- Issue
I have some issues with indentation while coding. I code in python. Pressing Enter after a colon results in the next line being indented using tabs. But my settings are to use spaces. Pressing Enter after a 'regular' line, the indentation is done using spaces. So I guess there is some problem with the implementation for python/colon. Python sometimes really get's finicky about mixing spaces and tabs.
This works for me, did you force the preference to apply to already open documents? Just setting the preference won't change the setting for already open documents unless you force it (see note at top of preference page)
Do you refer to http://www.geany.org/manual/current/index.html#preferences and the statement about changes under the 'Document' Tab? Anyway, I restarted Geany after changing settings. They showed up as I set there. Preferences Dialog -> Editor TAB Indentation: Type Spaces But don't seem to apply. Just to be sure, we are talking about the
same:
A sample, I have 'Show whitespaces' active at all times: . . . . if xmldoc.getElementsByTagName('ns3:message') == 'broken symlink': <hitting enter results in> ----->---->print "The symlink is broken" However, I've just had a look at the options under the Documents Tab
and
found that Indent Type was set to Tabs and space although my Settings in the Preferences
Dialog
show it as spaces. Changing it there, solves this. It also keeps this set after restarting Geany. Though this is the opposite of what it say's in the Geany manual: "The settings under the Document menu, however, are only for the
current
document and revert to defaults when restarting Geany." So I'm not sure whether this is a bug or just a 'glitch', but changing the filetypes.python changed this behavior as well.
- Issue
Is again related to the theme, after testing this in the VM. Auto completing/adding for parenthesis does not work with the theme. With the 'fresh' Geany closing parenthesis is added just as it
should
be, with the theme it's not. Curly and square braces are added without difficulty.
Again don't see how this is to do with the theme, more likely system configuration being different to the VM.
Also again, any suggestions on which system config element could
possibly
influence the behavior of the editor? I purged and reinstalled Geany, put the filetypes.* back in place and started the Editor, same picture. Though I have to admit, that the purging seems not to have been as thorough as I wished. After starting the editor, the
last
opened files reappeared.
- Issue
Might be related to no.2. Though the settings are set to use spaces, pressing tab inserts a tab and even converts preceding spaces in groups of $tabwidth into tabs Moving multiple lines at once with tab, also inserts and converts spaces to tabs. This seems not to be related to the theme as well.
See comment above, behaves as you describe even with pref changed unless the change is applied to the open file.
I'll gibe the version 0.20 a try. Lets see what this brings. Thanks again. Phil
Cheers Lex
So I don't know if these are 'bugs', so if someone know's anything about it, please let me know. Especially if it is a bug, that might already been filed as one. Regards Phil _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 24 January 2011 00:23, Philipp Kalder pkalder@googlemail.com wrote:
Hello, sorry for the delay. The indentation is not a problem anymore. As I stated in one of my previous emails, there seems to have been a problem with 'detecting from file'. Every indentation I do now works as I want it to. Only thing that remains is the behavior for parenthesis. But I guess I'll just cope with it. I can post the filetypes.python, as well as the filetypes.common if you still like to see them. As for the code I'm sorry to say that can't post even parts of it. I use Geany at work and the code is for our internal systems. Thanks so far Phil
Hi Phil,
Sorry your email got lost in the inbox. I don't quite understand what is happening wrong with the brackets, can you describe it again.
Cheers Lex
Hey,
no problem.
It's just that on some files auto-close parenthesis does not work, while on others it does. With all set types parenthesis, square and curly brackets. I have multiple files open that I work on that belong to the same framework I developed at work.
And on some files auto-close parenthesis works but it's doesn't for curly brackets. But that's something I get along with. That and the copy paste behavior is just something I'll get used to. The copy/paste is more of an inconvenience than the issue with parenthesis.
Regards, Philipp
On Thu, Jan 27, 2011 at 12:08 AM, Lex Trotman elextr@gmail.com wrote:
On 24 January 2011 00:23, Philipp Kalder pkalder@googlemail.com wrote:
Hello, sorry for the delay. The indentation is not a problem anymore. As I stated in one of my
previous
emails, there seems to have been a problem with 'detecting from file'. Every
indentation I
do now works as I want it to. Only thing that remains is the behavior for parenthesis. But I guess
I'll
just cope with it. I can post the filetypes.python, as well as the filetypes.common if you still like to see them. As for the code I'm sorry to say that can't post even parts of it. I use Geany at work and the code is for our internal systems. Thanks so far Phil
Hi Phil,
Sorry your email got lost in the inbox. I don't quite understand what is happening wrong with the brackets, can you describe it again.
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, Jan 27, 2011 at 12:06 PM, Philipp Kalder pkalder@googlemail.com wrote:
The copy/paste is more of an inconvenience than the issue with parenthesis.
I'm sorry, I never grasped the difference between "editor-style" copy/paste and "usual" copy/paste. When you say you mark text, do you mean put a marker on it, or just select it? Or do you mean select it, and then copy it to the clipboard with Ctrl+C? What is editor-style behavior supposed to be and what is usual behavior supposed to be?
Fair warning: I don't think I can help you, regardless of what your problem is. I am just completely missing *what* the problem is (regarding copy/paste) and just want to understand.
John
Hello John,
My bad I guess. What I labeled 'usual' style is the default linux behavior when selecting text. If you are using linux you know what I mean if not, heer some background.
If you select text, it's automatically added to the clipboard. (This and a clipboard manager is what eases work on linux a lot). You can then paste the selected text using the third-(middle-) Button or ctrl-v.
While in any other context this auto adding to clipboard behavior of linux is a great thing, while editing code however it's not. You want to select parts and paste them some where else. I have a habit of selecting/pasting identifiers for variables. Especially if it is a longer on. I do this to avoid typos while reusing code. I copy the lines of code, change what's needed, then select the identifier I need to use and then I select the identifier I want to replace.
Some IDE's and Editors I've come across disable this "auto add to clipboard" behavior to allow just that. Geany is one of them, but this stopped working after adding the mentioned theme.
I hope this explains it.
Phil
On Thu, Jan 27, 2011 at 6:54 PM, John Yeung gallium.arsenide@gmail.comwrote:
On Thu, Jan 27, 2011 at 12:06 PM, Philipp Kalder pkalder@googlemail.com wrote:
The copy/paste is more of an inconvenience than the issue with parenthesis.
I'm sorry, I never grasped the difference between "editor-style" copy/paste and "usual" copy/paste. When you say you mark text, do you mean put a marker on it, or just select it? Or do you mean select it, and then copy it to the clipboard with Ctrl+C? What is editor-style behavior supposed to be and what is usual behavior supposed to be?
Fair warning: I don't think I can help you, regardless of what your problem is. I am just completely missing *what* the problem is (regarding copy/paste) and just want to understand.
John _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Dnia sobota, 29 stycznia 2011 o 17:21:28 Philipp Kalder napisał(a):
Hello John,
My bad I guess. What I labeled 'usual' style is the default linux behavior when selecting text. If you are using linux you know what I mean if not, heer some background.
If you select text, it's automatically added to the clipboard. (This and a clipboard manager is what eases work on linux a lot).
The result depends on /how/ you select text.
If you select text by dragging the pointer, the text becomes the *PRIMARY* selection. If you select it by any other programmatic means, both the *PRIMARY* selection and the *CUT* *BUFFER* remain unaffected. If you execute the *Copy* action by whatever means, you push the text onto the *CUT* *BUFFER* and the *PRIMARY* selection remains unaffected. The *Clipboard*, on the other hand, is internal and private to the application; it can hold any data in an application-dependent format.
You can then paste the selected text using the third-(middle-) Button or ctrl-v.
The middle button inserts the contents of the *PRIMARY* selection. The Paste action, however it is invoked, inserts the contents of the current *CUT* *BUFFER*. These are /not/ synchronised automatically, although you can synchronise them by hand.
HTH, Chris
The middle button inserts the contents of the *PRIMARY* selection. The Paste action, however it is invoked, inserts the contents of the current *CUT* *BUFFER*. These are /not/ synchronised automatically, although you can synchronise them by hand.
Possibly OT, but speaking of copy&paste. I noticed that the cut buffer (or clipboard?) is cleared when geany exits, is there any reason for this?
I.e. I can select and copy text and paste it into e.g. gedit as long as I keep Geany open, but what I copied is lost if I close Geany in the meantime.
Best regards.
On Sun, 30 Jan 2011 17:19:52 +0100, Thomas wrote:
The middle button inserts the contents of the *PRIMARY* selection. The Paste action, however it is invoked, inserts the contents of the current *CUT* *BUFFER*. These are /not/ synchronised automatically, although you can synchronise them by hand.
Possibly OT, but speaking of copy&paste. I noticed that the cut buffer (or clipboard?) is cleared when geany exits, is there any reason for this?
AFAIK this is the default behaviour, also for other applications. I wouldn't even know how to change this.
As a workaround, just use a clipboard manager.
Regards, Enrico
On 30.01.2011 17:24, Enrico Tröger wrote:
AFAIK this is the default behaviour, also for other applications. I wouldn't even know how to change this.
As a workaround, just use a clipboard manager.
Regards, Enrico
It works as I expect in gedit, i.e. copy, close and paste in firefox.
Best regards.
On Sun, 30 Jan 2011 17:26:46 +0100, Thomas wrote:
On 30.01.2011 17:24, Enrico Tröger wrote:
AFAIK this is the default behaviour, also for other applications. I wouldn't even know how to change this.
As a workaround, just use a clipboard manager.
Regards, Enrico
It works as I expect in gedit, i.e. copy, close and paste in firefox.
No idea then. Obviously, gedit does something different. In Geany, copying text is done by Scintilla, at least within the editor widget. Could you test what happens when you copy some text from a standard GTK widdget, like the Search text field in the toolbar or the Scribble?
Regards, Enrico
On 30.01.2011 17:54, Enrico Tröger wrote:
No idea then. Obviously, gedit does something different. In Geany, copying text is done by Scintilla, at least within the editor widget. Could you test what happens when you copy some text from a standard GTK widdget, like the Search text field in the toolbar or the Scribble?
Regards, Enrico
Ah it seems to be related to killing geany/gedit with ctrl+c (when started via command line). In this scenario gedit also fails, and geany works correctly if I quit it normally.
Best regards.
On 28 January 2011 04:06, Philipp Kalder pkalder@googlemail.com wrote:
Hey, no problem. It's just that on some files auto-close parenthesis does not work, while on others it does. With all set types parenthesis, square and curly brackets. I have multiple files open that I work on that belong to the same framework I developed at work. And on some files auto-close parenthesis works but it's doesn't for curly brackets.
You are gonna have to give me more info to go on :-)
You are aware that closing brackets ([{< only closes unmatched open brackets so if a matching close is found none will be added?
Really need minimal example of non-working file.
Cheers Lex
But that's something I get along with. That and the copy paste behavior is just something I'll get used to. The copy/paste is more of an inconvenience than the issue with parenthesis. Regards, Philipp On Thu, Jan 27, 2011 at 12:08 AM, Lex Trotman elextr@gmail.com wrote:
On 24 January 2011 00:23, Philipp Kalder pkalder@googlemail.com wrote:
Hello, sorry for the delay. The indentation is not a problem anymore. As I stated in one of my previous emails, there seems to have been a problem with 'detecting from file'. Every indentation I do now works as I want it to. Only thing that remains is the behavior for parenthesis. But I guess I'll just cope with it. I can post the filetypes.python, as well as the filetypes.common if you still like to see them. As for the code I'm sorry to say that can't post even parts of it. I use Geany at work and the code is for our internal systems. Thanks so far Phil
Hi Phil,
Sorry your email got lost in the inbox. I don't quite understand what is happening wrong with the brackets, can you describe it again.
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hello Lex,
I very much appreciate your willingness to help.
I have to apologize for being so blind. I completely ignored what you had to remind me of:
You are aware that closing brackets ([{< only closes unmatched open brackets so if a matching close is found none will be added?
The main file I was concerned about, is a 1400 lines script that's part of a set of files working together. Their functions being accessed through calls to a WSGI Server. It's live, in a productive environment serving more than 300.000 calls a day.
If a function in it would be faulty, than the whole thing wouldn't work. That's what I've seen happening and that's what I assumed. Even though not all functions are used (some are for debugging purposes). I was wrong.
Here is what I did:
I was thinking that just part of the script in question wouldn't help. If all brackets would be consistent, then it would just work. I tried taking two functions out of it, pasting them into a new file and saved it. Testing it, as expected, showed auto-closing working properly. And then it struck me, I tried it in the first line of the original file, in the middle of it and on the last line. On the last line the parenthesis was auto-closed.
So all I have to do now is find the faulty function/line of code in 1400 lines ;-)
One question though is left: Would an opening bracket in some comment or commented out/disabled function cause this for the rest of the file as well?
So far I have narrowed it down to a function. Trying 'base64.b64decode(' prior to the def statement does not close it, trying the same right under the last line of this function prior to the next def statement closes the parenthesis. I'm not sure what this tells me, but . . .
I guess that's my puzzle to solve.
Thank you very much for exchanging views with me.
Regards, Philipp
Really need minimal example of non-working file.
Cheers Lex
But that's something I get along with. That and the copy paste behavior is just something I'll get used to. The copy/paste is more of an inconvenience than the issue with parenthesis. Regards, Philipp On Thu, Jan 27, 2011 at 12:08 AM, Lex Trotman elextr@gmail.com wrote:
On 24 January 2011 00:23, Philipp Kalder pkalder@googlemail.com
wrote:
Hello, sorry for the delay. The indentation is not a problem anymore. As I stated in one of my previous emails, there seems to have been a problem with 'detecting from file'. Every indentation I do now works as I want it to. Only thing that remains is the behavior for parenthesis. But I guess I'll just cope with it. I can post the filetypes.python, as well as the filetypes.common if
you
still like to see them. As for the code I'm sorry to say that can't post even parts of it. I
use
Geany at work and the code is for our internal systems. Thanks so far Phil
Hi Phil,
Sorry your email got lost in the inbox. I don't quite understand what is happening wrong with the brackets, can you describe it again.
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 30 January 2011 05:53, Philipp Kalder pkalder@googlemail.com wrote:
Hello Lex, I very much appreciate your willingness to help. I have to apologize for being so blind. I completely ignored what you had to remind me of:
You are aware that closing brackets ([{< only closes unmatched open brackets so if a matching close is found none will be added?
The main file I was concerned about, is a 1400 lines script that's part of a set of files working together. Their functions being accessed through calls to a WSGI Server. It's live, in a productive environment serving more than 300.000 calls a day. If a function in it would be faulty, than the whole thing wouldn't work. That's what I've seen happening and that's what I assumed. Even though not all functions are used (some are for debugging purposes). I was wrong. Here is what I did: I was thinking that just part of the script in question wouldn't help. If all brackets would be consistent, then it would just work. I tried taking two functions out of it, pasting them into a new file and saved it. Testing it, as expected, showed auto-closing working properly. And then it struck me, I tried it in the first line of the original file, in the middle of it and on the last line. On the last line the parenthesis was auto-closed. So all I have to do now is find the faulty function/line of code in 1400 lines ;-) One question though is left: Would an opening bracket in some comment or commented out/disabled function cause this for the rest of the file as well?
The brackets must have the same styling so as brackets in comments have different styling they don't count
Cheers Lex
So far I have narrowed it down to a function. Trying 'base64.b64decode(' prior to the def statement does not close it, trying the same right under the last line of this function prior to the next def statement closes the parenthesis. I'm not sure what this tells me, but . . . I guess that's my puzzle to solve. Thank you very much for exchanging views with me. Regards, Philipp
Really need minimal example of non-working file.
Cheers Lex
But that's something I get along with. That and the copy paste behavior is just something I'll get used to. The copy/paste is more of an inconvenience than the issue with parenthesis. Regards, Philipp On Thu, Jan 27, 2011 at 12:08 AM, Lex Trotman elextr@gmail.com wrote:
On 24 January 2011 00:23, Philipp Kalder pkalder@googlemail.com wrote:
Hello, sorry for the delay. The indentation is not a problem anymore. As I stated in one of my previous emails, there seems to have been a problem with 'detecting from file'. Every indentation I do now works as I want it to. Only thing that remains is the behavior for parenthesis. But I guess I'll just cope with it. I can post the filetypes.python, as well as the filetypes.common if you still like to see them. As for the code I'm sorry to say that can't post even parts of it. I use Geany at work and the code is for our internal systems. Thanks so far Phil
Hi Phil,
Sorry your email got lost in the inbox. I don't quite understand what is happening wrong with the brackets, can you describe it again.
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hey,
I checked that one. This seems not be true for my 0.20 install. I had stuff like this ;-) in doc strings and comments.
Genay made no difference between doc strings, comments and regular code. As long as it was there, the auto-close detected the ) in ;-) and left it open.
Greetings Philipp
On Sat, Jan 29, 2011 at 8:08 PM, Lex Trotman elextr@gmail.com wrote:
On 30 January 2011 05:53, Philipp Kalder pkalder@googlemail.com wrote:
Hello Lex, I very much appreciate your willingness to help. I have to apologize for being so blind. I completely ignored what you had to remind me of:
You are aware that closing brackets ([{< only closes unmatched open brackets so if a matching close is found none will be added?
The main file I was concerned about, is a 1400 lines script that's part
of a
set of files working together. Their functions being accessed through calls
to a
WSGI Server. It's live, in a productive environment serving more than 300.000 calls a day. If a function in it would be faulty, than the whole thing wouldn't work. That's what I've seen happening and that's what I assumed. Even though not all
functions
are used (some are for debugging purposes). I was wrong. Here is what I did: I was thinking that just part of the script in question wouldn't help. If all brackets would be consistent, then it would just work. I tried
taking
two functions out of it, pasting them into a new file and saved it. Testing
it,
as expected, showed auto-closing working properly. And then it struck me, I tried it in the first line of the original file, in the middle of it and on the last line. On the last line the parenthesis was auto-closed. So all I have to do now is find the faulty function/line of code in 1400 lines ;-) One question though is left: Would an opening bracket in some comment or commented out/disabled function cause this for the rest of the file as
well?
The brackets must have the same styling so as brackets in comments have different styling they don't count
Cheers Lex
So far I have narrowed it down to a function. Trying 'base64.b64decode(' prior to the def statement does not close it, trying the same right under the last
line
of this function prior to the next def statement closes the parenthesis. I'm not sure what this tells me, but . . . I guess that's my puzzle to solve. Thank you very much for exchanging views with me. Regards, Philipp
Really need minimal example of non-working file.
Cheers Lex
But that's something I get along with. That and the copy paste behavior is just something I'll get used to.
The
copy/paste is more of an inconvenience than the issue with parenthesis. Regards, Philipp On Thu, Jan 27, 2011 at 12:08 AM, Lex Trotman elextr@gmail.com
wrote:
On 24 January 2011 00:23, Philipp Kalder pkalder@googlemail.com wrote:
Hello, sorry for the delay. The indentation is not a problem anymore. As I stated in one of my previous emails, there seems to have been a problem with 'detecting from file'. Every indentation I do now works as I want it to. Only thing that remains is the behavior for parenthesis. But I
guess
I'll just cope with it. I can post the filetypes.python, as well as the filetypes.common if you still like to see them. As for the code I'm sorry to say that can't post even parts of it.
I
use Geany at work and the code is for our internal systems. Thanks so far Phil
Hi Phil,
Sorry your email got lost in the inbox. I don't quite understand
what
is happening wrong with the brackets, can you describe it again.
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 3 February 2011 04:26, Philipp Kalder pkalder@googlemail.com wrote:
Hey, I checked that one. This seems not be true for my 0.20 install. I had stuff like this ;-) in doc strings and comments. Genay made no difference between doc strings, comments and regular code. As long as it was there, the auto-close detected the ) in ;-) and left it open. Greetings Philipp
Hi Philip,
This bug has been pointed out before. Its due to Geany using scintilla wrongly. Have started another thread to discuss.
Cheers Lex
On Sat, Jan 29, 2011 at 8:08 PM, Lex Trotman elextr@gmail.com wrote:
On 30 January 2011 05:53, Philipp Kalder pkalder@googlemail.com wrote:
Hello Lex, I very much appreciate your willingness to help. I have to apologize for being so blind. I completely ignored what you had to remind me of:
You are aware that closing brackets ([{< only closes unmatched open brackets so if a matching close is found none will be added?
The main file I was concerned about, is a 1400 lines script that's part of a set of files working together. Their functions being accessed through calls to a WSGI Server. It's live, in a productive environment serving more than 300.000 calls a day. If a function in it would be faulty, than the whole thing wouldn't work. That's what I've seen happening and that's what I assumed. Even though not all functions are used (some are for debugging purposes). I was wrong. Here is what I did: I was thinking that just part of the script in question wouldn't help. If all brackets would be consistent, then it would just work. I tried taking two functions out of it, pasting them into a new file and saved it. Testing it, as expected, showed auto-closing working properly. And then it struck me, I tried it in the first line of the original file, in the middle of it and on the last line. On the last line the parenthesis was auto-closed. So all I have to do now is find the faulty function/line of code in 1400 lines ;-) One question though is left: Would an opening bracket in some comment or commented out/disabled function cause this for the rest of the file as well?
The brackets must have the same styling so as brackets in comments have different styling they don't count
Cheers Lex
So far I have narrowed it down to a function. Trying 'base64.b64decode(' prior to the def statement does not close it, trying the same right under the last line of this function prior to the next def statement closes the parenthesis. I'm not sure what this tells me, but . . . I guess that's my puzzle to solve. Thank you very much for exchanging views with me. Regards, Philipp
Really need minimal example of non-working file.
Cheers Lex
But that's something I get along with. That and the copy paste behavior is just something I'll get used to. The copy/paste is more of an inconvenience than the issue with parenthesis. Regards, Philipp On Thu, Jan 27, 2011 at 12:08 AM, Lex Trotman elextr@gmail.com wrote:
On 24 January 2011 00:23, Philipp Kalder pkalder@googlemail.com wrote: > Hello, > sorry for the delay. > The indentation is not a problem anymore. As I stated in one of my > previous > emails, there > seems to have been a problem with 'detecting from file'. Every > indentation I > do now works > as I want it to. > Only thing that remains is the behavior for parenthesis. But I > guess > I'll > just cope with it. > I can post the filetypes.python, as well as the filetypes.common > if > you > still like to see them. > As for the code I'm sorry to say that can't post even parts of it. > I > use > Geany at work and the > code is for our internal systems. > Thanks so far > Phil >
Hi Phil,
Sorry your email got lost in the inbox. I don't quite understand what is happening wrong with the brackets, can you describe it again.
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany