I haven't looked into this yet, but I'll comment about the hierarchy of bugs :-) as I see it.

The editor (Vincaed) isn't used at all in FluidShell or SSH shell. So bugs on FluidShell won't apply to Vincaed.

Then FuildShell and SSH Shell use the same Terminal for the UI. So a bug in FluidShell is either a "pure" FluidShell bug or just an UI bug in the VT100 terminal.

The thing is, if a bug is in the VT100 terminal, it should also be in the SSH Shell because it has the same UI.

So, before a FluidShell bug is assigned to VT100 is should be checked against the SSH Shell. Having the same UI problem in both shells would point towards the VT100 Terminal.

Having a bug only in FluidShell means it's a chance it's not a VT100 bug, so it should be first checked on the FluidShell side and only afterwards on VT100.

Since we don't have access to the FluidShell source code it makes bug investigation much harder than necessary from the VT100 side.

So -- has this bug been checked on the FluidShell side?

I guess Fung meant the FluidEditor class which is part of FluidShell. Indeed, is a FluidShell-only issue as it doesn't occur in SSH Terminal. The wrapping performed automatically by the Term class is useful for text output dump (such as some text coming from a \cat command etc) which is not hard-wrapped by the command sending this output. But this automatic wrapping cannot handle all the interactivity required on a shell (Home , End, Backspace, Arrow keys etc) and therefore these issues should be handled at FluidShell level.

In order to fix it, you need to enhance FluidShell with more functionality on the input line (prompter + chars entered by the user) by making use of terminal window's current number of columns. Below there is a comparision with Bash's behavior and required actions to implement in FluidShell:

• user enters more input making caret exceending the last column: in this case, Bash sends just a Space char followed by a Carriage Return; it does so relying on the automatic wrap performed by terminal emulator;
• caret will move from second line to the first one (when hitting Backspace or Left Arrow keys): Bash sends a CursorUp escape sequence ( ESC [ A ) followed by N number of CursorRight ( ESC [ C ) sequences, where N takes into account the prompter width and then performs corresponding actions (delete etc);
• handling of Home / End keys;
• input line (prompter + user input) rewriting when window is resized; Term class notifies you with the new rows x columns size when window is resized, you just have to register the listener on FluidTerminalWrapper and implement the sizeChanged() method:

    public FluidTerminalWrapper(FindBar findBar) {
        ...
        term.addListener(this);
        ...
    }

    @Override
    public void sizeChanged(Dimension cells, Dimension pixels) {
        // redraw input line
    }
 

Likely needs to rewrite most of fluid editor's code to support this.

There might be a bigger problem, which will require us to fix this.  See this scenario ...

1. I have a FluidShell window which is not very wide
2. I type a line such as [echo "This is the story"] which fits ok in the window.
3. I then move the cursor to the beginning of the quoted string before the word "This"
4. I start typing, which will add the character and move the rest of the text forword,
5. So I should have a sentence like [echo "In the beginning there was fire.  This is the story"]
6. But because the new sentence is too long for the sentence, then I don't see the full sentence.

The Term class automatically advances (i.e. wraps) text to the next line if a char is written while the cursor is at the end of the line. The problem reported by Niels is caused by a small implementation detail on how this automatic wrapping is performed: usually when a char is written to the screen, the caret automatically advances to the next column (without requiring any additional escape sequence for this). But when this char was written on the last column, the cursor is moved back one position to keep it on the visible area (see Term.java class, lines 3631-3636). Then you issue an ESC [ n D sequence to move the caret back to the proper position, which is usually ok, but not on this specific case, when the caret was already moved one step back because it reached the right margin.

This issue also cause major desynchronization between what user sees on the screen and what is actually stored on the input buffer line. (e.g. issue an \echo followed by some text till caret is 2-3 columns before the right margin, then move caret back and try to insert other words in the middle of the sentence, then hit ENTER ==> text is inserted on the input line buffer as indicated by the output of the echo command, but on the screen the new words will replace existing text on the input line and thus causing desynchronization).

In order to fix it you have to make FluidShell aware of window's current width (i.e. the number of columns) by registering the listener as shown on my first comment, then either issue an ESC [ (n-1) D sequence instead of ESC [ n D  if the char that was just written on the screen (not necessarily the same with the char typed by the user, it could be a char from the trailing part of the input line that is resent when user types something on the middle of the input line). Alternatively, you can write a space char when the char (from the input line) was written on the last column to make caret advance on the next line and thus keep it on the visible area. Bash behaves this way and probably seems more natural to the user than keeping the caret on the last position.

Also, when typing something on the middle of the input line, if trailing chars were written on the next line(s) you have to replace ESC [ n D sequence with a CursorUp (  ESC [ A  )   +   N times CursorRight ( ESC [ C ) combination to move caret back to desired position.

It seems a little bit complicated, but you can temporarily enable some debug info by adding term.setDebugFlags(Term.DEBUG_OPS); on AbstractTerminalWrapper 's constructor , then establish a connection with SSH Terminal to see what escape sequences are sent by Bash on various scenarios.

Feel free to ask me if you have questions implementing this shell interactivity.

It is possible that the input line to be split over several lines (if window is narrow enough etc), therefore multiple CursorUp sequences might be required.

Also, user should be able to move caret back from second, third etc input line to the previous one by hitting the Left Arrow key, which will either trigger a CursorLeft sequence or CursorUp + N-1 * CursorRight sequences (where N is the current width - in cells - of the window) if caret was already on the first column.

I think you sent questions regarding Term.getCursorCol() related to this issue.

Term.getCursorCol() does not return current column in screen coordinates (visual cell position on the screen), but current column on buffer coordinates (i.e. position of cursor inside the buffer that represent current line). Because this buffer is represented by a char[] , it can hold multi-byte chars on a single position in the array. That's way the returned result is not what you would expect.

Screen coordinates are stored internally in the Term class by the st.cursor.row and st.cursor.column respectively. You could use Term.ops().op_get_column()  to retrieve cursor column position on screen coordinate (0-based value). However, I don't think this is a reliable solution for #7015 . I think is better to mimic Bash's behavior, i.e. to make FluidShell aware of current screen width (total screen width; register the listener as shown on #7015 to obtain this size information) and to move cursor at the beginning of the line ( send a Carriage Return ) then send N times CursorRight ( ESC [ C  ) escape sequences to instruct the GUI to move cursor to the desired position.

The idea is that is important to keep FluidShell input line buffer and its caret position in sync with the GUI and this can be achieved by commanding the Term GUI via escape sequences. FluidShell is the controller and the Term GUI classes represents the View on the MVC paradigm.

Also, I would prefer to keep FluidShell direct tethering with Term classes at minimum and use escape sequences whenever this is possible. Otherwise I'm affraid the vt220 protocol / Term GUI can be easily messed up and then is difficult to debug why the screen has messed up. Having the escape sequences serialized, is then easy to find out the wrong escape sequence that messed up the screen.

I can enhance FluidShell with the features required for #7015 if you send me the source-code for the classes resposible for FluidShell's readline behavior.

Understood. I have responded that question earlier today:

> It's OK if this is by design and Term does not offer such an API.  I
> guess I can work out the actual columns being occupied by using the
> combination of the following APIs:
>    Term.getCursorCol()
>    Term.getCursorRow()
>    Term.getRowText(cursorRow)
>    Term.charWidth(char)
 

Yes, I've read that, too. However, I find it strange to query the GUI about what is on the screen on a specific line ( Term.getRowText() ) , because FluidShell already keeps caret offset and input line buffer internally, therefore normally there would be no need for these queries. FluidShell only needs to instruct the GUI to erase a line / move cursor backward, forward, upward etc. Term.charWidth(char) would be needed by FluidShell in order to determine multi-byte chars and to know how many cells to move backward / forward.

I think these changes in FluidShell (i.e query screen coordinates and line content) would impact the loose-coupling between the shell and the GUI and the risk of unexpected bugs gets higher. That's why I am worried about this fix on current issue. I think we need to double-check this fix (if you want to keep this approach) to ensure that the overall functionality and intended behavior of the lib.terminalemulator is the same and don't have hidden side effects.

In order to calculate everything correctly, line buffer needs to know on which screen column it should start writing its output. This is because shell prompt may not always starts at column 1.

Below are a couple examples ('S' means a single-byte char, 'M' means a multi-byte character):
   (1) prompt$ echo -n "SSS" <Enter>
   (2) SSSprompt$ echo -n "MMM" <Enter>
   (3) MMMprompt$ echo
In case (2), the shell prompt 'prompt$' and user's input needs to be redrawn from screen column 4.
In case (3), the shell prompt 'prompt$' and user's input needs to be redrawn from screen column 7.

SSS and MMM are generated by the previously executed command, not part of the current line buffer. Line buffer could only retrieve SSS and MMM from Term's buffer.
 

You're right. Bash doesn't handle this case; I was able to desync the view (Xterm / Terminal.app) and the shell (Bash) both under Ubuntu and OSX. You can use Term.ops().op_get_column(); when a command has ended its execution to establish the column where the view will start writing the prompter etc.

I don't think is necessary to query Term's buffer about SSS and MMM; it is enough to know prompter' start position to know how many chars to advance to the right (in order to restore cursor position when user inserts chars in the middle on the line and the trailing chars go on the next line, i.e. after these trailing chars were resent) or to know if the right margin has been hit ( prompterStartPosition + cursorPositionInsideFluidShellInputLineBuffer == window.width (in nb of cells) ).

Another case would be when issuing \echo -n "SSS" command, ouput is displayed, then user resizes the window. The prompter + input buffer is repainted (by the shell) in this case, but Bash repaints it by writing the prompter from the first column and thus overwriting the SSS. The prompterStartPosition would be required in this case, too.

Thanks. At the moment, I am using the Term APIs mentioned earlier today, they seem to work fine and fulfill my need.

The initial version is done, SVN r29371.
Shell code that is responsible for handling user's input has been rewritten completely. We need to test new code thoroughly.

Known problems are:

(1) Timing issue among threads:

As described previously, shell prompt may not always be displayed from the first column. In order to get wrapping work, we need to know how many screen columns have been occupied before the prompt.  Let's use the command example below to explain the timing issue:
    prompt$ echo -n SSS
the result of executing the previous command would be
    SSSprompt$
if S is single byte character, then 3 screen columns will be occupied before shell's prompt "prompt$"
There are 3 threads involved behind the scene on executing the echo command:

    (A) CommandThread --> write output 'SSS' to TerminalThread --> TerminalThread send 'SSS' to SwingThread (1)
    (B) CommandThread --> notify Editor in SwingThread (2) --> Editor sends 'prompt$' to TerminalThread --> TerminalThread send 'prompt$' to SwingThread (3)
    (C) SwingThread: received 'SSS' and display it -- this is the result from (1)
    (D) SwingThread: received 'prompt$' and display it -- this is the result from (2)

There are 3 places that SwingThread are called, (1), (2) and (3).  
(1) is the place where echo's output 'SSS' is sent to SwingThread.
(2) is the place where Editor gets notified to generate the shell prompt, it is also the place where Editor tries to figure out how many screen columns would be occupied before the prompt.
If (1) is executed before (2), then everything is fine.
If (2) is executed before (1), then wrapping won't work because Editor does not know how many screen columns will be occupied before the shell prompt.
On my desktop, (2) is always executed before (1), this is likely because there is a TerminalThread involved before (1).
We currently work around this timing problem by introducing a Thread in (2), this thread is delayed for 10 ms and then query Term for the number of columns to be placed before shell prompt via Swing thread.  It is possible that 10ms is not long enough to get the correct information, when this happened, wrapping won't work.

(2) Multi-byte character alignment on the screen boundary:

When a character is displayed on the screen, it might occupy 1 or more columns. If there are N columns left on the current screen row and a character would occupy M columns to be displayed, and M is greater than N, then this character will be displayed on the beginning of a new row but the current row. The last N columns on the current row are left blank.

When this happens, the current wrapping implementation won't display the cursor at the correct location (the first column of the new row) when left/right arrow keys are used, it leaves cursor on the end of the old row.  Backspace/Delete keys would still work, though.
 

SVN r29381 - Delete key might redraw the line inappropriately
SVN r29383 - new input might clear the text displayed before prompt

For 2 known problems described above:

>> (1) Timing issue among threads

If '10 ms delay' workaround still did not get correct cursor location, then when user start typing input on the command line, shell will redraw prompt from the cursor location it currently has which usually is column 1; in this case, the text before prompt will be cleared.

Note that this is different than resizing a shell panel, when shell panel is re-sized, prompt is always redrawn from the first column; i.e. text before prompt (if exits) is always cleared after panel is re-sized.

>> (2) Multi-byte character alignment on the screen boundary

A separate issue, #7636, is logged for this problem, assuming it is not critical.

Verified using ADStudio 12 RC 22:
* the initial problem when the entered text has to be split on multiple lines and the behavior of the cursor-moving keys;
* the problem mentioned by Niels when additional text is added from the beginning to an initial short text;
* the timing problem.

For when resizing the FluidShell tab after an 'echo -n test line echoed here', the line of the prompt doesn't get entirely cleared, it was logged as #7723 - Prompt's line after resize doesn't get entirely cleaned.

Closed.