roblabla / mintty Goto Github PK

Terminal output is stopped while the options dialog is up. This has been
inherited from PuTTY, but there's no immediately obvious reason why this
should still be necessary in MinTTY.

It's time to submit MinTTY for consideration as a Cygwin package.

[deleted issue]

When using the --config option, mintty tries to execute "--config" as the
child process command.

What steps will reproduce the problem?
1. Open the Run... dialog
2. Enter C:\cygwin\bin\mintty.exe
3. Hit OK

What is the expected output? What do you see instead?
I expect a stand-alone login shell similar to executing mintty from a Bash
prompt.  Instead is a confused environment.

What version of the product are you using? On what operating system?
0.3.5.  Win2K

Please provide any additional information below.
Here is the output of the new window:
c:\Program Files\AdminTools\Resource Kit\sed.exe: can't read
/etc/bash_completion: No such file or directory
bash-3.2$

Ultimately, I'd like to be able to bind mintty to a key in Windows for
quick launching.  Presently I need to start a Cygwin shell, then run mintty
from inside that.  And then the parent Bash shell does not close its Window
on exit -- I need to manually close the window with [X] button.

Providing a -l or --login flag (or something similar) would be helpful to
provide the desired behavior.

Currently the Readme is the only documentation, so a few wiki pages are needed.

Switching off the scrollbar by default means there's no obvious clue to the
scrollback's existence.

rxvt has a -title option to set the initial window title. Since echoing the
necessary ANSI sequence isn't always practical or convenient, this would be
nice to have in MinTTY.

MinTTY currently takes the Windows lines per wheel notch setting into
account when sending mousewheel events, i.e. by default it sends three
events per notch. This does not work well with apps such as vim (with ':set
mouse=a') that activate application mouse mode, which only expect one event
per notch and multiply that themselves. As a result, vim ends up scrolling
by nine lines per notch, and by three pages instead of one when holding Shift.

The three-page problem also applies to scrollback scrolling and to
non-mouse-mode apps.

Transparency is nice eye candy, but when actually working in a window it
might be distracting, so it would be good to be able to switch it off when
the window is active.

Should be straightforward to implement, and there's still a bit of space
for a setting on the "Window" pane of the options dialog.

Alot of unix-based systems use ^? rather than ^H by default.  I connect
using SSH into alot of systems with both the ssh command from openssh and
putty.  Is there any possibility to change the default for the backspace
key to send ^?.

Fullscreen mode in MinTTY fills up the whole screen with as many rows and
columns as the current font size allows, thus maximising the space
available, much like e.g. in web browsers.

Fullscreen mode in the DOS box on the other hand (when it was still
supported), switched the graphics card into character mode and kept the
number of rows and columns, thereby in effect zooming the window contents
up to the whole screen.

Character mode is out of the question for MinTTY, but something similar
could be done by scaling up the font size. Since the window geometry is
unlikely to exactly fit the screen geometry, the font size could be
increased as far as possible while still fitting all existing rows and columns.

Any remaining space could be filled up with additional character cells, but
those would have to be cut away again when going back to window mode.

The keycodes sent by the cursor keys do not agree with xterm when a
modifier key is pressed and the terminal is in application cursor keys mode.

For example, unmodified arrow-up sends '\eOA' when in app cursor mode, and 
'\e[A' otherwise. Similarly, currently shifted arrow-up sends '\eO1;2A'
when in app cursor mode, and '\e[1;2A' otherwise.

In xterm, however, modified cursor keys actually always send codes starting
with '\e[1;', no matter the app cursor mode parameter.

Hi.  I gave a report on a problem I was having all morning in
http://cygwin.com/ml/cygwin/2009-01/msg00674.html

In your reply, 
http://cygwin.com/ml/cygwin/2009-01/msg00687.html
you requested I follow up in this forum.

The problem must be intermittent; i.e., I cannot reproduce it now. 
Earlier, I had just updated my Xming to 7.4.0.1, and I just had to change
my starting directory in my startxwin.csh, so perhaps this might have
something to do with the problem.

If the problem comes back, I'll post here.

Thanks.

Lester

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

One of the features I'm missing from Putty is the ability to duplicate a
session / terminal.

Alt-F4 for closing a window is a well-established standard on Windows,
which is why MinTTY implements it too. The Windows console does not have it
though, presumably because many DOS applications would have processed
Alt-F4. rxvt and xterm don't have it either, 

This makes this a question of user preference, so I guess there should be
an option. A slight complication is that it would need to be reflected in
the window menu by removing the Alt+F4 shortcut from the Close item.

Some terminal emulators have a background image feature. This is firmly in
the realms of visual frippery though and unlike transparency it needs more
than a couple of function calls.

I would like to see an option to "Allow only one instance." This option
would subsequently suck all new terminal sessions into a new tab in the
same window.  The user could then switch tabs with a customizable key
combination, that would default to something reasonable like Ctrl+Tab.

MinTTY currently uses "PC-style" keycodes for F1..F4 (e.g. ^[11~ ), whereas
the Cygwin xterm uses vt220-style (e.g. ^[OP ). Since MinTTY sets TERM to
"xterm", it obviously needs to do act the same as xterm.

(This nonsense is too obscure to inflict an option for it on unsuspecting
users.)

The windows command shell can show the latest executed commands (press F7).
It would be useful if mintty could do something similar.

When invoked from a batch script such as Cygwin.bat, mintty leaves the
console window open whereas with rxvt it only flashes up briefly. Closing
all the standard files makes no difference, so rxvt must be doing something
more to detach itself.

(A better way to invoke mintty is through a shortcut, which avoids opening
a cmd.exe session altogether.)

Add a context menu on right-drop which allows to choose between dropping a
file as a Windows path or a Cygwin path.
Alternatively, just use a modifier key to make the choice. Alt perhaps?

When sending one of the process terminating signals (TERM, KILL, HUP, INT)
to MinTTY, it will not exit immediately, waiting for the next keypress instead.

The reason for that is that Win32 functions are not interruptible by
signals in Cygwin and MinTTY spends most of its time in
MsgWaitForMultipleObjects().

MinTTY currently just leaves the choice of starting position for its window
up to the OS. It would be nice to have a way of specifying it, e.g. with a
-geometry command line option as in many X programs.

If wait() reports that the child process quit with an error, MinTTY keeps
its window open so that any error output can be read. This is useful e.g.
for failed ssh connection attempts.

The process status handling is incomplete though: signals are not
considered, i.e. in that case the process status is interpreted incorrectly.

The window should be kept open if the child process quit either with a
non-zero exit code or with a runtime-error signal such as SIGSEGV, and only
if the user has not told MinTTY to close.

The Apply button is more or less standard on Windows, so it would be nice
to have. Adding the button is trivial, but a bit of rearranging of config
code will probably be needed.

It would be very handy if it was possible to log the console output to a
file (similar to Putty)

What steps will reproduce the problem?

1. mintty.exe in C:\Program Files\mintty\
2. cygwin installed in C:\cygwin\
3. Shortcut to mintty.exe on Desktop
4. "Target" (desktop shortcut) set to '"C:\Program Files\mintty\mintty.exe"
/bin/bash -l'
5. "Start in" (desktop shortcut) set to 'C:\cygwin\bin'

(single apostrophe (') used for clarity, not used in shortcuts)

What is the expected output? What do you see instead?

MinTTY starts and works as expected. Command window that invokes MinTTY
does not close.

What version of the product are you using? 

Tested on 0.3.3 and 0.3.4

On what operating system?

Windows 7 Beta, build 7000

The setting of the "Alt key on its own send ^[" is ignored 0.3.2, i.e. Alt
on its own always sends Escape.

MinTTY's interface currently is in English only, but particularly for
initial configuration and also for consistency with the rest of the system
it would be nice to have support for other languages. This should probably
be done using gettext.

When drag-selecting multiple lines of characters with the mouse, the first
character of the first line is always included even when moving the mouse
to the left of the window. This is non-standard and quite annoying. PuTTY
didn't do that, so I bugged it up somewhere along the way.

This would take the minimalist approach to the extreme by leaving only the
terminal screen and the window border. Alternative ways to move or close
the window would be needed though.

With a full scrollback buffer, MinTTY reproducibly crashes when scrolling
back beyond three quarters or so of the scrollback.

What steps will reproduce the problem?
1. Open the options dialog.
2. Click on any of its controls.

What is the expected output? What do you see instead?
The control should react to the click. Instead, nothing happens except that
the mouse pointer changes from an Ibeam to an arrow.

If you've manually resized your terminal window and then change an
unrelated setting in the options dialog and press OK, the current terminal
size will be committed to the config file even though you most likely
didn't intend that.

Also, if you make a change to the size settings while in fullscreen, that
change will not take effect when switching back to the normal window.

The setting of the vt100 LNM parameter, which is reflected by the
'cr_lf_return' field in the 'term' variable currently is ignored
completely. PuTTY takes it into account for input (where Return should send
CR LF when LNM is set), but not for output. The VT100 description at
http://vt100.net/docs/vt100-ug/chapter3.html requires it for both though,
so this will need a look at the rxvt and xterm implementations.

PuTTY's dialog framework supports accelerator keys, but MinTTY does not
currently use them.

At 9pt the default font size is a bit on the low side.

I'm very impressed with MinTTY, but I've noticed that extended ascii 
characters don't print correctly.  In my .vimrc I have:

execute 'set 
listchars=tab:'.nr2char(187).nr2char(183).',trail:'.nr2char(183).',extends:
>,precedes:<'

The nr2char commands display '%' as opposed to the characters that they are 
supposed to display.

As Robert Pendell pointed out, Cygwin 1.7 stores its mount points in
/etc/fstab rather than the Windows registry. As a consequence, reading
"HKLM\Software\Cygnus Solutions\Cygwin\mounts v2\/\native" to find the
cygwin root directory no longer works. Instead, it can now be found in
"HKLM\Software\Cygwin\setup\rootdir".

I don't think this needs to be addressed just yet though (and perhaps never
if MinTTY gets a Cygwin package). 1.7 is still a more or less private beta,
and anyone trying it already should be more than able to point MinTTY
towards the correct Cygwin DLL. Including a separate script for 1.7 in the
binary distribution might just confuse matters unnecessarily.

When selecting words with a double left click, the tilde character is not
considered part of filenames. The character categories might need a wider
review.

I would like to have something, when the application is up and running, to 
see what version I am using.

I'm sure a few other items could be added as well, such as a link to this 
project site.

Typing characters with Alt+numpad codes doesn't work. That's because I
haven't yet (re)implemented it.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

When MinTTY is invoked without a command, the user's default shell is
started as a non-login shell. It would be nice to be able to do that
without having to explicitly invoke the shell (as in "/bin/bash -li").

Currently the same alpha value is applied to the whole window, including
text and window frame. This is done rather simply by turning the window
into a "layered" window and setting it LWA_ALPHA attribute.

It would look better though if only the background was transparent, which
could be done using UpdateLayeredWindow() and an appropriate BLENDFUNCTION.
Trouble is, the standard controls don't work with that, so that a custom
scrollbar and the window controls would need to be implemented. This would
be far too much bother for what it's worth though, so it ain't gonna happen.

Vista's "Desktop Window Manager", however, might make this more doable.
Here's a blog that explains it:

http://weblogs.asp.net/kennykerr/archive/2006/08/10/Windows-Vista-for-Developers
-_1320_-Part-3-_1320_-The-Desktop-Window-Manager.aspx

What steps will reproduce the problem?
1. start vi (possibly any curses based interactive application) in minTTY.
2. enter insert mode
3. paste a multi-line buffer

What is the expected output? What do you see instead?
Expected: all lines of paste appear in vi
Actual: only the first line appears

What version of the product are you using? On what operating system?
minTTY 0.3.0, Windows Vista

Please provide any additional information below.
The paste_hold (variable) mechanics in minTTY require that the console
application push an EOL (either CR or LF) to the terminal to signal
successful completion of the partial (single line record) paste.  Only
after this signal does the paste continue with the next line record.  While
this works at the commandline where the bash (or any other) shell is
expected to honour a CR/LF input by emitting the same, under curses this is
not expected behaviour.  Under curses, the terminal may never get an EOL
but instead get cursor position movement sequences.

Some experimentation suggests that paste_hold can simply be disabled and
correct behaviour under curses is achieved.  However, this results in a
slight loss of input-to-output synchronization under a normal (bash) shell
prompt.  That is: the original behaviour using paste_hold provides a
throttling mechanism that better preserves the correlation of a single line
of input to its output.  Ideally, if the terminal could detect that it was
being driven by curses through some sort of ioctl/stty setting, the
paste_hold mechanism could be conditional upon that.

When sending one of the process terminating signals (TERM, KILL, HUP, INT)
to MinTTY, it will not exit immediately, waiting for the next keypress instead.

The reason for that is that Win32 functions are not interruptible by
signals in Cygwin and MinTTY spends most of its time in
MsgWaitForMultipleObjects().

Compatibility with the 'SCO ANSI' terminal emulation is on by default,
which among other things causes a ^L output character to be interpreted as
a formfeed rather than a linefeed as with DEC terminals and xterm.

On XP with transparency on and the "Disable transparency when active"
option set, there's a noticeable flicker when a transparent window loses or
gains focus.