Commits (3886)
include: 'https://gitlab.gnome.org/GNOME/citemplates/raw/master/flatpak/flatpak_ci_initiative.yml'
BUNDLE: "gedit-nightly.flatpak"
image: 'registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:master'
MANIFEST_PATH: "build-aux/flatpak/org.gnome.gedit.json"
RUNTIME_REPO: "https://sdk.gnome.org/gnome-nightly.flatpakrepo"
APP_ID: "org.gnome.gedit"
extends: .flatpak
stage: deploy
- 'flatpak'
extends: '.review'
stage: deploy
extends: '.stop_review'
[submodule "subprojects/libgd"]
path = subprojects/libgd
url = https://gitlab.gnome.org/GNOME/libgd.git
Active authors:
Paolo Maggi <paolo@gnome.org>
Paolo Borelli <pborelli@katamail.com>
Steve Frécinaux <code@istique.net>
Jesse van den Kieboom <jessevdk@gnome.org>
Ignacio Casal Quinteiro <icq@gnome.org>
Garrett Regier <garrettregier@gmail.com>
Sébastien Lafargue <slafargue@gnome.org>
Sébastien Wilmet <swilmet@gnome.org>
Old contributors:
Chema Celorio
James Willcox <jwillcox@gnome.org>
Federico Mena Quintero <federico@ximian.com>
Paolo Maggi <paolo@gnome.org>
Search on http://bugzilla.gnome.org for a list of known gedit's bug.
If you find a new bug, please report it at
The GNOME contributing guidelines require patches to be forwarded to GNOME's
Bugzilla instance hosted at https://bugzilla.gnome.org. Please do not open
GitHub pull requests against this module as they will be ignored. More
information is available at the following wiki page:
To know how to contribute, read the README and HACKING files.
Version 2, June 1991
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
......@@ -15,7 +15,7 @@ software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
......@@ -55,8 +55,8 @@ patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
0. This License applies to any program or other work which contains
......@@ -110,7 +110,7 @@ above, provided that you also meet all of these conditions:
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
......@@ -168,7 +168,7 @@ access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
......@@ -225,7 +225,7 @@ impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
......@@ -255,7 +255,7 @@ make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
How to Apply These Terms to Your New Programs
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
......@@ -303,17 +303,16 @@ the "copyright" line and a pointer to where the full notice is found.
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
......@@ -336,5 +335,6 @@ necessary. Here is a sample; alter the names:
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License.
The ChangeLog is autogenerated when creating the release.
If you are seeing this, use git log for viewing the list of changes.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
guidelines for gedit
Source code repository
gedit source code is maintained using the git version control system
and is available at the following location:
......@@ -10,25 +10,49 @@ Or if you have an account on GNOME servers:
A Web Interface is available at:
A web interface is available at:
Building from git
When building from a git checkout you will need to run the
autogen.sh script which takes care of running automake, autoconf,
etc and then run "configure" for you. You can pass options like
--prefix to autogen.sh and they will be forwarded to the configure
Note that you cannot run gedit from its build directory: you need
to install it with "make install". For this reason it is highly
recommended that you install in a separate prefix instead of
overwriting your system binaries. Note however that when running
gedit from a custom prefix you will need to set many environment
variables accordingly, for instance PATH and XDG_DATA_DIR.
The JHBuild tool can take care of all this for you.
Commit guidelines
Please don't commit directly to the git repository unless
you have been given the green light to commit freely to gedit.
you have been given the green light to commit freely to gedit.
When in doubt assume you haven't ;-).
Please attach patches in bugzilla (http://bugzilla.gnome.org).
If the patch fixes a bug that is not reported yet in bugzilla or is
an enhancement, create a new bugreport.
Please create patches with the git format-patch command.
If you are a translator feel free to mark strings for translation,
fix typos in the code, etc.
Please send patches for build & configure fixes too. I really appreciate
your help, I just want to review these fixes before applying.
If you are a "build sheriff", feel free to commit fixes for build and
If you are a "build sheriff", feel free to commit fixes for build and
configure (please, send me an e-mail with the patch you have applied).
When committing to the gedit git repository make sure to include a
......@@ -60,6 +84,111 @@ tracker reference if applicable) and so forth. Be concise but not too brief.
git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
Code conventions
You may encounter old code that doesn't follow all the following code
conventions, but for new code it is better to follow them, for consistency.
- Avoid trailing whitespace.
- Indent the C code with tabulations with a width of eight characters.
- The files should have a modeline for the indentation style.
- All blocks should be surrounded by curly braces, even one-line blocks. It
spaces out the code, and it is more convenient when some code must be added
or removed without the need to add or remove the curly braces.
- Follow the C89 standard. In particular, no "//"-style comments.
- As a general rule of thumb, follow the same coding style as the surrounding
- Do not be cheap about blank lines, spacing the code vertically help
readability. However never use two consecutive blank lines, there is really
no need.
Programming best practices
gedit is a pretty big piece of software, developed over the years by different
people and GNOME technologies. Some parts of the code may be a little old. So
when editing the code, we should try to make it better, not worse.
Here are some general advices.
- Simplicity: the simpler code the better. Any trick that seem smart when you
write it is going to bite your ass later when reading the code. Given that
you spend 90% of the time staring at the code and 10% writing it, making
reading the code harder is a net loss.
- Brevity: make an effort to refactor common code into utility functions and
use library function whenever is possible: every time you cut and paste a
line of code you are throwing away all the precious seconds of your life
that you will later spend trying to figure out the differences among the two
copies that will have surely diverged.
- Code for change: code is bound to contain bugs no matter how well it is
written. A good coding style allows to fix these bugs with minimal changes
instead of reformatting a whole section of unrelated code, this is
especially important to make patch review easier and to easily understand
the commit history. Some practical examples are:
- Factor code into self contained functions so that changing a function
does not require to change all the callers.
- Do not align variable declaration, "case" statements etc, since this
will inevitably mean that when a line will change you'll have to
reformat all the surrounding ones.
- Declare variables in the strictest scope as possible.
- Reorder functions so that you do not need prototypes for static
functions so that when you change them you need to change them only in
one place.
- Self documentation and code comments: use code comments parsimoniously. Code
should be written so that it is clear and evident without the need of
comments. Besides, comments usually get outdated when the code is changed
and they become misleading. In particular avoid stating the obvious e.g. "a
= 1; /* assign 1 to a */". Use good function names and variables to make the
code self-documented.
A good function name is one that explain clearly all what its code really
does. There shouldn't be hidden features. If you can not find easily a good
function name, you should probably split the function in smaller pieces. A
function should do only one thing, but do it well.
Please avoid lots of one-letter variables. And a variable should be used for
only one purpose.
Self-documentation is obviously not always possible, so when a comment is
needed, it is needed. In those cases make sure to explain why and not only
how a specific thing is done: you can deduce the "how" from the code, but
not the "why". Public library functions should always be documented and in
particular should include the calling conventions, e.g. if the result should
be freed by the caller.
Do not use fancy frames around comments like a line full of
/*---------------*/ etc.
- Contribute below on the stack. Fix a problem at the right place, instead of
writing hacks to work around a bug or a lack of feature in an underlying
See also
The gedit team.
Installation Instructions
Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
2006, 2007 Free Software Foundation, Inc.
This file is free documentation; the Free Software Foundation gives
unlimited permission to copy, distribute and modify it.
Basic Installation
Briefly, the shell commands `./configure; make; make install' should
configure, build, and install this package. The following
more-detailed instructions are generic; see the `README' file for
instructions specific to this package.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, and a
file `config.log' containing compiler output (useful mainly for
debugging `configure').
It can also use an optional file (typically called `config.cache'
and enabled with `--cache-file=config.cache' or simply `-C') that saves
the results of its tests to speed up reconfiguring. Caching is
disabled by default to prevent problems with accidental use of stale
cache files.
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If you are using the cache, and at
some point `config.cache' contains results you don't want to keep, you
may remove or edit it.
The file `configure.ac' (or `configure.in') is used to create
`configure' by a program called `autoconf'. You need `configure.ac' if
you want to change it or regenerate `configure' using a newer version
of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system.
Running `configure' might take a while. While running, it prints
some messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
6. Often, you can also type `make uninstall' to remove the installed
files again.
Compilers and Options
Some systems require unusual options for compilation or linking that the
`configure' script does not know about. Run `./configure --help' for
details on some of the pertinent environment variables.
You can give `configure' initial values for configuration parameters
by setting variables in the command line or in the environment. Here
is an example:
./configure CC=c99 CFLAGS=-g LIBS=-lposix
*Note Defining Variables::, for more details.
Compiling For Multiple Architectures
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you can use GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
With a non-GNU `make', it is safer to compile the package for one
architecture at a time in the source code directory. After you have
installed the package for one architecture, use `make distclean' before
reconfiguring for another architecture.
Installation Names
By default, `make install' installs the package's commands under
`/usr/local/bin', include files under `/usr/local/include', etc. You
can specify an installation prefix other than `/usr/local' by giving
`configure' the option `--prefix=PREFIX'.
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
pass the option `--exec-prefix=PREFIX' to `configure', the package uses
PREFIX as the prefix for installing programs and libraries.
Documentation and other data files still use the regular prefix.
In addition, if you use an unusual directory layout you can give
options like `--bindir=DIR' to specify different values for particular
kinds of files. Run `configure --help' for a list of the directories
you can set and what kinds of files go in them.
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
Optional Features
Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.
For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.
Specifying the System Type
There may be some features `configure' cannot figure out automatically,
but needs to determine by the type of machine the package will run on.
Usually, assuming the package is built to be run on the _same_
architectures, `configure' can figure that out, but if it prints a
message saying it cannot guess the machine type, give it the
`--build=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name which has the form:
where SYSTEM can have one of these forms:
See the file `config.sub' for the possible values of each field. If
`config.sub' isn't included in this package, then this package doesn't
need to know the machine type.
If you are _building_ compiler tools for cross-compiling, you should
use the option `--target=TYPE' to select the type of system they will
produce code for.
If you want to _use_ a cross compiler, that generates code for a
platform different from the build platform, you should specify the
"host" platform (i.e., that on which the generated programs will
eventually be run) with `--host=TYPE'.
Sharing Defaults
If you want to set default values for `configure' scripts to share, you
can create a site shell script called `config.site' that gives default
values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.
Defining Variables
Variables not defined in a site shell script can be set in the
environment passed to `configure'. However, some packages may run
configure again during the build, and the customized values of these
variables may be lost. In order to avoid this problem, you should set
them in the `configure' command line, using `VAR=value'. For example:
./configure CC=/usr/local2/bin/gcc
causes the specified `gcc' to be used as the C compiler (unless it is
overridden in the site shell script).
Unfortunately, this technique does not work for `CONFIG_SHELL' due to
an Autoconf bug. Until the bug is fixed you can use this workaround:
CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
`configure' Invocation
`configure' recognizes the following options to control how it operates.
Print a summary of the options to `configure', and exit.
Print the version of Autoconf used to generate the `configure'
script, and exit.
Enable the cache: use and save the results of the tests in FILE,
traditionally `config.cache'. FILE defaults to `/dev/null' to
disable caching.
Alias for `--cache-file=config.cache'.
Do not print messages saying which checks are being made. To
suppress all normal output, redirect it to `/dev/null' (any error
messages will still be shown).
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
`configure' also accepts some other, not widely useful, options. Run
`configure --help' for more details.
......@@ -2,10 +2,6 @@ Paolo Borelli
E-mail: pborelli@gnome.org
Userid: pborelli
Paolo Maggi
E-mail: paolo@gnome.org
Userid: paolo
Jesse van den Kieboom
E-mail: jessevdk@gnome.org
Userid: jessevdk
## Process this file with automake to produce Makefile.in
SUBDIRS = gedit pixmaps po plugins data docs tests win32 osx
if !OS_OSX
SUBDIRS += help
distuninstallcheck_listfiles = find . -type f -print | grep -v scrollkeeper
ChangeLog-20011116 \
ChangeLog-20051212 \
ChangeLog-20090418 \
gedit.doap \
xmldocs.make \
omf.make \
gnome-doc-utils.make \
intltool-extract.in \
intltool-merge.in \
gnome-doc-utils.make \
intltool-extract \
intltool-merge \
aclocal.m4 \
config.guess \
config.h.in \
config.sub \
depcomp \
gtk-doc.make \
install-sh \
ltmain.sh \
missing \
mkinstalldirs \
omf.make \
py-compile \
xmldocs.make \
m4/gnome-doc-utils.m4 \
m4/gtk-doc.m4 \
m4/intltool.m4 \
m4/libtool.m4 \
m4/ltoptions.m4 \
m4/ltsugar.m4 \
m4/ltversion.m4 \
m4/lt~obsolete.m4 \
`find "$(srcdir)" -type f -name Makefile.in -print`
DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper --enable-gtk-doc
@if test -d "$(srcdir)/.git"; \
then \
echo Creating ChangeLog && \
(GIT_DIR=$(top_srcdir)/.git \
./missing --run git log $(CHANGELOG_START)^^.. --stat -M -C --name-status --date=short --no-color) | \
fmt --split-only > ChangeLog.tmp \
&& mv -f ChangeLog.tmp $(top_distdir)/ChangeLog \
|| ( rm -f ChangeLog.tmp ; \
echo Failed to generate ChangeLog >&2 ); \
else \
echo A git clone is required to generate a ChangeLog >&2; \
-include $(top_srcdir)/git.mk
This diff is collapsed.
General Information
This is version 3.2.2 of gedit. gedit is a small and lightweight UTF-8 text
editor for the GNOME environment.
gedit is part of GNOME and uses the latest GTK+ and GNOME libraries.
Complete GNOME integration is featured, with support for Drag and Drop (DnD)
from Nautilus (the GNOME file manager), the use of the GNOME help system,
the GNOME Virtual File System and the GNOME print framework.
gedit uses a Multiple Document Interface (MDI), which lets you edit more than
one document at the same time.
gedit supports most standard editing features, plus several not found in your
average text editor (plugins being the most notable of these).