search

EgorMaksimov / mintty

Automatically exported from code.google.com/p/mintty
GNU General Public License v3.0
0 stars 0 forks source link

Scroll directly using Page Up/Down (without pressing Shift) #166

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I tried to use *VT100.translations: #override
in ~/.Xdefaults / ~/.Xresources file, but was unable to do this.

Original issue reported on code.google.com by sidda...@gmail.com on 1 Mar 2010 at 2:39

GoogleCodeExporter commented 8 years ago 
Now probably i understand why it did not work. Because .Xresources is 
applicable to 
Xserver / Xclient scenario and mintty is not an Xclinet (as rxvt is)!

Original comment by sidda...@gmail.com on 2 Mar 2010 at 2:12

GoogleCodeExporter commented 8 years ago 
Yep, so you're essentially asking for a new option, which I always try to avoid 
unless 
there's very good reason, in order to keep complexity down.

PgUp/Dn were part of the VT220's keyboard (as "Prev Screen" and "Next Screen"), 
sending 
escape sequences. Holding down Shift to scroll instead seems straightforward 
and is 
more or less standard across different terminal emulators. So do you have any 
particular reason to prefer plain PgUp/Dn for scrolling?

Original comment by andy.koppe on 3 Mar 2010 at 5:59

GoogleCodeExporter commented 8 years ago 
I am really not aware that it will increase the complexity.

Actually i was using dtterm on solaris which uses PgUp/Dn for scrolling, and 
wanted to 
have same functionality in mintty...(no particular reason except i am used to 
of that)

Hence i was looking for a way to override the key mappings in mintty in the 
same (or 
different) way xterm provides.

Original comment by sidda...@gmail.com on 3 Mar 2010 at 6:13

GoogleCodeExporter commented 8 years ago 
There is nothing similar to VT100.translations in mintty. Full keyboard
customisability would certainly involve a lot of work and added complexity. So 
no, I
don't plan to add that.

And while a specific option for your request wouldn't by itself make much 
difference,
these little options do add up, increasing UI complexity and making it more 
likely
that bugs are overlooked.

Anyway. If a choice of 'None' was added to the scroll modifier option, what 
should
happen to line-by-line scrolling (normally Shift+Up/Down) and jumping to the 
start or
end of the scrollback (Shift+Home/End)? I guess you'd still want plain Up/Down 
and
Home/End to be sent to the shell?

Original comment by andy.koppe on 4 Mar 2010 at 6:12

GoogleCodeExporter commented 8 years ago 
Yes :-)

Andy, could you give me some pointers where to make changes in source code to 
have this 
functionality? I want to give it a try...

Original comment by sidda...@gmail.com on 4 Mar 2010 at 4:37

GoogleCodeExporter commented 8 years ago 
Grep for 'scroll_mod'.

Original comment by andy.koppe on 4 Mar 2010 at 6:24

GoogleCodeExporter commented 8 years ago 
I looked into this a bit more. Googling didn't turn up significant demand for 
this in 
other terminals, except from some other ex-dtterm users on Gnome/Solaris. 
Interestingly though, Apple's Terminal.app does the same thing as dtterm: 
PgUp/Dn 
scroll by a page at a time, whereas Home/End jump to the top/bottom of the 
scrollback. But that results in regular complaints such as this: 
http://bryanpearson.com/blog/2010/02/os-x-terminal-fix-home-end-page-up-page-dow
n-
keys

Obviously this wouldn't be the default in mintty anyway, but nevertheless I 
just 
don't think it's good UI design. It's inconsistent to treat the arrow and the 
page 
up/down keys so differently. It's wrong not to send PgUp/Dn, which are standard 
terminal keys, to the application. It's a shame not to have line-by-line 
scrolling. 
And the Home/End behaviour conflicts with Windows and Linux standards.

So unless there's significant additional demand for this, I won't implement it.

Original comment by andy.koppe on 6 Mar 2010 at 5:40

GoogleCodeExporter commented 8 years ago 
Reopening at priority 'None' to see whether there's more demand inspite of my 
misgivings.

And repeating an earlier question: if this was to be implemented, what should 
Home and 
End do? I read that in dtterm and Terminal.app they jump to the top and bottom 
of the 
scrollback. Apparently that's standard behaviour at least in MacOS, but of 
course on 
Windows the standard behaviour is to go to the start or end of the current line.

Original comment by andy.koppe on 10 Mar 2010 at 8:31

GoogleCodeExporter commented 8 years ago 
To me scrolling pages is quite frequent operation, hence I want only PgUp/PgDn 
to map 
to scrolling directly.

And yes, I also believe the behaviour of Home/End/Up/Down should be as per 
Windows 
standard (send to shell)

Original comment by sidda...@gmail.com on 11 Mar 2010 at 6:25

GoogleCodeExporter commented 8 years ago 
Decided to implement this after all, in r846 on trunk.

Removing the "Access scrollback from alternate screen" option as part of issue 
174 
removed the awkward question about whether Page Up/Down should be sent to the 
application or scroll the scrollback buffer when that option was enabled.

With the new "Page Up/Down scroll without modifier" option enabled, Page 
Up/Down key 
presses scroll when on the primary screen, but they're sent to the application 
when 
on the alternate screen. This means that scrolling in the likes of less, vim or 
emacs 
continues to work as before. When on the primary screen, Page Up/Down can still 
be 
sent to the application by holding down the scroll modifier (Shift by default).

As discussed, the option does not affect the arrow keys or Home/End.

Original comment by andy.koppe on 18 Apr 2010 at 5:25

GoogleCodeExporter commented 8 years ago 
Thank you very much Andy!!!

Original comment by sidda...@gmail.com on 19 Apr 2010 at 4:07

GoogleCodeExporter commented 8 years ago

Original comment by andy.koppe on 3 May 2010 at 7:44