{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":7196253,"defaultBranch":"master","name":"vim-rsi","ownerLogin":"tpope","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2012-12-16T22:38:18.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/378?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1613519273.505343","currentOid":""},"activityList":{"items":[{"before":"4c673fb6c70652a09682c50a0e308184731ca70b","after":"45540637ead22f011e8215f1c90142e49d946a54","ref":"refs/heads/master","pushedAt":"2023-04-30T14:35:16.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"tpope","name":"Tim Pope","path":"/tpope","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/378?s=80&v=4"},"commit":{"message":"Support meta maps with modifyOtherKeys\n\nSome terminals, including xterm and iTerm, contain support for alternate\nescape sequences for meta keys presses.  For example, Meta-a, normally\nencoded as \"<Esc>a\", is instead encoded as \"<Esc>[27;3;97~\", where \"3\"\nmeans \"meta\", and \"97\" is the ASCII decimal representation of \"a\".  Our\n\":set\" hack won't catch these; we need the native \"M-\" map.\n\nThe rub is that Vim internally represents meta key combos as the regular\nASCII character with the 8th bit set.  For example, since ASCII \"a\" is\n0x61, <M-a> is 0xE1, which in UTF-8 is encoded as 0xC3 0x81.  But in\nUnicode, \"á\" is also character U+00E1, which means any map of <M-a> will\nalso trigger upon typing \"á\".\n\nHowever, if we define the map in another encoding, the key combo gets\nencoded as a different sequence of bytes.  For example, in the latin1\nencoding, we get the simple 1 byte sequence of 0xE1, which doesn't\nconflict with \"á\", but does conflict with, among other characters,\nU+1E05, aka \"ḅ\", which in UTF-8 is encoded as 0xE1 0xB8 0x85.\n\nSo what's a locale that won't give us a conflict?  If we start with the\nlist at `:help encoding-values` and eliminate anything 8-bit or Unicode\nderived, we're left with a handful of options, most of which are flagged\nas \"Windows only\" or \"Unix only\".  The Korean encoding cp949 is listed\nas supporting both platforms, and encodes <M-a> as 0x80 0xFC 0x08 0x65.\nThis is not a valid UTF-8 sequence, even if we start mid-character, so\nit should serve our needs perfectly.\n\nShout out to Neovim for doing what Vim should have done 15 years ago and\nfixing this positively archaic quirk.","shortMessageHtmlLink":"Support meta maps with modifyOtherKeys"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAADIzS-cwA","startCursor":null,"endCursor":null}},"title":"Activity · tpope/vim-rsi"}