Branch: refs/heads/master
Author: Enrico Tröger <enrico.troeger(a)uvena.de>
Committer: Enrico Tröger <enrico.troeger(a)uvena.de>
Date: Sun, 19 Nov 2017 10:44:04 UTC
Commit: 525952cebf08b3f080819b019a77efc258ad5000
https://github.com/geany/geany/commit/525952cebf08b3f080819b019a77efc258ad5…
Log Message:
-----------
Update NEWS for 1.32
Modified Paths:
--------------
NEWS
Modified: NEWS
57 lines changed, 56 insertions(+), 1 deletions(-)
===================================================================
@@ -1,4 +1,59 @@
-Geany 1.32 (unreleased)
+Geany 1.32 (November 19, 2017)
+
+ General
+ * Improve CLI argument help (PR#1644).
+ * Keep the current tab when closing documents to the right of another tab.
+ * Re-enable SIGTERM handling (PR#1255).
+ * Create correct path for filetype config files (Jiří Techet, PR#1482).
+ * Add an option to enable IME's candidate window display inline
+ (Sinpo Wei, PR#1514).
+ * Add an option to automatically reload files changed on disk
+ (Mark O'Donovan, PR#1246).
+
+ Bug fixes
+ * Fix backward compatibility of the geometry saving setting.
+ * Close "Deleted from Disk" Infobar on Reload (Lars Paulsen, PR#1628).
+ * Make sure GDK_MOD2_MASK is cleared when getting modifiers
+ (Jiří Techet, PR#1636).
+ * Use non-symlinked VTE libraries on MacOS X (Jiří Techet, PR#1625).
+ * Fix crash if plugin manager is opened more than once (PR#1564).
+ * Fix incorrect variable reference (Thomas Martitz, PR#1561).
+
+ Interface
+ * Add "Close Documents to the Right" feature (PR#1362).
+ * Add an option to save/reload either window position or size,
+ but optionally not both (delt01, PR#1456).
+
+ Editor
+ * Update Scintilla to version 3.7.5 (PR#1503).
+ * Improve snippet support (visual indicators and more)
+ (Thomas Martitz, PR#1470).
+ * Push current position to navqueue before navigating back
+ (Vasiliy Faronov, PR#1537).
+
+ Filetypes
+ * Add GNU assembler filetype extensions (Issue#904).
+ * Make Python comment hash space (PR#1682).
+ * Add missing string and comment styles for various lexers (PR#1502).
+ * Add missing PHP keywords, especially for PHP 7.x (1547, PR#1547).
+ * Python: Don't highlight sub-identifiers as keywords (PR#1544).
+
+ Plugins
+ * FileBrowser: don't change directory on project save
+ (Jiří Techet, PR#1400).
+
+ Windows
+ * Fix Execute button on Windows when using HTML files and
+ "builtin" command (Issue#1018, PR#1667).
+
+ API
+ * Add `utils_get_real_path()` and deprecate `tm_get_real_path()` (PR#1224).
+ * Add `geany_plugin_get_data()` (PR#1234).
+ * Add `keybindings_load_keyfile()` (Jiří Techet, PR#1430).
+ * Add `tm_tag_get_type()` (Thomas Martitz, PR#1465).
+
+ HACKING:
+ * Add note about data types and update for best practices (PR#1282).
Internationalization
* Updated translations: ca, de, el, es, fr, it, lt, lv, nl, pt, ru,
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: https://github.com/geany/infrastructure).
Branch: refs/heads/elextr-patch-2
Author: Matthew Brush <matt(a)geany.org>
Committer: Matthew Brush <matt(a)geany.org>
Date: Thu, 16 Nov 2017 05:09:42 UTC
Commit: ea5d32a49f018aaa1cebf2ef863737d16192877e
https://github.com/geany/geany/commit/ea5d32a49f018aaa1cebf2ef863737d161928…
Log Message:
-----------
Fix some grammar and spelling errors
Modified Paths:
--------------
HACKING
Modified: HACKING
17 lines changed, 9 insertions(+), 8 deletions(-)
===================================================================
@@ -154,24 +154,25 @@ into an executable program::
This usually takes a few minutes, depending on the speed of your
system. This step is where you'll get all of your compilation errors
-so if you've change the source code, take heed of the warning/error
+so if you've changed the source code, take heed of the warning/error
messages reported here.
If you have multiple CPUs/cores you can pass the `-j` option to `make`
to have it spin up the specified number of concurrent processes where
possible to complete the compilation and linking stages in less time.
-Geany's build system is incremental, so after you hack on the code and
+Geany's build system is also incremental, so after you hack on the code and
want to rebuild, you can run `make` again and only the needed files
-will be built, which makes it much faster than the initial build.
+will be re-built, which makes it much faster than the initial build.
-Once Geany is built, we want to install it into the provided `--prefix`
+Once Geany is built, we want to install it into the directory
+previously specified to the `configure` script using `--prefix` option
to test it, like this::
$ make install
-In fact, the `make install` rule will necessary run the complete build,
-so you can skip running `make` by itself as above and instead just run
-`make install`, combining the two steps into one.
+In fact, the `make install` rule will necessarily run the complete
+build, so you can skip running `make` by itself as above and instead
+just run `make install`, combining the two steps into one.
Now that Geany is installed in our special isolated prefix, we can run
it as follows::
@@ -203,7 +204,7 @@ to the master branch like this::
$ git checkout master
-Whenever you've made changes to the source in some branch and want to
+Whenever you've made changes to the sources in some branch and want to
test them, you can always re-run these commands::
$ make install
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: https://github.com/geany/infrastructure).
Branch: refs/heads/elextr/hacking-build
Author: Matthew Brush <matt(a)geany.org>
Committer: Matthew Brush <matt(a)geany.org>
Date: Thu, 16 Nov 2017 04:11:34 UTC
Commit: 0c4916aaa56079920d4b5c1b7fc705c3b3a901e6
https://github.com/geany/geany/commit/0c4916aaa56079920d4b5c1b7fc705c3b3a90…
Log Message:
-----------
Flesh-out new HACKING docs
This is a rather long tutorial-style section, but it seems to fit nicely
towards the start of the HACKING file.
Modified Paths:
--------------
HACKING
Modified: HACKING
180 lines changed, 165 insertions(+), 15 deletions(-)
===================================================================
@@ -41,23 +41,173 @@ The documentation will be output to doc/reference/index.html.
Alternatively you can view the API documentation online at
http://www.geany.org/manual/reference/.
-Build a standalone Geany for hacking
+Setting up a Development Environment
------------------------------------
-This performs a simple in-tree build of Geany that does not interfere with your installed version.
-Assuming you have installed the necessary tools.
-
-Create a directory `/home/you/somewhere/` then::
-
- cd /home/you/somewhere
- git clone https://github.com/geany/geany.git
- cd geany
- ./autogen.sh --prefix=/home/you/somewhere
- make install
- cd ../bin
- ./geany -c ../config
-
-Note no privileges or sudo are required, and when you are finished just `rm -rf /home/you/somewhere`.
+If you plan on hacking on Geany's code, you probably want to setup a
+working environment for compiling it and testing it out without
+interfering with your main Geany installation from your package manager
+or release package. This approach does not require "root"/sudo
+permissions, and doesn't risk messing up your system or leaving cruft
+behind.
+
+This section assumes you have all of the tools, and development
+dependencies already installed (ex. autoconf, automake, libtool, GTK+
+development headers, etc), which are documented elsewhere. Generally
+speaking if you encounter an error during the set up here, read any
+warning/error messages produced and most likely they will mention if
+you need to install something else. Install these dependencies using
+your package manager or preferred software distribution mechanism
+
+To save some typing and potential typos, lets first define an
+environment variable containing the path to where your Geany "hacking"
+files will live, for example::
+
+ $ export DEVDIR=$HOME/geany-dev
+
+Everything related to this "hacking" build will be below this
+directory. You can call the directory whatever you want, but it's
+recommended that it's a directory somewhere below your home directory.
+
+Now let's create that directory and change into it::
+
+ $ mkdir -p $DEVDIR
+ $ cd $DEVDIR
+
+We'll keep a checkout of Geany's source code in a directory called
+`source`. Let's use Git to put a fresh copy of Geany's development code
+in this directory and then change into it::
+
+ $ git clone https://github.com/geany/geany.git source
+ $ cd source
+
+If you plan on ever contributing your changes back to Geany, you should
+setup the Git repository with your correct authorship information::
+
+ $ git config user.name "Your Name Here"
+ $ git config user.email "you(a)domain.com"
+
+This should be one of the email addresses you've setup with Github (if
+applicable) if you want Github to recognize your user as having
+authored the changes (linking to your profile, etc).
+
+The first time you checkout Geany's source code from Git, and possibly
+later down the line if you find yourself hacking on Geany's build
+system, you need to run the `autogen.sh` script to bootstrap the build
+system and prepare the configuration scripts. The `autogen.sh` script
+will automatically run the build system configuration scripts by
+default, which we don't want with the way the development environment
+will be set up, so we're setting the `NOCONFIGURE` environment variable
+for the `autogen.sh` script to disable that behaviour::
+
+ $ cd $DEVDIR/source
+ $ NOCONFIGURE=1 ./autogen.sh
+
+After this command a script named `configure` will be available in the
+source directory that needs to be run to actually configure the build
+system. It's usually a good idea not to build Geany right inside the
+source directory because it will produce all kinds of files that will
+soil your nice clean Git checkout, so we'll do an "out-of-tree" build
+by executing the `configure` script from a different directory, which
+we'll create and change into like this::
+
+ $ mkdir -p $DEVDIR/build
+ $ cd $DEVDIR/build
+
+Now to actually run the `configure` script that will check your system
+to ensure you have all of the requisit tools, libraries and headers
+installed, and produce Make files which we'll use to compile and link
+Geany.
+
+We can run it as follows::
+
+ $ CFLAGS='-Wall -Wextra -Wno-unused-parameter' \
+ $DEVDIR/source/configure \
+ --prefix=$DEVDIR/prefix/install_1
+
+This might look a little complicated but it's actually not bad (note
+the escaped line-breaks are for readability, you don't have to put it
+on multiple lines). The first line is setting the `CFLAGS` environment
+variable to enable some stricter-than-default compiler warning messages
+(see `Compiler options & warnings`_). If you're hacking on Geany's
+source and have any intention of providing your changes for inclusion
+into Geany proper, you definitively want stricter-than-default compiler
+warnings.
+
+The second line is actually calling the `configure` script using an
+explicit path, since we're building in a different directory.
+
+The third line is passing the `--prefix` option to the `configure`
+script, giving a directory within the development directory called
+`prefix/install_1`. This is where this build of Geany will be installed
+later, as opposed to the default directory (usually `/usr/local`, which
+requires root permissions). The reason it's called `install_1` is
+simply to highlight that you may want to have several concurrent
+development installs without them interfering with each other. You
+might name another install `install_2`, for example. The actual path is
+completely arbitrary.
+
+With the build system configured, we're ready to compile and link Geany
+into an executable program::
+
+ $ make
+
+This usually takes a few minutes, depending on the speed of your
+system. This step is where you'll get all of your compilation errors
+so if you've change the source code, take heed of the warning/error
+messages reported here.
+
+If you have multiple CPUs/cores you can pass the `-j` option to `make`
+to have it spin up the specified number of concurrent processes where
+possible to complete the compilation and linking stages in less time.
+Geany's build system is incremental, so after you hack on the code and
+want to rebuild, you can run `make` again and only the needed files
+will be built, which makes it much faster than the initial build.
+
+Once Geany is built, we want to install it into the provided `--prefix`
+to test it, like this::
+
+ $ make install
+
+In fact, the `make install` rule will necessary run the complete build,
+so you can skip running `make` by itself as above and instead just run
+`make install`, combining the two steps into one.
+
+Now that Geany is installed in our special isolated prefix, we can run
+it as follows::
+
+ $ $DEVDIR/prefix/install_1/bin/geany -v -c $DEVDIR/conf/install_1
+
+This fires up the freshly installed Geany executable passing it the
+`-v` option to have it print out verbose debugging messages in the
+terminal, as well as the `-c` option to specify a configuration
+different from our main Geany installation. The sub-directory
+`conf/install_1` is used here to indicate that we're testing that
+specific installation (from above). This path is completely arbitrary
+and it would not be uncommon to have more than one testing "config"
+directory per installation/hacking session. Generally, whenever you
+want to start from scratch at manually testing some changes to Geany,
+especially preferences, filetypes, plugin preferences, etc, you should
+work from a new config directory.
+
+Now you're ready to start hacking away on Geany. If you have an
+explicit change in mind and plan to propose it for inclusion into Geany
+proper, it's always best to create a Git branch to keep the changes
+isolated from everything else::
+
+ $ git checkout -b fix-some-bug
+
+Now you can make changes to Geany's source and commit them to this
+branch, and always get back to a clean Geany checkout by switching back
+to the master branch like this::
+
+ $ git checkout master
+
+Whenever you've made changes to the source in some branch and want to
+test them, you can always re-run these commands::
+
+ $ make install
+ $ $DEVDIR/prefix/install_1/bin/geany -v -c $DEVDIR/conf/install_1
Pull requests
-------------
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: https://github.com/geany/infrastructure).
Branch: refs/heads/elextr-patch-2
Author: Matthew Brush <matt(a)geany.org>
Committer: Matthew Brush <matt(a)geany.org>
Date: Thu, 16 Nov 2017 04:11:34 UTC
Commit: 0c4916aaa56079920d4b5c1b7fc705c3b3a901e6
https://github.com/geany/geany/commit/0c4916aaa56079920d4b5c1b7fc705c3b3a90…
Log Message:
-----------
Flesh-out new HACKING docs
This is a rather long tutorial-style section, but it seems to fit nicely
towards the start of the HACKING file.
Modified Paths:
--------------
HACKING
Modified: HACKING
180 lines changed, 165 insertions(+), 15 deletions(-)
===================================================================
@@ -41,23 +41,173 @@ The documentation will be output to doc/reference/index.html.
Alternatively you can view the API documentation online at
http://www.geany.org/manual/reference/.
-Build a standalone Geany for hacking
+Setting up a Development Environment
------------------------------------
-This performs a simple in-tree build of Geany that does not interfere with your installed version.
-Assuming you have installed the necessary tools.
-
-Create a directory `/home/you/somewhere/` then::
-
- cd /home/you/somewhere
- git clone https://github.com/geany/geany.git
- cd geany
- ./autogen.sh --prefix=/home/you/somewhere
- make install
- cd ../bin
- ./geany -c ../config
-
-Note no privileges or sudo are required, and when you are finished just `rm -rf /home/you/somewhere`.
+If you plan on hacking on Geany's code, you probably want to setup a
+working environment for compiling it and testing it out without
+interfering with your main Geany installation from your package manager
+or release package. This approach does not require "root"/sudo
+permissions, and doesn't risk messing up your system or leaving cruft
+behind.
+
+This section assumes you have all of the tools, and development
+dependencies already installed (ex. autoconf, automake, libtool, GTK+
+development headers, etc), which are documented elsewhere. Generally
+speaking if you encounter an error during the set up here, read any
+warning/error messages produced and most likely they will mention if
+you need to install something else. Install these dependencies using
+your package manager or preferred software distribution mechanism
+
+To save some typing and potential typos, lets first define an
+environment variable containing the path to where your Geany "hacking"
+files will live, for example::
+
+ $ export DEVDIR=$HOME/geany-dev
+
+Everything related to this "hacking" build will be below this
+directory. You can call the directory whatever you want, but it's
+recommended that it's a directory somewhere below your home directory.
+
+Now let's create that directory and change into it::
+
+ $ mkdir -p $DEVDIR
+ $ cd $DEVDIR
+
+We'll keep a checkout of Geany's source code in a directory called
+`source`. Let's use Git to put a fresh copy of Geany's development code
+in this directory and then change into it::
+
+ $ git clone https://github.com/geany/geany.git source
+ $ cd source
+
+If you plan on ever contributing your changes back to Geany, you should
+setup the Git repository with your correct authorship information::
+
+ $ git config user.name "Your Name Here"
+ $ git config user.email "you(a)domain.com"
+
+This should be one of the email addresses you've setup with Github (if
+applicable) if you want Github to recognize your user as having
+authored the changes (linking to your profile, etc).
+
+The first time you checkout Geany's source code from Git, and possibly
+later down the line if you find yourself hacking on Geany's build
+system, you need to run the `autogen.sh` script to bootstrap the build
+system and prepare the configuration scripts. The `autogen.sh` script
+will automatically run the build system configuration scripts by
+default, which we don't want with the way the development environment
+will be set up, so we're setting the `NOCONFIGURE` environment variable
+for the `autogen.sh` script to disable that behaviour::
+
+ $ cd $DEVDIR/source
+ $ NOCONFIGURE=1 ./autogen.sh
+
+After this command a script named `configure` will be available in the
+source directory that needs to be run to actually configure the build
+system. It's usually a good idea not to build Geany right inside the
+source directory because it will produce all kinds of files that will
+soil your nice clean Git checkout, so we'll do an "out-of-tree" build
+by executing the `configure` script from a different directory, which
+we'll create and change into like this::
+
+ $ mkdir -p $DEVDIR/build
+ $ cd $DEVDIR/build
+
+Now to actually run the `configure` script that will check your system
+to ensure you have all of the requisit tools, libraries and headers
+installed, and produce Make files which we'll use to compile and link
+Geany.
+
+We can run it as follows::
+
+ $ CFLAGS='-Wall -Wextra -Wno-unused-parameter' \
+ $DEVDIR/source/configure \
+ --prefix=$DEVDIR/prefix/install_1
+
+This might look a little complicated but it's actually not bad (note
+the escaped line-breaks are for readability, you don't have to put it
+on multiple lines). The first line is setting the `CFLAGS` environment
+variable to enable some stricter-than-default compiler warning messages
+(see `Compiler options & warnings`_). If you're hacking on Geany's
+source and have any intention of providing your changes for inclusion
+into Geany proper, you definitively want stricter-than-default compiler
+warnings.
+
+The second line is actually calling the `configure` script using an
+explicit path, since we're building in a different directory.
+
+The third line is passing the `--prefix` option to the `configure`
+script, giving a directory within the development directory called
+`prefix/install_1`. This is where this build of Geany will be installed
+later, as opposed to the default directory (usually `/usr/local`, which
+requires root permissions). The reason it's called `install_1` is
+simply to highlight that you may want to have several concurrent
+development installs without them interfering with each other. You
+might name another install `install_2`, for example. The actual path is
+completely arbitrary.
+
+With the build system configured, we're ready to compile and link Geany
+into an executable program::
+
+ $ make
+
+This usually takes a few minutes, depending on the speed of your
+system. This step is where you'll get all of your compilation errors
+so if you've change the source code, take heed of the warning/error
+messages reported here.
+
+If you have multiple CPUs/cores you can pass the `-j` option to `make`
+to have it spin up the specified number of concurrent processes where
+possible to complete the compilation and linking stages in less time.
+Geany's build system is incremental, so after you hack on the code and
+want to rebuild, you can run `make` again and only the needed files
+will be built, which makes it much faster than the initial build.
+
+Once Geany is built, we want to install it into the provided `--prefix`
+to test it, like this::
+
+ $ make install
+
+In fact, the `make install` rule will necessary run the complete build,
+so you can skip running `make` by itself as above and instead just run
+`make install`, combining the two steps into one.
+
+Now that Geany is installed in our special isolated prefix, we can run
+it as follows::
+
+ $ $DEVDIR/prefix/install_1/bin/geany -v -c $DEVDIR/conf/install_1
+
+This fires up the freshly installed Geany executable passing it the
+`-v` option to have it print out verbose debugging messages in the
+terminal, as well as the `-c` option to specify a configuration
+different from our main Geany installation. The sub-directory
+`conf/install_1` is used here to indicate that we're testing that
+specific installation (from above). This path is completely arbitrary
+and it would not be uncommon to have more than one testing "config"
+directory per installation/hacking session. Generally, whenever you
+want to start from scratch at manually testing some changes to Geany,
+especially preferences, filetypes, plugin preferences, etc, you should
+work from a new config directory.
+
+Now you're ready to start hacking away on Geany. If you have an
+explicit change in mind and plan to propose it for inclusion into Geany
+proper, it's always best to create a Git branch to keep the changes
+isolated from everything else::
+
+ $ git checkout -b fix-some-bug
+
+Now you can make changes to Geany's source and commit them to this
+branch, and always get back to a clean Geany checkout by switching back
+to the master branch like this::
+
+ $ git checkout master
+
+Whenever you've made changes to the source in some branch and want to
+test them, you can always re-run these commands::
+
+ $ make install
+ $ $DEVDIR/prefix/install_1/bin/geany -v -c $DEVDIR/conf/install_1
Pull requests
-------------
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: https://github.com/geany/infrastructure).
Branch: refs/heads/elextr-patch-2
Author: elextr <elextr(a)gmail.com>
Committer: GitHub <noreply(a)github.com>
Date: Wed, 15 Nov 2017 06:48:40 UTC
Commit: 8c0d06378b75bc367e7110ca5f4b6a946e127eef
https://github.com/geany/geany/commit/8c0d06378b75bc367e7110ca5f4b6a946e127…
Log Message:
-----------
Add simplest development build process to HACKING
New developers not familiar with open source tools seem to struggle to build Geany simply, add a section near the top of hacking with the simple "get you started" process.
Modified Paths:
--------------
HACKING
Modified: HACKING
18 lines changed, 18 insertions(+), 0 deletions(-)
===================================================================
@@ -41,6 +41,24 @@ The documentation will be output to doc/reference/index.html.
Alternatively you can view the API documentation online at
http://www.geany.org/manual/reference/.
+Build a standalone Geany for hacking
+------------------------------------
+This performs a simple in-tree build of Geany that does not interfere with your installed version.
+
+Assuming you have installed the necessary tools.
+
+Create a directory `/home/you/somewhere/` then::
+
+ cd /home/you/somewhere
+ git clone https://github.com/geany/geany.git
+ cd geany
+ ./autogen.sh --prefix=/home/you/somewhere
+ make install
+ cd ../bin
+ ./geany -c ../config
+
+Note no privileges or sudo are required, and when you are finished just `rm -rf /home/you/somewhere`.
+
Pull requests
-------------
Making pull requests on Github is the preferred way of contributing for geany.
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: https://github.com/geany/infrastructure).