ADFA-1414 Adding tooltips for java/kotlin operators#1067
Merged
hal-eisen-adfa merged 6 commits intostagefrom Apr 10, 2026
Merged
ADFA-1414 Adding tooltips for java/kotlin operators#1067hal-eisen-adfa merged 6 commits intostagefrom
hal-eisen-adfa merged 6 commits intostagefrom
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughReplaces the long-press selection call in EmptyStateFragment to use IDEEditor.selectWordOrOperatorAtCursor; adds operator-detection utilities; and updates ShowTooltipAction to resolve operator-based tooltip tags and normalize editor-null handling. (49 words) Changes
Sequence DiagramsequenceDiagram
participant User
participant EmptyStateFragment
participant IDEEditor
participant OperatorSelection
participant ShowTooltipAction
User->>EmptyStateFragment: long-press
EmptyStateFragment->>IDEEditor: selectWordOrOperatorAtCursor()
IDEEditor->>IDEEditor: selectCurrentWord()
alt word selected
IDEEditor->>ShowTooltipAction: request tooltip for selection
ShowTooltipAction->>ShowTooltipAction: resolveTooltipTag(..., isKotlinOperatorToken/isJavaOperatorToken)
else no word selected
IDEEditor->>OperatorSelection: getOperatorRangeAt(line, column)
OperatorSelection-->>IDEEditor: range or null
alt operator found
IDEEditor->>ShowTooltipAction: request tooltip for operator
ShowTooltipAction->>ShowTooltipAction: resolveTooltipTag(..., isKotlinOperatorToken/isJavaOperatorToken)
else none
IDEEditor-->>EmptyStateFragment: no selection
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@editor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt`:
- Around line 26-84: The OPERATORS list orders tokens by length for
longest-match-first but contains the 4-char operator ">>>=" placed under the //
3-char section, preventing correct matching; move the string ">>>=" to precede
the 3-char operators (i.e., place it before ">>>", "<<=", ">>=") in the
OPERATORS list so the longest operators are listed first and the matching logic
using OPERATORS works as intended.
- Around line 94-103: The operator-detection fails because suffix.subSequence(0,
op.length) == op compares a CharSequence (possibly ContentLine) to a String
using reference equality; in getOperatorRangeAt change the comparison to a
content-based check such as suffix.subSequence(0, op.length).contentEquals(op)
or compare suffix.subSequence(0, op.length).toString() with op, ensuring the
check uses contentEquals or String equality so OPERATORS are detected correctly
(use the local variables suffix, op and the function getOperatorRangeAt to
locate the change).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 388846b4-8344-495d-83db-ef63c3764d29
📒 Files selected for processing (3)
app/src/main/java/com/itsaky/androidide/fragments/EmptyStateFragment.kteditor/src/main/java/com/itsaky/androidide/editor/ui/IDEEditor.kteditor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt
editor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt
Show resolved
Hide resolved
editor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt
Show resolved
Hide resolved
dara-abijo-adfa
approved these changes
Mar 19, 2026
…he tooltip database
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kt (1)
91-97: Consider treating.ktsas Kotlin here.
File.extensionis"kts"for Gradle Kotlin scripts, so those editors currently fall back toCATEGORY_IDEand won't use the Kotlin/operator tooltip path.Suggested fix
internal fun tooltipCategoryForExtension(extension: String?): String = when (extension) { "java" -> TooltipCategory.CATEGORY_JAVA - "kt" -> TooltipCategory.CATEGORY_KOTLIN + "kt", "kts" -> TooltipCategory.CATEGORY_KOTLIN "xml" -> TooltipCategory.CATEGORY_XML else -> TooltipCategory.CATEGORY_IDE }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kt` around lines 91 - 97, The tooltipCategoryForExtension function currently maps "kt" to TooltipCategory.CATEGORY_KOTLIN but misses Kotlin script files whose extension is "kts"; update tooltipCategoryForExtension to treat "kts" like "kt" (e.g., add a branch for "kts" that returns TooltipCategory.CATEGORY_KOTLIN or combine "kt", "kts" in the same when-arm) so Gradle Kotlin scripts use the Kotlin tooltip path.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kt`:
- Around line 107-110: The current branch only maps operator tokens when
category == TooltipCategory.CATEGORY_KOTLIN, so operator selections in Java
editors are left as raw symbols; change the condition to check
isOperatorToken(textToUse) regardless of category (preserving the earlier
!editorTag and CATEGORY_XML && isXmlAttribute cases) so the operator mapping
(the line producing "kotlin.operator.$textToUse") runs for Java too; update the
case that references isOperatorToken, textToUse, and
TooltipCategory.CATEGORY_KOTLIN in ShowTooltipAction.kt accordingly.
---
Nitpick comments:
In `@app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kt`:
- Around line 91-97: The tooltipCategoryForExtension function currently maps
"kt" to TooltipCategory.CATEGORY_KOTLIN but misses Kotlin script files whose
extension is "kts"; update tooltipCategoryForExtension to treat "kts" like "kt"
(e.g., add a branch for "kts" that returns TooltipCategory.CATEGORY_KOTLIN or
combine "kt", "kts" in the same when-arm) so Gradle Kotlin scripts use the
Kotlin tooltip path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2a18a0f9-8ce2-4665-b8fb-c8204ac3a631
📒 Files selected for processing (2)
app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kteditor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt
🚧 Files skipped from review as they are similar to previous changes (1)
- editor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt
app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kt
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
editor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt (1)
26-35:⚠️ Potential issue | 🟡 MinorMove
">>>="before 3-char operators to keep longest-match-first behavior.At Line 34,
">>>="is placed after">>>", sogetOperatorRangeAt()will match">>>"first and never return the full">>>="range.Proposed fix
private val OPERATORS: List<String> = listOf( + // 4-char + ">>>=", // 3-char (=== and !== before 2-char == and !=) "===", "!==", ">>>", "<<=", ">>=", - ">>>=",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@editor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt` around lines 26 - 35, The OPERATORS list currently places ">>>=" after ">>>", causing getOperatorRangeAt() to match the shorter ">>>" first; reorder the OPERATORS list so that all longer multi-character operators come before their shorter prefixes (specifically move ">>>=" before ">>>") to preserve longest-match-first behavior in getOperatorRangeAt().
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In
`@editor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt`:
- Around line 26-35: The OPERATORS list currently places ">>>=" after ">>>",
causing getOperatorRangeAt() to match the shorter ">>>" first; reorder the
OPERATORS list so that all longer multi-character operators come before their
shorter prefixes (specifically move ">>>=" before ">>>") to preserve
longest-match-first behavior in getOperatorRangeAt().
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 088b144a-4a3b-4936-a7e9-b2b9901a5aa8
📒 Files selected for processing (2)
app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kteditor/src/main/java/com/itsaky/androidide/editor/utils/OperatorSelection.kt
🚧 Files skipped from review as they are similar to previous changes (1)
- app/src/main/java/com/itsaky/androidide/actions/file/ShowTooltipAction.kt
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I'm not seeing anything in the documentation db yet, but I need to check in with Elissa.
OPERATORS list: 3‑char, 2‑char, then 1‑char (so e.g. >>> is matched before >> and >).
getOperatorRangeAt(lineContent, column): Pair<Int, Int>?
Returns (startColumn, endColumnExclusive) for the operator at that column, or null. Uses 0‑based columns; end is exclusive.
Content.getOperatorRangeAt(line, column): Pair<Int, Int>?
Same semantics for a Sora Content, with bounds checks for line and column.
selectWordOrOperatorAtCursor()
Calls selectCurrentWord(); if the cursor still has no selection, gets the operator range at cursor.leftLine / cursor.leftColumn and, if present, calls setSelectionRegion(line, startCol, line, endCol).
onFragmentLongPressed()
Now calls currentEditor.selectWordOrOperatorAtCursor() instead of currentEditor.selectCurrentWord().