xtermjs / xterm.js Goto Github PK

Cursor is over the second character y in this image:

Hey,

I like the design of xterm.js and would like to use it to connect to a docker container.
In the documentation I can see that in the client you connect to a docker container using the following uri:
url = 'ws://docker/containers/mycontainer/attach/ws/?stdin=1&stdout=1&stderr=1&logs=1'

As far as I understood there is a server application (e.g., node.js) that's exposing the docker terminal over a socket connection. In the docker documentation I can see that you can connect to a socket container via the docker REST API, so I can do http requests to the docker daemon (http://x.x.x.x:4500/containers/json). But how can I connect to my running container using the socket protocol (ws://x.x.x.x:4500/containers/mycontainer/attach/ws/?stdin=1&stdout=1&stderr=1&logs=1')?

Thanks.

Copying this:

Pasted result:

While potentially difficult, it's probably possible to do a smooth selection over multiple pages by:

• Recording start selection position
• Scroll the terminal up when dragging from terminal and cursor is close to/beyond top
• Scroll the terminal down when dragging from terminal and cursor is close to/beyond bottom
• Whenever the terminal is scrolled, reset the selection position
• When copy is triggered, intercept and select the text between the start and end (probably won't work in older browsers)

Proposal of @chani in #6 discussion.

See chjj/term.js#96

vs gnome-terminal:

Notice the characters are exactly 2 ascii characters in width

It would be great if a virtual scroll bar was provided.

Text: अर्धतत्सम

Characters change:

Can't move further back that this:

If you open up the demo page in Firefox (32.0 in Linux Mint) and you hit the enter key there is no newline, instead everything is written on the same line. In Chrome it does work as expected, though.

example:

Kind of a small issue:

We could change all files to ES2015 modules. This will help simplify the code base which takes care of commonjs, amd and plain browser environments.

I assume though that if we decide to move on with this it would be a good idea to provide prebuilt files for amd, commonjs and plain browser environment.

Start:

ctrl+shift+↑

Happens with mouse wheel too.

All we have to do actually is apply #49 to all add-ons.

The event should prevent default here

This issue is present in Windows/Chrome.

We could use React in order to render the terminal.

I guess that we could take advantage of React's Virtual DOM to minify the number of DOM mutations needed when updating the terminal.

We should have in mind though that such a change will dramatically increase the payload of the library.

Hello!

I'm using xterm in a new Electron-based IDE we're developing for Tingbot. Thanks for the library, it's proving to be super-useful.

I'm running up against some strange behaviour when resizing the terminal, which occurs more often than most terminals due to our window layout - the terminal is a panel at the bottom of the window that slides up and down

When resizing this panel we see unexpected behaviour from the terminal, when it's getting smaller, it removes lines from the top of the scrollback, and when getting bigger, it adds lines to the bottom - so it moves text off the screen if it's closed/opened.

I've had a look at the source and the problem seems to be around xterm.js:2526 - I think the terminal could just adjust its scroll position, rather than adding/removing rows.

I'd be happy to submit a pull request, if somebody could give me a pointer about how the scroll position is stored - I've seen two variables - this.ydisp and this.ybase - what do these do?

I'm using xterm.js in conjunction with ssh2 to build a SSH client, which has been working quite well so far (thanks for the awesome library!). One issue that I have encountered though is that inverse text styles appear as normal text. For example, on nearly any terminal, running nano will show the nano editor with a white status bar across the top implemented using inverse styles. In xterm.js, these appear as normal text instead. This issue also appears when using the colors.js library.

Peeking into the code, the problem seems to lie in the styles being applied by Terminal.prototype.refresh(). For inverse text, the classes applied to the surrounding <span> in each div.xterm-rows is xterm-bg-color-257 xterm-color-256 neither of which are defined in xterm.css and aren't valid xterm-256 colors. The correct classes should be xterm-bg-color-15 xterm-color-0 for a white background with black text.

For nano, the data variable that sets the inverse text in Terminal.prototype.refresh() is 2228992 (I'm not sure if that helps but that seems to be the value that causes bg and fg to evaluate to incorrect values).

Before:

After:

After ++:

The situation gets worse with every keystroke.

This problem occurs only when you type the url. If it appears in another way it is properly likified
This is especially annoying since typing for any reason a file name breaks the terminal (#26)

Either a Sourcelair bug or an issue with restoring state?

After ctrl+c:

Most probably this will be implemented as a separate add-on.

Related: #61

Initial:

←

Text: 안녕하십니까?

I was looking into using xterm.js for vscode's integrated terminal but the colors seem to be gone after I swapped out jeremyramin/term.js.

Expected:

This is how I was setting the colors:

terminal.colors = [...]; // array of 16 string in format '#rrggbb'
terminal.refresh(0, terminal.rows);

Hi, I found a bug in Safari. When I press backspace, "keypress" event fired in Safari. But in Chrome this event is not fired.

We can fix it in keyPress function:

     if (ev.charCode) {
       key = ev.charCode;
     } else if (ev.which == null) {
       key = ev.keyCode;
     } else if (ev.which !== 0 && ev.charCode !== 0) {
       key = ev.which;
     } else {
       return false;
     }

    // fix backspace in Safari
    if (key === 8) {
      return false;
    }

This would make it easier to read in addition to just being plain cool

/* blink/webkit */
.element::selection {
  color: fg;
  background-color: bg;
}
/* -moz-selection (probably deprecated) */

Original:

Reduce width:

Restore width:

Press left arrow:

Notice the first line is not restored at all.

It just moves the cursor a single character currently.

In case a lot of data is being transmitted to the client, consecutive renderings may turn the browser non responsive.

A solution that could work is buffer the the Websocket messages and render them to the terminal 10ms after the first message received. This way the maximum rendering frequency will be every 10ms.

Start:

Mouse wheel up:

xterm.js should be well tested in order to ensure that new releases and add-ons do not break any functionality introduced before.

Candidate libraries

• https://github.com/facebook/jest
• http://mochajs.org/#getting-started
• https://github.com/avajs/ava
• https://jasmine.github.io/

At least on Chrome. This is because of:

body {
    line-height: 1.4;
}

Before:

After:

Same on demo:

While in Firefox, it is not possible to make a selection in xterm. The selection instantly dissapears.

Firefox 41.0.2
Windows 10

Greetings.

I'm sure someone who enjoys css more than me has a better fix for the following, but when I have a terminal app (mcedit is a good example) that brings up a dialog with ansi characters in it the padding seems to blow out.

I can fix it with

.xterm-rows div {
    height: 16px;
}

but I imagine it's not the best fix (breaks scaling)

Hello,

in Windows (does not matter if virtualized or native) we are having problems with the | and @. While the latter is simply not printed it gives the following output:

altKey: true
bubbles: true
cancelBubble: false
cancelable: true
charCode: 0
ctrlKey: true
currentTarget: null
defaultPrevented: false
detail: 0
eventPhase: 0
keyCode: 81
keyIdentifier: "U+0051"
keyLocation: 0
location: 0
metaKey: false
path: Array[12]
repeat: false
returnValue: true
shiftKey: false
srcElement: textarea.xterm-helper-textarea
target: textarea.xterm-helper-textarea
timeStamp: 1444663462186
type: "keydown"
view: Window
which: 81
proto: KeyboardEvent

For the | key I get no debug output at all for key/ev. In Firefox and in Chrome running Linux it does work fine, though. Any ideas on this?

Cheers

example: