Next: GPS Themes, Up: Customizing and Extending GPS [Index]
This dialog, available through the menu Edit->Preferences
, allows you to
modify the global preferences of GPS.
To enable the new preferences, you simply need to confirm by pressing
the OK
button. To test your changes, you can use the Apply
button. Pressing the Cancel
button will undo all your changes.
Each preference is composed of a label displaying the name of the preference, and an editing area to modify its value. If you leave to mouse over the label, a tool tip will be displayed giving an on-line help on the preference.
The preferences dialog is composed of several areas, accessible through the tabs at the left of the dialog. Each page corresponds to a set of preferences.
This page allows you to quickly change the current settings for GPS, including preferences, key bindings, menus…; See GPS Themes for more information on themes. It is only displayed when there are themes registered.
The default font used in GPS. The background color you select for this preference will set the background color for all consoles and most views (the ones that display their data as trees, mostly). To change the background color of editors, see the preference Edit/Fonts&Colors/Default.
The fixed (monospace) font used in views like the outline view, the bookmark view, …; As much as possible, this font should use a fixed width for characters, for a better rendering
Name of character set to use when reading or writting text files. GPS uses UTF-8 and Unicode internally, which can handle any character in any language. However, your system will generally not support Unicode natively, and thus the contents of the files should be translated from the file system encoding to unicode.
This preference indicates the file system encoding in use. It defaults to ISO-8859-1, which corresponds to western european characters.
Whether a splash screen should be displayed when starting GPS.
Whether GPS should display the welcome window for the selection of the project to use.
Whether the tool bar should show both text and icons, or only icons.
Whether unsaved files and projects should be saved automatically before calling external tools (e.g. before a build).
Whether the desktop (size and positions of all windows) should be saved when exiting. If you are working with a project created automatically by GPS, the desktop will not be saved.
Determines when source editors should be saved in the desktop: Never
,
Always
, or when a source file is associated with the current project
(From_Project
).
The multi-language builder to be used in case a multi-language or non Ada project has been loaded.
By default, gprbuild
will be used. Alternatively, its prototype
gprmake
can be selected to help the transition, although we do not
recommend it at this stage.
Finally, if you want to force the use of gnatmake, even for projects
that contain other sources, you can use the gnatmake
setting. Note
that Gnatmake will only consider Ada files.
Whether the first entry of the location window should be selected automatically, and thus whether the corresponding editor should be immediately open.
Whether using the Next Tag
and Previous Tag
actions/menus
should wrap around to the beginning when reaching the end of the category.
The default is to wrap around, as was done in previous GPS versions.
Whether the Locations view should be closed automatically when it becomes empty.
Whether to display hyper links in the editors when the Control key is pressed. See Navigating with hyperlinks.
This controls the size of the list where all the entries copied into the
clipboard through Edit->Copy
and Edit->Cut
are saved. This list
is navigated through the menu Edit->Paste
and
Edit->Paste Previous
, as described earlier in this guide.
How the tool bar should be displayed: not at all, with small icons or with large icons
Whether the status bar at the bottom of the GPS window should be displayed. This status bar contains one or more progress bars while GPS is executing long actions like a build or a search. These progress bars can be used to monitor the progress of those actions.
If you wish to save vertical screen space, you can hide this status
bar. The progress bars will no longer be visible. Instead, you can
display the Task Manager through the Tools->Views->Tasks
menu,
to get similar information. This manager can then be put on the right
or left side of the GPS window, for instance just below the Project
View.
Prefered way to fix code when parts have to be removed.
Always_Remove
means that the code will be removed by GPS.
Always_Comment
means that the code will always be commented out.
Propose_Both_Choices
will propose a menu with both choices.
Whether GPS will display a Tip of the Day dialog at start up.
This section specifies preferences that apply to the Multiple Document Interface described in Multiple Document Interface.
If True, items will be resized or moved opaquely when not maximized.
If False, closing the window associated with a floating item will put the item back in the main GPS window, but will not destroy it. If True, the item is destroyed.
If True, then all the windows will be floating by default, i.e. be under the control of your system (Windows) or your window manager (Unix machines). This replaces the MDI.
If True, all floating windows will have a short title. In particular, base file names will be used for editors instead of full names.
Color to use for the background of the MDI.
Color to use for the title bar of unselected items.
Color to use for the title bar of selected items.
If Always, each window in GPS will have its own title bars, showing some particular information (like the name of the file edited for editors), and some buttons to iconify, maximize or close the window. This title bar is highlighted when the window is the one currently selected.
If Never, the title bar is not displayed, to save space on the screen. The tabs of the notebooks will then be highlighted.
If Central Only, then only the windows in the central area (ie the part that gets preserved when switching perspective, mostly editors) will have a title bar. All other windows will not show the title bar. This is often a good way to save space on the screen: the title bar is useful for editors since it gives the full name of the file as well as provide an easy handle for drag and drop operations, whereas the other views do not change position as much and it is better to save space on the screen by not displaying their title.
Indicates when the notebook tabs should be displayed. If set to "Never", you will have to select the window in the Window menu, or through the keyboard. If set to "Automatic", then the tabs will be shown when two or more windows are stacked.
Indicates where the notebook tabs should be displayed by default. It is possible to select the position of tabs individually for each notebook by right-clicking in any of their tabs and chosing a new position in the contextual menu. This position will be saved as part of the desktop and restored the next time you restart GPS. However, if you change the value of this preference, all notebooks will reset the position of their tabs to match the new value of the preference.
Whether the editor should remove trailing blanks when saving a file.
Choose between Unix, Windows and Unchanged line terminators when saving files. Choosing Unchanged will use the original line terminator when saving the file; Unix will use LF line terminators; Windows will use CRLF line terminators.
Whether the line numbers should be displayed in file editors.
Whether the subprogram name should be displayed in the editor’s status bar.
Whether tool tips should be displayed automatically.
Time (in milliseconds) before displaying tooltips.
Determine whether the delimiter matching the character following the
cursor should be highlighted. The list of delimiters includes: {}[]()
The period (in seconds) after which an editor is automatically saved, 0 if none.
Each modified file is saved under a file called .#filename#
, which is
removed on the next explicit save operation.
The right margin to highlight. 0 if none.
This value is also used to implement the Edit->Refill
command.
Whether the editor should highlight the current block. The current block depends on the programming language, and will include e.g. procedures, loops, if statements, …
Whether the editor should provide the ability to fold/unfold blocks.
When the Speed Column should be shown on the side of the editors:
Never
The Speed Column is never displayed.
Automatic
The Speed Column is shown whenever lines are highlighted in the editor, for example to show the current execution point, or lines containing compilation errors, …; It disappears when no lines are highlighted.
Always
The Speed Column is always displayed.
This is a Windows specific preference which is disabled by default. When enabled GPS will use the ACL to change the file’s write permission. Note that ACL can’t be used on network drives.
The default external editor to use.
Specify the command line for launching a custom editor. It is assumed that the command will create a new window/terminal as needed. If the editor itself does not provide this capability (such as vi or pico under Unix systems), you can use an external terminal command, e.g:
xterm -geo 80x50 -exe vi +%l %f
The following substitutions are provided:
%l
line to display
%c
column to display
%f
full pathname of file to edit
%e
extended lisp inline command
%p
top level project file name
%%
percent sign (’%’)
True if all editions should be done with the external editor. This will deactivate completely the internal editor. False if the external editor needs to be explicitly called by the user.
When enabled, GPS loads on startup all the information needed for the Smart completion to work.
The timeout, expressed in milliseconds, after which the Smart completion window appears automatically after entering a triggering character, such as ’.’
The default font, default foreground and default background colors used in the source editor.
Font variant and colors used to highlight blocks (subprograms, task, entries, ...) in declarations.
Font variant and colors used to highlight types in declarations.
Font variant and colors used to highlight keywords.
Font variant and colors used to highlight comments. Setting the color to white will set a transparent color.
Font variant and colors used to highlight annotated comments.
Only relevant to Ada currently. Annotated comments are comments immediately
followed by a special character, e.g. #[]
.
Setting the color to white will set a transparent color.
Font variant and colors used to highlight strings. Setting the color to white will set a transparent color.
Color for highlighting the current line. Leave it to blank for no highlighting. Setting the color to white will set a transparent color.
Whether to use a thin line rather than full background highlighting on the current line.
Color for highlighting the current source block.
Color for highlighting delimiters.
Color for highlighting the search results in the text of source editors.
Color used for the cursor in editors and interactive consoles
Defines the size of the cursor, relatively to characters. 100 means the cursor will occupy the same size as a character, 10 means it will only occupy 10% of the size occupies by a character.
How the editor should indent Ada sources. None means no indentation; Simple means that indentation from the previous line is used for the next line; Extended means that a language specific parser is used for indenting sources.
Whether the editor should use tabulations when indenting.
Note that this preference does not modify the Tab key which will still
insert Tab characters. Consider also the /Edit/Insert Tab With Spaces
key
shortcut which can be mapped (to e.g. Tab) via The Key Manager Dialog. Finally, another alternative is to reconfigure the default key
binding for the automatic indentation action: by default, it is mapped to
Ctrl-Tab
and can be changed to Tab by modifying the /Edit/Format Selection
action from The Key Manager Dialog.
The number of spaces for the default Ada indentation.
The number of extra spaces for continuation lines.
The number of extra spaces for multiple line declarations. For example, using a value of 4, here is how the following code would be indented:
variable1, variable2, variable3 : Integer;
The number of extra spaces used to indent multiple lines conditionals within parentheses.
For example, when this preference is set to 1 (the default), continuation lines are indented based on the previous parenthesis plus one space:
if (Condition1 and then Condition2) then
When this preference is set to 3, this gives:
if (Condition1 and then Condition2) then
The number of extra spaces for record definitions, when the record
keyword is on its own line.
For example, when this preference is set to 3 (the default), the following sample will be indented as:
type T is record F : Integer; end record;
When this preference is set to 1, this gives:
type T is record F : Integer; end record;
Whether GPS should indent case statements with an extra level, as used in the Ada Reference Manual, e.g:
case Value is when others => null; end case;
If this preference is set to Non_Rm_Style
, this would be indented as:
case Value is when others => null; end case;
By default (Automatic
), GPS will choose to indent with an extra
level or not based on the first when
construct: if the first
when
is indented by an extra level, the whole case statement will
be indented following the RM style.
The way the editor will handle the case settings below.
Disabled
no auto-casing will be done;
End_Of_Line
auto-casing will be done when hitting Enter key;
End_Of_Word
auto-casing will be done word-by-word while typing;
On_The_Fly
auto-casing will be done character-by-character while typing.
For the End_Of_Line
, End_Of_Word
and On_The_Fly
policies
it is always possible to force the casing of the current line by pressing the
indentation key (Ctrl-Tab by default).
It is also possible to disable the casing for a single character
(action No Casing/indentation on Next Key
, default Ctrl-Q) or
temporarily (action Toggle Auto Casing/indentation
,
default Alt-Q).
How the editor should handle reserved words casing.
Unchanged
will keep the casing as-is;
Upper
will change the casing of all reserved words to upper case;
Lower
will change the casing to lower case;
Mixed
will change the casing to mixed case (all characters to
lower case except first character and characters after an underscore
which are set to upper case);
Smart_Mixed
As above but do not force upper case characters to
lower case.
How the editor should handle identifiers casing. The values are the same as for the Reserved word casing preference.
Whether the editor should add extra spaces around operators and delimiters
if needed.
If enabled, an extra space will be added when needed in the following cases:
before an opening parenthesis;
after a closing parenthesis, comma, semicolon;
around all Ada operators (e.g. <=
, :=
, =>
, …)
Whether the editor should automatically align colons in declarations and parameter lists. Note that the alignment is computed by taking into account the current buffer up to the current line (or end of the current selection), so if declarations continue after the current line, you can select the declarations lines and hit the reformat key.
Whether the editor should automatically align arrows in associations (e.g. aggregates or function calls). See also previous preference.
Whether the editor should align continuation lines in variable declarations based on the colon character.
Consider the following code:
Variable : constant String := "a string";
If this preference is enabled, it will be indented as follows:
Variable : constant String := "a string";
Whether to indent lines containing only comments and blanks, or to keep these lines unchanged.
Whether to align comment lines following record
and
is
keywords immediately with no extra space.
When enabled, the following code will be indented as:
package P is -- Comment [...] end P;
When disabled, the indentation will be:
package P is -- Comment [...] end P;
How the editor should indent C/C++ sources. None means no indentation; Simple means that indentation from the previous line is used for the next line; Extended means that a language specific parser is used for indenting sources.
Whether the editor should use tabulations when indenting. If True, the editor will replace each occurrence of eight characters by a tabulation character.
The number of spaces for the default indentation.
Whether to indent lines containing only comments and blanks, or to keep these lines unchanged.
If this preference is enabled, the debugger will automatically save breakpoints when it exists, and restore them the next time the same executable is debugged. This is a convenient way to work on an executable, where the typical usage looks like compile, debug, compile, debug, …
When the preference is enabled, the debugger will also preserve the contents of the data window whenever it is closed. Reopening the window either during the same debugger session, or automatically when a new debugger is started on the same executable, will recreate the same boxes within the data window.
This preference controls what happens to debugger-related windows, like the call stack, the data window, the tasks view,..., when the debugger is terminated. There are three possible behavior:
In this case, all these windows are closed. This saves memory and space on the screen, but you will need to explicitly reopen them and put them in the right location on the desktop the next time you start a debugger session.
In this case, the windows are cleared, but kept on the desktop. When you start a new debugger session, the windows will be automatically reused. This ensures that you won’t have to reopen and reposition them, but takes space on your screen
The windows are cleared, and hidden. When you start a new debugger session, they are automatically made visible again and reused. This also ensures you will not have to reopen and reposition them, but requires a bit of memory. If you move some windows around while these windows are hidden, they might reappear in unexpected location the next time, although you then just have to move them.
Specifies whether a breakpoint on all exceptions should be set by default when loading a program. This setup is only taken into account when a new debugger is initialized, and will not modify a running debugger (use the breakpoint editor for running debuggers).
Specifies whether the debugger should create a separate execution window for the program being debugged.
Note that this preference cannot be taken into account for the current debug session: you need to terminate the current debug session and restart a new one.
If true, a separate console will be created. Under Unix systems, this console is another window in the bottom part of the main window; under Windows, this is a separate window created by the underlying gdb, since Windows does not have the notion of separate terminals (aka ttys).
Note that in this mode under Windows, the Debug->Interrupt
menu
will only interrupt the debugged program with recent versions of gdb.
If you are using older versions of gdb, you need to hit
Ctrl-C in the separate execution window to interrupt it while it is
running. Note also that this separate execution window uses the default
system-wide console properties (the size of the window, the
colors...). It is possible to change those properties using e.g. the
default console menu (top-left of the console) on Windows XP.
If false, no execution window will be created. The debugger assumes that the program being debugged does not require input, or that if it does, input is handled outside GPS. For example, when you attach to a running process, this process already has a separate associated terminal.
Specifies whether the source editor should display blue dots for lines that contain code. If set to False, gray dots will be displayed instead on each line, allowing breakpoint on any line. Disabling this option provides a faster feedback, since GPS does not need to query the debugger about which lines contain code.
If enabled, do not create new items when an item with the same address is already present on the canvas.
Number of assembly lines to display in the initial display of the assembly window. If the size is 0, then the whole subprogram is displayed, but this can take a very long time on slow machines.
Color used to highlight the assembly code for the current line.
Color used for highlighting in the debugger console.
Indicates color to be used for the items that are click-able (e.g pointers).
Indicates color to be used to highlight fields in the data window that have changed since the last update.
Color used by default in the memory view window.
Color used for highlighted items in the memory view.
Color used for selected items in the memory view.
Indicates the font to be used for the name of the item in the data window.
Indicates font to be used to display the type of the item in the data window.
The maximum width an item can have.
The maximum height an item can have.
Command used to list processes running on the machine.
Program used to run a process on a remote machine. You can specify arguments,
e.g. rsh -l user
Program used to copy a file from a remote machine. You can specify arguments,
e.g. rcp -l user
Program used to execute commands externally.
Only used under Unix, not relevant under Windows where the default HTML browser is used. Program used to execute view HTML files, for instance the documentation. Empty by default, which means that GPS will try to find a suitable HTML browser automatically. Only change the value if GPS cannot find a HTML browser, or if the browser found is not your preferred one.
External program used to print files.
This program is required under Unix systems in order to print, and is set to
a2ps
by default.
If a2ps
is not installed on your system, you can download it
from ftp://ftp.enst.fr/pub/unix/a2ps/, although other printing programs
such as lp
can be specified instead.
Under Windows systems, this program is optional and is empty by default, since a built-in printing is provided. An external tool will be used if specified, such as the PrintFile freeware utility available from http://www.lerup.com/printfile/descr.html
Enable or disable the confirmation popup for the replace all action.
If this option is enabled, the search window will be closed when a match is found.
If this option is enabled, the focus will be given to the editor when a match is found.
If this option is enabled, the contents of the "Look in:" field will be preserved between consecutive searches in files.
Color to use to draw the selected item.
Color used to draw the background of the browsers.
Color used to draw the hyper links in the items.
Color to use for links between selected items.
Color used to draw the links between unselected items.
Color to use for the background of the items linked to the selected item.
Color to use for the background of the items linked from the selected item.
Whether the layout of the graph should be vertical (True) or horizontal (False). This setting applies to most browsers (call graph for instance), but does not apply to the entities browsers.
Whether a status action can be launched as part of another action. For example to get the revision numbers of new files after an update command. If the network connection with the repository is slow disabling this command can speed-up the VCS actions.
Whether the built-in ClearCase (see Version Control System) module is activated or disabled.
The default VCS to use when the project does not define a VCS.
Note that in order to perform visual comparison between files, GPS
needs to call external tool (not distributed with GPS) such as diff
or patch
. These tools are usually found on most unix systems, and
may not be available by default on other OSes. Under Windows, you can
download them from one of the unix toolsets
available, such as msys (http://www.mingw.org) or
cygwin (http://www.cygwin.com).
How GPS displays visual diffs between two files:
Editors are displayed side-by-side; new editors are created as needed
No new editor is created, and changes are displayed directly in the reference editor.
Command used to compute differences between two files.
Arguments can also be specified. The visual diff expects a standard diff
output with no context (that is, no -c
nor -u
switch).
Arguments of interest may include (this will depend on the version of diff
used):
Ignore changes in amount of white space.
Ignore changes that just insert or delete blank lines.
Ignore changes in case; consider upper and lower case letters equivalent.
Ignore white space when comparing lines.
Command used to apply a patch. Arguments can also be specified. This command is used internally by GPS to perform the visual comparison on versioned files (e.g. when performing a comparison with a version control system).
This command should be compatible with the GNU patch
utility.
Use the old version of the visual comparison.
This item is only displayed if the preference Use old diff is disabled. Command used to query a 3-way diff. See Diff command for a description of the parameters.
This item is only displayed if the preference Use old diff is disabled. The color used to indicate lines on which there is a difference, in the "reference" editor.
This item is only displayed if the preference Use old diff is disabled. The color used to indicate spaces used by lines not present in one of the editors in a 3-way diff and present in the other editors.
This item is only displayed if the preference Use old diff is disabled. The color used to display the lines that are present in an editor but not in the reference editor.
This item is only displayed if the preference Use old diff is disabled. The color used to display the lines that are present in the reference editor but not in other editors.
This item is only displayed if the preference Use old diff is disabled. The color used to display the lines that have changed between the reference editor and the other editors.
This item is only displayed if the preference Use old diff is disabled. The color used to highlight fine differences within a modified line.
This item is only displayed if the preference Use old diff is enabled. The number of lines displayed before and after each chunk of differences. Specifying -1 will display the whole file.
Color used to highlight text in the messages window.
Color used to highlight lines causing compilation errors/warnings in the source editors. When this color is set to white, the errors/warnings are not highlighted. (Compilation/Build)
Pattern used to detect file locations and the type of the output from the messages window. This is particularly useful when using an external tool such as a compiler or a search tool, so that GPS will highlight and allow navigation through source locations. This is a standard system V regular expression containing from two to five parenthesized subexpressions corresponding to the file, line, column, warnings or style error patterns.
Index of filename in the file pattern.
Index of the line number in the file pattern.
Index of the column number in the file pattern.
Index of the warning identifier in the file pattern.
Index of the style error identifier in the file pattern.
Whether paths should be absolute or relative when the projects are modified.
If the project respects a number of restrictions, activating the preference will provide major speed up when GPS parses the project. This is especially noticeable if the source files are on a network drive.
GPS assumes that the following restricitions are true when the preference is activated. If this isn’t the case, no error is reported, and only minor drawacks will be visible in GPS (no detection that two files are the same if one of them is a symbolic link for instance, although GPS will still warn you if you are trying to overwrite a file modified on the disk).
The restrictions are the following:
Whether the Xref information should be automatically loaded into memory when a new project is loaded. See Support for Cross-References.
A regular expression used to match hidden directories. Such directories are not displayed by default in the project view, and are not taken into account for VCS operations working on directories.
You can choose a specific font for the outline view. Typically, this will be used to use a slightly smaller font than in the editor, so that you can see more entities at once on the screen.
For some of the languages, in particular Ada, GPS can display the profile (list of parameters) for the subprograms. This can be used to differentiate between overloaded entities (ie entities with the same name). Disabling this preference will only show the entity name.
If this preference is activated, the entities will be sorted alphabetically in the outline view. If disabled, they will be displayed in the order they are found in the source file.
If this option is set, the current subprogram will be selected in the outline view every time the cursor position changes in the current editor. This option requires some computation for GPS, and you might want to avoid the slow down by disabling it.
If this option is set, the outline view will show the name of the file on its first line, and indent slightly all following lines. If this option is unset, this will save some screen real estate, but you will have to look at the current editor to see what file is descrived in the Outline View.
This section specifies preferences that apply to the Documentation Generator. Documentation Generation for more information.
If this preference is enabled, implementation files will be processed. Otherwise, only the specification files will.
By default, no documentation is generated for private entities. Enabling this preference will change this behavior.
If enabled, the documentation tool will compute and take advantage of source references to e.g generate call graph information. Activating this option will slow down the documentation generation process.
If enabled, only files having up-to-date cross references information will be documented.
A regular expression used to filter to comments found in the source code before using them for generating documentation. For example "^!.*" will remove all comments starting with ’!’.
If enabled, a browser is spawned after each documentation generation to view the generated files. This browser is not spawned if disabled.
If enabled, GPS will try to find references to entities in comments, and generate links to them when generating the documentation.
Select which coverage toolchain (gcov
or xcov
) to use from
the Tools->Coverage
menu.
Next: GPS Themes, Up: Customizing and Extending GPS [Index]