wed
Version:
Wed is a schema-aware editor for XML documents.
1,180 lines (885 loc) • 69 kB
Plain Text
==========
Wed's Help
==========
The following help covers the basic features of wed. There are some important
caveats to keep in mind when reading this documentation.
First caveat. Wed is designed to be an XML editor that provides on the fly
validation, and *only* this. Consequently, wed has no notion of a "document
collection" and provides no means to load documents from a collection or save
documents under some name into a collection. Functions such as these are to be
provided by the larger application in which wed is being used. **The following
documentation does not cover the functions which are outside the scope of wed.**
Second caveat. The functions of wed are exposed to the user through *editing
modes* (usually just referred to as "modes"). It is possible to use wed with
custom modes that present the document differently from what the generic mode
does, or include toolbars, menus, dialogs, etc. **The following documentation
covers only what the generic mode (bundled with wed) provides.** Custom modes
will have to provide their own documentation.
Third caveat. Make sure that wed is supported on your browser before `filing a
bug report <https://github.com/mangalam-research/wed/issues>`_. See `Browser
Requirements`_.
Editing Controls
================
Wed divides the screen into various areas.
Toolbar
-------
Above the validation progress bar, wed presents a toolbar that allows to perform
some operations through the mouse.
.. note:: Wed does not include in the toolbar a button for every single
operation that may be performed through the keyboard. It includes only
some operations by default, and modes may add more custom operations
to the toolbar.
.. figure:: help_images/toolbar.png
:align: center
:alt: This image shows the default toolbar.
The default toolbar.
If you hover the mouse pointer over a button, you will get a prose description
of what the button does. In the image above, from left to right the buttons
perform the following actions:
* Save the document.
* Undo.
* Redo.
* Decrease the `label visibility level <Label Visibility_>`_.
* Increase the `label visibility level <Label Visibility_>`_.
* Remove markup from mixed content.
* Toggle attribute autohiding off and on.
* Set the selection mode to `span <Span Mode_>`_.
* Set the selection mode to `unit <Unit Mode_>`_.
The attribute autohiding button is a toggle. When autohiding is on, the button
is pressed down, as shown by shadows. When autohiding is off, the button is
flat, as shown by the absence of shadows.
The buttons that set the selection mode are mutually exclusive. The button which
corresponds to whichever mode is active will is pressed down.
Mode-specific buttons may appear to the right of the double bar. The buttons
that appear there are those that correspond to the mode in effect at the caret
location.
The Validation Progress Bar
---------------------------
As you edit your document, wed validates your document according to the Relax NG
schema that was specified when wed was started. Whenever you make a change to
the document, wed revalidates the document.
.. note:: At the moment, wed itself does not provide a GUI to select different
schemas. It is up to the software that uses wed to provide to the user
the means to select a schema. How to do this depends on the needs of
the project. For instance, wed is used in `BTW
<https://btw.mangalamresearch.org>`_ to allow the editing of scholarly
documents. There there can be only one schema in use and thus no need
to ask the user to select a schema.
The validation progress bar is located above the editing pane. The image below
shows the general location of the bar.
.. figure:: help_images/validation_bar.png
:align: center
:scale: 50%
:alt: This image shows the location of the validation bar, above the editing
pane.
The location of the validation bar.
When an document is first loaded, or when a revalidation occurs, the bar starts
empty (all white). It is progressively filled with color as validation
proceeds. For small documents, validation will occur very quickly and
consequently the user will see the bar instantly fill to completion. The color
of the bar and the status that appears in the center of the bar will vary
depending on the results of validation.
* The bar will be green and the status will be "valid" if validation is complete
and the document is valid.
.. figure:: help_images/validation_bar_valid.png
:align: center
:alt: The validation bar is green and shows the status "valid".
A validation bar indicating a valid document.
* The bar will be red and the status will be "invalid" if the document is not
valid.
.. figure:: help_images/validation_bar_invalid.png
:align: center
:alt: The validation bar is red and shows the status "invalid".
A validation bar indicating an invalid document.
* The bar will be blue and the status will be "working" as long as validation is
not complete.
.. figure:: help_images/validation_bar_working.png
:align: center
:alt: The validation bar is blue and shows the status "working".
A validation bar indicating the validation is not complete.
* There is also a "stopped" status, which you should never see.
Modification and Save Status
----------------------------
On the left side of the screen, at the top, wed shows you the modification and
save status of the document being edited.
.. figure:: help_images/modification_and_save_status.png
:align: center
:scale: 50%
:alt: This image shows the location of the modification and save status, on
the top left side of the screen.
The location of the modification and save status.
The rectangle on the left is the modification status. A green modification
status indicates that the document has not been modified since it has last been
loaded or last saved. To the right of the modification status is the save
status. It starts gray to indicate that the document has never been saved
*during the current editing session.*
.. figure:: help_images/unmodified_unsaved.png
:align: center
:alt: An unmodified and unsaved status.
The status shown for a document that has not been modified since last loaded
and has not yet been saved in this editing session.
When you modify the document, the modification status becomes orange and
contains an asterisk to indicate that the document in the editor has
modifications that have not been saved yet.
.. figure:: help_images/modified_unsaved.png
:align: center
:alt: A modified and unsaved status.
The status shown for a document that has been modified since last loaded and
has not yet been saved in this editing session.
When you save manually (for instance, by doing :kbd:`Ctrl-s`), the modification
status returns to green and the saved status becomes green. The saved status
also tells you how long ago the last save occurred. Hovering on the save status
brings up a tooltip telling you what kind of save last occurred: autosave, or
manual save.
.. note:: The delay between autosaves is configurable, and can be turned off by
the application which makes use of wed. The availability of autosaves
and the delay between autosaves is determined by the application which
makes use of wed for editing.
.. figure:: help_images/unmodified_manual_save.png
:align: center
:alt: An unmodified and manually saved status, with tooltip.
The status shown for a document that has been manually saved moments ago.
The save status will update periodically to show approximately how long ago the
document was last saved.
.. figure:: help_images/unmodified_manual_save_minutes_ago.png
:align: center
:alt: An unmodified and saved status, which occurred minutes ago.
The status shown for a document that has been saved almost five minutes ago.
The Error Pane
--------------
On the left of the screen, under the modification and save status, you can find
the error pane. This is where XML validation errors are shown to the user.
.. figure:: help_images/error_pane.png
:align: center
:alt: The location of the error pane.
The error pane.
The error pane is collapsible. It can be collapsed or expanded by clicking on
the pane's heading. Clicking on `error markers <Error Markers_>`_ in the editing
pane will expand the error pane. Clicking on an error description in the error
pane will scroll the editing pane to the location of the error. It will also
make the error "selected". The selected error has its description blinking in
the error page and has its error marker blinking in the editing pane.
.. figure:: help_images/click_on_error_description.gif
:align: center
:alt: Shows what happens when the user clicks on an error description.
Clicking on an error description scrolls the editing pane to that error.
The Navigation Pane
-------------------
The navigation pane is a basic functionality of wed but will be visible only if
a mode makes use of it. **The generic mode does not make use of the navigation
pane.** The generic mode is meant to be truly *generic* and thus does not know
what elements serve as section headings in a document. Therefore, it does not
know how to build the content of the navigation pane. So if you are using the
generic mode, you won't see it.
Custom modes that make use of the pane will show this pane under the
`modification and save status <Modification and Save Status_>`_, above the error
pane.
.. figure:: help_images/navigation_pane.png
:align: center
:alt: Shows where the navigation pane is situated.
The navigation pane.
The user can click on the headings in the navigation pane to quickly scroll the
editing pane to the corresponding area of the document. Some modes may also
support bringing up special contextual menus on the headings of the navigation
pane.
The Minibuffer
--------------
As the name suggests, this is inspired by Emacs' minibuffer. However, wed's
minibuffer is much more primitive than Emacs'. The minibuffer is a space that
wed uses to quickly prompt for input *instead of* bringing up a dialog box. It
allows for quick operations like `quick searches <Quick Search_>`_. When it is
not in use, the minibuffer is empty. A prompt appears there when wed prompts the
user.
.. figure:: help_images/minibuffer.png
:align: center
:alt: Shows the minibuffer just under the editing pane.
The minibuffer.
In the example above, the minibuffer is prompting the user for a quick search,
forward in the document.
The Location Bar
----------------
The location bar appears right under the minibuffer. It indicates the hierarchy
of elements that contain the caret. Each XML element in the hierarchy is
separated from the next by a forward slash (``/``).
.. figure:: help_images/location_bar.png
:align: center
:alt: Shows where the location bar is situated.
The location bar.
In the example above, reading from the end of the location bar, the caret is
located in a ``note`` element contained by a ``notesStmt`` element contained by
a ``biblFull`` element, etc.
The Editing Pane
----------------
The editing pane is where the document being edited is displayed and where most
changes to a document are performed. It appears under the validation progress
bar, above the location bar and to the right of the error pane.
.. figure:: help_images/editing_pane.png
:align: center
:alt: Shows where the editing pane is located.
The editing pane.
If the document is too long for the space given to wed, the editing pane will
show a scroll bar on the right that allows scrolling the document.
We will now go over each distinctive element of the editing pane.
The Caret
~~~~~~~~~
The caret indicates where the document is being edited. It is a blinking
vertical bar. It can be moved by left clicking. When the caret is already in the
document, the arrow keys on your keyboard can be used to move the caret.
.. figure:: help_images/caret.gif
:align: center
:alt: Shows the caret.
The caret can be moved with left clicks of the mouse or the arrow
keys.
The element that contains the caret also acquires a pale yellow background color
while the caret is in it. Only the element which immediately contains the caret
acquires this color. The elements that contain this element do not change
background color.
Placeholders
~~~~~~~~~~~~
Empty elements contain placeholders. The placeholders are meant to help users
easily put the caret in empty elements. Without the placeholder, the start and
end labels of empty elements would be immediately adjacent, and getting the
caret between them would be more difficult. (It would require clicking on the
start label and moving right or clicking on the end label and moving left.) When
an element is edited to contain text or other elements, it loses its
placeholder. When an element is emptied it gains a placeholder. When the caret
is in a placeholder, the placeholder blinks to indicate that it contains the
caret.
.. figure:: help_images/placeholder.gif
:align: center
:alt: Text editing add and removes placeholders.
The ``hi`` element gains a placeholder when the text is removed,
and loses the placeholder when text is added back.
Placeholders also appear as the value of those attributes which have no value
set.
Element Labels
~~~~~~~~~~~~~~
By default, the generic mode bundled with wed shows the start of each XML
element with a start label, and the end of each XML element with an end
label. The start and end labels can be distinguished from one another by the
fact that a start label ends with a right angle bracket (``>``) and an end label
starts with a left angle bracket (``<``).
.. note:: It is possible for custom modes to display elements using more
specialized rendering, and omit the start and end labels. For
instance, a custom mode could distinguish "paragraph" elements through
line breaks and indentation, and omit the start and end labels of
these elements.
.. figure:: help_images/start_end_labels.png
:align: center
:alt: An example of start and end labels.
This figure contains a total of 8 labels: two start labels for two elements
``p``, and the corresponding two end labels, two start labels for two
elements ``hi`` and the corresponding two end labels.
Clicking on an element's label selects the element and allows the user to
perform actions on the element as a whole. When the element is selected, both
the start and end labels are colored orange.
.. figure:: help_images/selected_labels.png
:align: center
:alt: An example of selected labels.
This figure shows a ``p`` element which is selected. Its labels are orange.
Right-clicking on an element label will bring up a `contextual menu <Contextual
Menus_>`_ appropriate for the element. Start labels may contain the attributes
associated with the XML element to which the label belongs. For each attribute,
the label first shows the attribute's name, followed by the equal sign (``=``)
and the attribute value in double quotes (``"``). The attribute's value appears
in black on a white background.
.. figure:: help_images/attributes.png
:align: center
:alt: An example of attributes in a start label.
This figure shows a ``p`` element with the attributes ``rend`` and ``style``.
Modes may configure wed so that some elements are hidden if the caret is out of
a start label, but shown then the caret is moved inside the start label. Labels
that have hidden attributes will show an ellipsis (``...``) before the right
angle bracket (``>``).
.. figure:: help_images/attributes_ellipsis.png
:align: center
:alt: An example of start label with hidden attributes.
This figure shows a ``div`` element with the ellipsis that indicates some
attributes have been hidden.
When the caret is moved inside the start label, the hidden attributes are shown,
and they are hidden again as soon as the caret is moved out of the start label.
.. figure:: help_images/attributes_shown.gif
:align: center
:alt: An example of start label with hidden attributes that are shown.
This figure shows a ``div`` element with its hidden attributes shown.
.. note:: Attribute visibility is determined by the mode being used to edit the
file, and how this mode is configured. The generic mode by default
shows attributes. It is possible for an application using wed to
configure the generic mode to hide attributes. Custom modes may be
designed to hide attributes too.
.. note:: When a double quote appears as part of an attribute's value, wed will
show the double quote as a double quote. In other words, it does not
visually escape it. **However, wed does encode double quotes appearing
in an attribute's value properly.**
Whenever the mode being used has provided element documentation, hovering over a
label will bring up a tooltip with the documentation of the element.
.. figure:: help_images/label_tooltip.png
:align: center
:alt: An example of a start label with its tooltip open.
This figure shows a label for a ``p`` element whose tooltip is open. The
tooltip contains documentation on the element.
.. note:: Whether documentation is actually available depends on the mode being
used and how the mode was configured and packaged with wed.
Element documentation is not provided by wed itself. The generic mode
used in Wed's demo is set to work with TEI documents, and thus provide
documentations on TEI elements. This documentation was converted for
use by wed but its contents was created by the authors of the TEI
schema. Wed merely extracted it.
Label Visibility
''''''''''''''''
The editing modes of wed can be designed to assign different levels of
visibility to labels. Imagine for instance a mode that represents breaks in
paragraphs through line breaks and indentation, or foreign text by showing it in
italics, and so on. For each element that is represented on screen using
styling, it is usually not necessary to show the end and start labels of the
element: the presence of the element and its extent is already visible through
styling.
.. figure:: help_images/default_label_visibility.png
:align: center
:alt: A document shown at default label visibility. There is no
element label visible in the picture.
This is an example of the situation described above in the text.
It still may be useful sometimes for users to see the labels. Perhaps there is
an operation they want to perform that is easier to do with labels. In such
case, wed allows changing the label visibility level.
.. figure:: help_images/increased_label_visibility.png
:align: center
:alt: A document shown at increased label visibility. Every single element
gets labels.
This is an example of the same document shown earlier but with increased
label visibility. You'll notice that the word "prasāda" now has start and end
labels for ``foreign``. Paragraphs also have the ``p`` element.
Error Markers
~~~~~~~~~~~~~
Error markers indicate where in the document there is a validation error. They
appear as red rectangles at the location of the errors they mark.
.. figure:: help_images/error_marker.png
:align: center
:alt: An error marker.
An error marker appearing in an attribute value.
Clicking an error marker will expand the error pane if it was closed, and will
scroll the pane to show the error message corresponding to the error
marker. Both the marker and the error message will become selected. Selected
markers and their message blink slowly to indicate that they are selected.
.. figure:: help_images/error_marker_click.gif
:align: center
:alt: Clicking an error marker.
When an error marker is clicked, the marker and the error's description
become selected.
Contextual Menus
~~~~~~~~~~~~~~~~
Right-clicking on element labels or in the text contained by elements or
attributes brings up a contextual menu. As the term "contextual" suggests, the
content of the menu is determined by the location where the contextual menu is
being invoked. In particular, the list of operations available in the menu is
determined by what the Relax NG schema that governs the editing session allows
in the specific location where the menu was invoked. For instance, if an element
allows only the attributes ``a`` and ``b``, and ``b`` is already present on the
element, then the contextual menu that you get when right-clicking on the start
label of the element will show only an option to add the ``a`` attribute,
because adding a ``b`` attribute again would not be valid.
.. figure:: help_images/contextual_menu.png
:align: center
:alt: A contextual menu.
This is a contextual menu brought up on the start label of the ``title``
element.
The top of the contextual menu contains buttons and an input field that allow
filtering the list of options presented by the menu. When editing a document
using a complex schema, there can be dozens of options available. Filtering
helps finding the desired option quickly.
The input field filters the options that pertain to attributes or elements on
the basis of attribute name or element name. It filters other options on the
basis of the name of the option shown in the menu. When you bring up the
contextual menu, the input field is focused automatically, so you can type in it
right away, without having to focus it with the mouse.
.. figure:: help_images/contextual_menu_text_filter.gif
:align: center
:alt: Using the input field to filter entries in the contextual menu.
The user brings up a contextual menu and filters options to those that
contain the text ``xml``.
The buttons above the input field allow filtering the list of options according
to characteristics other than text. The buttons are divided into two groups: the
first group filters by the kind of operation performed, the second group filters
by what kind of XML construct the operation affects. Hovering the mouse over
each button will give you a description of the filtering performed by the
button. The buttons in the first group filter as follows:
* |add| filters the list of options to those that add content. For instance,
adding elements and attributes.
* |delete| filters the list of options to those that delete content. For
instance, deleting elements and attributes.
* |wrap| filters the list of options to those that wrap content into an
element. For instance, wrapping text into a new element.
* |unwrap| filters the list of options to those that unwrap content. For
instance, unwrapping an element.
* |other| filters the list of options to those that are not in one of the
previous categories.
.. |add| image:: help_images/filter_add.png
.. |delete| image:: help_images/filter_delete.png
.. |wrap| image:: help_images/filter_wrap.png
.. |unwrap| image:: help_images/filter_unwrap.png
.. |other| image:: help_images/filter_other.png
The buttons of the second group filter as follows:
* < filters the list of options to those that perform operations on XML
elements. For instance, if you select this filter, then all options that edit
attributes would be removed.
* @ filters the list of options to those that perform operations on XML
attributes. For instance, if you select this filter, then all options that
edit elements will be removed.
* |other| filters the list of options to those that are not in one of the
previous categories. Therefore, it would filter the list of options to remove
those options that perform operations on elements or attributes.
The first characters typed into the input field can serve to select the buttons
listed above by means of the keyboard rather than using the mouse. When one of
these keys is used to select a button, this key only performs the task of
selecting a button *but does not appear in the input field*. The keys recognized
are:
* :kbd:`+` selects |add|
* :kbd:`-` selects |delete|
* :kbd:`,` selects |wrap|
* :kbd:`.` selects |unwrap|
* :kbd:`?` selects |other| in the first group of buttons. That is, it filters
options to those that do not add, delete, wrap or unwrap.
* :kbd:`<` selects <
* :kbd:`@` selects @
* :kbd:`!` selects |other| in the second group of buttons. That is, it filters
options to those that do not operate on elements or attributes.
* :kbd:`ESC` resets filtering. It will clear all the filtering buttons and will
clear the input field. If no filtering was in effect, then it will close the
contextual menu.
Once a button has been selected, *either with the mouse or by using one of the
keys above*, then the keys that select filters from that group no longer have
for effect to select filters. Instead, they will be added into the input field,
just like any other key. Here are some examples of this behavior:
* If the user opens a contextual menu and types ``+``, this will have for effect
to select the |add| button and filter the options to those that add
content. So far so good. Then if the user types ``-``, this will *not*
unselect |add| to select |delete| instead. Rather, the ``-`` character will
appear literally in the input field so that the end result will be that only
options that add content and operate on attribute or elements which have ``-``
in their name.
* If the user opens a contextual menu and types ``+``, and then ``@``, the |add|
and @ buttons will be selected and the list will show only those options that
add attributes. After the user types ``+``, the keys associated with the first
group of buttons cease to select buttons, but those associated with the second
group continue to be available to select one of the buttons in the second
group. Once ``@`` has been typed too, then none of the keys that select
buttons perform button selections anymore.
Resetting filtering by typing :kbd:`ESC` resets this behavior. In other words,
the keys that select buttons become operational again.
It is possible to select an option from the contextual menu by using the up and
down arrow keys on the keyboard and typing :kbd:`ENTER` on the desired
option. :kbd:`ESC` closes the contextual menu without performing a selection,
provided there is no filtering in effect, otherwise it will clear the
filtering. If filtering is in effect, then using :kbd:`ESC` twice in a row will
close the contextual menu.
Completion Menus
~~~~~~~~~~~~~~~~
If the schema used to edit the document specifies an enumerated list of possible
values, wed will present the user with a completion menu. A common case is for
attributes that may take only a limited set of values. Upon first placing the
caret in a location that can be auto-completed, wed will present the whole list
of possible values.
.. figure:: help_images/completion_initial.png
:align: center
:alt: A completion menu in its initial state.
The user just clicked into the ``sample`` attribute. Wed presents the list of
possible values.
The user may use the arrows on the keyboard to go up and down the list of values
to highlight a value, and hit :kbd:`ENTER` to insert it as the attribute
value. Note that hitting :kbd:`ENTER` when no value is highlighted in the menu
will insert the first value in the menu. Or the user may start typing a value at
the keyboard. As a value is entered, the list of completions will be narrowed to
those values that begin with the characters entered by the user. The matched
prefix will be bolded in the list of values. The user may then use the keyboard
arrows and :kbd:`ENTER` to complete the value already begun. It is possible also
to just type the whole value at the keyboard (which may be faster, in some
cases, than fiddling with a menu), in which case the menu will close once the
value is complete.
.. figure:: help_images/completion_typing.gif
:align: center
:alt: A completion menu as the user types in.
The user types ``med`` into the completion menu and then hits :kbd:`ENTER` to
complete the value.
Replacement Menus
~~~~~~~~~~~~~~~~~
Replacement menus are similar to completion menus. Completion menus appear
automatically but only *when the document contains a value that can be
completed*. Given an attribute that has a limited set of possible values, if the
attribute is already filled with a complete value, then the completion menu does
not appear. Suppose an attribute ``height`` which can take the values ``high``,
``medium``, ``low``, and it is already filled with the value ``medium``. If you
want to change the value, you won't be able to use the completion menu, because
there's nothing to complete since ``medium`` is already complete. So if you want
to change the value with the help of the editor, you have to use a replacement
menu by hitting :kbd:`Ctrl-?`.
Replacement menus are available in the same places completion menus are
available. The list of values they offer is the same as the list provided by a
completion menu in the same location. Choosing an item from the list in a
replacement menu replaces the entire attribute value with the item selected.
Note that replacement menus, contrarily to completion menus, do not support
changing the document while the menu is open. You need to exit the menu before
you can continue editing the document. If you don't want to make a change, click
outside the menu or hit :kbd:`ESCAPE`.
.. figure:: help_images/replacement_menu.png
:align: center
:alt: A replacement menu.
The user just brought up the replacement menu in the ``sample`` attribute.
Kinds of XML Operations
=======================
Wed divides operations on elements and attributes into a few categories:
* Adding. Such operations are usually marked with the |add| symbol. These are
operations that add entirely new elements or attributes to the document. They
normally do not operate on selections.
.. figure:: help_images/adding.gif
:align: center
:alt: A user adds an element.
The user adds an ``abbr`` element to the document.
* Deleting. Such operations are usually marked with the |delete| symbol. These
are operations that remove whole elements or attributes from the
document. They normally do not operate on selections.
.. figure:: help_images/deleting.gif
:align: center
:alt: A user deletes an element.
The user deletes an ``abbr`` element from the document.
* Wrapping. Such operations are usually marked with the |wrap| symbol. These
operations add an element around a section of the document being edited. The
section is indicated by clicking and dragging with the mouse to select a part
of the document. Therefore, wrapping operations appear in the contextual menu
only if a selection is in effect. They "wrap" the selection in a new element.
.. figure:: help_images/wrapping.gif
:align: center
:alt: A user wraps an element.
The user wraps text in an ``abbr`` element.
* Unwrapping. Such operations are usually marked with the |unwrap| symbol. This
is the reverse of wrapping. These operations operate on an element so as to
remove the element but put the element's original content in place of the
element being removed. They normally do not operate on selections.
.. figure:: help_images/unwrapping.gif
:align: center
:alt: A user unwraps the content of an element.
The user unwraps the content of an element.
Searching
=========
Wed offers two types of searches: quick searches, and dialog searches.
Moreover, wed will search through text in two possible contexts. Do not confuse
context and scope. The scope is the range of the document within which the
search operates. The context determines what *in this range* is part of the
search. Here are the two contexts:
* Element text. This encompasses only the text of elements. For instance,
searching for ``some`` in the XML ``<some.element some.attribute="some
value">some text</some.element>`` would only hit the word ``some`` that
appears before the word ``text`` and nothing else.
Note that because this context ignores the XML tags, it is possible for it to
perform matches across element boundaries. For instance if you search for ``I
am happy`` in the XML ``<p>I <bold>am</bold> happy</p>``, the search will
match the entire content of ``p``. That is, the ``bold`` element does not
prevent the match.
* Attribute values. This encompasses only the values of element attributes. In
the example above, a search for ``some`` would match only the word ``some``
appearing before ``value``.
Note that this kind of search does not span attributes. For instance, if you
have ``<p type="abc" subtype="def"/>`` and search for ``abcdef`` you will
**not** get a match that spans the values of ``@type`` and ``@subtype``. This
is probably not a desirable behavior at any rate, but we're mentioning it,
just in case.
It is not possible to search for element names or attribute names with the quick
search or dialog search. Nor is it possible to search for text which is purely
created for the sake of displaying the XML. Here's an example of the
latter. Suppose the following document::
<doc>
<p>
Johnson demonstrated (<ref target="/some/bibliographical/item"/>) that ...
</p>
</doc>
In this example, ``ref`` is a reference to a bibliographical item. Your wed
mode, fetches the bibliographical information and shows it instead of showing
the XML element as-is. So what you see is something like::
doc >
p >
Johnson demonstrated (Johnson, Five Ways to Eat Sushi) that ...
< p
< doc
``doc >``, ``p >``, ``p <`` and ``< doc`` are the start and end labels that
normally shows for elements. The string ``Johnson, Five Ways to Eat Sushi`` is
text that is not part of the XML but that the editing mode adds when it shows
you your document. It is more informative than ``<ref
target="/some/bibliographical/item"/>``. At any rate, neither searching through
element text or element attributes can find that text.
If you need to search for element names, attribute names or text created for
display purposes, you must use your browser's built-in search.
Quick Search
------------
You can use :kbd:`Ctrl-f` to quick-search forward, and :kbd:`Ctrl-b` to
quick-search backwards. When you hit either of these shortcuts, the `minibuffer
<The Minibuffer_>`_ becomes active and prompts you for a search term. As you
type the term you are searching for, wed will search through the document and
highlight in yellow the term it finds. To move to another hit, press
:kbd:`Ctrl-f` or :kbd:`Ctrl-b` again. Type :kbd:`ESCAPE` to end the search.
If you have a selection in effect when you start the search, the search will be
scoped to that selection. That is, the search will only search between the start
and end of the selection. (The selection disappears while you are searching:
this is normal and a current limitation of wed.) If you have no selection in
effect when you start the search, then the whole document will be searched.
.. figure:: help_images/minibuffer.png
:align: center
:alt: Shows the minibuffer just under the editing pane.
The minibuffer.
In the example above, the minibuffer is prompting the user for a quick search,
forward in the document. You can see the word "original" was found and
highlighted in yellow. When you hit the end of the search scope in either
direction, the highlight will disappear. If you then hit the shortcut to
continue in the same direction you were going, the search will continue from the
start of your search scope.
Dialog Search
-------------
You can use :kbd:`Ctrl-Shift-f` to search forward, and :kbd:`Ctrl-Shift-b` to
search backwards. Dialog searches are thus named because they bring up a dialog
box to provide the user with more search options than the quick searches.
Just like quick searches, if you have a selection in effect when you start the
search, the search will be scoped to that selection. That is, the search will
only search between the start and end of the selection. (The selection
disappears while you are searching: this is normal and a current limitation of
wed.) If you have no selection in effect when you start the search, then the
whole document will be searched.
.. figure:: help_images/dialog_search.png
:align: center
:alt: Shows the dialog that is brought up by dialog searches.
A dialog search.
The "Search for:" field is where you type the term you are searching for.
The "Replace with:" field is where you type the text you want to use to replace
the hits you find.
The "Direction": buttons determine in which direction the search goes. The
direction is initially determined by which shortcut you use to bring up the
search but you may change it later if you want.
The "Context:" buttons determine what is searched. There are two possible
contexts:
* "Only element text": this searches only through the text of
elements. Consequently, attributes are not searched.
* "Only attributes": this searches only through the attribute values of
elements. Consequently, the text of elements is not searched.
The buttons:
* "Find" looks for the next match.
* "Replace and Find" replaces the current match and finds the next.
* "Replace All" replaces all matches until the search reaches a boundary of the
search scope currently in effect. The boundary depends on the direction of the
search. If searching forward, the boundary marking the end of the search is
the end of the scope. If searching backwards, it is the start of the scope.
* "Close" closes the dialog.
.. warning:: Wed cannot replace hits that select an ill-formed portion of an XML
document. For instance, you have the XML ``tea<bold>pot</bold>``
and you search for ``ap``. If we mark the start and end of the hit
with the element ``mark`` we'd have
``te<mark>a<bold>p</mark>ot</bold>``. This is not well-formed XML
because ``mark`` and ``bold`` are straddling. Wed cannot replace
such cases, and will disable the "Replace and Find" button when you
land on such a case.
Note however that the "Replace All" button is never disabled. When
you use "Replace All", wed replaces all instances that it **can**
replace.
Saving
======
You can save by using :kbd:`Ctrl-s` or whatever means provided by the
application that uses wed. Possible outcomes:
* The data is saved. You will see a message telling you that the data was saved,
and the `save status <Modification and Save Status>`_ will indicate the data
was saved.
.. figure:: help_images/saved_message.png
:align: center
:alt: A green message saying "Saved".
This is the message that a user gets when a document was saved.
* Wed is disconnected from the server. You will get a dialog box saying:
It appears your browser is disconnected from the server. Editing is frozen
until the connection is reestablished. Dismissing this dialog will retry
saving. If the operation is successful, you'll be able to continue
editing. If not, this message will reappear.
You're effectively prevented from further edits until wed is able to
reestablish connectivity with the server.
.. note:: It is possible to configure wed to use other types of saving
mechanisms than sending data to a server. For instance,
``localStorage`` can be used to record data in the browser
itself. What mechanism wed uses depends on how the application in
which wed is used has configured wed.
* The server responded to the save request with a message that indicated that
the document being edited with wed changed on the server. In other words,
while you were editing a document someone else edited and saved the same
document, or an automated process modified the document. You'll get a dialog
box with the following message:
Your document was edited by someone else since you last loaded or saved
it. You must reload it before trying to edit further.
On reload, wed will acquire a fresh copy of the document from the
server. **The edits you performed on your document will be lost.** Wed is not
currently equipped to deal with concurrent modifications from multiple
sources.
.. note:: This is another instance where application that makes use of wed is
the party responsible for providing the means to resolve concurrent
modification conflicts or prevent them from happening in the first
place.
The solution is really application-specific. For `BTW`_ we decided
that locking documents to prevent concurrent modifications was the
right solution. Another project could conceivably decide to solve
conflicts in a way similar to what ``git`` does for merge
conflicts. There's no single answer here.
* There is an application-specific error which prevents saving the data. You
will see a message in a red notification bubble telling you what error
happened, and the `save status <Modification and Save Status>`_ will not be
updated. The content of the error message depends on the specific nature of
the error. For instance, an application which requires that documents be given
titles before they are saved could report an error if you try to save a
document without a title.
Copy, Cut and Paste
===================
Wed allows copying, cutting and pasting parts of a document. When you perform a
copy operation, the data is copied from the document to the clipboard. When you
perform a cut operation, the data is copied from the document to the clipboard,
and is also removed from the document. When you perform a paste operation, the
data is copied from the clipboard to the document. This is not specific to wed
but is the standard way software manipulates the keyboard.
.. note:: Readers needing more details about how copy, cut and paste interact
with the clipboard should consult general-purpose documentation about
how to use computers.
Wed supports two selection modes:
* Span mode: a mode by which you must select a span of the document to operate
on. This is similar to how you would select text in common plain text editors
like Notepad or word-processors like Word.
* Unit mode: a mode by which you direct the editor to copy or cut entire XML
structural units, like attributes or elements.
You can use the toolbar or :kbd:`Ctrl-SPACE` to change the selection mode. Wed
operates in a way that prevents mixing data from the two modes described
above. If you start copying data to the clipboard in span mode, then switch to
unit mode and copy more data, then the data you copied in span mode will be
removed from the clipboard. The same is true if you start in unit mode and
switch to span mode.
Span Mode
---------
This mode works mostly like how copy, cut, and paste works in plain text editors
like Notepad, or word-processors like Word. You select a span of the document
and direct the editor to perform an operation on it. However, because wed edits
XML, there are some limitations to what you can do.
Copy
~~~~
Copying contents *as XML* works only if the selection being cut starts and ends
inside the same XML element or the same XML attribute value. The selection can
span over XML elements, provided that it completely contains these elements. If
your selection straddles XML elements, then it will be copied *naively*, and you
will get a notification telling you that your selection was copied as such.
Note that "copied naively" here means that the content will be copied by the
browser itself, as if you were copying text from any web page. This means that
any decorations that wed creates and is part of the selection, will have its
textual content copied.
.. figure:: help_images/invalid_selection_cut.png
:align: center
:alt: A selection which cannot be copied as XML.
This selection cannot be copied as XML because it begins in one ``p``
element but ends in the subsequent ``p`` element.
.. figure:: help_images/valid_selection_cut.png
:align: center
:alt: A selection which can be copied as XML.
This selection can be copied as XML because it begins and ends in the same
``p`` element. There is an ``lb`` element inside the selection, which is
fine.
Cut
~~~
Cutting will work only if the selection being cut starts and ends inside the
same XML element or the same XML attribute value. The selection can span over
XML elements, provided that it completely contains these elements.
.. figure:: help_images/invalid_selection_cut.png
:align: center
:alt: A selection which cannot be cut.
This selection cannot be cut from the document because it begins in one ``p``
element but ends in the subsequent ``p`` element.
.. figure:: help_images/valid_selection_cut.png
:align: center
:alt: A selection which can be cut.
This selection can be cut from the document because it begins and ends in the
same ``p`` element. There is an ``lb`` element inside the selection, which is
fine.
A selection that cannot be cut can still be copied.
Paste
~~~~~
Wed will attempt parsing the pasted text, and if it is a well-formed XML
fragment, it will insert into your document the *parsed XML*, even if the
original document was plain text. Here's an example. Suppose you have a plain
text editor opened, and you have the text ``<foo>something</foo>`` in it. If you
select that text and paste it into wed, wed will create a ``foo`` element that
contains the text ``something``. It will not paste the text
``<foo>something</foo>`` *as text*.
If the text in the clipboard is not well-formed XML, then wed will insert it
into your document as text. So if you have the copy the text ``<foo blah</foo>``
from your plain text editor, and paste it into wed, this will be pasted *as
text*.
Note that pasting into attribute values always pastes the clipboard data as text
because attributes cannot contain anything else than text.
Unit Mode
---------
In unit mode, the editor copies entire XML structural units. There are two kinds
of XML structural units that wed operates on:
* attributes,
* elements.
.. note:: We talk of "units" because other candidate terms already have specific
meanings in XML. We cannot talk of "elements mode" because XML
elements are just *one* specific type of XML structure, and the mode
also works on attributes, which are not elements. We cannot talk of
"entities mode" because entities are another specific XML
structure. "Unit" was one term that does not already have a special
meaning in basic XML parlance.
Besides operating on XML structural unit, unit mode also allows a kind of
operation that span mode does not allow: it allows adding to the contents of the
clipboard instead of replacing it. So besides copy and cut, you can also
copy-add and cut-add.
Indicating Units
~~~~~~~~~~~~~~~~
In this mode you do not use a selection to indicate which unit you want to
operate on. Indeed, **you cannot set a selection while in unit mode**. Instead,
when you copy or cut, the editor will copy or cut the smallest unit enclosing
the current caret position. We call it the "smallest enclosing unit", for short.
.. note:: People who are used to think of XML as a tree of nodes might find it
easier to use an alternative way to think about how units are
selected. The "smallest enclosing unit" is always equivalent to the
tree leaf that immediately contains the caret, with the caveat that
text nodes are ignored. For instance, if one imagines the XML document
as a DOM tree and the caret is in a text node, then the smallest
enclosing unit is the element which contains the text node, not the
text node itself.
Look at the following example:
.. figure:: help_images/caret_in_attribute.png
:align: center
:alt: A caret in an attribute.
In this example, the caret is in the ``rend`` attribute of the first ``p``
element. The units that enclose the caret are:
* the attribute ``rend``,
* the element ``p`` (the first one),
* the element ``body``,
* the element ``text``.
``rend`` is the *smallest* enclosing unit because all other enclosing units
contain more data than ``rend`` does. For instance, ``p`` contains another
attribute besides ``rend`` and contains text.
Consider this example:
.. figure:: help_images/caret_in_text.png
:align: center
:alt: A caret in text.
In this example, the caret is in the text of the first ``p`` element. The units
that enclose the caret are:
* the element ``p`` (the first one),
* the element ``body``,
* the element ``text``.
``p`` is the *smallest* enclosing unit because all other enclosing units contain
more than ``p``. For instance, ``body`` contains two other elements besides the
``p`` element in which the caret is located.
Consider this similar example:
.. figure:: help_images/caret_in_element_name.png
:align: center
:alt: Caret in an element's name.
In the example, the caret is at the start of the start label for the element
``p``. Since it is outside of any attribute, then the smallest enclosing unit is
like in the previous example: the first ``p`` element.
Consider this example:
.. figure:: help_images/caret_between_elements.png
:align: center
:alt: Caret between elements.
In this example, the caret is just before the first ``p`` element in
``body``. The caret is not in any of the elements that are children of ``body``
(the two ``p`` elements and the ``div`` element). The smallest enclosing element
is ``body``.
Copy and Cut
~~~~~~~~~~~~
Performing a copy replaces the