GitLab

"Search forward" is not a good name, because it can be confused with the
normal search and replace feature, to go to the next search occurrence.

Ideally I would prefer to document the Ctrl+click shortcut directly in
the menu item, instead of Ctrl+alt+f.

The release was created in a side-branch. From now on, I'll try to keep
the NEWS file complete on the master branch, to have a good history
overview.

I think it's useful information. It can be retrieved from git, but to do
it correctly (get the commiter date of the commit that the git tag
points to) is more difficult. It's easier if it's present in the NEWS
file.

The dates have been added with this quick and dirty script:
```
	#!/usr/bin/env bash

	tags_list=`git tag`
	for tag in $tags_list
	do
		# For the date, it takes the commiter date of the git commit that $tag
		# points to. This is normally the closest date to the real date of the
		# release (if the tag refers to a version). Sometimes a maintainer
		# forgets to create the tag and the tag is created afterwards.
		#
		# To show git tags alongside the tag creation dates, use the following
		# command instead:
		# $ git tag -l --format="%(refname:strip=2) - %(taggerdate:short)"

		commiter_date=`git log -1 --date=short --pretty="format:%cd" $tag`

		sed -i "s/^\(Release ${tag#v}\)$/\1, ${commiter_date}/" NEWS
	done

	sed -i "s/\(--------\)/\1------------/" NEWS
```

For the versions <= 0.2, the dates have been added manually from the
information in the first git repo (no longer public).

Indentation with tabs, alignment with tabs and then spaces to align on
the parenthesis.

https://wiki.gnome.org/Projects/GnomeCommon/Migration

Best practice is to use CLEANFILES to clean stuff built by make, and
DISTCLEANFILES only for stuff built by configure. Everyone has to run
make and it's very unexpected for 'make clean' to not clean things it
builds.

Best practice is to use CLEANFILES to clean stuff built by make, and
DISTCLEANFILES only for stuff built by configure. Everyone has to run
make and it's very unexpected for 'make clean' to not clean things it
builds.

The errors were:
org.gnome.latexila.appdata.xml: FAILED:
• tag-missing  : <name> is not present
• tag-missing  : <summary> is not present
• style-invalid: Too many <p> tags for a good description [5/4]

I don't really like merging the two paragraphs. I think when people see
long paragraphs they don't read them. And translations will need to be
updated, otherwise the description will be partly in English… Oh well,
anyway.

This is deprecated and will break with a future version of Automake.
Also, we already call AC_CONFIG_MACRO_DIR([m4]) in configure.ac, so it's
also useless. The downside is that it will introduce a nag warning from
libtool, but that's a libtool bug.

For the following code:
for (i = 0; i < n_names; i++)

The type of n_names is gsize, which is an unsigned long.

https://wiki.gnome.org/Projects/GnomeCommon/Migration

https://wiki.gnome.org/Projects/GnomeCommon/Migration

All the separate pkg-config calls were done after reading:
http://tirania.org/blog/archive/2012/Oct-20.html
("Drowning Good Ideas with Bloat. The tale of pkg.m4."
by Miguel de Icaza)

But all the GNOME modules I contribute to use PKG_CHECK_MODULES or
AX_PKG_CHECK_MODULES for a library. With those macros, it shows all the
errors at once (if several libs are missing or too old) instead of
aborting at the first error.

Automake 1.14 has been released 3 years ago, so I think we can depend on
it.

This permits to remove the call to AM_PROG_CC_C_O.

From the Automake documentation:

https://www.gnu.org/software/automake/manual/automake.html

AM_PROG_CC_C_O

    This is an obsolescent macro that checks that the C compiler
supports the -c and -o options together. Note that, since Automake 1.14,
the AC_PROG_CC is rewritten to implement such checks itself, and thus
the explicit use of AM_PROG_CC_C_O should no longer be required.

Copy the latest version from:
https://wiki.gnome.org/Projects/GnomeCommon/Migration

But remove glib-gettextize, keep only intltoolize for i18n.

Rafael Fontenelle authored Nov 20, 2016 and Administrator committed Nov 20, 2016

(cherry picked from commit 5e41fdc3)

So the call to _main_window.jump_to_file_position() is more natural.

To simplify the code.