-
-
Notifications
You must be signed in to change notification settings - Fork 254
Open
Description
In chat message bubbles, file references are rendered as a “chip” (.message-file-link) showing a blue basename plus a grey “parent path”. When the referenced path is outside the workspace root, that grey portion becomes a long workspace-relative path full of ../ segments (e.g. ../../../../config/...).
Problems
- The
../-heavy relative path is hard to read/scan and often looks like part of the value/code. - It does not help disambiguate files that share the same basename across different folders, because the displayed path is effectively unreadable.
- When basenames collide, the suffix path still doesn’t help because it’s a noisy wall of
../segments; it’s hard to understand which folder a file is actually in. - The ordering (basename first, then parent path) is confusing; the suffix doesn’t read like a normal breadcrumb/path.
Request
- Don’t show
../segments in the UI for file-reference chips. - Either:
- Hide the grey parent-path suffix entirely (keep full path in tooltip/context menu), OR
- Replace it with a readable disambiguation path (e.g. trailing segments like
…/parent/file.extorparent/file.ext) that never includes../, and expands as needed when basenames collide.
Acceptance criteria
- No file-reference chip ever displays
../. - Duplicate basenames remain distinguishable (or we fall back to a more readable truncated path).
- Full path is still accessible (tooltip/context menu) and open-file behavior is unchanged.
Implementation pointers
FileReferenceLink+relativeDisplayPath/parseFileReferenceinsrc/features/messages/components/Markdown.tsx- Styling in
src/styles/messages.css(.message-file-link-*).
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels