Hi,
I've noticed that "Edit --> Format --> Reflow Lines/Block" only seems to work if the Pref for "Editor tab : Display tab : Long line marker" is enabled.
It would seem to me that reflow should work as long as the Columns combo box contains a usable value (since it doesn't get grayed out when the "Long line marker" checkbox is unchecked).
If the current behavior is what's desired, then when "Long line marker" is disabled, perhaps it would be useful if -- when the user tries to reflow -- a message appeared in the Messages pane at the bottom indicating that it won't work unless Long line marker is enabled.
Sidenote: I notice that a max column value shows up in 2 separate places in the Prefs: "Editor tab : Features tab", and also "Editor tab : Display tab". The one in the Display tab affects reflow behavior.
Thanks, ---John
On 14 May 2011 03:18, John Gabriele jmg3000@gmail.com wrote:
Hi,
I've noticed that "Edit --> Format --> Reflow Lines/Block" only seems to work if the Pref for "Editor tab : Display tab : Long line marker" is enabled.
It would seem to me that reflow should work as long as the Columns combo box contains a usable value (since it doesn't get grayed out when the "Long line marker" checkbox is unchecked).
If the current behavior is what's desired, then when "Long line marker" is disabled, perhaps it would be useful if -- when the user tries to reflow -- a message appeared in the Messages pane at the bottom indicating that it won't work unless Long line marker is enabled.
Sidenote: I notice that a max column value shows up in 2 separate places in the Prefs: "Editor tab : Features tab", and also "Editor tab : Display tab". The one in the Display tab affects reflow behavior.
Hi John,
This has been fixed, it will be in the next major release (I'm not sure about the upcoming point release). If you are impatient you can build the SVN version.
It uses the line breaking column if it is set otherwise it uses the long line marker if it is set, otherwise it just beeps at you.
Cheers Lex
Thanks, ---John _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, May 13, 2011 at 7:11 PM, Lex Trotman elextr@gmail.com wrote:
On 14 May 2011 03:18, John Gabriele jmg3000@gmail.com wrote:
This has been fixed, it will be in the next major release (I'm not sure about the upcoming point release). If you are impatient you can build the SVN version.
It uses the line breaking column if it is set otherwise it uses the long line marker if it is set, otherwise it just beeps at you.
Thanks, Lex.
Just grabbed 0.21 (r5796) from svn and it's still showing me the same behavior: it only wraps when I have long-line marker enabled (and is using the column value for the long-line marker). Not getting any beep if I try when long-line marker is disabled.
$ geany --version geany 0.21 (svn >= r5796) (built on May 13 2011 with GTK 2.20.1, GLib 2.24.1, GIO)
This is on Ubuntu 10.04.
---John
On Fri, May 13, 2011 at 10:36 PM, John Gabriele jmg3000@gmail.com wrote:
Not getting any beep if I try when long-line marker is disabled.
Whoops. Sorry. Take that one item back -- I do get beeped at. :)
On 14 May 2011 12:36, John Gabriele jmg3000@gmail.com wrote:
On Fri, May 13, 2011 at 7:11 PM, Lex Trotman elextr@gmail.com wrote:
On 14 May 2011 03:18, John Gabriele jmg3000@gmail.com wrote:
This has been fixed, it will be in the next major release (I'm not sure about the upcoming point release). If you are impatient you can build the SVN version.
It uses the line breaking column if it is set otherwise it uses the long line marker if it is set, otherwise it just beeps at you.
Thanks, Lex.
Just grabbed 0.21 (r5796) from svn and it's still showing me the same behavior: it only wraps when I have long-line marker enabled (and is using the column value for the long-line marker). Not getting any beep if I try when long-line marker is disabled.
Ahhh, I see what I said could be misinterpreted, by "line breaking column if it is set" I mean if "line breaking" is set not just if the column is set.
The point is if the user has line breaking set then it makes sense to reflow to the same column, otherwise reflow to the long line setting as we always did.
Cheers Lex
$ geany --version geany 0.21 (svn >= r5796) (built on May 13 2011 with GTK 2.20.1, GLib 2.24.1, GIO)
This is on Ubuntu 10.04.
---John _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, May 13, 2011 at 10:58 PM, Lex Trotman elextr@gmail.com wrote:
On 14 May 2011 12:36, John Gabriele jmg3000@gmail.com wrote:
On Fri, May 13, 2011 at 7:11 PM, Lex Trotman elextr@gmail.com wrote:
It uses the line breaking column if it is set otherwise it uses the long line marker if it is set, otherwise it just beeps at you.
Thanks, Lex.
Just grabbed 0.21 (r5796) from svn and it's still showing me the same behavior: it only wraps when I have long-line marker enabled (and is using the column value for the long-line marker). Not getting any beep if I try when long-line marker is disabled.
Ahhh, I see what I said could be misinterpreted, by "line breaking column if it is set" I mean if "line breaking" is set not just if the column is set.
The point is if the user has line breaking set then it makes sense to reflow to the same column, otherwise reflow to the long line setting as we always did.
Ah, of course. I see what you mean now. Yes, the behavior you describe works as advertised. (I hadn't noticed the per-document Line Breaking setting.) Would be useful if there were a hover tooltip on the "Line breaking column" line in the "Editor : Feature" pref pane that said, "this is for the per-document line-breaking setting".
Incidentally, I like the terminology used here: line breaking (for automatically putting in real newlines while you're typing), and line wrapping (for simply displaying long lines wrapped). Nice and clear.
And, as you point out,
1. If I have the long-line marker disabled, *but* have the per-document line-breaking setting enabled, then Ctrl-J (reflow) works great (and uses the "line-breaking column" pref setting), and
2. Geany does indeed beep at me if I try to use Ctrl-J when it won't work (though, when getting the beep, it would be useful to get a message telling me, "for reflow to work, either turn on per-document line-breaking for this document, or else enable the long-line marker pref").
Thanks! ---John
Ah, of course. I see what you mean now. Yes, the behavior you describe works as advertised. (I hadn't noticed the per-document Line Breaking setting.) Would be useful if there were a hover tooltip on the "Line breaking column" line in the "Editor : Feature" pref pane that said, "this is for the per-document line-breaking setting".
Its possible, BTW from the manual:
Line breaking column The editor column number to insert a newline at when Line Breaking is enabled for the current document.
Line breaking is per document because its destructive and you almost certainly do not want it for code. Line wrapping is just a reversible display feature and so can be global.
Incidentally, I like the terminology used here: line breaking (for automatically putting in real newlines while you're typing), and line wrapping (for simply displaying long lines wrapped). Nice and clear.
Since I didn't choose it I am free to say I agree completely.
And, as you point out,
1. If I have the long-line marker disabled, *but* have the per-document line-breaking setting enabled, then Ctrl-J (reflow) works great (and uses the "line-breaking column" pref setting), and
- Geany does indeed beep at me if I try to use Ctrl-J when it won't
work (though, when getting the beep, it would be useful to get a message telling me, "for reflow to work, either turn on per-document line-breaking for this document, or else enable the long-line marker pref").
Note "beep on error" is a preference setting. Maybe a status bar message, but a popup that you have to then dismiss is too intrusive.
You might put those two suggestions into the feature tracker, if they are left on this list it is very likely that they will be forgotten.
Cheers Lex
Thanks! ---John _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Sat, May 14, 2011 at 12:34 AM, Lex Trotman elextr@gmail.com wrote:
You might put those two suggestions into the feature tracker, if they are left on this list it is very likely that they will be forgotten.
Is the feature request tracker actively used?
On 15 May 2011 10:51, John Gabriele jmg3000@gmail.com wrote:
On Sat, May 14, 2011 at 12:34 AM, Lex Trotman elextr@gmail.com wrote:
You might put those two suggestions into the feature tracker, if they are left on this list it is very likely that they will be forgotten.
Is the feature request tracker actively used?
They are looked at when someone thinks they have enough time to do so. Agreed, that might not be often, and then there is no guarantee that someone is interested in doing any particular feature request, but thats the nature of open source projects. Its not ideal I agree, but part of the cause for the slow response to feature requests is also that there are still large parts of Geany being developed, or from outside developers waiting for integration. As Geany matures these will decrease and likely more attention will be given to individual specific requests.
But unless someone immediately says they are going to do it, things on this list *will* be forgotten :-).
Cheers Lex
You might put those two suggestions into the feature tracker, if they are left on this list it is very likely that they will be forgotten.
Is the feature request tracker actively used?
They are looked at when someone thinks they have enough time to do so. Agreed, that might not be often, and then there is no guarantee that someone is interested in doing any particular feature request, but thats the nature of open source projects. Its not ideal I agree, but part of the cause for the slow response to feature requests is also
Hi Lex,
Sorry, didn't mean to suggest there's a slow response to Geany feature requests (on the contrary, in the past I've found the core devs to be interested in what users ask for in general), nor even that anyone is under any sort of expectation to work on features that someone else is interested in seeing. :)
I was curious if the request tracker is actively used because when when I took a brief look there I randomly ran across [an older request][1] that had already been implemented (as a plug-in) but was still listed as "open".
[1]: http://sourceforge.net/tracker/?func=detail&aid=1530436&group_id=153...
I should've spent more time browsing though. Seems active.
Thanks, ---John
I was curious if the request tracker is actively used because when when I took a brief look there I randomly ran across [an older request][1] that had already been implemented (as a plug-in) but was still listed as "open".
Hmmm, interesting point, there is nothing in the workflow that cleans up feature requests when someone else implements them as plugins (unless someone just happens to notice), especially as plugins are not under the core project's control.
Given the restrictions it has I don't know if I would call the split window "implemented", even after some recent love by Matthew.
Cheers Lex
On Friday 13 May 2011 11:44:17 pm John Gabriele wrote:
Incidentally, I like the terminology used here: line breaking (for automatically putting in real newlines while you're typing), and line wrapping (for simply displaying long lines wrapped). Nice and clear.
+1
Randy Kramer