Dear devels The {datetime} & {date} templates are updated only after reloading the config. To reproduce insert {datetime} in ~/.config/geany/templates/changelog, reload the config and then in a blank document do c-menu > insert > changelog. Wait a minute (or an hour, or a day) and insert again the entry, and you will notice that Geany always uses the time of the last Tools > Reload config, and not the current system time. The behaviour can easily make the user insert the wrong time (or even day or week, when keeping the session alive using suspend) when compiling logs.
Is this something that could be easily fixed? Thank you Liviu
System: Geany 0.20 on Xubuntu 10.04 64bit
On 14 April 2011 23:27, Liviu Andronic landronimirc@gmail.com wrote:
Dear devels The {datetime} & {date} templates are updated only after reloading the config. To reproduce insert {datetime} in ~/.config/geany/templates/changelog, reload the config and then in a blank document do c-menu > insert > changelog. Wait a minute (or an hour, or a day) and insert again the entry, and you will notice that Geany always uses the time of the last Tools > Reload config, and not the current system time. The behaviour can easily make the user insert the wrong time (or even day or week, when keeping the session alive using suspend) when compiling logs.
Is this something that could be easily fixed? Thank you Liviu
System: Geany 0.20 on Xubuntu 10.04 64bit
Yes the {datetime} and {date} are substituted when the templates are initialised, usually when Geany is opened. As you say this may not be very useful.
This can be changed just by moving the call to templates_replace_default_dates, but where to?
Options are:
1. when the document is created from the template 2. when the document is saved as a file (when untitled gets replaced)
Votes please.
Cheers Lex
On Thursday 14 April 2011 08:02:17 pm Lex Trotman wrote:
Yes the {datetime} and {date} are substituted when the templates are initialised, usually when Geany is opened. As you say this may not be very useful.
This can be changed just by moving the call to templates_replace_default_dates, but where to?
Options are:
- when the document is created from the template
- when the document is saved as a file (when untitled gets replaced)
Votes please.
I haven't yet used those templates (and might never, my file format is a multi-record format and I will want to timestamp the creation of each record, but I anticipate doing that with a recorded (or Lua) macro).
I can't remember how those dates are handled in something like Microsoft Word (the last time I can remember using something like those tempates--but close to 10 years ago, now), but I'm pretty sure it would *not* be a good idea to change them each time the document is saved.
More likely, I'd want them changed (and "captured") when a document is created.
But, I strongly suggest matching the behavior to other similar applications (i.e., editors / word processors).
Randy Kramer
On 15 April 2011 21:51, Randy Kramer rhkramer@gmail.com wrote:
On Thursday 14 April 2011 08:02:17 pm Lex Trotman wrote:
Yes the {datetime} and {date} are substituted when the templates are initialised, usually when Geany is opened. As you say this may not be very useful.
This can be changed just by moving the call to templates_replace_default_dates, but where to?
Options are:
- when the document is created from the template
- when the document is saved as a file (when untitled gets replaced)
Votes please.
I haven't yet used those templates (and might never, my file format is a multi-record format and I will want to timestamp the creation of each record, but I anticipate doing that with a recorded (or Lua) macro).
I can't remember how those dates are handled in something like Microsoft Word (the last time I can remember using something like those tempates--but close to 10 years ago, now), but I'm pretty sure it would *not* be a good idea to change them each time the document is saved.
Apologies if it was unclear, but after the {date} or {datetime} marker is *replaced* by the date/time the first time it no longer exists so no further updates occur.
Cheers Lex
More likely, I'd want them changed (and "captured") when a document is created.
But, I strongly suggest matching the behavior to other similar applications (i.e., editors / word processors).
Randy Kramer
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Friday 15 April 2011 08:57:00 am Lex Trotman wrote:
Apologies if it was unclear, but after the {date} or {datetime} marker is *replaced* by the date/time the first time it no longer exists so no further updates occur.
Lex,
Thanks! No problem, it sounds like what I (vaguely) remember from Word.
Randy Kramer
On Fri, 15 Apr 2011 22:57:00 +1000 Lex Trotman elextr@gmail.com wrote:
On 15 April 2011 21:51, Randy Kramer rhkramer@gmail.com wrote:
On Thursday 14 April 2011 08:02:17 pm Lex Trotman wrote:
Yes the {datetime} and {date} are substituted when the templates are initialised, usually when Geany is opened. As you say this may not be very useful.
This can be changed just by moving the call to templates_replace_default_dates, but where to?
Options are:
- when the document is created from the template
- when the document is saved as a file (when untitled gets replaced)
Votes please.
I haven't yet used those templates (and might never, my file format is a multi-record format and I will want to timestamp the creation of each record, but I anticipate doing that with a recorded (or Lua) macro).
I can't remember how those dates are handled in something like Microsoft Word (the last time I can remember using something like those tempates--but close to 10 years ago, now), but I'm pretty sure it would *not* be a good idea to change them each time the document is saved.
Apologies if it was unclear, but after the {date} or {datetime} marker is *replaced* by the date/time the first time it no longer exists so no further updates occur.
What about moving this to request time? So not parsing at startup but parsing it when requested by user to insert?
Cheers, Frank
On Fri, Apr 15, 2011 at 6:35 PM, Frank Lanitz frank@frank.uvena.de wrote:
What about moving this to request time? So not parsing at startup but parsing it when requested by user to insert?
Yes! This would definitely be much better. Of course, if easy enough to implement. Liviu
On 17 April 2011 20:37, Liviu Andronic landronimirc@gmail.com wrote:
On Fri, Apr 15, 2011 at 6:35 PM, Frank Lanitz frank@frank.uvena.de wrote:
What about moving this to request time? So not parsing at startup but parsing it when requested by user to insert?
Yes! This would definitely be much better. Of course, if easy enough to implement. Liviu
Personally I'd prefer it to happen automatically the first time the file is saved, the way the filename is inserted.
If its manual I'll forget to request it, guaranteed. :-(
Cheers Lex
Hello I'm not sure I follow.
On Sun, Apr 17, 2011 at 12:40 PM, Lex Trotman elextr@gmail.com wrote:
On 17 April 2011 20:37, Liviu Andronic landronimirc@gmail.com wrote:
On Fri, Apr 15, 2011 at 6:35 PM, Frank Lanitz frank@frank.uvena.de wrote:
What about moving this to request time? So not parsing at startup but parsing it when requested by user to insert?
This means that when selecting c-menu > insert > changelog the {datetime} inserted will be the system current date and time. Correct? Inserting a second time, 2 min later, would insert a new date and time (again current with respect to the moment of insertion).
Yes! This would definitely be much better. Of course, if easy enough to implement. Liviu
Personally I'd prefer it to happen automatically the first time the file is saved, the way the filename is inserted.
This would set the date and time to the time of the file first save. And then it would stay static. Correct? I'm not sure how useful this would be, at least not for me.
Regards Liviu
If its manual I'll forget to request it, guaranteed. :-(
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 17 April 2011 20:55, Liviu Andronic landronimirc@gmail.com wrote:
Hello I'm not sure I follow.
On Sun, Apr 17, 2011 at 12:40 PM, Lex Trotman elextr@gmail.com wrote:
On 17 April 2011 20:37, Liviu Andronic landronimirc@gmail.com wrote:
On Fri, Apr 15, 2011 at 6:35 PM, Frank Lanitz frank@frank.uvena.de wrote:
What about moving this to request time? So not parsing at startup but parsing it when requested by user to insert?
This means that when selecting c-menu > insert > changelog the {datetime} inserted will be the system current date and time. Correct? Inserting a second time, 2 min later, would insert a new date and time (again current with respect to the moment of insertion).
Yes! This would definitely be much better. Of course, if easy enough to implement. Liviu
Personally I'd prefer it to happen automatically the first time the file is saved, the way the filename is inserted.
This would set the date and time to the time of the file first save. And then it would stay static. Correct? I'm not sure how useful this would be, at least not for me.
Please note my response to Randy, once the string {datetime} or {date} is replaced it no longer exists in the file, so the date recorded is always static, no matter when it is done. If you want a variable date, thats a different piece of functionality to what we are talking about here.
Cheers Lex
Regards Liviu
If its manual I'll forget to request it, guaranteed. :-(
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
-- Do you know how to read? http://www.alienetworks.com/srtest.cfm http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Ummmm, I have just realised I have misunderstood Franks comment, since I was mostly thinking about file templates and he was talking about insertions, so I'll change my answer. I agree that substitution should happen when the template is put in the buffer not when Geany is started, for both types.
The option of substitute when the file is written can only sensibly be applied to file templates, but the above handles all templates uniformly.
Cheers Lex
On Thu, 14 Apr 2011 15:27:44 +0200 Liviu Andronic landronimirc@gmail.com wrote:
The {datetime} & {date} templates are updated only after reloading the config. To reproduce insert {datetime} in ~/.config/geany/templates/changelog, reload the config and then in a blank document do c-menu > insert > changelog. Wait a minute (or an hour, or a day) and insert again the entry, and you will notice that Geany always uses the time of the last Tools > Reload config, and not the current system time. The behaviour can easily make the user insert the wrong time (or even day or week, when keeping the session alive using suspend) when compiling logs.
Should be fixed now in SVN, thanks.
Regards, Nick
On Sat, Apr 23, 2011 at 2:19 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 14 Apr 2011 15:27:44 +0200 Liviu Andronic landronimirc@gmail.com wrote:
The {datetime} & {date} templates are updated only after reloading the config. To reproduce insert {datetime} in ~/.config/geany/templates/changelog, reload the config and then in a blank document do c-menu > insert > changelog. Wait a minute (or an hour, or a day) and insert again the entry, and you will notice that Geany always uses the time of the last Tools > Reload config, and not the current system time. The behaviour can easily make the user insert the wrong time (or even day or week, when keeping the session alive using suspend) when compiling logs.
Should be fixed now in SVN, thanks.
Cool! Thanks.
I tried to compile r5734 but I hit a bump: AR libtagmanager.a make[3]: Leaving directory `/usr/local/build/geany/tagmanager' make[2]: Leaving directory `/usr/local/build/geany/tagmanager' Making all in scintilla make[2]: Entering directory `/usr/local/build/geany/scintilla' Making all in include make[3]: Entering directory `/usr/local/build/geany/scintilla/include' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/build/geany/scintilla/include' make[3]: *** No rule to make target `PlatGTK.cxx', needed by `PlatGTK.o'. Stop. make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 make[3]: Entering directory `/usr/local/build/geany/scintilla' make[3]: Leaving directory `/usr/local/build/geany/scintilla' make[2]: Leaving directory `/usr/local/build/geany/scintilla' make[1]: Leaving directory `/usr/local/build/geany'
make (6140) returned '2'
Configure went fine: Install Geany in : /usr/local Using GTK version : 2.20.1 Build with GTK printing support : yes Build with plugin support : yes Use virtual terminal support : yes Use (UNIX domain) socket support : yes GNU regex library : system Compiling Subversion revision : r5734
Configuration is done OK.
Am I missing something? Liviu
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 23/04/2011 20:25, Liviu Andronic a écrit :
On Sat, Apr 23, 2011 at 2:19 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 14 Apr 2011 15:27:44 +0200 Liviu Andronic landronimirc@gmail.com wrote:
[...]
Should be fixed now in SVN, thanks.
Cool! Thanks.
I tried to compile r5734 but I hit a bump: [...]
I guess you've not build Geany since a while, right? Just regenerate the whole build system, there is a known problem since the big change in the Scintilla directory tree. You just need to:
make distclean && ./autogen.sh && make
Cheers, Colomban
On Sat, Apr 23, 2011 at 10:21 PM, Colomban Wendling lists.ban@herbesfolles.org wrote:
I guess you've not build Geany since a while, right?
Yup.
Just regenerate the whole build system, there is a known problem since the big change in the Scintilla directory tree. You just need to:
make distclean && ./autogen.sh && make
Right, distclean! I only fancied make clean. Now it worked.
The {datetime} & {date} templates seem to be updated, as expected, upon inserting. Thanks! Liviu
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 23.04.2011 22:37, schrieb Liviu Andronic:
Right, distclean! I only fancied make clean. Now it worked.
The {datetime}& {date} templates seem to be updated, as expected, upon inserting. Thanks! Liviu
That "make clean" worked was would have been my expecation too. Is something wrong with the build system?
Best regards.
Le 24/04/2011 02:32, Thomas Martitz a écrit :
Am 23.04.2011 22:37, schrieb Liviu Andronic:
Right, distclean! I only fancied make clean. Now it worked.
The {datetime}& {date} templates seem to be updated, as expected, upon inserting. Thanks! Liviu
That "make clean" worked was would have been my expecation too. Is something wrong with the build system?
I'm not really sure, but it seems the Autotools had some problems dealing with major refactoring (all build system under scintilla changed around the end of 2010 IIRC), failing to detect properly the need to regenerate itself. I'm no Autotools guru [1], so I can't tell whether it's a problem in the Autotools side or if we did something wrong at some point; all I can say is that the build system looks well formed to me (well, I haven't done a review, but still), and that forcing the regeneration fixes the problem -- so it at least work ^^
Finally, note that "make clean" only removes files generated at build time (.o, .lo, etc) but not in any case any of the build system files. Distclean, however, removes all the parts of the build system that are generated on configuration, in order to get a fresh build system that only waits to be configured (as a distribution tarball expects it) -- meaning it removes Makefiles, config.h, etc. See http://www.gnu.org/software/automake/manual/automake.html#Clean for details.
Cheers, Colomban
[1] Though I'm happy to start knowing it quite well with the time :)