Terminal - where is the "sweet spot" for you?

Development OS
1

Hello everyone! I am a new user to Haiku, but not new to terminals. :slight_smile: This weekend I got Haiku running on both bare metal (Dell Inspiron 15 from 2016) and of course in a VM, and I absolutely love what I see!

I am interested in contributing to the Terminal application. It’s code is clean, accessible, very very nice. But I have seen a few bugs including crashes and screen garbage, and minor gaps in vt100 compliance. I know how to fix these, and plan to make some patches for consideration via the documented guidelines. (Sidebar: Though I respect the contributions of folks who have figured out the LLM thing, I personally have never used LLM tools, and my own prior code in this space is available under both MIT license (Jexer) and dedicated to the public domain (Qodem/LCXterm).) However, I do not have the history and breadth you all do about what you really need in your system default terminal that needs to run well on any hardware Haiku will be installed on. So I figured I would ask:

What is Terminal’s “sweet spot” for you, feature-wise? What are you missing? What is a bridge too far?

(I have my own ideas of course, but don’t want to influence you all. I consider the opportunity to contribute a privilege and a thank you to the team here. :slight_smile: Some of the terminals I have seen and tested before are listed here . )

5 Likes
2

Hello and welcome! :slight_smile:

Related to Terminal, there are some minor / visual issues specially on curses applications. You can figure out quickly by just comparing how applications like MidnightCommander show in Konsole (also available on Haiku).

1 Like
3

If you want to get the PGUP and PGDOWN keys to scroll up and down the buffer, that would be just awesome.

1 Like
4

If you don’t already know what to fix/add, here the current list of tickets opened for Haiku’s Terminal app:

Maybe some defects are no more reproducible, just asserting that will be a big plus.

But I’m sure with your experience you can bring your own set of fixes and enhancements.

5

Unless I’m misunderstanding you, that’s SHIFT-PGUP/SHIFT-PGDOWN.

3 Likes
6

I never thought to try that; I’ll check into it; thanks.

Every other terminal I use can tell when you’re just in a shell, not an app within the shell, and use unmodified PGUP/DOWN to scroll the buffer. It’s really nice.

7

Well, that may be the part I was misunderstanding :frowning: If you meant in a specific application, then just forget what I said.

8

I use it a lot. With shell vi mode. Can’t think of a thing I’d change. (I mean, maybe the PageUp shouldn’t need a Shift modifier, that’s a fair point.)

9

Thank you very much! :slight_smile:

I can definitely investigate a few of these, for example: 18330 19631 18848 8482. Small updates for vt100/vttest will address keyboard and bce; the background color RGB at first glance may share a root cause with another RGB issue I want to get into. For 18519 it might be worthwhile to consider xterm’s modifyOtherKeys option(s) first; it gives a lot of similar functionality, but may be a moving target after xterm extended it in patch 398.

I’m going to see about getting a diagnosis/fix ready. Once that’s done, would it be best to comment in the relevant Trac issue first, or submit a patch for review and discuss from there? I’d like to start off with whatever workflow folks are most used to.

10

Well, for bugs for which the solution is to correct something, you can go directly to the patch submission for review, just remember to refer to the ticket number in the commit message so that reviewer(s) could get some context during their review.

For enhancement or more notable changes which could lead to multiple choices of design, preferences, possible regression impact to weight pro vs con, it’s better to start discussing a bit more in a ticket, a new one if necessary, or to react in the existing one with your analysis and proposal there.

If after a while you got not reaction, move on the patch submission stage.
Be patient, the backlog after +25 years is heavy, and the team is not that large yet.

1 Like
11

If you want to give a heads up so nobody else is suprised by your patch and works on it simultaniously (granted this seems unlikely with the terminal currently) you can write a comment. Otherwise you can go straight to review, especially if there is already a ticket with a discussed fix. If there isn’t you can still go straight to review, but then you may have to explain on the review why your aproach is correct (also for the benefit of the reviewer in this case)

12

Haiku Terminal code has a glitch in how emulates application mode arrows. I found this out when trying to get mousewheel to work in Terminal app I was working on about a year ago. I managed to find a work around but just FYI, something to look into.

13

VTkeymap.h is still mising some ESC sequences. From and old WIP (and semi-forgotten) patch I have lying around:

#define SHIFT_INSERT_KEY_CODE "\033[2;2~"
+#define SHIFT_DELETE_KEY_CODE "\033[3;2~"
 #define SHIFT_HOME_KEY_CODE "\033O2H"
 #define SHIFT_END_KEY_CODE "\033O2F"
+#define SHIFT_PAGE_UP_KEY_CODE "\033[5;2~"
+#define SHIFT_PAGE_DOWN_KEY_CODE "\033[6;2~"
+
+#define CTRL_INSERT_KEY_CODE "\033[2;5~"
+#define CTRL_DELETE_KEY_CODE "\033[3;5~"
+#define CTRL_HOME_KEY_CODE "\033O5H"
+#define CTRL_END_KEY_CODE "\033O5F"
+#define CTRL_PAGE_UP_KEY_CODE "\033[5;5~"
+#define CTRL_PAGE_DOWN_KEY_CODE "\033[6;5~"

(needs minor adjustments to TermViewStates.cpp to actually make those work).

14

I noticed glitches in dialog(1) mostly; not sure about other apps. Outside of Haiku the terminal is one of my favorite places to be, so any improvements would be welcome.

1 Like
15

Based on the feedback here (thank you!), I am going to focus first on patches for:

  1. 8482 - Arrow key modes (which also include Home/End): DECCKM + indication via DECRQM. Also add support for the xterm modifiers of those keys (ref: ctlseqs(ms) ) so that Ctrl-Left / Shift-Down / etc. can be recognized by applications; finally, add xterm modifiers for PgUp/PgDn/Ins/Del/F1-F12.
  2. vttest (see: https://qodem.sourceforge.io/screenshots.html ) - Just cursor movement, screen features, and VT102. Clearing these should give us 19631 and 18330 immediately, likely a solid clue to 18848, and make curses-based applications look correct.
  3. Mouse modes - X10, Normal, ButtonEvent, and AnyEvent are a bit off, preventing the use of mouse-draggable/sizable windows like zellij floating windows can do. I found a partial solution last night, but still need to fix MouseUp events in SGR encoding. (I think the Be API only sends MouseUp to a BView when the last button is released? If so, then it’s similar to the ncurses mouse API – and there is a way to handle SGR encoding mouse release with just a teeny bit more housekeeping.)
  4. Does anyone want mouse wheel up/down support? If so, just let me know how you would like to disambiguate “passing wheel up/down to the application” (example: scrolling text within an emacs buffer) vs “scrolling up/down the Terminal window scrollbar”. Or if there a Trac issue I will follow up there.
  5. metaSendsEscape support, so that M-x etc. work in emacs (+ DECSET/DECRQM 1036 so that applications can request/detect).

This list above should eliminate most visual, keyboard, and mouse glitches. Terminal is honestly very close, I think the patches will be pretty small individually.

…and then more things to think about. :slight_smile:

8 Likes
16

I’ve no idea what the numbers and acronyms refer to, but I likes your plan anyway :wink:
Patch away!

5 Likes
17

We already have that, no? It works fine with scrolling the backlog, and when having a pager open like less. Am I missing something?

The only thing where it does not work for me is in “git diff”

18

I saw in the code that wheel up/down is being detected from the end-user, and in response it would send the keyboard sequences for PgUp/PgDn/UpArrow/DownArrow to the application. I’ll have to look deeper, but I did not initially see code to send the mouse sequences for wheel up/down (button 4/5 press) to the application. So it looks like it is doing xterm’s alternateScoll behavior (maybe with the opposite default as xterm), and possibly not the wheel buttons. Ref: ctlseqs(ms) I’ll take this question over to a new Trac item later.

2 Likes
19

In the meantime, your first CR to add 8482 support is merged.
Thanks!

3 Likes
20

Moved topic there, as Terminal app is part of Haiku.