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 can remember using a mail client that had a feature much like that,
except that blocks of encrypted text in the message were introduced by
a line saying [encrypt]. I forget how they were terminated. I think
it's important to have a more distinctive marker than { and } because
otherwise people will be inadvertently encrypting sections of their C
programs.
[snip]
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.
Perhaps a safer way is to have a hash as part of the encrypted text.
When the text is decrypted the result is checked against the hash as a
confirmation of validity. Merely detecting printable text is hard
when most characters are printable.
On Thu, 18 Jan 2007 00:21:57 -0600, Robert Lee
[EMAIL PROTECTED] wrote:
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.
I can't think of any reason why this would be useful in source code.
The point of encryption is to protect data, so the data must be
encrypted in the file and revealed on the display (the way Vim already
does it for entire files). Source code must be stored on disk in
unencrypted form or otherwise it can't be used.
You seem to be thinking of this as a way of storing cleartext in the
file but hiding it on the display, which is essentially no security at
all.
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:
[snip]
- Count of *'s is indicative of length of hidden area (user can add
whitespace padding to obscure when desired)
That's a really bad idea. Anyone who shouldn't know what's there has
absolutely no business knowing how long the obscured text is, and
even those who know the password shouldn't need to care. If you're
performing an assignment like $password = some string you don't
really care what the content of the string happens to be, but only
that it's assigned to a variable.
--
Matthew Winn
Re: BOF Vim 8 - Suggestions
1. Persistence of search highlighting is IMO good thing. Forgot to explain why: newbies often are pressing Esc just in case of ... . So this key shouldn't do by default anything more than changing of mode. m. Adaptacja bestsellerowej powieści Patricka Süskinda Pachnidło, Historia Mordercy już w kinach - Naprawdę warto zobaczyć! http://klik.wp.pl/?adr=www.pachnidlo.wp.plsid=982
Re: BOF Vim 8 - EncryptLine
Nicolas Weber wrote:
Hi,
You are correct, I was thinking of this the other way around. My
suggestion would only be security in the sense that someone reading
over your shoulder would be prevented from seeing sensitive content
in the file (e.g. passwords) and would really only be an extension to
folding. No change would be made to the file on disk (e.g. the file
would need to be secured on disk using some other external mechanism).
this can already been done with g?$ (or g?a{ )...so if you only want
to protect your data from people looking over your shoulders, that's
already there.
Nico
Nicolas,
Thanks for the feedback, I wasn't even aware of this feature. My only
concern here is that it appears to change the buffer contents (not just
the view). A subsequent w will write this change to disk -- a possibly
undesired result. Also, executing such a command on a password while
someone is watching only brings attention to the password, which appears
in clear text until the command sequence has been completed (where-as
folding can be applied automatically when the file is opened, and each
fold remains closed until explicitly opened).
This is such a rare scenario, however, that I think I'm over-analyzing
it. Vim works great for me exactly as it is. :o)
-Robert
Re: VC8 makefile patch
On 17/01/2007 19:44, Bram Moolenaar wrote:
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.
Proposal #2 - now derives VC version from _NMAKE_VER. Updated a couple
of checks for VC4 so the file is a bit more more self documenting.
Enjoy.
Mike
--
Barnum was wrong... it's more like every thirty seconds.
*** Make_mvc.mak.orig Wed Apr 26 10:30:22 2006
--- Make_mvc.makThu Jan 18 11:07:26 2007
***
*** 320,326
--- 320,348
INTDIR=$(OBJDIR)
OUTDIR=$(OBJDIR)
+ # Derive version of VC being used
+ !if $(_NMAKE_VER) ==
+ VC_VER = 4
+ !endif
+ !if $(_NMAKE_VER) == 162
+ VC_VER = 5
+ !endif
+ !if $(_NMAKE_VER) == 6.00.8168.0
+ VC_VER = 6
+ !endif
+ !if $(_NMAKE_VER) == 7.00.9466
+ VC_VER = 7
+ !endif
+ !if $(_NMAKE_VER) == 8.00.50727.42
+ VC_VER = 8
+ !endif
+ # Default to VC6 (arbitrarily) if unknown
+ !ifndef VC_VER
+ VC_VER = 6
+ !endif
+
# Convert processor ID to MVC-compatible number
+ !if $(VC_VER) 8
!if $(CPUNR) == i386
CPUARG = /G3
!elseif $(CPUNR) == i486
***
*** 334,339
--- 356,367
!else
CPUARG =
!endif
+ !else
+ # VC8 only allows specifying SSE architecture
+ !if $(CPUNR) == pentium4
+ CPUARG = /arch:SSE2
+ !endif
+ !endif
!ifdef NODEBUG
VIM = vim
***
*** 344,349
--- 372,383
!else # MAXSPEED
OPTFLAG = /Ox
!endif
+ !if $(VC_VER) = 8
+ # Use link time code generation if not worried about size
+ !if $(OPTIMIZE) != SPACE
+ OPTFLAG = $(OPTFLAG) /GL
+ !endif
+ !endif
CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG)
RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG
! ifdef USE_MSVCRT
***
*** 363,369
CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG
# The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in
VC4.0.
! ! if $(_NMAKE_VER) ==
LIBC =
! else
LIBC = /fixed:no
--- 397,403
CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG
# The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in
VC4.0.
! ! if $(VC_VER) == 4
LIBC =
! else
LIBC = /fixed:no
***
*** 707,712
--- 741,755
$(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 $(VC_VER) = 8
+ !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
***
*** 795,801
# Create a default rule for transforming .c files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(_NMAKE_VER) ==
.c{$(OUTDIR)/}.obj:
!ELSE
.c{$(OUTDIR)/}.obj::
--- 838,844
# Create a default rule for transforming .c files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(VC_VER) == 4
.c{$(OUTDIR)/}.obj:
!ELSE
.c{$(OUTDIR)/}.obj::
***
*** 804,810
# Create a default rule for transforming .cpp files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(_NMAKE_VER) ==
.cpp{$(OUTDIR)/}.obj:
!ELSE
.cpp{$(OUTDIR)/}.obj::
--- 847,853
# Create a default rule for transforming .cpp files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(VC_VER) == 4
.cpp{$(OUTDIR)/}.obj:
!ELSE
.cpp{$(OUTDIR)/}.obj::
Re: BOF Vim 8 - EncryptLine
On 1/18/07, Robert Lee [EMAIL PROTECTED] wrote: Also, executing such a command on a password while someone is watching only brings attention to the password, which appears in clear text until the command sequence has been completed (where-as folding can be applied automatically when the file is opened, and each fold remains closed until explicitly opened). Seriously, where the hell are you sitting writing down passwords where people walk by you and drop down over your shoulder to sneak a peek? A couple of suggestions: 1. Don't write down passwords in a file unencrypted (because what you're suggesting is that encryption would only be necessary during display, i.e, when the file is loaded) 2. Don't write down passwords at all - use phrases that you remember instead 3. Don't write down passwords where other people might walk by and see what you're typing nikolai
Re: VC8 makefile patch
Mike Williams wrote: On 17/01/2007 19:44, Bram Moolenaar wrote: 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. Proposal #2 - now derives VC version from _NMAKE_VER. Updated a couple of checks for VC4 so the file is a bit more more self documenting. Enjoy. Mike ...sorry, my mailer shows the patches inline but doesn't quote them on reply. Rather than testing for specific strings, couldn't you just use the first digit(s) of _NMAKE_VER as the version number if followed by a period? Or doesn't the make evaluation syntax allow for that? (I suppose if someday the version string becomes, let's say, 9.05.77643.25 we should take this as meaning version 9 rather than default to version 6 don't you think?) Best regards, Tony.
Re: Bug with --remote-tab-silent
Alexei Alexandrov wrote: Hi Bram et al., here is a rather strange bug. It seems to be specific for Windows and only when I try to open *.exe or *.dll file (yes, it's strange but sometimes I use it). If I open an *.exe file with gvim bjam.exe it opens just fine. But if I open it with gvim --remote-tab-silent bjam.exe command, I get error message E479: No match. The problem reproduces even if bjam.exe file doesn't exist. Exe or dll files are usually binaries (which shouldn't cause E479 however); and unlike cmd.exe when executing them, Vim doesn't lookup the PATH for editfiles. 1) Are you sure the directory containing the editfile was current? If it wasn't, you should mention the path to the file on the command-line. 2) If the file's dir was current, try using gvim --remote-tab-silent +set bin bjam.exe Note: The Vim help is not very explicit: I'm not sure if the additional parameter should be +set bin +set bin or +set\ bin If one of them doesn't set 'binary', try another variant. Best regards, Tony.
Re: patch 182 and selectbuf
Denis Perelyubskiy wrote: hello, I briefly upgraded to patch 182 a little while back, and selectbuf script which I absolutely adore :) stopped working (http://vim.sourceforge.net/scripts/script.php?script_id=107) I am using version .178 right now. Something about those 4 patches (179.180.181.182) breaks the script. Error is something about dirname not being found. (error is a generic E15) Before I dig any deeper and re-install 182 and try debugging this - has any user of selectbuf seen any problems after upgrading? thanks! You may want to check the bottom lines of the patches' README file http://ftp.vim.org/pub/vim/patches/7.0/README to help you guess which of these patches might be breaking your favourite script. BTW the patchlevel has been upped to 188 since then. Best regards, Tony.
Re: Odp: BOF Vim 8 - Suggestions
Mikołaj Machowski wrote: 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 Vim defaults to 'compatible' mode everywhere, except where it finds a user _vimrc or .vimrc (system vimrc doesn't count). I personally recommend to create the following as $HOME/_vimrc (or $HOME/.vimrc) immediately after first installation, and to add tweaks as one gets going: quote runtime vimrc_example.vim /quote Bram says it's better to _copy_ the vimrc_example rather than _source_ (or :runtime) it. My personal opinion is that the vimrc_example will give headaches if one tries to understand it too soon, and that leaving it unmodified (with user tweaks in a different, hopefully simpler and smaller, file) keeps things more orderly. It's always possible (and educational) to use :view $VIMRUNTIME/vimrc_example.vim when one feels relaxed and curious. Changes to the menu/messages language should go before invoking the vimrc_example; most any other tweaks should go after it. Best regards, Tony.
Re: Bug with --remote-tab-silent
Hi Bram Moolenaar, you wrote: I can't reproduce it. It could be caused by a plugin. Does adding -V10 show some context of the error? Does anyone else see this? Not sure if my previous message reached the list: the bug is reproducible only if the extension of the file is in 'wildignore' -- Alexei Alexandrov
Re: Bug with --remote-tab-silent
Hi A.J.Mechelynck, you wrote: Exe or dll files are usually binaries (which shouldn't cause E479 however); and unlike cmd.exe when executing them, Vim doesn't lookup the PATH for editfiles. 1) Are you sure the directory containing the editfile was current? If it wasn't, you should mention the path to the file on the command-line. 2) If the file's dir was current, try using gvim --remote-tab-silent +set bin bjam.exe Note: The Vim help is not very explicit: I'm not sure if the additional parameter should be +set bin +set bin or +set\ bin If one of them doesn't set 'binary', try another variant. The key in the bug report is that error is reproducible only with --remote-tab-silent. I'm not sure why the advices above can have different behavior with this option. -- Alexei Alexandrov
Re: BOF Vim 8 - Suggestions
Hi John Beckett, you wrote: 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. I also think that Vim is feature-enough. What affects me most of all every day is Vim performance. Especially on Windows. Startup is slower than it should be and redraw of the screen is also rather slow - and almost unusable with TTF fonts with Antialiasing on. If would need to choose _one_ thing I'd like to have in Vim improved I'd choose performance... -- Alexei Alexandrov
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.
This is very a specific feature. You should implement this in a script,
this doesn't sound like something Vim should support internally.
--
A day without sunshine is like, well, night.
/// 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: 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. Proposal #2 - now derives VC version from _NMAKE_VER. Updated a couple of checks for VC4 so the file is a bit more more self documenting. Thanks, looks much better. I wonder what actually does. Is it a textual compare? Perhaps you can try out if using or works to avoid these magic build numbers. Some people must have different builds (otherwise they wouldn't include these numbers, right?). -- You have the right to remain silent. Anything you say will be misquoted, then used against you. /// 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: Bug with --remote-tab-silent
Alexei Alexandrov wrote: On 1/17/07, Bram Moolenaar [EMAIL PROTECTED] wrote: I can't reproduce it. It could be caused by a plugin. Does adding -V10 show some context of the error? Does anyone else see this? It reproduces only when the extension of the file is added into 'wildignore'. In my .vimrc I have set wildignore=*.o,*.obj,*.exe,*.lib,*.a,*.dll,*.swp,*.ncb,*.aps,*.opt,*.pdb,*.bak,*~,*.d and the bug can be reproduced for any of these extensions. And only with --remote-tab-silent. OK, I can reproduce it now. I have *.pyc in 'wildignore' and editing foo.pyc causes the error message in the remote gvim with --remote-tab and --remote-tab-silent. What is worse: with --remote it crashes. I'll look into it. -- Micro$oft: where do you want to go today? Linux: where do you want to go tomorrow? FreeBSD: are you guys coming, or what? /// 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: BOF Vim 8 - Suggestions
John Beckett wrote: 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. Mostly PageUp and PageDown do the reverse of each other. If you mean that the cursor has moved, that is a completely different thing. 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. This feature is off by default. Only when you run Vim in non-compatible mode it's on. Switching off search highlighting is part of the tutor. People who skip the vimtutor are going to run into trouble anyway. 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 do agree that good defaults are important. But backwards compatibility is also important. It's not always easy to make a choice. -- Everyone has a photographic memory. Some don't have film. /// 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 czwartek 18 styczeń 2007, Matthew Woehlke napisał: ...I am not a Vim hacker, but if you can rig Vim to handle some escape sequence, I may be able to help make Konsole understand/send them. A start might be to write a simple application that sends the sequence to turn on the function and then listens for them and takes some action (like beeping and/or printing a message with a time stamp) when it receives a notification. You could use that to test Konsole. (Read: if you write that, it will make me much more motivated to help you with hacking on Konsole :-).) I am not Vim hacker, not even programmer. The only I am able to do is simple shell thingy: #!/bin/bash read key if [ `echo $key | grep '24' ` ]; then echo -e 'you got it' fi 24 should be replaced by escape code, if code is coming from terminal maybe it should be ``read -e``, not just ``read``. In addition you have to manually press enter to go further :( Works with codes of function keys. m.
Re: Konsole: lost focus of window or tab
Dnia czwartek 18 styczeń 2007, Bram Moolenaar napisał: Note that we also need one to enable/disable getting these events. A program should only get the events when asked for. Are you talking here about Vim part or Konsole part? m.
Re: Konsole: lost focus of window or tab
Mikolaj Machowski wrote: Dnia czwartek 18 styczeñ 2007, Bram Moolenaar napisa³: Note that we also need one to enable/disable getting these events. A program should only get the events when asked for. Are you talking here about Vim part or Konsole part? Both. The terminal emulater needs to support enable/disable for sending focus events. Vim must send the enable/disable when appropriate (e.g., it needs to be disabled when executing a shell command). Although this can perhaps be part of the already existing t_ke and t_ks codes. -- I wonder how much deeper the ocean would be without sponges. /// 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: Bug with --remote-tab-silent
Bram Moolenaar wrote:
Alexei Alexandrov wrote:
On 1/17/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
I can't reproduce it. It could be caused by a plugin.
Does adding -V10 show some context of the error?
Does anyone else see this?
It reproduces only when the extension of the file is added into
'wildignore'. In my .vimrc I have
set
wildignore=*.o,*.obj,*.exe,*.lib,*.a,*.dll,*.swp,*.ncb,*.aps,*.opt,*.pdb,*.bak,*~,*.d
and the bug can be reproduced for any of these extensions. And only
with --remote-tab-silent.
OK, I can reproduce it now. I have *.pyc in 'wildignore' and editing
foo.pyc causes the error message in the remote gvim with --remote-tab
and --remote-tab-silent. What is worse: with --remote it crashes.
I'll look into it.
I've only looked into it for a bit, but if you start Vim with a command
line argument (eg. gvim /tmp/foo.txt) You don't get the crash with
--remote. If you start it without one (eg. gvim ) then it crashes.
This appears to be caused by
buf = buflist_findnr(ARGLIST[0].ae_fnum);
in ex_drop at ex_cmds.c:6984
I'm not familiar with Vim's source at all, but it looks like ARGLIST is
empty
(gdb) print (curwin)-w_alist-al_ga
$3 = {ga_len = 0, ga_maxlen = 0, ga_itemsize = 8, ga_growsize = 5,
ga_data = 0x0}
Todd
Re: Konsole: lost focus of window or tab
Bram Moolenaar wrote: Mikolaj Machowski wrote: Dnia czwartek 18 styczeñ 2007, Bram Moolenaar napisa³: Note that we also need one to enable/disable getting these events. A program should only get the events when asked for. Are you talking here about Vim part or Konsole part? Both. The terminal emulater needs to support enable/disable for sending focus events. Vim must send the enable/disable when appropriate (e.g., it needs to be disabled when executing a shell command). Although this can perhaps be part of the already existing t_ke and t_ks codes. So, just to make sure I am following, Vim does or does not currently understand any escape sequences for focus events? It sounds like no, but then what about A.J.'s comment about reacting to [focus] events for 'the GUI and a few console versions where this can be detected'? -- I wonder how much deeper the ocean would be without sponges. It would be less deep, of course, since the sponges take up volume! :-) -- Matthew What a wonderful smell you've discovered! -- Princess Leia Organa
Re: Konsole: lost focus of window or tab
Dnia piątek 19 styczeń 2007, Matthew Woehlke napisał: So, just to make sure I am following, Vim does or does not currently understand any escape sequences for focus events? It sounds like no, but then what about A.J.'s comment about reacting to [focus] events for 'the GUI and a few console versions where this can be detected'? From placement of focus related functions in Vim source looks like currently such events are supported only in GUI and Win32 console. There is no general code. m.
