Hop 2.17 Explorer direction: keep it simple or move toward a more IDE-like experience (line numbers, themes, icons, markdown, syntax highlighting) #6515
Replies: 3 comments 3 replies
-
|
I agree this would be helpful. The idea is to let Hop Gui evolve more and more into an IDE. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I’d like to propose a set of usability and productivity improvements to the Hop file editor, inspired by what VS Code offers while keeping the editor lightweight and focused.
Add line numbers with a preference to enable/disable. Ideally provide a fast toggle via right-click context menu inside the editor and/or a global setting.
Automatically detect file type by extension and apply an appropriate editing mode: .sql, .yml/.yaml, .md, .py, .js, .java, .bat, .sh (and other pipeline-relevant types). Also provide a simple “language mode” selector to override detection when needed.
Add theme support (at least light/dark) and syntax highlighting. Visually distinguish: comments keywords strings numbers variables/parameters and their values Even basic highlighting significantly improves readability.
Show the full path (or breadcrumbs) at the top, similar to VS Code. This reduces mistakes (editing the wrong file) and improves navigation in larger projects.
A marketplace for extensions would be great. I understand it’s a larger initiative and likely incremental, but it’s worth considering as a strategic direction. Additional improvements with high impact / low friction Ctrl+F / Ctrl+H with options: regex (optional), case sensitivity, whole word Critical for scripts and configuration files.
With line numbers, add “Go to line” and a lightweight status bar showing: line/column, encoding, line endings (LF/CRLF)
Folding by indentation/markers helps a lot for .yaml, .sql, .py, .java.
Support tabs for multiple open files and a clear unsaved changes marker.
If a file changes outside Hop, prompt the user to reload to avoid conflicts. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
In Apache Hop 2.17, the UI improvements—especially the updated Explorer / file search & navigation experience—are a big step forward. My team loved it: organizing pipelines using folders/subfolders (mappings, subpipelines, etc.) feels much more natural now and has noticeably improved our daily workflow.
My question is about the intended direction for this area:
Is the goal to keep the Explorer simple, focused on browsing and basic file opening (Explorer-like), or
Is there an intention to evolve it into a more complete experience, closer to an editor/IDE (VS Code-like) for auxiliary files?
Context
In many projects, besides Hop files, we need to work with other artifacts that are part of the pipeline, such as .sql, .py, .json, .md, config files, etc. Today we typically have to open a separate IDE (we use VS Code) to edit those.
Optional enhancement ideas
These are not critical features, but they could add real value and be a nice differentiator—if aligned with the roadmap:
Show line numbers
Support themes (light/dark) and UI consistency
Improve/extend icons per file type
Syntax highlighting for common types (SQL, Python, JSON, Java, etc.)
Markdown preview/rendering
Detect file types by extension and open with the appropriate editor
Question
Is there an official direction (or ongoing discussion) regarding how far the Hop Explorer/Editor should go?
If the vision is to keep it simple, that’s totally fine—but if there’s room to evolve it, I’d be happy to open separate issues for incremental improvements (line numbers, themes, markdown, highlighting, etc.) based on what makes sense for the project.
Note
Congrats to the team—this area is genuinely better. We’ve seen clear productivity gains, especially because we apply a software-engineering style organization to our pipelines (folders/subfolders by domain and responsibility).
Just to recall, the screen is very good, this would be like a small interface adjustment that would make it easier to adopt a single tool for minor edits in other files
Beta Was this translation helpful? Give feedback.
All reactions