Update doc links again

crates/bevy_picking/src/events.rs

@@ -3,7 +3,7 @@
 //!
 //! # Usage
 //!
-//! To receive events from this module, you must use an [`Observer`](bevy_ecs::observer::Observer)
+//! To receive events from this module, you must use an [`Observer`]
 //! The simplest example, registering a callback when an entity is hovered over by a pointer, looks like this:
 //!
 //! ```rust
@@ -22,9 +22,10 @@
 //! 3. and they allow events of different types to be called in a specific order.
 //!
 //! The order in which interaction events are received is extremely important, and you can read more
-//! about it on the docs for the dispatcher system: [`pointer_events`]. This system runs in [`PreUpdate`]
-//! in [`PickSet::Focus`]. All pointer-event observers resolve during the sync point between
-//! [`pointer_events`] and [`crate::focus::update_interactions`].
+//! about it on the docs for the dispatcher system: [`pointer_events`]. This system runs in
+//! [`PreUpdate](bevy::app::PreUpdate) in [`Focus`](crate::picking::PickSet::Focus). All pointer-event observers
+//! resolve during the sync point between [`pointer_events`] and
+//! [`update_interactions`](crate::focus::update_interactions).
 //!
 //! # Events Types
 //!

crates/bevy_picking/src/lib.rs

@@ -29,10 +29,11 @@
 //!
 //! ## Expressive Events
 //!
-//! The events in this module (see `[crate::event]`) cannot be listened to with normal `EventReader`s.
+//! The events in this module (see [`crate::event`]) cannot be listened to with normal `EventReader`s.
 //! Instead, they are dispatched to *ovservers* attached to specific entities. When events are generated, they
 //! bubble up the entity hierarchy starting from their target, until they reach the root or bubbling is haulted
-//! with a call to [`bevy_ecs::observer::Trigger::propagate`]. See [`bevy_ecs::observer`] for details.
+//! with a call to [`Trigger::propagate`](bevy_ecs::observer::Trigger::propagate).
+//! See [`Observer`](bevy_ecs::observer::Observer) for details.
 //!
 //! This allows you to run callbacks when any children of an entity are interacted with, and leads
 //! to succinct, expressive code:
@@ -97,25 +98,25 @@
 //! This plugin is designed to be extremely modular. To do so, it works in well-defined stages that
 //! form a pipeline, where events are used to pass data between each stage.
 //!
-//! #### Pointers ([`crate::pointer`])
+//! #### Pointers ([`pointer`](crate::pointer))
 //!
 //! The first stage of the pipeline is to gather inputs and update pointers. This stage is
-//! ultimately responsible for generating [`pointer::PointerInput`] events. The provided crate does this
-//! automatically for mouse, touch, and pen inputs. If you wanted to implement your own pointer,
-//! controlled by some other input, you can do that here. The ordering of events within the
-//! `PointerInput` stream is meaningful for events with the same `PointerId`, but not between
-//! different pointers.
+//! ultimately responsible for generating [`PointerInput`](pointer::PointerInput) events. The provided
+//! crate does this automatically for mouse, touch, and pen inputs. If you wanted to implement your own
+//! pointer, controlled by some other input, you can do that here. The ordering of events within the
+//! [`PointerInput`](pointer::PointerInput) stream is meaningful for events with the same
+//! [`PointerId`](pointer::PointerId), but not between different pointers.
 //!
 //! Because pointer positions and presses are driven by these events, you can use them to mock
 //! inputs for testing.
 //!
-//! After inputs are generated, they are then collected to update the current [`pointer::PointerLocation`]
-//! for each pointer.
+//! After inputs are generated, they are then collected to update the current
+//! [`PointerLocation`](pointer::PointerLocation) for each pointer.
 //!
-//! #### Backend ([`crate::backend`])
+//! #### Backend ([`backend`](crate::backend))
 //!
-//! A picking backend only has one job: reading [`PointerLocation`] components, and producing
-//! [`PointerHits`](backend::PointerHits). You can find all documentation and types needed to
+//! A picking backend only has one job: reading [`PointerLocation`](pointer::PointerLocation) components,
+//! and producing [`PointerHits`](backend::PointerHits). You can find all documentation and types needed to
 //! implement a backend at [`backend`].
 //!
 //! You will eventually need to choose which picking backend(s) you want to use. This crate does not
@@ -127,7 +128,7 @@
 //! This crate provides some backends out of the box, but you can even write your own. It's been
 //! made as easy as possible intentionally; the `bevy_mod_raycast` backend is 50 lines of code.
 //!
-//! #### Focus ([`crate::focus`])
+//! #### Focus ([`focus`](crate::focus))
 //!
 //! The next step is to use the data from the backends, combine and sort the results, and determine
 //! what each cursor is hovering over, producing a [`HoverMap`](`crate::focus::HoverMap`). Note that
@@ -137,7 +138,7 @@
 //! order of the backend, and the [`Pickable`] state of the entity. In other words, if one entity is
 //! in front of another, usually only the topmost one will be hovered.
 //!
-//! #### Events ([`create::events`])
+//! #### Events ([`events`](crate::events))
 //!
 //! In the final step, the high-level pointer events are generated, such as events that trigger when
 //! a pointer hovers or clicks an entity. These simple events are then used to generate more complex