Re: Konsole: lost focus of window or tab
On 1/17/07, Matthew Woehlke [EMAIL PROTECTED] wrote: Mikolaj Machowski wrote: Is it possible to recognize if window or tab of Konsole lost focus through termcap/terminfo sequence? Or is it at least possible with dcop or any other way? I am investigating ways to support Vim FocusGain/FocusLost autoevents. Long answer (short answer below): [A really long answer] Hi! Sorry, but I just had to ask, what exactly are you responding to? I saw no suggestion of using DCOP in the vim-dev thread. Did someone on the kde list suggest it? Just curious on what they were suggesting. Thanks! nikolai
VC8 makefile patch
Hi, Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Enjoy. Mike -- If space is a vacuum, who changes the bags? *** Make_mvc.mak.orig Wed Apr 26 10:30:22 2006 --- Make_mvc.makWed Jan 17 13:48:57 2007 *** *** 321,326 --- 321,327 OUTDIR=$(OBJDIR) # Convert processor ID to MVC-compatible number + !if $(_NMAKE_VER) != 8.00.50727.42 !if $(CPUNR) == i386 CPUARG = /G3 !elseif $(CPUNR) == i486 *** *** 334,339 --- 335,346 !else CPUARG = !endif + !else + # VC8 only allows specifying SSE architecture + !if $(CPUNR) == pentium4 + CPUARG = /arch:SSE2 + !endif + !endif !ifdef NODEBUG VIM = vim *** *** 344,349 --- 351,362 !else # MAXSPEED OPTFLAG = /Ox !endif + # Use link time code generation in VC8 if not worried about size + !if $(_NMAKE_VER) == 8.00.50727.42 + !if $(OPTIMIZE) != SPACE + OPTFLAG = $(OPTFLAG) /GL + !endif + !endif CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG) RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG ! ifdef USE_MSVCRT *** *** 706,711 --- 719,733 LINKARGS2 = $(CON_LIB) $(GUI_LIB) $(LIBC) $(OLE_LIB) user32.lib $(SNIFF_LIB) \ $(MZSCHEME_LIB) $(PERL_LIB) $(PYTHON_LIB) $(RUBY_LIB) \ $(TCL_LIB) $(NETBEANS_LIB) $(XPM_LIB) $(LINK_PDB) + + # Report link time code generation progress if used. + !ifdef NODEBUG + !if $(_NMAKE_VER) == 8.00.50727.42 + !if $(OPTIMIZE) != SPACE + LINKARGS1 = $(LINKARGS1) /LTCG:STATUS + !endif + !endif + !endif all: $(VIM).exe vimrun.exe install.exe uninstal.exe xxd/xxd.exe \ GvimExt/gvimext.dll
Re: VC8 makefile patch
Mike Williams wrote: Hi, Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Enjoy. Mike Why the test on !if $(_NMAKE_VER) == 8.00.50727.42 ? Are you sure the old behaviour will be the right thing to do with _any_ older _or_ newer version? Shouldn't we rather assume that versions 8.0 or later of MSVC will require the new arguments? We should provide as best as we can for future versions, to avoid, if possible, the need for constant re-patching of the makefile with every new version that Gates Co will decide to publish. Best regards, Tony
Re: VC8 makefile patch
On 17/01/2007 15:09, A.J.Mechelynck wrote: Mike Williams wrote: Hi, Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Enjoy. Mike Why the test on !if $(_NMAKE_VER) == 8.00.50727.42 ? Are you sure the old behaviour will be the right thing to do with _any_ older _or_ newer version? Shouldn't we rather assume that versions 8.0 or later of MSVC will require the new arguments? We should provide as best as we can for future versions, to avoid, if possible, the need for constant re-patching of the makefile with every new version that Gates Co will decide to publish. The comparison operators can be made relative if desired. It is normal for any new VC compiler to review compiler options and update any build scripts. VC8 retired, deprecated, and added a large number of compiler/linker options. There is nothing to say future versions wont do the same. To have a build script use minimal options for an unrecognised compiler version is reasonable - as long as it reports that this is the case. Mike -- Do you think that you're right and I'm wrong? How naive if you do...
Re: Konsole: lost focus of window or tab
Nikolai Weibull wrote: On 1/17/07, Matthew Woehlke wrote: Mikolaj Machowski wrote: Is it possible to recognize if window or tab of Konsole lost focus through termcap/terminfo sequence? Or is it at least possible with dcop or any other way? I am investigating ways to support Vim FocusGain/FocusLost autoevents. Long answer (short answer below): [snip really long answer] Hi! Sorry, but I just had to ask, what exactly are you responding to? I saw no suggestion of using DCOP in the vim-dev thread. Did someone on the kde list suggest it? Just curious on what they were suggesting. Mikolaj Machowski though of it (see his original e-mail to kde-devel, quoted above). So this is a follow up of the previous thread, FocusLost and terminal functionality; also it raised a number of curiosity questions (about Vim) on my part, so I cross-posted. :-) (And because we are talking about Vim, of course.) -- Matthew HIPPOS feel unacknowledged. HIPPOS get angry. PRAISE HIPPOS HIPPOS seem somewhat placated.
Re: Konsole: lost focus of window or tab
Matthew Woehlke wrote: Mikolaj Machowski wrote: Is it possible to recognize if window or tab of Konsole lost focus through termcap/terminfo sequence? Or is it at least possible with dcop or any other way? I am investigating ways to support Vim FocusGain/FocusLost autoevents. [snip long answer] [...and short answer, too] Robert Knight says we should be able to add escape sequences to Konsole to support this. I might be able to help with the patching (although it is KDE4 that will really get the fix, anything for KDE3 does not seem likely to be accepted, so you would be patching your own local version), but someone Vim-side needs to tell us what Konsole needs to provide... Does Vim already support notifications for some terminal emulators? If so, how do we go about adding Konsole to that list? -- Matthew HIPPOS feel unacknowledged. HIPPOS get angry. PRAISE HIPPOS HIPPOS seem somewhat placated.
Re: Konsole: lost focus of window or tab
Matthew Woehlke wrote: Matthew Woehlke wrote: Mikolaj Machowski wrote: Is it possible to recognize if window or tab of Konsole lost focus through termcap/terminfo sequence? Or is it at least possible with dcop or any other way? I am investigating ways to support Vim FocusGain/FocusLost autoevents. [snip long answer] [...and short answer, too] Robert Knight says we should be able to add escape sequences to Konsole to support this. I might be able to help with the patching (although it is KDE4 that will really get the fix, anything for KDE3 does not seem likely to be accepted, so you would be patching your own local version), but someone Vim-side needs to tell us what Konsole needs to provide... Does Vim already support notifications for some terminal emulators? If so, how do we go about adding Konsole to that list? Sure. At the very least, it reacts to the notifications that a key has been pressed, or the mouse moved or clicked ;-) or, more seriously, to FocusGained and FocusLost events for the GUI and a few console versions where this can be detected. I suppose any notification mechanism would be OK, as long as Vim can be made to listen to it and trigger its (already defined) FocusGained and FocusLost events (q.v.). Do the termcap/terminfo libraries provide for representation of focus-related event signals? I don't know, but IMHO it would be easiest if they did; however, even if they don't, I suppose an appropriate event handler could be programmed into Vim, provided that there existed _any_ method to communicate those events unambiguously to a running program. If there are several incompatible ways to do it depending on OS and terminal, then I suppose it could be implemented via a configure argument and/or a configure library search, the way mouse handlers are already included or excluded at compile (or more precisely configure) time: see vim --version | grep mouse Best regards, Tony.
Re: VC8 makefile patch
Mike Williams wrote: Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Although MS keeps changing the arguments, the new ones mostly get used again in future versions. Thus this check: + !if $(_NMAKE_VER) != 8.00.50727.42 Should probably check if the version is greater than or smaller than this specific number. At least do the comparing with this specific number once and pass the result to further ifs. -- Q. What happens to programmers when they die? A: MS-Windows programmers are reinstalled. C++ programmers become undefined, anyone who refers to them will die as well. Java programmers reincarnate after being garbage collected. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: Konsole: lost focus of window or tab
Matthew Woehlke wrote: Matthew Woehlke wrote: Mikolaj Machowski wrote: Is it possible to recognize if window or tab of Konsole lost focus through termcap/terminfo sequence? Or is it at least possible with dcop or any other way? I am investigating ways to support Vim FocusGain/FocusLost autoevents. [snip long answer] [...and short answer, too] Robert Knight says we should be able to add escape sequences to Konsole to support this. I might be able to help with the patching (although it is KDE4 that will really get the fix, anything for KDE3 does not seem likely to be accepted, so you would be patching your own local version), but someone Vim-side needs to tell us what Konsole needs to provide... Does Vim already support notifications for some terminal emulators? If so, how do we go about adding Konsole to that list? Vim does check for some events, such as the xterm version response. We need to add termcap/terminfo codes for this internally (won't work anywhere else). Thus if you follow what's there in Vim it should not be too complicated. -- To define recursion, we must first define recursion. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: Konsole: lost focus of window or tab
Dnia środa 17 styczeń 2007, Matthew Woehlke napisał: Matthew Woehlke wrote: Mikolaj Machowski wrote: Is it possible to recognize if window or tab of Konsole lost focus through termcap/terminfo sequence? Or is it at least possible with dcop or any other way? I am investigating ways to support Vim FocusGain/FocusLost autoevents. [snip long answer] [...and short answer, too] Robert Knight says we should be able to add escape sequences to Konsole to support this. I might be able to help with the patching (although it is KDE4 that will really get the fix, anything for KDE3 does not seem likely to be accepted, so you would be patching your own local version), I was waiting 2 years for Lists in VimL so I can wait several months for KDE 4 ;) but someone Vim-side needs to tell us what Konsole needs to provide... Looks like it should be similar communication like with mouse events. Proper escape codes - I suppose there is no standard at the moment. If Konsole would be first to do it there is chance that will become standard. Does Vim already support notifications for some terminal emulators? If so, how do we go about adding Konsole to that list? Comment in :ui.c:3010: says: /* * Called when focus changed. Used for the GUI or for systems where this can * be done in the console (Win32). */ m.
Re: Konsole: lost focus of window or tab
Dnia środa 17 styczeń 2007, Matthew Woehlke napisał: I'm willing to (try to, at least) help get this working in 3.5.x if you can dig up what the needed escapes are (it sounds like there are already existing examples?)... it probably won't be accepted but you could use it locally, and of course submit it for porting to KDE4. On kde-devel R. Knight said he can accept it to 3.5.7 release and later maintain it for KDE 4. Now, some start. I don't know much about term internals. I read something yesterday and today so forgive me if I wrote something stupid. Just seed for further discussion: Base info according to man terminfo: Variable String: focus_lost Cap name:flo TCapcode:fL Description: terminal lost focus Escape sequence: \E[1fl Variable String: focus_gained Cap name:fga TCapcode:fG Description: terminal gained focus Escape sequence: \E[1fg These sequences and names don't conflict with any other entry defined in my /etc/termcap or /usr/share/terminfo/** . m.
Re: Konsole: lost focus of window or tab
Mikolaj Machowski wrote: Dnia Åroda 17 styczeÅ 2007, Matthew Woehlke napisaÅ: I'm willing to (try to, at least) help get this working in 3.5.x if you can dig up what the needed escapes are (it sounds like there are already existing examples?)... it probably won't be accepted but you could use it locally, and of course submit it for porting to KDE4. On kde-devel R. Knight said he can accept it to 3.5.7 release and later maintain it for KDE 4. Now, some start. I don't know much about term internals. I read something yesterday and today so forgive me if I wrote something stupid. Just seed for further discussion: Base info according to man terminfo: Variable String: focus_lost Cap name:flo TCapcode:fL Description: terminal lost focus Escape sequence: \E[1fl Variable String: focus_gained Cap name:fga TCapcode:fG Description: terminal gained focus Escape sequence: \E[1fg These sequences and names don't conflict with any other entry defined in my /etc/termcap or /usr/share/terminfo/** . There are some rules about escape sequences, I think ending in fl or fg is not good. Try asking Thomas Dickey, he has a good overview of the codes. Note that we also need one to enable/disable getting these events. A program should only get the events when asked for. -- hundred-and-one symptoms of being an internet addict: 38. You wake up at 3 a.m. to go to the bathroom and stop and check your e-mail on the way back to bed. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
BOF Vim 8 - Suggestions
Sorry I'm late, but I just listened to the Vim BOF session that Bram mentioned three months ago. In the talk, Bram sounded quite evangelical with regard to promoting Vim usage, and he asked for suggestions on how he should best spend his limited time in working towards a new version (Vim 8). I am posting this introductory message with my response, plus a second message describing a feature I would like (EncryptLine). The best way to expand Vim usage IMHO would be to work out better default settings to improve the first hour of contact. In addition, perform necessary fixups, but resist new features. If I were starting Vim usage now, I would probably abandon it as soon as I discovered that pressing PageUp did NOT reverse the effect of PageDown. I still hate that! Vim has many wonderous features, but I imagine that many people don't stay to find them because of irritations like PgUp/PgDn. Highlighting all matches when searching is excellent, but there needs to be a way for a new user to turn it off. I map Space for this, however, it would be better to press Escape to clear highlights and message text (if Escape is pressed while in Normal mode, remove search highlights and clear any message). Maybe also have a way for this feature to be turned off. I won't say more now. If Bram feels that improved defaults would be worth investigating, a discussion here would probably be best. OTOH people who dream in Vim script may not be the best source of ideas on how Vim should be configured to win new converts. John
BOF Vim 8 - EncryptLine
Suggested new feature:
Make an easy way to encrypt a secret within a line.
Then you can have a simple text file to document stuff, with
embedded secrets. On reading, you only need to enter a key if you
want to see a secret.
Example lines before encryption:
server12 { admin topsecret } any text
mybank { account 123456789 pin 1234 }
Example lines after encryption:
server12 {~8vP09fb3+Pn6+/z9/v8AAwocSE9cDYPAYJUThgE} any text
mybank {~afSDKoy9saGMCZ91x6F7pHkwdzEcMBoGCSqGSIb3DQEJ}
When viewing a file with encrypted secrets, it doesn't matter if
others are shoulder surfing. You only need to get rid of onlookers
for the short time it would take to enter a key and view a secret in
the message line (which would not change the file).
I implemented this scheme in an obsolete editor many years ago,
and offer the suggestion in case it appeals to Bram. However, as
noted in my Suggestions message, I think new features should be
resisted in favour of fixups, so I won't be offended if this is
ignored.
A more detailed description of the proposal follows.
A secret is entered between { and } on a single line.
There is a space after the opening brace.
The encrypted result is stored as base64 text, with ~ inserted as
the first character. The space (plaintext) and tilde (ciphertext)
are safety checks so text is not encrypted or decrypted twice.
These commands would be required:
EnterKey - Prompt user to enter a key for encryption/decryption.
EncryptLine - Encrypt text inside braces on the current line.
DecryptLine - Reverse EncryptLine.
ShowSecret - Show decrypted secret in the message line.
EnterKey prompts the user and allows them to enter a key (no echo).
The key is hashed, and the hash is retained in memory for this
session. It can be cleared by using EnterKey to enter a blank key.
The hashed key is used for any subsequent encryption and decryption.
EncryptLine checks that the current line contains { (with space),
followed by }. It then uses the hashed key to encrypt the text
between the braces, then replaces that text in the current line with
a base64 encoded form of the ciphertext.
EncryptLine inserts a tilde (~) after the first brace. This is a
safety mechanism so you won't accidentally encrypt a line twice.
EncryptLine inserts a small amount of random padding (salt). The
padding is of variable length so the length of the secret is not
known to intruders. However, there is only a small amount of padding
so the result is fairly compact.
ShowSecret decrypts the secret in the current line, and displays the
plaintext in the message line. The file is not changed. There should
be an easy way to put the plaintext in the clipboard, and an easy
way to blank the displayed secret.
DecryptLine reverses EncryptLine, changing the current line. It does
nothing (apart from display an error) if the result is not
reasonable (the ciphertext must be a tilde followed by base64, and
the decryption should satisfy certain sanity checks, and should
yield printable text starting with a space). This is a safety check
to avoid losing data if the wrong key is used to decrypt.
John
Re: BOF Vim 8 - EncryptLine
John Beckett wrote:
Suggested new feature:
Make an easy way to encrypt a secret within a line.
Then you can have a simple text file to document stuff, with
embedded secrets. On reading, you only need to enter a key if you
want to see a secret.
Example lines before encryption:
server12 { admin topsecret } any text
mybank { account 123456789 pin 1234 }
Example lines after encryption:
server12 {~8vP09fb3+Pn6+/z9/v8AAwocSE9cDYPAYJUThgE} any text
mybank {~afSDKoy9saGMCZ91x6F7pHkwdzEcMBoGCSqGSIb3DQEJ}
When viewing a file with encrypted secrets, it doesn't matter if
others are shoulder surfing. You only need to get rid of onlookers
for the short time it would take to enter a key and view a secret in
the message line (which would not change the file).
I implemented this scheme in an obsolete editor many years ago,
and offer the suggestion in case it appeals to Bram. However, as
noted in my Suggestions message, I think new features should be
resisted in favour of fixups, so I won't be offended if this is
ignored.
A more detailed description of the proposal follows.
A secret is entered between { and } on a single line.
There is a space after the opening brace.
The encrypted result is stored as base64 text, with ~ inserted as
the first character. The space (plaintext) and tilde (ciphertext)
are safety checks so text is not encrypted or decrypted twice.
These commands would be required:
EnterKey - Prompt user to enter a key for encryption/decryption.
EncryptLine - Encrypt text inside braces on the current line.
DecryptLine - Reverse EncryptLine.
ShowSecret - Show decrypted secret in the message line.
EnterKey prompts the user and allows them to enter a key (no echo).
The key is hashed, and the hash is retained in memory for this
session. It can be cleared by using EnterKey to enter a blank key.
The hashed key is used for any subsequent encryption and decryption.
EncryptLine checks that the current line contains { (with space),
followed by }. It then uses the hashed key to encrypt the text
between the braces, then replaces that text in the current line with
a base64 encoded form of the ciphertext.
EncryptLine inserts a tilde (~) after the first brace. This is a
safety mechanism so you won't accidentally encrypt a line twice.
EncryptLine inserts a small amount of random padding (salt). The
padding is of variable length so the length of the secret is not
known to intruders. However, there is only a small amount of padding
so the result is fairly compact.
ShowSecret decrypts the secret in the current line, and displays the
plaintext in the message line. The file is not changed. There should
be an easy way to put the plaintext in the clipboard, and an easy
way to blank the displayed secret.
DecryptLine reverses EncryptLine, changing the current line. It does
nothing (apart from display an error) if the result is not
reasonable (the ciphertext must be a tilde followed by base64, and
the decryption should satisfy certain sanity checks, and should
yield printable text starting with a space). This is a safety check
to avoid losing data if the wrong key is used to decrypt.
John
John,
Since this requires the file to contain markup characters on the line,
its usefulness is limited in source files where the tags { and } would
cause a syntax error and cannot be marked as comments. As long as this
limitation is acceptable, I think it might me equally as useful and
perhaps more simple and intuitive if instead foldmarkers were used
along with the fold commands (zc, zo):
Password fold exposed:
?php
$admin_password = /*{{{*/ 'maryhadababyitsaboy' /*}}}*/ ;
?
Password fold closed:
?php
+-- 1 line: $admin_password = * ;
?
This has some advantages:
- Less work for the user to visibly protect screen content (no
passwords, etc).
- Reuses existing keyboard sequences: zc, zo, zm, zr, zM, zR, etc...
- Only extends existing functionality (folding -- support for
single-line folds would need to be added)
- Count of *'s is indicative of length of hidden area (user can add
whitespace padding to obscure when desired)
- The obscuration character (*) could be configurable, perhaps as a
multi-character seq, e.g. '**', to also help obscure length.
- Source code is still readable (e.g. the reader is still able to see
that an assignment is occurring and on what variable)
- mkview will cause the fold state to be remembered, to be recalled
later, perhaps automatically when the file is reopened.
This can already be done with traditional multi-line folds:
?php
// {{{ $admin_password = '***';
$admin_password = 'maryhadababyitsaboy';
// }}}
?
to become:
?php
+-- 3 Lines: $admin_password = '***'; ---
?
Must my $0.02.
-Robert
Odp: BOF Vim 8 - Suggestions
I won't say more now. If Bram feels that improved defaults would be worth investigating, a discussion here would probably be best. OTOH people who dream in Vim script may not be the best source of ideas on how Vim should be configured to win new converts. I suppose this apply for me also ;), but: 1. Persistence of search highlighting is IMO good thing. 2. Star behaviour of keys much depends on packager. If Vim starts in compatible mode there is nothing which can be done. In nocompatible mode everything works as newbie can expect. AFAIR on Win32 default Vim mode is nocompatible, on Linux distributions it depends on packager but I think apart from redhattish vim-minimal for admin purposes everywhere is nocompatible. m. Ania - Kilka historii na ten sam temat - trasa koncertowa: Wrocław, Zielona Góra, Warszawa, Ełk, Lublin... Sprawdź: Sprawdź:http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fbytom.htmlsid=993
