We don't want to apply labels for components that are inside not visible components. For example, setting has `SettingsEditor` with multiple `SettingWrapper` for each selected tab but only one is visible at one time. So we don't want to apply labels on not visible tabs
Trees are skipped as they contain a lot of elements and would generate too many hints.
A similar situation is with vertical scroll panes (e.g. editors). but not horizontal.
This is a heuristic that I observed that horizontal scroll doesn't have many elements and doesn't have any keyboard navigation.
We are skipping Tree and scroll panes inside status bar as they would be a performance problem.
Exception is when we are inside the status bar where we want to apply hints on individual components.
When Tree was expanded and we positioned label on center it could not be rendered as center of tree was outside of view. To fix that we calculate label position based only on visible part of Tree.
By default, IntelliJ disables actions while a modal dialog is open.
We override isEnabledInModalContext flag so hints can target components inside popups and dialogs (e.g., IdeaVim settings).
- Feature branches SHOULD be used for development work
- Feature branches MUST be rebased to master frequently (e.g., daily)
- Update API layer spec and plan to use feature branch
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- spec.md, plan.md: Change from feature branch to master (trunk-based)
- constitution.md: Expand branch selection guidelines
- Long-running features develop on master to avoid divergence
- Short-lived changes may use feature branches
- Planning must analyze scope to determine branch strategy
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add Principle VIII: Trunk-Based Development
- Master branch as trunk, always release-ready
- Prefer direct commits to master when safe
- Feature branches for long-running work
- Rebase-only integration (no merge commits)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Clarifications from /speckit.clarify session:
- External plugins: Use list from doc/IdeaVim Plugins.md, re-research
before migration to ensure completeness
- Deprecation: No harsh deprecation; approach defined after successful
external plugin migrations
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Defines requirements for IdeaVim extension API layer:
- Complete API module exposing all extension functionality
- Internal plugin migration to validate API design
- External plugin support with team-provided migration PRs
- API safety (state updates, editor context, test accessibility)
Based on prior Mia API analysis and design decisions:
- XML-based extension registration (not @VimPlugin annotation)
- Listener/event API deferred to future version
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Added principles:
- V. External Contributors: Recognizes community contributions
- VI. Documentation Goals: Commits to improving code documentation
- VII. Architecture Decision Records: ADRs tracked in YouTrack
Expanded:
- IV. Code Quality Standards: Added commit clarity requirements
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
