Xcode editing panes are homogeneous. The features, functions, and capabilities are identical regardless of where they appear. This imparts one extremely useful feature: No matter where a source file appears in Xcode, you have the full power of the Xcode editor at your disposal.

The text of a file that appears in a search window, the debugger, or the object browser can all be edited immediately without any need to locate the file or open another window. The same file can appear in multiple editing panes at once. Changes made to one are reflected in all.

The Project Window's Editor Pane

The editor pane of the project window is no exception, but the behavior is a little more complex. When you're using the Default and All-In-One Xcode styles, the project source list shares a window with the details list and an editor pane. Figure 6-2 shows all three panes visible at once.

Figure 6-2. FIGURE 6-2

Selecting a single file in either the Groups & Files list or the details list immediately brings the contents of that file into the editor pane — that is, if the editor pane is visible. As you saw in Chapter 3, the details list and the editor pane share the same area in the project window. You can adjust the division between the two by using the divider bar, the View

Note

The Editor toolbar button is shown in Figure 6-2, but is not part of the default project window toolbar. Choose View

All three configurations of the details list and editor pane are shown in Figure 6-3. On the left, only the details list is visible. On the right, only the editor pane is visible. In the center, both share the same area. The divider between them can be dragged to the top to fill the area with the editor pane, to the bottom to hide it, or anywhere in between. Double-clicking the divider alternately collapses the editor pane so it is completely hidden, or restores it to its previous location — which could be at the top, completely hiding the details list.

Figure 6-3. FIGURE 6-3

The View

Holding down the Option key turns the command into Zoom Editor In/Out Fully. When used in a multi-pane window like the project window, Zoom Editor In Fully collapses all other panes. This would be equivalent to expanding the editor, and then collapsing the Groups & Files list so only the editor pane is visible. Zoom Editor Out Fully runs the editor pane back down and re-expands the Groups & Files list. Using the All-In-One window style, this is a quick way of pushing everything else aside in order to see the code, and may be more convenient than opening the file in a separate window.

Normally, the division between the details list and the editor pane stays put until you change it. When the editor pane is collapsed, this requires two commands to edit the contents of a file. You must first select the file in a list, and then resize the divider or use the Zoom Editor In command before the editor pane is visible. If you find yourself doing this often, enable the Automatically Open/Close Attached Editor option in the General pane of the Xcode Preferences. Checking this option causes the editor pane to expand automatically whenever a single source file is selected in the Groups & Files or details list.

Using a Group Editor Window

Xcode, like most document-based applications, creates a new window for every file you open in a separate window. If that statement sounds ridiculously obvious, bear with me. It can, however, restrict all files to a single separate editing window. This mode is accessible only through the toolbar Grouped/Ungrouped control, shown in Figure 6-4.

Figure 6-4. FIGURE 6-4

If the control shows as Ungrouped, opening a new file in a separate editor creates a new window. There is no practical limit on the number of separate editor windows you can have open at a time. Clicking the button toggles the mode and establishes that window as the "group" editing window. In this mode, opening a file simply changes the file being displayed in the active pane of the group editor window; no new windows are created. This mode can be used to avoid window clutter. The setting of this mode does not affect any other windows that have already been created, and only one window can be designated as the group editor window at a time.

Opening Files from the Filesystem

Xcode also lets you open files in the traditional manner by picking a file in the filesystem. It will also respond to open document requests from the Finder or any other application. Xcode understands the formats of many file types that it doesn't "own." You can cause Xcode to open a file that would normally launch another application by dropping the file into Xcode's icon in the dock, as shown in Figure 6-5.

Figure 6-5. FIGURE 6-5

Opening an editable file using the traditional File

Open Quickly by Filename or Symbol

An extremely useful command for finding and opening a file is the File

Figure 6-6. FIGURE 6-6

Note

If you have text selected in the editor when you invoke the Open Quickly command, it's used as the default search. This makes it really easy to open a header file (select the #include filename, then press Command+Shift+D) or find the file that defines almost any symbol.

Close any window using the File

TIP TO REMEMBER

Hold down the Option key and click the close button of an independent editor window, or choose File

Because Xcode enables you to edit a source file in multiple windows simultaneously, there isn't a one-to-one correspondence between a window and a file. Unless you use the Close File "filename" command, closing a window does not necessarily force you to save the changes made to that file. Even closing all of the visible panes where a file was being edited might not force the changes to be written. The changes are held in memory until committed in response to another command. Files that have been modified but not yet saved appear grey in the project window. In Figure 6-7, the PromiseListViewController.h, PromiseListViewController.m, and DueDatePicker.h files have been edited but not saved.

Figure 6-7. FIGURE 6-7

The File

Figure 6-8. FIGURE 6-8

Some actions cause the Save All window to appear automatically. Closing a project forces you to save or abandon the changes made in all unsaved project files. You can configure the Build commands in the Xcode Preferences to automatically save all unsaved files or prompt you for which ones to save before building.

The scrollbar controls are standard and shouldn't surprise anyone who has used a modern graphical user interface. Xcode enhances their basic behavior with a few extras.

Holding down the Option key when you click the arrow buttons scrolls the window slightly less than one screen's worth of text.

The editor is scroll-wheel aware, although a scroll-wheel is not an Xcode-specific feature. If your mouse, trackball, or trackpad has a scroll-wheel, the active editor pane will respond to it. I personally consider a multi-button trackball with a scroll-wheel an indispensable development tool.

The gutter, described in more detail later, indicates compiler errors and warnings for the text that is visible in the window. Warnings and errors above or below the visible text are indicated as thin black (warning) or red (error) lines in the vertical scrollbar, as shown in Figure 6-9. This allows you to scroll quickly through the window to reveal other warnings or errors in the file. In your System Preferences, the Appearance pane has a Jump to the Spot That's Clicked option. If selected, clicking in the empty part of the scrollbar jumps immediately to that point in the file. Though this is a system-wide preference change, it makes jumping to relative locations in source files particularly convenient.

Above the scrollbar is the split pane button. Clicking it splits that editor pane into two independent panes, one above the other, separated by a divider bar, as shown in Figure 6-10.

Figure 6-10. FIGURE 6-10

You can achieve the same effect using the View

Holding down the Option key splits the pane horizontally, as shown in Figure 6-11. Choosing to split a pane horizontally or vertically only works for the first pane. After a pane is split horizontally, all subsequent splits are horizontal regardless of whether you select a horizontal or vertical split. The same is true for vertical splits. (This is considered a bug by the Xcode development team and may be fixed in a future version.)

Figure 6-11. FIGURE 6-11

Unlike the pane divider between the editor pane and the details list, the divider between editing panes does not respond to a double-click. However, it is possible to drag the divider all the way to one edge if you want to hide a pane from view. Drag it back out to the middle again, or close the visible pane, to reveal the hidden pane.

The panes that result from a split are truly independent editing environments. The "Jumping to Other Files" section explains how to switch from one file to another in the same pane. You can do this with split panes, which allows you to edit two or more different files in a single editor window — very handy for editing a code file and its header in the same window. Notice back in Figure 6-11 that the right pane is displaying the MakePromiseViewController.m file and the left pane is editing its companion .h file.

The gutter is the shaded bar running down the left edge of the editor pane. If it is not visible, enable it by selecting Show Gutter in the Text Editing pane of the Xcode Preferences. The gutter, shown in Figure 6-12, can display a variety of annotations.

Figure 6-12. FIGURE 6-12

The gutter displays errors or warnings for a particular line, breakpoints, the current execution location of the debugger, and (optionally) line numbers. The display of line numbers is set in the Xcode Preferences. Warnings and errors are indicated by the yellow caution and red stop-sign symbols. Breakpoints show up as wide blue tabs. Active breakpoints are dark blue. Inactive ones are light grey. A large red arrow indicates where program execution is currently paused in the debugger.

Clicking an error or warning icon in the gutter toggles its description in the text, enabling you to hide error descriptions selectively — which can be a bit distracting if you're trying to fix the problem.

Clicking a breakpoint alternately enables or disables the breakpoint. You can set new breakpoints by clicking anywhere in the background of the gutter. Breakpoints can only be set in file types that Xcode recognizes as program source (C, C++, Objective-C, Java, AppleScript, and so on). You cannot set a breakpoint in XML or other types of non-program text files. You can relocate breakpoints to another line by dragging them there, or delete them by dragging them out of the gutter. Right/Control+click a breakpoint, or in the gutter, to add, remove, edit, or review breakpoints. Double-clicking a breakpoint opens the Breakpoints window. See Chapter 18 for more about breakpoints.

The navigation bar, shown in Figure 6-13, occupies the top edge of the editor pane and contains several status and navigation controls. You can hide the navigation bar of the active editor pane with the View

Figure 6-13. FIGURE 6-13

The following table lists the functions of the navigation bar controls.

The Lock button toggles the lock (read-only) attribute of the file. If you lock a file, or the file was locked when it was opened, the editor will be in display-only mode. If you attempt to change the document, Xcode warns you that you cannot edit the file. You can override this mode in the dialog box and make changes to the document, but that does not change the permissions of the file and you will not be able to save changes until the file is made writable. Unlocking a file automatically switches the editor to its normal editing mode. See the option Save Files As Writable in the "Display Options" section of this chapter.

All of the other navigation controls are explained in the "Navigating Within a File" section, later in this chapter.

The View

Control characters and the space character are normally invisible. Two more commands in the View

The font and size of the text used for all editor panes are set in the Fonts & Colors tab of the Xcode Preferences. These settings are described in the "Syntax Coloring" section of Chapter 7.

Several global settings control the appearance of editor panes for all windows. These are in the Text Editing tab of the Xcode Preferences, as shown in Figure 6-14.

Figure 6-14. FIGURE 6-14

[self setDelegate:[[[MyDelegate alloc] init] autorelease]];

[[MyObject alloc] init] autorelease];

{ [ ( ' " ) ] }

Save Options

The Save Options are an eclectic set of options that deal with file permissions and line endings. The Save Files as Writable option causes Xcode to set the POSIX write permission of a file when it is saved. With this option off, Xcode preserves the POSIX write permissions the file had before it was saved. That is, if the file were read-only it will be left read-only. When opening a read-only file, Xcode puts the editor pane in display-only mode. Any attempt to change the file is met with a warning, as shown in Figure 6-15. This is mostly to prevent you from trying to edit read-only files that belong to frameworks.

Figure 6-15. FIGURE 6-15

Clicking the Allow Editing button puts the editor pane in its normal editing mode, but it does not change the permissions of the underlying file. In this state, Xcode refuses to save the file from the Save All window. However, you can save the file by using the File

Set the Save Files as Writable option and Xcode will not restore the read-only permissions after a save, leaving the file writable. After the save, the file will behave like any other writable file.

This behavior applies to the POSIX write permissions for the file. The other method of making a file unwritable is to set its POSIX immutable flag. (On an HFS filesystem, this flag is synonymous with the HFS locked attribute.) You can set or clear this flag by using the Lock button in the navigation bar, or in the Get Info window for the file in the Finder. The POSIX immutable flag is never overwritten by Xcode, making it a more secure method of preventing changes to a file than merely denying write permission. A locked file behaves the same as a file that lacks write privileges, except that File

Start with just moving around in a single source file. The following table lists the key combinations that simply move the cursor around in the text.

Memorize this table or earmark this page in the book. It will save you an immense amount of time navigating your source code. The most important thing to remember is that the amount of cursor movement increases depending on the modifier key used with the left or right arrow keys, as shown in Figure 6-16. These are, in increasing order or magnitude: none, Control, Option, and Command.

Figure 6-16. FIGURE 6-16

A word in Xcode is a run of letters, numbers, or the underscore character. A subword is a capital letter followed by a run of lowercase letters, a run of numbers, a run of uppercase letters, or a run of underscore characters between subwords. Leading and trailing underscore characters do not count as subwords.

You may have noticed a few odd synonyms for some of the cursor movements, like Control+P to move up one line, or Control+E to move to the end of the line. Xcode key bindings emulate a number of the standard Emacs editor commands. If you're used to using Emacs, you will want to explore the key bindings in the Xcode Preferences to see what Emacs control sequences are supported. This book doesn't go into all of the Emacs commands that are supported by Xcode, but the following table provides a couple of examples.

Emacs maintains the concept of a "mark," which is simply a saved location in the file, much like a bookmark. You can set the mark by pressing Control+spacebar. You can also "swap" the mark with the current cursor position or selection by pressing Control+X Control+X (that's Control+X twice in a row). The current cursor position or selection becomes the new mark, and the cursor position or selection is moved to the previous mark. This can be very handy when copying and pasting between two different sections of the same file.

Besides the scrollbar controls, key combinations also exist that scroll the text without changing the current cursor position or selection, as listed in the following table.

These can often result in scrolling the text so that the current cursor position is no longer visible. Every cursor movement includes an implied request to scroll the window so that the new cursor position is visible. To scroll the window so that the current cursor or selection is visible again, use the Edit

The navigation bar provides several tools for navigating to locations within the current file, as shown in Figure 6-13.

All of these controls are drop-down menus. Select an item in the menu and the cursor moves immediately to that location in the file. Keyboard shortcuts also exist for these menus, as listed in the following table. Using one of the shortcuts drops the menu down. You can then navigate the menu with the up and down arrows or by typing the first few letters of the desired item. Press Return when the desired item is highlighted. Press Esc to dismiss the menu.

The File History, Class Hierarchy, and Included Files menus are described a little later in the "Jumping to Other Files" section. The remaining menus navigate within the current file.

Functions

The Functions menu, shown in Figure 6-17, parses the definitions in the source file and dynamically builds a list of functions, classes, methods, types, defines, and markers. This is one of the syntax-aware editing features of Xcode and only works when you're editing file types that Xcode recognizes as being program source files.

Figure 6-17. FIGURE 6-17

The menu includes an item for each of the following that Xcode discovers in your source code:

• A class, method, or function (declaration or definition)

• A type (typedef) declaration

• #define directives

• #pragma mark directives

• Any comment that contains the (case-sensitive) text:

  • MARK:

  • TODO:

  • FIXME:

  • !!!:

  • ???:

Normally, the menu is in the order that the declarations appear in the file. Hold down the Option key when clicking the menu or using the keyboard shortcut to sort the items in alphabetical order. Method names in Java and Objective-C classes are sorted as though their names were fully qualified (for example, MyReader::isEOF), so all of the methods for a class cluster together in the list, subsorted by method name. You can choose to switch the default order by setting the Sort List Alphabetically option in the Code Sense pane of the Xcode Preferences. When this option is set, the list is sorted alphabetically by default and in file order when the Option key is used.

Declarations are italicized in the menu. Declarations can be excluded by turning off the Show Declarations option in the Code Sense pane of the Xcode Preferences.

The most flexible means of adding arbitrary entries to the Functions menu is to insert a #pragma mark directive to your source code, as shown in Figure 6-17. The statement #pragma mark - adds a menu divider.

Finally, the Functions menu acts as a location indicator. Whenever the cursor or selection is in a definition or the body of a class, function, or method, the menu indicates the name of the current location. When the menu is popped open, the current location is indicated with a check mark. If the cursor position is not within any definition, the message "<No Selected Symbol>" is displayed.

Bookmarks

The Bookmarks menu lists all of the bookmarks set in the file. It does not list bookmarks set in other files. Use the Bookmarks window or the Bookmarks smart group in the project window to see those. Bookmarks are always listed in the order they appear in the file.

To set a bookmark, position the cursor or make a selection and choose the Edit

Just as important as being able to move around quickly within a file is the ability to move quickly between files. You've already seen how to open and browse files from the project window, but Xcode provides a variety of other ways to switch directly from one file to another.

MOST PRODUCTIVE SHORTCUTS

Before I get into some of the more mundane ways of navigating between files, let me point out probably the two most useful shortcuts in Xcode:

SHORTCUT	COMMAND	EFFECT
Command+double-click	Edit	Quickly jumps to the source code where the symbol is defined.
Option+double-click	Help	Opens the symbol's documentation in a Quick Help window.

The double-click action selects the word or symbol at your cursor location, so these shortcuts perform two actions simultaneously: select the symbol and jump to its definition or documentation. These shortcuts are described in this and the help chapters, but they're so useful that I encourage you to take a moment to memorize them now.

File History

The File History menu in the navigation bar maintains a list of the files that have been displayed in that editor pane, as shown in Figure 6-18. Select a file from the list and the pane switches to that file. The keyboard shortcut for the File History menu is Control+1.

Figure 6-18. FIGURE 6-18

File history is maintained individually for each editor pane. Even multiple panes within the same window have their own history. For the editor pane in the project window, or when you're using the Grouped window mode, this can be quite a long list. For separate editor windows, it tends to be just the file that is being edited. All new panes have an empty history, and closing a pane discards the history for that pane. The only exception is when Xcode saves the state of a window in the project document. It always does this for the project window, and it saves the state of other open windows if the Save Window State option in the General preferences is set. Thus, the history of the project window's editor pane is always preserved and so is, possibly, the state of all open editor windows.

To limit (or not) how much file history is retained, the File History menu has two special items, as previously shown in Figure 6-18. The Clear File History item does just that. It forgets all previously visited files except the current one. The History Capacity item sets the limit for the number of files in the list. The capacity defaults to Unlimited. For most editor panes, this isn't an issue because they rarely get past two. For editor panes, like those in the project window that are constantly being reused, you may want to limit the size of the history, or the list may become unwieldy. Like the file history itself, this setting is stored separately for each editor pane and is saved in the window's state.

The two arrow buttons to the left of the File History menu move through the history list, like the previous and next buttons in a browser. The File History menu lists each file in alphabetical order, but the history buttons are really a browser-like history of the locations that have been visited, in the order that they were visited. Clicking the Previous button takes you to the location previously visited, not the file above the current one in the menu. It is unlike the File History menu in two other respects: it remembers your location within each file, not just files. This appears as a filename and line number, such as "main.c:27." A file and location may occur more than once. The history and the menu are both limited to the number of items set in the History Capacity menu.

Adding an Arbitrary File to the History

Xcode windowing options tend either to open all files in a single editor pane, or every file in a separate window. Consequently, the file history consists of every file you've ever visited or just the file opened in that window. There are some times when you'd like to work with a select number of files in a single, separate, editor window. You have three ways of accomplishing this.

The first method is to use the Group window, described in the "Using a Group Editor Window" section earlier. This directs all new files to the same window. Use the File History menu to switch between all of the files that have occupied that window.

The second method is to use the aggregate file history to switch to a file that has been visited in some other editor pane. Once the file is brought into the current window, it becomes part of its history. This is the simplest way of adopting a file that is, or has been, opened elsewhere.

The last method is to drag a file and drop it directly into the navigation bar, as shown in Figure 6-19. This switches the editor pane to that file and adds it to its history.

Figure 6-19. FIGURE 6-19

The source of the drag can be a source item in the project window, a file from the Finder, or the file icon in the title bar of a document window. This technique can only be used to add one file at a time.

Included Files

The Included Files menu is another syntax-aware feature for C and C-like language files. Each #include or #import directive that it finds is listed in the top portion of the menu, as shown in Figure 6-20. Selecting an item from the list jumps to that file. The keyboard shortcut is Control+6.

Figure 6-20. FIGURE 6-20

When used in a header file, the Included Files menu also lists the files that include this file at the bottom of the menu. In Figure 6-20, the current file, MyViewController.h, includes one header file, UIKit.h, and is included by two other files in the project, AppDelegate.m and MyViewController.m.

Switching Between a Header and its Source File

The convention for C, C++, and Objective-C languages is to place the declarations for functions and data types in a header file with an .h or .hpp filename extension, and write the implementation of those functions in a source file of the same name. If you use this convention, Xcode lets you quickly jump back and forth between the two using the View

Whether the counterpart file opens in a new editing window depends on your layout style and the setting of the Open Counterparts in Same Editor option in the General pane of the Xcode preferences.

Jumping to a Definition

As mentioned earlier in this section, one of the most useful navigation tools in Xcode is the Edit

Jump to Definition uses the syntax-aware symbols table to index all of the class, function, type, and constant names that are defined in your project. Command+double-clicking a word, or selecting a symbol name and choosing Edit

If there are multiple symbols with the same name, or if you choose a class name with multiple implementations, Xcode pops up a list of the possible matches, as shown in Figure 6-21. Select the desired symbol and the editor jumps there.

Figure 6-21. FIGURE 6-21

Code Sense indexing must be enabled for this feature to work. See the "Code Sense" section in Chapter 7.

All of the standard text selection gestures work in Xcode. Click and drag to select some text. Hold down the Shift key to extend a selection. Selecting text by dragging is dependent on timing; see the "Drag and Drop" section later for an explanation.

Selecting Columns

One of the more obscure features of the editor is the ability to select columns of text. You can select all of the characters between two column positions across multiple lines by holding down the Option key and dragging out a selection. Figure 6-22 shows a column selection. Hold down the Shift and Option keys to extend or contract an existing column selection.

Figure 6-22. FIGURE 6-22

You can copy the selected characters to the clipboard or delete them. If you copy the selection, the clipboard will contain the selected characters of each line on separate lines. Lines that have no characters selected (lines shorter than the first column) are not included. You cannot paste into a column selection or otherwise replace a column with multi-line content.

Selecting Code Blocks

The Edit

This command is similar to, and independent of, the Select to Matching Brace option in the Text Editing pane of the Xcode Preferences, described earlier in the "Editing Options" section. This command, however, works only with braces and brackets.

Jumping to a Line or Character

The Edit

Figure 6-23. FIGURE 6-23

Enter the position within the file that you want to select. The radio buttons determine whether the position will be interpreted as a character offset or a line number.

Press the Return key and that line or character is selected in the file and the Goto window closes. Alternatively, you can click the Select button. This also selects your chosen position, but leaves the Goto window open. If you check the Auto-Update option, the position in the Goto window continuously updates to reflect your current position within the file.

The text editor provides several useful variations of the standard delete key for deleting text adjacent to the insertion point, as listed in the following table.

The Delete key, just above the Return key (sometimes labeled

The delete keys follow the same pattern that the right and left arrow keys do. The amount they delete increases depending on the modifier used: either none, Control, Option, or Command. The one exception is the combination of Command+right-delete, which doesn't work; use Shift+Command+right-arrow to select to the end of the line, and then press the Delete key.

Control+H and Control+D are Emacs synonyms for Delete and delete-right. Use these if you prefer or if you don't have a delete-right key on your keyboard. These control key equivalents cannot be combined with the Option or the Control key modifiers. The Emacs-centric Control+W command deletes from the current cursor location to the location of the mark, previously set with Control-spacebar or Control+X Control+X.

A text selection can be dragged around within a document, between documents, and between Xcode and other applications.

A text selection and a text drag use the same gesture: click, move, and release. The difference is in the timing. To drag out a new text selection, press down the mouse button and move the mouse immediately. The cursor remains a text cursor. To start a drag, press down the mouse button and wait. After a very short delay (less than a second) the cursor turns into an arrow. You are now dragging the text selection. You can customize this delay to suit your mousing speed. See the discussion of the NSDragAndDropTextDelay expert setting in Chapter 23.

Press down the Option key before dropping the text to make a copy. Dragging between documents always performs a copy. Dragging from other applications inserts the text equivalent of the object being dragged. Dragging file icons from the Finder or the project window inserts the URL of the file, not the contents of the file itself. To insert the contents of a file, open that file in Xcode, choose Edit

Most lists, displays, and fields in Xcode can be the source of a drag even when they are not editable. How useful this is will vary, but keep it in mind before you reach for a yellow pad to write something down. You might simply be able to drag it somewhere to keep it. Drag any text selection to the desktop or an open Finder window to create a clipping file containing that text. This is a handy way of saving or "setting aside" a chunk of code while you experiment.

Program source files are plaintext files that do not include any font, style, color, or other typographic information. Logically then, the commands and tools in the Edit

When you use Xcode's RTF (styled text) editor, the commands in these menus perform as expected.

All editor panes, except for ones just created with the File

The Revert to Saved (Command+U) command is the opposite of the various Save commands. Instead of writing the changes to the file, it discards any changes made since the file was opened or saved and re-reads the text from the file. Xcode presents a warning beforehand, shown in Figure 6-24, ensuring that you really do want to abandon all the changes you've recently made. You cannot recover these changes once the Revert to Saved command has executed.

Figure 6-24. FIGURE 6-24

Xcode's undo features work pretty much the way they do in most modern applications, but a couple of differences exist. Undo history is maintained on a per-file basis. Until the file is saved and all editing panes that contain it are closed, Xcode maintains the undo history for the file, and all editing panes showing the same file share the same undo history.

Each atomic editing action is recorded as a step in the undo history. An "atomic" action would be typing some sequence of regular text characters, navigation, auto-completion, using the Tab key, deleting text, cutting, pasting, or any other menu command that changes the contents of the text buffer.

The Edit

The Redo command performs the complement of the Undo command. It takes the most recent action moved to the redo list, performs it again, and adds it to the undo history. Together, the Undo and Redo commands are like a time machine, allowing you to step forward and backward through the history of the file's changes until you find the state of the file you want.

Any new change made to a file erases the redo list. If you go back in time and make a different choice, you can no longer visit the future that contained the original choice. The Revert to Saved command empties both the undo and redo information for a file.

The Save command does not alter the undo or redo information for a file. This means it is possible to undo changes made to a file after it has been saved. Whenever you try to undo the last action that occurred before a file was saved, Xcode presents a dialog box like the one shown in Figure 6-25.

Figure 6-25. FIGURE 6-25

Some developers find this dialog box annoying. Chapter 19 explains how to set the XCShowUndoPastSaveWarning advanced setting to disable that warning.

Start the interactive spelling checker with the Edit

Figure 6-27. FIGURE 6-27

Checking starts at the text cursor or the beginning of the current selection. Checking is not limited to the text selection; it just starts there. The next word that the spelling checker suspects is misspelled is highlighted in the text and displayed in the entry field of the palette. Above the suspect word is a list of suggested corrections.

The Ignore button adds the suspect word to the temporary ignore list. The spelling checker ignores this word, and assumes that it is spelled correctly, until the next editor session. Use this to teach the spelling checker temporarily about correctly spelled words, without permanently adding them to the dictionary.

The Find Next button skips this word and goes looking for the next suspicious word. The spelling checker still considers the word to be misspelled.

You can immediately replace a word with a suggestion from the Guess list by selecting the suggestion and clicking the Change button, or by double-clicking a suggestion in the list. You can replace the word with any arbitrary text by editing the contents of the text field before clicking the Change button.

If the spelling checker cannot guess the correct spelling of the word, you can help it by editing the suspect word and telling it to guess again using the Guess button. For example, the spelling checker cannot guess that you mean "exhausted" if you've actually typed "eghosted." Replacing the "g" with an "x" and clicking the Guess button, as shown in Figure 6-28, gets the word close enough for the spelling checker to find the correct word.

Figure 6-28. FIGURE 6-28

The pop-up at the bottom of the palette lets you choose a different language. The Learn and Ignore buttons take the word currently in the entry field and either add or remove it from your user dictionary. To remove a word you previously added, you have to type or paste it into the field before clicking the Ignore button. Your user dictionary is shared by all applications that use the Spelling Checker interface, so add to it wisely and sparingly.

You can invoke the spelling checker without bringing up the spelling checker palette with the Edit

This is probably the most useful spell checking command for programmers. After writing a long comment, position the cursor at the beginning of the comment and press Command+;. The spelling checker will skip to the first suspect word in the comment. Once you've corrected all of the English words in the comment, simply go back to writing code.

The Spelling menu has an option to Check Spelling as You Type. If selected, words that you just typed or edited are spell checked and highlighted automatically. Note that this does not spell check the entire document, or text that you paste or drag. It only checks the word that your cursor was just in or adjacent to. The word that the cursor is currently in or adjacent to is never highlighted (because it is assumed that you are in the process of changing it).

You may find this feature useless and annoying when you're editing source code, because practically every "word" in your program is going to be tagged as misspelled. However, if you are writing a large amount of documentation in Xcode, you might find it helpful to turn it on temporarily.

To prepare a file for localization, open the Info window for the file's item and click the Make File Localizable button. The file's source item is turned into a group and the existing file becomes the localized version for the development region. In the project structure group, the source item becomes a kind of source group. The top-level item acts as a proxy for the development region's version of the file, equivalent to the original file; that is, opening the item opens the localization for the development region. To open or change settings for an individual locale, expand the group and deal with each version separately.

After you initially localize the file, you can add more localizations by opening an Info window for either the item group, or any specific localization, and clicking the Add Localization button. Enter the name of the localization, or choose one from the pop-up menu, as shown in Figure 6-32. A new file is created by duplicating the current file. The new file becomes the localized version for that region.

Figure 6-32. FIGURE 6-32

In the project folder, Xcode creates an .lproj subfolder for each localization. All of the files localized for English are in the English.lproj subfolder, all the files localized for French are in the French.lproj subfolder, and so forth. When the file is first localized, a localization folder for the development region is created in the same location, and the file is moved into the .lproj subfolder. The Multiglot project, shown in Figure 6-33, shows the organization of the project and project folder after the MainMenu.nib and InfoPlist.strings files have been localized for English, French, and Spanish.

Figure 6-33. FIGURE 6-33

To remove a single localization of a file, select the specific localization within the file's group and delete it like you would any other source item.

To remove all localizations of a file, open the Info window for the localized group or any specific localization. Click the Remove All Localizations button. The localization for the development region is moved from the .lproj subfolder back to its original location. The localized group in the project is replaced with a simple source file reference again. Any additional localized versions of the file are left in their respective .lproj folders, but are no longer referred to in the project. If you later localize the file again, Xcode will not automatically pick up the other localized versions. However, if you add a localization for a region that already has a file in its .lproj subfolder, the file is not replaced and it becomes the localization for that region.