RE: Unsubscrible vim_dev
I have subscrible the list with new gmail box. But I can't unsubscrible the list with my current work mail box. I have sent the vim-dev-unsubscr...@vim.org the empty mail message many times, but have no any effect. So other managers don't have to look, I have done the unsubscribe. But what if he didn't want to unsubscribe, but wanted to unscribble? :) Sorry for my poor english, but I can still receive mail from the list. Please help me to unsubscribe! Thansk. -- You received this message from the vim_dev 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
Re: patch for strong encryption in vim, resending patch for vim7* dev branch.
On Tue, May 4, 2010 at 3:59 AM, Chris Sutcliffe ir0nh...@gmail.com wrote: On 4 May 2010 00:23, Patrick Texier wrote: On Mon, 3 May 2010 13:23:48 -0700, Mosh wrote: No more problems, it works on window32 bit (XP with VC60) and linux 64 bits gcc, ones I tested on. I'm waiting a patch for Borland C++ 5.5.1. I had a problem with a 64-bits integer type declaration. Can you send me the last version, please? If you could send it to the list it would be greatly appreciated, since I would like to test it with MinGW. The typedef error in sha2.h with borland bcc 551 was easy to fix, BUT borland bcc 551 is generating different code causing sha2 self test to fail. I will debug sha2 self test in borland. It is small enough but bunch of nasty macros to manipulate bits. I may replace the file sha2.c with another more portable version of the code as a last resort. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- You received this message from the vim_dev 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 from the vim_dev 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
Re: Keyboard input handling
On Tue, May 4, 2010 at 8:14 PM, Tom Sorensen wrote: On Tue, May 4, 2010 at 7:14 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: Over the past 7 years, I have been a member of the #vim channel on Freenode. Almost every week we get somebody in the channel who wonders such things as how to map Ctrl-Shift-T differently from Ctrl-T. We explain that isn't possible. Even in Gvim. Actually, he's understating it. We usually get at least two people a week. Several people a day isn't too uncommon. A lot of this is because vim has already used pretty much every non-shifted key on the keyboard -- you're left with either replacing default functionality (which I don't like suggesting) or using Leader based combinations (which I'm fine with, to a certain extent, but many others are not). I'd be certain that the average is at least 2 or 3 people a day - many of the IRC regulars have seen this question get asked multiple times in one day, and we're not on for 24 hours - usually more like 2 or 3. And let's not forget how often it comes up on the mailing list - A quick search over the last ~1 year shows the below list of threads that all amount to you can't map that in vim. I emphatically agree that vim's keyboard handling is one of the ugliest parts of the editor; something definitely needs to be done to bring vim back up on par with other GUI tools. ~Matt Mapping Shift-space: how to tell if its possible? How to imap C-= ? CTRL+W under MS Windows map a-h on win32 (Win XP) gvim 7.2 in french layout work incorrectly accent grave in french(France) keyboard layout is not printing. win32 (Win XP) Platform why nmapA-0 not work? map a-h on win32 (Win XP) gvim 7.2 in french layout work incorrectly What is Alt-T supposed to do by default? Mapping ctrl-; (ctrl semicolon) mapping problems How to map Ctrl+/ ? mapping alt-keys add mapping to auto-fill Binding Ctrl+Tab and Ctrl+Shift+Tab difficulties with Vim and PuTTY. Bugging me for a long time Can't :imap S-space How to map Alt+key when using vim in putty How to get Alt-[ in putty terminal How to map ctrl-del to delete word? how to map tab and c-i independently How to map key shift+ctrl+N? I can't remap Shift-F4 key Insert Mode Mappings on a Mac map! C-= C-ogt and map! C-- C-ogT Don't work map command, ctrl-v and .vimrc map C-J C-Wj not operate...help.. mapping control+0-1 or backtick Maping Ctrl-Shift-s problems Mapping shift-space Mappings to shift-keys within terminal mode Mappings for tab navigation don't work Tab and C-i will clash in mappings unable to map ctrl-1 Unable to map Ctrl+Shift+Z Strange behavior with Key Maps -- You received this message from the vim_dev 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
RE: Unsubscrible vim_dev
Simson Liu wrote: I can still receive mail from the list. I have tried again, and have responded directly to Simson. I'm just replying here to let others know that I have acted. John -- You received this message from the vim_dev 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
Re: Keyboard input handling
On May 5, 1:14 am, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: Vim's keyboard input system revolves centrally around a queue of bytes. This worked well when all the world was serial terminals. In this new world of GUIs this model doesn't work so well. I advocate changing it to a queue of keypress events. [...] FWIW: I wholeheartedly support this feature, and would make myself available for implementation and testing, if someone with the ability to see it through takes the lead. Henrik -- You received this message from the vim_dev 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
Re: Keyboard input handling
On May 4, 6:14 pm, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: Vim's keyboard input system revolves centrally around a queue of bytes. This worked well when all the world was serial terminals. In this new world of GUIs this model doesn't work so well. I advocate changing it to a queue of keypress events. I know next to nothing about the termcap/terminfo/etc. code or what is involved in such a change, and do not have the time currently to start delving into Vim's C code (sometime soon, I keep telling myself) but I would certainly be willing to test on Windows XP and Vista, even to the point of learning how to compile my own Vim on these systems so that I can try out the patches. I have a Ubuntu system at home but don't get many chances to use it; I image we'll have a plethora of testers on such systems though. -- You received this message from the vim_dev 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
Re: Keyboard input handling
Original-Nachricht Datum: Wed, 5 May 2010 00:14:06 +0100 Von: Paul LeoNerd Evans leon...@leonerd.org.uk An: vim_dev@googlegroups.com Betreff: Keyboard input handling Vim's keyboard input system revolves centrally around a queue of bytes. This worked well when all the world was serial terminals. In this new world of GUIs this model doesn't work so well. I advocate changing it to a queue of keypress events. [...] I could test it on Ubuntu 10.04 and Mac OS X 10.6. Would this change also handle special keys found on some keyboards? I could test with some different keyboards. HTH, Dennis Benzinger -- You received this message from the vim_dev 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
Re: Keyboard input handling
On Wed, May 5, 2010 at 11:20 AM, Ben Fritz wrote: On May 4, 6:14 pm, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: Vim's keyboard input system revolves centrally around a queue of bytes. This worked well when all the world was serial terminals. In this new world of GUIs this model doesn't work so well. I advocate changing it to a queue of keypress events. I know next to nothing about the termcap/terminfo/etc. code or what is involved in such a change, and do not have the time currently to start delving into Vim's C code (sometime soon, I keep telling myself) but I would certainly be willing to test on Windows XP and Vista, even to the point of learning how to compile my own Vim on these systems so that I can try out the patches. I have a Ubuntu system at home but don't get many chances to use it; I image we'll have a plethora of testers on such systems though. I've got access to xterm on HP-UX, AIX, and Solaris 9 and 10 - nothing too exotic, but I can help test there - and in Linux with fbiterm, which is pretty exotic as far as terminal emulators go these days. ~Matt -- You received this message from the vim_dev 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
Re: Keyboard input handling
Paul LeoNerd Evans wrote:
Vim's keyboard input system revolves centrally around a queue of bytes.
This worked well when all the world was serial terminals. In this new
world of GUIs this model doesn't work so well. I advocate changing it to
a queue of keypress events.
Over the past 7 years, I have been a member of the #vim channel on
Freenode. Almost every week we get somebody in the channel who wonders
such things as how to map Ctrl-Shift-T differently from Ctrl-T. We
explain that isn't possible. Even in Gvim. Because of vim's input queue
system. People often don't realise that Tab is Ctrl-I, or Enter is
Ctrl-M. We have to explain why it's not possible to map one of these
pairs without breaking the other. It's become apparent to me that the
byte-based model is no longer appropriate if Vim is to remain relevant
and current on newer platforms. It's time we changed the core.
That's not completely correct. Vim can have a key modifier in the
queue, it can have CTRL and SHIFT before a T. It's a design choice to
have CTRL-SHIFT-T and CTRL-T result in the same code. See the global
variable mod_mask.
It's possible to make a difference between the two when there is a
mapping for CTRL-SHIFT-T. I actually thought that was working, but it
doesn't. Perhaps this only works in combination with Alt, don't have
time right now to check the details.
I would like to propose that the base of the input queue be turned into
a queue of structures something like the following form:
struct keypress {
enum {
UNICODE,
SPECIAL,
} type;
int keycode;
int modifiers;
};
In this scheme we can represent any of the keypresses vim can handle:
A= { .type = UNICODE, keycode = 'A', .modifiers = 0 }
Ctrl-T = { .type = UNICODE, keycode = 'T', .modifiers = CTRL }
Enter = { .type = SPECIAL, keycode = ENTER, .modifiers = 0 }
In this scheme, it is simple to write the code that :map etc.. will use
to recognise the keys and turn them into basic operations. It's also
simple to generate these events from GUI events (such as from GTK or
Win32).
This scheme is also relatively simple to generate from terminal input
bytes, since vim already has this functionality.
Once using this scheme, gvim would now fully support mapping Tab, Ctrl-I
and Ctrl-Shift-I as three separate independent keys. Newer terminals
like xterm already posess ways to encode these three keystrokes
differently at the byte level, and with e.g. libtermkey[*]'s help, vim
could be taught how to recognise all these three too.
I think this is possible without changing the input queue.
In recognition of the non-trivial amount of work required here, and as a
token of my commitment to this issue, I would be happy to donate a
further EUR100 to the vim development sponsorship on top of the EUR20 I
have just sent, if we could come to a mutual agreement on how to proceed
on this front. It would be great if we would be able to make this
feature a reality; I would be happy to consider a further donation at
that point.
I know this isn't the way terminals have worked for the past 20 years.
However, it is the way terminals, being the units of end-user
interaction, will work for the next 20 years. It would be nice if vim
were able to cope as well with the next 20 as it has with the last.
-
*: I have also been developing a library, libtermkey, which aims to be
a better way to read key press events from terminals than existing
solutions that are curses or terminfo-based. While it reads the
terminfo database, it also fully understands the extended ways that
xterm et.al. encode modified keypresses, in a way that would be
fully compatible with vim's core, and existing behaviours.
http://www.leonerd.org.uk/code/libtermkey/
Now that sounds like a long awaited improvement. The termcap/terminfo
system is completely inadequate. Vim must have xterm special key
support built-in, since there is no way to define these keys with the
old libraries.
It would be great if someone can make a patch for Vim that uses this
library and is fully backwards compatible for the special xterm keys
codes. That would be a good test for the library as well.
--
hundred-and-one symptoms of being an internet addict:
23. You can't call your mother...she doesn't have a modem.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the vim_dev 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
inputdialog with lots of text expands past window boundaries
Vim 7.2.411 Windows 7 64bit Windows XP SP3 Both have nVidia cards (though different). I also have my TaskBar at the TOP of my screen since I extend my monitor above my laptop. The TaskBar is also 2 rows deep. This introduces some additional undesirable behaviour. I am issuing an inputdialog with lots and lots of data with newlines. echo inputdialog(a\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\na\nb\nc\n) On XP things are _almost_ correct. 1. A dialog is opened and positioned with the title of the dialog box underneath the Taskbar, so I can't actually click on the title of the bar to move it. The bottom of the dialog is at the bottom of the screen and is correct. 2. A dialog is opened with a scrollbar, which allows me to scroll through all the item and read them. On Windows 7 (64bit), things are much worse. 1. A dialog is opened and positioned with the title of the dialog box underneath the Taskbar, so I can't actually click on the title of the bar to move it. The bottom of the dialog extends beyond the bottom of the screen. 2. The dialog is opened withOUT a scrollbar, so you cannot see all of the items in the dialog. In both cases, whatever you call the top LEFT of the Window, which you can click on (or ALT-Space) to get the menu: Restore Move Size Minimize Maximize Close Does not exist on the dialogs, so you cannot use ALT-Space M, to use the cursor keys to move the dialog (like I frequently do with all other Windows) when this happens. Can anyone else confirm this behaviour? Any suggestions on a fix? Much appreciated. Dave -- You received this message from the vim_dev 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
Possible bug when side scrolling
In the following, these Unicode characters are used:
\u200e = 'LEFT-TO-RIGHT MARK' (U+200E)
\u2013 = 'EN DASH' (U+2013)
On my 7.2.411 system, the following commands show a bug:
gvim -u NONE
:set columns=96 nowrap encoding=utf-8
:$put =repeat('a',50) . nr2char(0x200e) . repeat('b',40) . 'ABCDE'
The first command sets some options that I have in my vimrc.
The second command appends a line of 96 characters.
Press $ to jump to the last character of that line ('E').
Note that cursor is positioned a few characters AFTER 'E'.
Type ga to view code for character under cursor ('E').
Type FA (go back to 'A') to show a similar problem.
Enter ':set columns=80' then press $ (result: works ok).
If replace 0x200e with 0x2013, there is no problem.
I imagine the code for side scrolling is not accounting for
the fact that U+200E is displayed as 200e (six characters).
John
--
You received this message from the vim_dev 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
