Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-19 Thread Enrico Tröger
Hey guys,


 1. Incorrect indentation guides - ID: 2637071 [1]

 I opened the attached document and did not see any issues with
 indentation guides.  I could miss something because I rarely use the
 guies, but...  Maybe it was already fixed in Scintilla?

 Enrico replied to this report in 2009.

 
 I think this bug is still present if I understand it correctly. The
 attached file causes indentation guides to be shown on the blank line
 that has no indentation at all.

I can't reproduce it here, see attached screenshot.
Maybe it's related to some preferences set?


Regards,
Enrico
attachment: geany_indentation_guides_2637071.png___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-19 Thread Enrico Tröger
Heya,

Eugene, thanks for the efforts on this front!



 I just taught the file mangler to run geany -c so it never interrupts
 what a normal Geany is doing :)
 
 I don't think that's something everybody should need to do.
 
 Yeah, I don't usually do that either. I almost always have an instance of
 Geany running on my 2nd monitor and if not, I'm usually not surprised by the
 behaviour since I do use projects mostly unless I'm just quickly editing a
 file or two.


 Why not have a vote and finally implement or wontfix it? I volunteer to
 write the preference, as a graphical or vaiouus preference, if we decide
 aye.



 Since there is no always right answer as to how Geany should react
 I'd say wont change since we have well known documented behaviour
 already.
 
 I personally do think what we do is definitely the Wrong Thing.
 Honestly, I always have found this behavior very counter-intuitive and
 not helpful.  I mean, if I tell Geany to restore my session, I expect it
 to be restored whenever I start Geany, not only in some cases.
 
 OK, for me it's not a real problem since I always have one or more Geany
 instance open, but remembering the early times I did unexpectedly lost
 some session data because of this behavior.
 
 To summarize, I think that the current behavior will most likely NOT be
 the expected one and will disturb most users.  See, even us do
 workaround that in some ways, either using -c or having an instance
 always open.
 
 So I'd say aye to Dimitar since he gently volunteered :)  Moreover if
 it is a preference I don't see any loss; but I'd better see this
 preference turned on by default for new configurations if the restore
 session one is on.

FWIW, I'd agree as well.
I think in the past, I denied this but it caused me also a few times
losing my session and indeed many people prefer to keep the session when
opening files from the CLI (or file manager or whatever).

So, my vote is 'yes' as well.



Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-19 Thread Colomban Wendling
Le 19/02/2012 16:42, Enrico Tröger a écrit :
 Hey guys,
 
 
 1. Incorrect indentation guides - ID: 2637071 [1]

 I opened the attached document and did not see any issues with
 indentation guides.  I could miss something because I rarely use the
 guies, but...  Maybe it was already fixed in Scintilla?

 Enrico replied to this report in 2009.


 I think this bug is still present if I understand it correctly. The
 attached file causes indentation guides to be shown on the blank line
 that has no indentation at all.
 
 I can't reproduce it here, see attached screenshot.
 Maybe it's related to some preferences set?

I think you just don't have indent guides enabled ;)

 
 
 Regards,
 Enrico
 
 
 
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-19 Thread Colomban Wendling
Le 19/02/2012 01:06, Lex Trotman a écrit :
 [...]

 I just taught the file mangler to run geany -c so it never interrupts
 what a normal Geany is doing :)

 I don't think that's something everybody should need to do.

 
 Yes, true.
 
 [...]
 I personally do think what we do is definitely the Wrong Thing.
 Honestly, I always have found this behavior very counter-intuitive and
 not helpful.  I mean, if I tell Geany to restore my session, I expect it
 to be restored whenever I start Geany, not only in some cases.

 
 Looking at it like that, then the current behaviour is wrong.
 
 I also checked a few other apps and all restore past sessions and add
 the new file to it, so I would say this is the behaviour a user would
 expect.
 
 
 OK, for me it's not a real problem since I always have one or more Geany
 instance open, but remembering the early times I did unexpectedly lost
 some session data because of this behavior.

 To summarize, I think that the current behavior will most likely NOT be
 the expected one and will disturb most users.  See, even us do
 workaround that in some ways, either using -c or having an instance
 always open.
 
 Or both, so I *never* saw it as a problem :)
 

 So I'd say aye to Dimitar since he gently volunteered :)  Moreover if
 it is a preference I don't see any loss; but I'd better see this
 preference turned on by default for new configurations if the restore
 session one is on.

 
 Colomban has been so persuasive

Hehe :D

 that I don't even think it needs
 another option, the suggested behaviour is non-destructive, so why not
 just turn restoring sessions on or off.

Agreed, another pref isn't needed, either always restore or never
restore should be enough; IMO too.

Sounds reasonable to everybody?

Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Line operations

2012-02-19 Thread Colomban Wendling
Le 19/02/2012 08:02, Eugene Arshinov a écrit :
 Hi there.

Hi Eugene,

 
 Quick overview - I posted a pull request [3] which removes `move_lines`
 function and uses commands already available in Scintilla.  See below.
 
 On Sun, 05 Feb 2012 20:50:38 +0100
 Colomban Wendling lists@herbesfolles.org wrote:
 
 Le 05/02/2012 13:51, Eugene Arshinov a écrit :
 Hello all.

 Hey Eugene,

 I have several suggestions and questions about certain line
 operations implemented in Geany.

 1) Recently I found that move lines up/down command does not work
 properly for the last line not ending with a newline.  You can
 easily check it yourself.  Couple of minutes ago I made a pull
 request [1] with an implementation of `editor.c:move_lines()` which
 handles the problem.  Dear unknown someone, please review and pull
 if it's okay.

 I know this problem, but it needed a so big code refactoring it hurts
 (I want as a proof the fact your rewrite is... huge), so... I just
 postponed it.  Ok, shame on me.

 I haven't reviewed the new code yet, but I'll do.  Just as a note,
 Scintilla has a command to do that that suffers (suffered?) of the
 exact same bug we had.  Maybe it'd be good to fix their copy and use
 the SCI message in place of our code.

 [snip]
 
 I didn't find those Scintilla commands (SCI_MOVESELECTEDLINES{UP,DOWN}
 to be precise) because they are not mentioned in the official Scintilla
 documentation [1], though they are of course mentioned in Scintilla.h.
 For completeness, here is the feature request for Scintilla where those
 commands came from - [2].

It is in the docs:
http://www.scintilla.org/ScintillaDoc.html#SCI_MOVESELECTEDLINESUP

 The commands indeed work similarly to our own `move_lines` function.  I
 posted pull request #24 [3] which removes `move_lines` function and
 leverages the commands.  I hope it can be committed so that I can
 switch my effort of improving Move lines feature from Geany to
 Scintilla.

Looks fine to -- apart of course it doesn't fix the initial problem yet.
 At least so there would be only one copy of the functionality.

So just to be sure we understand each other: I drop your previous pull
request (#21), apply this one (#24) and wait for your patch to be in
Scintilla?


Regards,
Colomban

 
 [1]:http://www.scintilla.org/ScintillaDoc.html
 [2]:https://sourceforge.net/tracker/?func=detailaid=3304850group_id=2439atid=352439
 [3]:https://github.com/geany/geany/pull/24
 
 --
 Best regards,
 Eugene.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-19 Thread Enrico Tröger
On 19/02/12 16:49, Colomban Wendling wrote:
 Le 19/02/2012 16:42, Enrico Tröger a écrit :
 Hey guys,


 1. Incorrect indentation guides - ID: 2637071 [1]

 I opened the attached document and did not see any issues with
 indentation guides.  I could miss something because I rarely use the
 guies, but...  Maybe it was already fixed in Scintilla?

 Enrico replied to this report in 2009.


 I think this bug is still present if I understand it correctly. The
 attached file causes indentation guides to be shown on the blank line
 that has no indentation at all.

 I can't reproduce it here, see attached screenshot.
 Maybe it's related to some preferences set?
 
 I think you just don't have indent guides enabled ;)

Ah, stupid me.
I confused indentation guides with 'show whitespace'.

Now, I looked a bit deeper into it and the behaviour is correct for the
mode SC_IV_LOOKBOTH which we use for most filetypes (including C),
according to the Scintilla documentation:

Indentation guides are shown beyond the actual indentation up to the
level of the next non-empty line or previous non-empty line whichever is
the greater.

And now, I also understand my comment on the bug report again :). Though
I could have said this in more detail.
Now done and closed.

If anyone disagrees, just re-open it and put some more info in. If it's
a real issue still, one could make the used indentation guide
configurable per language. Since I don't use, I don't feel like doing it
is necessary but that's just me.

Regards,
Enrico
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Empty project properties dialog

2012-02-19 Thread Jiří Techet
On Sat, Jan 14, 2012 at 21:16, Jiří Techet tec...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 22:57, Lex Trotman ele...@gmail.com wrote:
 On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbr...@codebrainz.ca wrote:
 On 01/13/2012 03:31 AM, Lex Trotman wrote:

 [...]

 What if we deprecate the old project create/confirm API altogether, add
 the
 project preferences dialog to GeanyMainWidgets structure, and just let
 plugins use the response, hide and show signals on it as a normal
 GtkDialog?


 Sounds fine to my limited understanding.


 This wasn't possible before when the dialog was created/destroyed each
 time
 since the pointer in the main_widgets global would change all the time,
 but
 now it'll stay the same right from before `geany-startup-complete` all
 the
 way until after plugins are unloaded . We could even say with certainty
 that
 this API *won't ever* change, the project dialog in main_widgets would
 *always* be a (subclass of) GtkDialog and so would only break if GTK+
 broke
 this.


 But how much of the internal structure of the dialog are you going to
 document?

 Is Jiri expected to find the notebook widget within the dialog or will
 it be passed some other way? If from the dialog it needs to be
 documented (or at least its name does).


 Yeah, I thought about this after I sent the last message. We would need to
 add the dialog *and* the dialog's notebook to the main_widgets struct, like
 we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have
 to guarantee a name so it could be accessed through ui_lookup_widget() or do
 the signals on the wrong object thing like is done for most signals (with
 the renames Jiri proposed).

 Well I'd say the first or second, but Jiri or others may have a
 different preference.


 I don't really care - both versions would work. But I too prefer using

So finally I had some free time to test and listening on the dialog
signals doesn't work as I need. The the code for displaying project
dialog in Geany looks like this:

while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
{
if (update_config(e, FALSE))
{

Now when I connect to the dialog signals, they get emitted on the line

while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)

which means that in the signal handler I don't have access to the
updated config values from the dialog because these are updated
afterwards by

if (update_config(e, FALSE))

So if there aren't any objections, I'll go back to the implementation
I originally suggested and which emits the signal only after the
config has been successfully updated.

Cheers,
Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Line operations

2012-02-19 Thread Eugene Arshinov
On Sun, 19 Feb 2012 17:24:00 +0100
Colomban Wendling lists@herbesfolles.org wrote:

 Le 19/02/2012 08:02, Eugene Arshinov a écrit :
  Hi there.
 
 Hi Eugene,
 
  
  Quick overview - I posted a pull request [3] which removes
  `move_lines` function and uses commands already available in
  Scintilla.  See below.
  
  On Sun, 05 Feb 2012 20:50:38 +0100
  Colomban Wendling lists@herbesfolles.org wrote:
  
  Le 05/02/2012 13:51, Eugene Arshinov a écrit :
  Hello all.
 
  Hey Eugene,
 
  I have several suggestions and questions about certain line
  operations implemented in Geany.
 
  1) Recently I found that move lines up/down command does not
  work properly for the last line not ending with a newline.  You
  can easily check it yourself.  Couple of minutes ago I made a pull
  request [1] with an implementation of `editor.c:move_lines()`
  which handles the problem.  Dear unknown someone, please review
  and pull if it's okay.
 
  I know this problem, but it needed a so big code refactoring it
  hurts (I want as a proof the fact your rewrite is... huge), so...
  I just postponed it.  Ok, shame on me.
 
  I haven't reviewed the new code yet, but I'll do.  Just as a note,
  Scintilla has a command to do that that suffers (suffered?) of the
  exact same bug we had.  Maybe it'd be good to fix their copy and
  use the SCI message in place of our code.
 
  [snip]
  
  I didn't find those Scintilla commands
  (SCI_MOVESELECTEDLINES{UP,DOWN} to be precise) because they are not
  mentioned in the official Scintilla documentation [1], though they
  are of course mentioned in Scintilla.h. For completeness, here is
  the feature request for Scintilla where those commands came from -
  [2].
 
 It is in the docs:
 http://www.scintilla.org/ScintillaDoc.html#SCI_MOVESELECTEDLINESUP
 

Stupid me.  Probably I searched for MOVELINES, not MOVESELECTEDLINES

  The commands indeed work similarly to our own `move_lines`
  function.  I posted pull request #24 [3] which removes `move_lines`
  function and leverages the commands.  I hope it can be committed so
  that I can switch my effort of improving Move lines feature from
  Geany to Scintilla.
 
 Looks fine to -- apart of course it doesn't fix the initial problem
 yet. At least so there would be only one copy of the functionality.
 
 So just to be sure we understand each other: I drop your previous pull
 request (#21), apply this one (#24) and wait for your patch to be in
 Scintilla?
 

Yes.  But I don't promise that I'll post a request to Scintilla *soon*…
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Some obsolete(?) bug reports

2012-02-19 Thread Eugene Arshinov
On Sun, 19 Feb 2012 16:51:54 +0100
Colomban Wendling lists@herbesfolles.org wrote:

 Le 19/02/2012 01:06, Lex Trotman a écrit :
  [...]
 
  I just taught the file mangler to run geany -c so it never
  interrupts what a normal Geany is doing :)
 
  I don't think that's something everybody should need to do.
 
  
  Yes, true.
  
  [...]
  I personally do think what we do is definitely the Wrong Thing.
  Honestly, I always have found this behavior very counter-intuitive
  and not helpful.  I mean, if I tell Geany to restore my session, I
  expect it to be restored whenever I start Geany, not only in some
  cases.
 
  
  Looking at it like that, then the current behaviour is wrong.
  
  I also checked a few other apps and all restore past sessions and
  add the new file to it, so I would say this is the behaviour a user
  would expect.
  
  
  OK, for me it's not a real problem since I always have one or more
  Geany instance open, but remembering the early times I did
  unexpectedly lost some session data because of this behavior.
 
  To summarize, I think that the current behavior will most likely
  NOT be the expected one and will disturb most users.  See, even us
  do workaround that in some ways, either using -c or having an
  instance always open.
  
  Or both, so I *never* saw it as a problem :)
  
 
  So I'd say aye to Dimitar since he gently volunteered :)
  Moreover if it is a preference I don't see any loss; but I'd
  better see this preference turned on by default for new
  configurations if the restore session one is on.
 
  
  Colomban has been so persuasive
 
 Hehe :D
 
  that I don't even think it needs
  another option, the suggested behaviour is non-destructive, so why
  not just turn restoring sessions on or off.
 
 Agreed, another pref isn't needed, either always restore or never
 restore should be enough; IMO too.
 
 Sounds reasonable to everybody?
 

I agree.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Empty project properties dialog

2012-02-19 Thread Jiří Techet
On Sun, Feb 19, 2012 at 17:57, Jiří Techet tec...@gmail.com wrote:
 On Sat, Jan 14, 2012 at 21:16, Jiří Techet tec...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 22:57, Lex Trotman ele...@gmail.com wrote:
 On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbr...@codebrainz.ca wrote:
 On 01/13/2012 03:31 AM, Lex Trotman wrote:

 [...]

 What if we deprecate the old project create/confirm API altogether, add
 the
 project preferences dialog to GeanyMainWidgets structure, and just let
 plugins use the response, hide and show signals on it as a normal
 GtkDialog?


 Sounds fine to my limited understanding.


 This wasn't possible before when the dialog was created/destroyed each
 time
 since the pointer in the main_widgets global would change all the time,
 but
 now it'll stay the same right from before `geany-startup-complete` all
 the
 way until after plugins are unloaded . We could even say with certainty
 that
 this API *won't ever* change, the project dialog in main_widgets would
 *always* be a (subclass of) GtkDialog and so would only break if GTK+
 broke
 this.


 But how much of the internal structure of the dialog are you going to
 document?

 Is Jiri expected to find the notebook widget within the dialog or will
 it be passed some other way? If from the dialog it needs to be
 documented (or at least its name does).


 Yeah, I thought about this after I sent the last message. We would need to
 add the dialog *and* the dialog's notebook to the main_widgets struct, like
 we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have
 to guarantee a name so it could be accessed through ui_lookup_widget() or 
 do
 the signals on the wrong object thing like is done for most signals (with
 the renames Jiri proposed).

 Well I'd say the first or second, but Jiri or others may have a
 different preference.


 I don't really care - both versions would work. But I too prefer using

 So finally I had some free time to test and listening on the dialog
 signals doesn't work as I need. The the code for displaying project
 dialog in Geany looks like this:

        while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
        {
                if (update_config(e, FALSE))
                {

 Now when I connect to the dialog signals, they get emitted on the line

        while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)

 which means that in the signal handler I don't have access to the
 updated config values from the dialog because these are updated
 afterwards by

                if (update_config(e, FALSE))

 So if there aren't any objections, I'll go back to the implementation
 I originally suggested and which emits the signal only after the
 config has been successfully updated.

I've created new pull request with the changes here:

https://github.com/geany/geany/pull/25

If you are interested, these are the changes made to GProject:

https://github.com/techee/geany-plugins/compare/project_prefs_fix

Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel