Alternative Keystroke generation

[Tom Feist]

Hi all,

I've recently been playing with libtermkey (http://www.leonerd.org.uk/code/libtermkey/
) and discovered
that, like a lot of terminals, quite a few key-combinations are
impossible to detect because they all
send the same sequence of bytes.

I ended up chatting with the author of the library, who has a proposal
to fix this particular problem
written up here: http://www.leonerd.org.uk/hacks/fixterms/

I'm curious as to what others, especially the devs, think about
supporting such a specification (which
is why I'm posting to the list and not just making it an Issue)

As long as we maintain backwards compatibility, or offer the choice
via some sort of config option, I
think it would be extremely beneficial to have the ability to
distinguish between various keycombos
hitherto impossible to detect.

I welcome your thoughts on the matter,

--Tom

[George Nachman]

Hi Tom,

I think this is a great idea. Does it work well in practice? Is it
being adopted by other terminal emulators?

There would probably be too many keybindings to try to define every
one individually, but I think it would be a fairly straightforward
code change. Please file a feature request for it.

On Sat, May 7, 2011 at 7:14 PM, Tom Feist <sha...@gmail.com> wrote:
> Hi all,
>
> I've recently been playing with libtermkey

> (http://www.leonerd.org.uk/code/libtermkey/) and discovered

[Pelle Johansson]

I also thinks it sounds nice, except that I really think C1 should be avoided wherever possible.
There's still a lot of other encodings in use except for UTF-8. Windows latin 1 encodes € (euro) as 0x80 for example.
Also, I've actually started pressing escape then ., escape then d etc. on keyboards with no meta key.

But I guess this isn't really the forum to discuss the specifics.
--
Pelle Johansson

[George Nachman]

I've read the doc a few times and I don't see how he's proposing to use C0 and C1, except that he notes their existence and usability. Where is it in the protocol?

[Tom Feist]

Hey,

Returning to this topic, I've made a bit of progress on implementing
the 'fixterms' ideas, Thanks to George merging my patches for
arbitrary bookmark keybinding presets, it's now possible to create a
preset that implements the specification (well, mostly. I might have
missed a bit). <url:http://www.leonerd.org.uk/hacks/fixterms/> -- a
reminder of what I'm talking about.

It's primarily generated by the script at <url:https://github.com/
shabble/iTerm2/blob/fixterms/generate-fixterms-mappings.pl>

there's also a pre-built Presets file at <url:http://metavore.org/faff/
PresetKeyMappings.plist> (which should be placed in the /Applications/
iTerm.app/Contents/Resources/ dir) if anyone wants to fiddle.

My next job is going to be to start making applications aware of the
new bindings. Irssi is my first target, because I use it heavily and
I could really do with the extra keyspace, but in theory it could be
implemented in the readline lib and then many things would be able to
use it by default.

Cheers,

Tom.

[George Nachman]

Thanks, Tom! Once there are some apps that support this feature, we'll need to document how to use it.

Another consideration would be to add a custom escape sequence to change keyboard mappings when entering/exiting programs that support fixterms.

[Tom Feist]

Yeah, having an escape to swap between presets would be pretty cool.
I think we'd need a way to save presets as well though - at the moment
they obliterate everything that's already there, so the only way to use
them is to generate the plist manually, as my script does.

Actually, additional keys can be added after loading the preset, but I'm
half wondering if there should be some sort of confirmation dialog (or
undo)
when selecting a preset, since it does clean out your whole key-
profile. I've
done that accidentally more than once while testing the loading code.

Cheers,

Tom

[George Nachman]

This can become complicated! The spectrum of possibilities I see are

1. What we have today

2. Undo selection of a keys preset

3. Allow users to save their current keymappings as a new preset

4. Full import/export functionality for keys presets, as we have with colors

Undo is probably a good fit for the current level of demand, but it would be difficult for users to discover.

On Sun, May 29, 2011 at 10:06 PM, Tom Feist <sha...@gmail.com> wrote:

Yeah, having an escape to swap between presets would be pretty cool.
I think we'd need a way to save presets as well though - at the moment
they obliterate everything that's already there, so the only way to use
them is to generate the plist manually, as my script does.

Actually, additional keys can be added after loading the preset, but I'm
half wondering if there should be some sort of confirmation dialog (or undo)

when selecting a preset, since it does clean out your whole key-profile.  I've

[Tom Feist]

Well, Cmd-Z is quite a well-known binding, and there's already undo/
redo items in the
mainmenu -> edit section. I know a lot of people hate confirmation
dialogs, and instinctively
dismiss them, but a "Loading this preset will erase all of your
current key mappings. Are you sure
you want to continue? Yes | No". would go at least a little way
towards preventing accidents.
(We can always make it a hidden 'defaults write' option if people
complain, but I think it's a rare
enough action that it won't cause that much bother)

I think in the long term it'd be nice to be able to save keybindings
independently of bookmarks,
like the colour settings, but I'm not sure I'm experienced enough yet
to write it. I'll maybe have
a go and try to clone the colour approach.

Do we have an easy way of generating confirmation dialogs? I seem to
recall seeing something like that
in the source, but I can't find it now, which is bugging me.

On a completely unlrelated note, the project dir is getting pretty
huge and disorganised, I'm wondering how
hard it would be to build some sort of subdir-modular structure,
although I have no idea how xcode would deal
with it. You can 'group' things there, but that doesn't seem to do
anything at all about their actual
filesystem location.

--Tom.

[George Nachman]

I think in the long term it'd be nice to be able to save keybindings independently of bookmarks,
like the colour settings, but I'm not sure I'm experienced enough yet to write it.  I'll maybe have
a go and try to clone the colour approach.

Cmd-Z would work, but I just don't think people expect to use it in that kind of setting. I think a confirmation dialog (including a "never show this again' button) is OK: I believe most people use this UI at most one time. When there are more interesting options in the menu, we can revisit import/export.

 

Do we have an easy way of generating confirmation dialogs? I seem to recall seeing something like that
in the source, but I can't find it now, which is bugging me.

Have a look at _maybeWarnAboutMeta in PreferencePanel.m. I suppose a bit of refactoring is in order here, too, as there are already two very similar functions.

 

On a completely unlrelated note, the project dir is getting pretty huge and disorganised, I'm wondering how
hard it would be to build some sort of subdir-modular structure, although I have no idea how xcode would deal
with it.  You can 'group' things there, but that doesn't seem to do anything at all about their actual
filesystem location.

Yeah, the code has gotten a bit sprawling. One can create subdirectories and add them to XCode and it'll show up in the file hierarchy like it looks on disk. I think the right organization would be something like:

Profiles

  BookmarkListView

  BookmarkModel 

  BookmarksController 

  BookmarksWindow

  ITAddressBookMgr

  iTermTerminalProfileMgr 

Popups

  Autocomplete

  PasteboardHistory 

  Popup 

Search

  FindCommandHandler 

  FindView 

  FindViewController 

  iTermSearchField 

GTM

  GTM*

Expose

  GlobalSearch

  iTermExpose 

DVR

  DVR

  DVRBuffer 

  DVRDecoder 

  DVREncoder 

  DVRIndexEntry 

Window

  FakeWindow

  PTToolbarController

  PTYWindow 

  PseudoTerminal 

  PTYTab 

  PTYTabView

Misc

  ITViewLocalizer

  NSDateFormatterExtras

  NSStringITerm 

Session

  LineBuffer

  LineBufferTest

  PTYScrollView 

  PTYSession 

  PTYTask 

  PTYTextView 

  ScreenChar 

  SessionView 

  TextViewWrapper 

  Trouter 

  VT100Screen 

  VT100Terminal 

Prefs

  PreferencePanel 

App

  ProcessCache

  iTermApplication 

  iTermApplicationDelegate 

  iTermController 

  iTermGrowlDelegate 

  iTermKeyBindingMgr 

  main

There are a few files that need to be split up: PreferencePanel.m, PseudoTerminal.m, PTYTextView.m, and iTermControlller.m are the first that come to mind.

This is something that's on my "to do when I have nothing more pressing list", and it's been there for a while :)

[Tom Feist]

Well, I'm happy to try and sort it out if you like. Keep your eyes
peeled for Pull Requests. :)

[George Nachman]

Thanks, Tom! Let me start a 1.1 branch for these changes; it's a bit more risk than I want in the 1.0 release which is (I hope) coming soon.

[George Nachman]

I added a branch called "dev". Not sure how pull requests work from your end, but let's keep anything that isn't bug-fixes in that branch until 1.0 is out. Not sure if the pull req you sent for the bouncing dock feature can be pulled into the dev branch?

[George Nachman]

From the department of "better late than never": I have added support for libtermkey/libtickit/CSI u into the nightly build. Enable **Prefs>Profiles>Keys>Report modifiers using CSI u**.