2016-05-21 1:35 GMT+03:00 Tony Mechelynck <antoine.mechelynck@gmail.com>:
> On Sat, May 21, 2016 at 12:00 AM, Nikolay Aleksandrovich Pavlov
> <zyx.vim@gmail.com> wrote:
>> 2016-05-20 23:03 GMT+03:00 Tony Mechelynck <antoine.mechelynck@gmail.com>:
>>> On Wed, May 18, 2016 at 4:48 PM, Nikolay Aleksandrovich Pavlov
>>> <zyx.vim@gmail.com> wrote:
>>>> 2016-05-18 14:08 GMT+03:00 Igor Forca <igor2x@gmail.com>:
>>>>> Hi,
>>>>> I really like to use big fonts in my gVim 7.4 on Windows 7. But time to time I would like to have smaller font size, to actually see bigger picture (without need to move up or down).
>>>>>
>>>>> In this case I would like to create key mapping CTRL and minus to shrink font and CTRL and plus to set it back to normal. Something very similar is used in a lot of programs like in Firefox (to zoom up/down).
>>>>>
>>>>> What I have figure it out I can set the following:
>>>>> nnoremap <C-x> <Esc>:set guifont=Consolas:h9:cDEFAULT<CR>
>>>>> nnoremap <C-y> <Esc>:set guifont=Consolas:h15:cDEFAULT<CR>
>>>>>
>>>>> and works fine, but instead of C-x and C-y I would like to set C-- and C-+
>>>>> like:
>>>>> nnoremap <C--> <Esc>:set guifont=Consolas:h9:cDEFAULT<CR>
>>>>> nnoremap <C-+> <Esc>:set guifont=Consolas:h15:cDEFAULT<CR>
>>>>>
>>>>> But when pressing CTRL and minus nothing happens, the same with CTRL and plus.
>>>>> It looks like there is something else going on. How to debug this problem? How to map "CTRL and minus" and "CTRL and plus" to above setting?
>>>>
>>>> You cannot use modifiers with any non-ASCII character and some of the
>>>> ASCII ones: namely those that do not live in range 0x40 .. 0x5F: i.e.
>>>> from `@` to underscore; . The single exception are special keys like
>>>> F1..F12, arrows, etc. So `<C-->` is probably `<C-_>`, but `<C-+>` will
>>>> not work, this is by design (problem is internal representation of
>>>> those keys and legacy from the days when Vi supported ASCII-only
>>>> terminals, modern terminal emulators *still* not supporting more key
>>>> combinations makes this issue even harder because it narrows down a
>>>> number of people who need this fixed; strange, but `:echo "\<C-+>"`
>>>> yields something which looks like special internal representation of
>>>> `<C-+>`, but still this key combo is not going to work). Neovim has
>>>> wider support of such key combinations, but AFAIR its Windows build is
>>>> still experimental (and I do not know about GUI).
>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>
>>>
>>>
>>> What might work is to use Alt instead of Ctrl. The usual result
>>> (depending on your terminal settings) is that Alt sets the 0x80 bit on
>>
>> OP mentions gVim. So terminal settings are not involved. Do not know
>> how `<A-` is encoded there, but `:echo "\<A-t>"` producing U+00F4
>> (note: *not* 0xF4 byte) (&encoding is utf-8) suggests that it would be
>> again handled in a strange fashion.
>>
>>> printable keys, so that <A--> maps to 0xAD or U+00AD which is (in
>>> Latin1 and in UTF-8) the soft-hyphen, and <A-+> maps to 0xAB or U+00AB
>>
>> 0xAD byte is *not* U+00AD in UTF-8. U+00AD in UTF-8 is 0xC2 0xAD. Same
>> for U+00AB.
>
> I didn't mean U+00AD was single-byte 0xAD in UTF-8; indeed, the latter
> is illegal alone. I meant Alt adds (or, I think, ORs) a 0x80 bit,
In terminals (depending on the configuration) it indeed may do OR
0x80, resulting in a *byte* 0xAD. Depends on the terminal and its
setting: e.g. xterm may send any of <Esc>-, 0xAD byte and U+00AD,
depending on its settings and locale. I do not understand why gVim
have chosen to use U+00AD, but AFAIR that was discussed a few times.
> changing the minus sign to 0xAD in Latin1 or U+00AD in UTF-8: when I
> hit Alt-minus in Insert mode in my gvim instance (X11 Huge with
> GTK2/Gnome2), with 'encoding' set to utf-8, I get U+00AD: ga answers
> "< > 173, Hex 00ad, Octal 255" and g8 answers (as you noticed) "c2
> ad". For the record, if instead of Alt-minus I hit Ctrl-V followed by
> Alt-minus I get exactly the same. So I expect that <A--> and <A-+>,
> when sourced in the {lhs} of a :map instruction after having made sure
> that 'encoding' is UTF-8 and that 'nocompatible' is set (the latter
&compatible setting is almost never checked by Vim. (Un)setting it
triggers setting other settings, which are being checked, but still
you can always have &compatible==1 and make Vim behave like
&compatible==0 most of time (:set-& and :version will still behave
slightly differently and scrolling back with more-prompt will be
disabled). The recognition of <…> keys is enabled/disabled by a flag
in &cpoptions, not by &compatible.
> for the <> mappings), would be stored internally as U+00AD and U+00AB
> respectively, and recognized correctly when hit in Normal mode later
> on.
>
>>
>>> which is the opening French quote. AFAIK neither of these collides
>>> with anything useful in Normal mode, but in Insert mode your text
>>> writing habits may (or may not) call for soft-hypens and/or French
>>> quotes.
>>>
>>> Best regards,
>>> Tony.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment