Re: A performance question (utility included)
Charles E Campbell Jr wrote:
I've attached a patch to vim 7.1 which extends getfsize()
As I've mentioned, I think further testing will be needed before
patching Vim for 64-bit file lengths.
Here is a possible interim workaround to allow Dr.Chip's
LargeFile.vim script to accurately detect large files on many
platforms.
Attached is a tiny C program to build a tool called filemeg.
Example usage: filemeg /path/to/file
gives output: 42
which means that the specified file is 42 megabytes (actually,
any value from 42 to nearly 43).
I was going to work out how to adapt the LargeFile script to use
this tool, if the user sets an option to invoke it. But it's
taking too long because I don't know enough about Vim, so I'm
just presenting the tool at this stage.
People may like to check how filemeg works on various systems
and report back. I have tried it on files over 4GB on Fedora
Core 6 and Windows XP (x86-32 platform).
Putting something like this inside Vim would be a bit of a
nightmare IMHO because of the extraordinary range of supported
compilers, operating systems and hardware.
Adapting LargeFile.vim to work with filemeg:
- Compile the source and test running at command line.
- Put the executable in your path (better: in a Vim
directory which the script could invoke somehow).
- Set a new script option to use filemeg.
- The script BufReadPre would call a new script function.
- That function would check the file size with:
let result = system('filemeg /path/to/file')
- If result is a number, it is the file size in megabytes.
- Otherwise, result is Error... and the script should
treat the file as large (or maybe not...).
I've attached the C source, and included it below for those who
don't mind a little wrapping.
John
/* Output length of specified file in megabytes.
* John Beckett 2007/05/25
* For Linux with LFS (large file support), and Win32.
*
* Output is suitable for reading by a script.
* Output is always one line.
* If any problem occurs, line starts with Error.
* Otherwise, line is the size of the specified file in megabytes.
* Size is a truncated integer (file of 3.9MB would give result 3).
* The size won't overflow a 32-bit signed integer (Error if it does).
* If argument is a directory, result is 0 (done by stat64()).
*/
#if defined(__linux)
# define _LARGEFILE64_SOURCE
#elif defined(_WIN32)
# define off64_t__int64
# define stat64 _stati64
#endif
#include stdio.h
#include sys/types.h
#include sys/stat.h
int main(int argc, char *argv[])
{
off64_t size, overflowmask;
struct stat64 sb;
if ( argc != 2 ) {
puts(Error: Need path of file to report its size in megabytes.);
return 1;
}
if ( stat64(argv[1], sb) != 0 ) {
puts(Error: Could not get file information.);
return 1;
}
size = sb.st_size 20; /* 2^20 = 1 meg */
overflowmask = 0x7fff;/* ensure 64-bit calculation */
if ( (size ~overflowmask) != 0 ) {
puts(Error: File size in megabytes overflows 32-bit signed
integer.);
return 1;
}
printf(%d\n, (int)size);
return 0;
}
filemeg.c
Description: Binary data
Re: A performance question (patch included)
Charles E Campbell Jr wrote: I'm also under the impression that ls itself uses fstat(), so its not likely to be any more informative. That's likely on some systems, but 'ls -l' gives correct results for files over 4GB on Fedora Core 6 using x86-32. John
Re: feedkeys() allowed in sandbox
Ciaran McCreesh wrote: 100 bytes is more than enough room to download and execute a file that contains the real malicious code. I actually agree that it is extremely unlikely that a length check would make modelines more secure, but I'm being argumentative because it's irritating to be authoritatively assured that a length check would have no benefit in the future. We just don't know whether some future vulnerability (perhaps using a currently-unknown new feature) might be avoided with a modeline length check. John
Re: feedkeys() allowed in sandbox
Matthew Winn wrote: My objection to your idea is that it won't improve security by even the tiniest bit. It's not defence in depth at all. We've probably slugged this out enough, but I'm glad to have another opportunity to promote the safe modelines message. Bram has made the point that despite repeated modeline vulnerabilities over several years, there are no known cases of a malicious attack. We have only seen PoC and jokes. I see the sense of that position - why put in a bunch of ugly checking which is going to reduce features and upset some users? Why do it if there are no known benefits? My answer is essentially an appeal to a higher moral purpose. There may never be in-the-wild exploits based on modelines, but that would make it all the easier to direct a specific attack against a targeted victim. The attacker would have a list of 10 or 20 slight security flaws in the victim's network. One of those would be the fact that the victim uses Vim. An attacker may use a Vim modeline as the coup de grace to fully own the victim's network. I find that situation offensive, and believe that modelines should be REALLY fixed. My claim is: 1. A modeline can execute untrusted code. 2. That is incredibly dangerous. 3. Any bugs in modeline handling should be fixed. 4. In addition, modelines should be sanity checked. I think we agree on points 1-3. I mentioned that the first step for point 4 should (IMHO) be rejecting any modeline beyond some fairly small maximum size. However, that was just the first part of my hoped-for sanity check. After that, I would like the modeline to be examined to determine whether there are any constructs that look dangerous. I would reject any modeline with more than ten backslashes, and would reject anything looking like an expression or 'call'. What I'd really like would be a separate sanity check that verifies that the syntax in the modeline is boringly standard 'set' options for a declared whitelist of things that a modeline is allowed to do. Note that this checking should NOT be done only in the code that executes the modeline. The checking should be an independent, prior step. That redundancy is likely to save someone's foot in future years, when extra features are added. My objection to your idea [to limit modeline length] is that it won't improve security by even the tiniest bit. You may be right. But if I were to accidentally execute malware, I would prefer that the malware was short, rather than of an essentially unlimited length. I agree that 100 bytes of malware could do more damage than I could bear, but I would still prefer that situation. For example, 100 bytes of malware might be able to erase my files, but perhaps it couldn't do something more sophisticated like launching a hidden infiltration of my network. I don't really know why I want to limit the modeline length. That's the whole point of proper security measures. Just because I can't think of a way that a long modeline might be bad, does not mean that some attacker won't find a way, particularly in five years after a bunch more stuff has been added to Vim. That means that my modelines are quite long. I'm a reasonable guyg. Let's take your longest modeline and double it. That length should be the maximum allowed for a modeline unless some new anything goes option is enabled. Re Perl tainting: I think we essentially agree on this, although I don't think Vim needs to mark an executable expression read from a modeline as tainted. Vim should immediately reject any modeline that might execute code (unless some new anything goes option is enabled). John
Re: feedkeys() allowed in sandbox
Bram Moolenaar wrote: N times as safe still isn't 100% safe. I am not claiming that sanity-checking a modeline before execution would make it 100% safe. But there have been many examples in other software where minor bugs have turned into security disasters because some simple point that could have been checked, wasn't. While code is working correctly, a simple check is redundant, and indeed is offensive because it lengthens and obscures the code. But a few simple checks may prevent disaster at some future time, when Vim is further developed. The Google test (searching for past instances of trouble with Vim's modeline) proves the case that future problems are likely. Modelines are default off when you are root. The mail filetype plugin also switches it off. Good grief - I didn't know that. So you *have* got sanity checks built in! I'll go and sit in the corner now, but thanks for confirming that multiple layers of defence are desirable. John
Re: feedkeys() allowed in sandbox
Matthew Winn wrote: If there was a security problem in Vim do you really think it couldn't be exploited in 100 characters? That's a pretty shaky foundation on which to build your security. I am quite surprised at the lack of appreciation for the merits of defense in depth here. I am not claiming that a length limit would preclude damage, just that a modeline should be sanity checked before execution, and a reasonable length would be the first check. It's certainly true that a modeline of 100 bytes could wreak havoc on an unpatched Vim. But it is quite possible that a future vulnerability might allow code to be injected from a modeline, and limiting its length *might* make the attacker's job harder. It's sensational that Vim can process files with very long lines, for the occasions we need that. But it would be absurd for Vim to process a multi-megabyte modeline. By all means abuse me for my cheeky suggestion to limit modelines to 100 bytes, but while doing that you might agree that some limit under 1MB should be enforced. A web browser should be able to handle anything thrown at it in a way that doesn't compromise security. _Every_ application should be able to handle anything thrown at it in a way that doesn't compromise security. Even if a program is perfect now, a later change can introduce a bug. Any program which can automatically execute untrusted code should sanity-check the input as a separate step from sandboxing. That is standard Security 101 stuff - not my idea. What you're suggesting isn't much different from security through obscurity. Jargon is great, but not when it's misused. Perl and Vim have exactly the same requirements: the need to safely handle code taken from an untrustworthy source. It makes no difference whether it comes directly from a network or from a disk. (If, like me, you use Vim as your source viewer for web pages, the need for the same level of security is obvious.) It doesn't matter, but for the record, Perl's tainting system is not related to the scenario you describe. Perl wants to make sure that untrusted input is not later used as the basis for some expression that could do harm, such as executing SQL code. John
Re: feedkeys() allowed in sandbox
A.J.Mechelynck wrote: Is folding really needed in a default modeline? Folding may be useful in a modeline. (Don't know what you call a default modeline.) By default modeline I mean I would like Vim to be changed so that its default behaviour is aggressively safe. If wanted, there could be a new option to enable clever features, and a user could choose to allow modelines with folding or expression evaluation, etc. But the only long-term safe procedure is to have Vim *default* to work with only very restricted modelines (set tab and other options - no way to even get near executing code). I am wondering what the lack of comment on this topic indicates. Do you understand that another modeline vulnerability could allow the next file you open to overwrite all files under your home folder? Or it might overwrite all sectors on your disk, if you have sufficient privilege. How about if you go to another computer that you rarely use. Would you be happy using Vim on that computer? Network admins in secure environments should be prohibited from using Vim. If I am overlooking something, or am overly alarmist, please tell me. For anyone new to this, enter following in Google: vim vulnerability modeline I just noticed that the fourth hit features Ciaran McCreesh who discovered a vulnerability in January 2005. John
Re: feedkeys() allowed in sandbox
Matthew Winn wrote: I don't like the idea of preventing modelines over 100 bytes. I imagine (haven't looked) that a modeline has no hard limit to its length. So multi-megabyte modelines are probably handled by Vim. That's potentially offering attackers extraordinary power. Would someone who wants a modeline longer than 100 bytes please show us an example. How about a 200-byte limit? Modelines are enabled by default, and are very useful for things like setting tabs. So most people, and all new installs, will have modelines enabled. It's very poor security practice to offer a rich auto-execution environment with a single line of defence (the sandbox). This discussion reminds me of the days of the Code Red vulnerability in IIS (Microsoft web server), and of the years of repeated vulnerabilities in Internet Explorer. The IIS and IE developers just couldn't bring themselves to build in limits to what their wonderful software could do. But a web site might need a 100KB URL with hundreds of '../' paths!. Furthermore, what am I supposed to do if I want a long, complicated but legitimate modeline? I would like a default high security setting for handling modelines. If people want modelines that do complex stuff, I would recommend setting a new anything goes option. I like Perl's approach to untrustworthy data. It's flagged as tainted at the point it is read, and anything derived from it is also flagged as tainted. Perl has to have that system because part of its intended usage is to handle data entered into web pages. It's pretty complex and has taken years to get right. Vim is a text editor - it should not automatically execute code in any old file that I might accidentally open. John
Re: feedkeys() allowed in sandbox
Bram Moolenaar wrote: That's pretty nasty. I'll make a patch right away. Thanks. However, perhaps the modeline concept needs more safety - defence in depth. Perhaps modelines should only allow a VERY limited set of operations by default (even more restricted than now). Googling for 'vim feedkeys joke' shows April 1 joke with the following (I've replaced vim with vvv): vvv: foldmethod=expr:foldexpr=feedkeys( \\esc\\x3a%!cat\\x20-n\\CR\\esc\\x3a%s/./\:)/g\\CR \\esc\\x3aq!\\CR): I'm too lazy to unobfuscate this, but one glance tells you that modelines should not be fixed - going down that path is likely to give a new vulnerability every year. Instead, modelines should be SEVERELY limited by default. Examples: Total length 100 bytes. No expressions; no function calls; no execution. Treat a double-quoted string as if in single quotes. Is folding really needed in a default modeline? John
Re: feedkeys() allowed in sandbox
Tomas Golembiovsky wrote: today somebody came to #vim, and pasted some modeline (containig joke or such). Thanks for raising that issue. I found the April 1 joke with Google. I actually noticed that posting (seeing Vim while browsing a security list caught my attention), but there's so much waffle out there that I didn't pay any attention to the point of the message. John
Re: feedkeys() allowed in sandbox
Bram Moolenaar wrote: Perhaps modelines should only allow a VERY limited set of operations by default (even more restricted than now). Sure, simply use :set nomodeline. I'm suggesting defence in depth. My vimrc might have ':set nomodeline', but what if I make a mistake? What if I'm using some other machine where I'm not sure what's in vimrc? What if I use the -u option? And there are probably other scenarios where a simple oversight could cause me to execute a modeline in an untrusted file. What if I want modelines (but never to do more than set a few options like tabs). Even setting 'textwidth' to 2 may already be considered harmful, or at least annoying. I don't mind being occasionally irritated with a stupid modeline. But I really don't want an editor to execute code when I open a file. Change volatile settings - no problem. Execute - no thanks. Perhaps we can add yet-another-option to completely disable setting some options from the modeline. Modelines should default to be safe (safe by design, AND safe because of defence in depth). If another option were added, it should be to allow expressions or other features that are potentially unsafe (not disallow unsafe features). Potentially unsafe means we're pretty sure it IS safe, but (for example), it's simply not worthwhile allowing a modeline longer than 100 bytes because if another vulnerability were ever found, we don't want to make it easy for the attacker. It's better to make sure the sandbox works as it should. Of course, but bitter experience shows that defence in depth is the best strategy. Vim has a lot of very clever features that are too complex to ever be secure, when executing a modeline from an untrusted source. John
Re: BOF Vim 8 - EncryptLine
Robert Lee wrote: What is wrong with SCP/SFTP? If these are not available, externally encrypt the file. You can even make a vim macro to do the job IIRC. Text editors don't do encryption and never should. I promise to stop posting when everyone else does! SCP etc just encrypts the traffic when copying a sensitive file to another machine. After backups are taken and stored, and various other stuff happens, your sensitive file can end up in quite a lot of places. Defence-in-depth means you have to encrypt the actual secret (the file, or the secret parts of the file). As Tony pointed out, Vim can encrypt a file. That is good because if you rely on scripts and what-have-you, there can be temp files, and files left over when something crashes. It's much better if Vim handles the decryption and encryption for you - much more convenient, and reliable, and a lot more secure. I can see that my EncryptLine proposal doesn't have any support. Fair enough - I accept the judgement. But the idea is not stupid. When you document tricky stuff on a network, you end up with a file where normal file-access security is good enough to protect 95% of the content. What about the passwords in the document? You really need to encrypt the file to protect them, but that means you have to decrypt the file (enter its key) everytime you need to extract some fact (like an IP address). I have actually implemented my EncryptLine on an obsolete editor and it works really well - but only because I have a need for it. John
Re: BOF Vim 8 - Suggestions
A.J.Mechelynck wrote:
IMHO it is important that function keys (with the exception of F1 = :help)
should by default _not_ have preset functions in Vim, in order that they
be safely available for whatever mappings any user would want to assign to
them, without competing with existing functions. There aren't so many keys
that users can safely use as the {lhs} of a mapping with no fear that it
will collide with an existing function.
For the record, I don't want function keys to be mapped by default. I am
suggesting that there should be a really simple (preferably built-in) way to
invoke a sample set of mappings for a C programmer.
For example, I could then send someone an email telling them to download
Vim and enter command :set template=cprogram (or whatever). I could
then advise the new user (a C programmer, not a dummy) that they can do
(whatever) to grep stuff, and (whatever) to use ctags. You would then have
one more converted Vim user!
As a final comment, I would recommend that any such template should
include mappings:
- Clear search highlights and the message line.
- Search for highlighted text.
John
Re: BOF Vim 8 - EncryptLine
Marc Weber wrote: 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. I don't think this should be a general vim feature either. Yet another idea to solve this: Why not use syntax and set forgground/background color to the same value to hide the text? Then you don't even notice that there is text. OK - I'm convinced that EncryptLine is not wanted! However, I want the secret to really be encrypted because I use a system to copy my data files from machine to machine for backups. The encryption is to protect the secret if someone somehow gets access to the file. John
Re: Odp: BOF Vim 8 - Suggestions
A.J.Mechelynck wrote: 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: ... Good advice, as always, Tony. But I am trying to crack a different nut. In the BOF talk, Bram really was asking for ideas on what would make new users flock to Vim. These days there are a lot of really good editors. No one is going to spend a couple of hours methodically working through vimtutor (sorry Bram!). A new user is just going to try Vim as an editor. If the default Vim behaviour confuses or upsets the user, Vim will never be used again. I sense an attitude here that it's just the luser's loss if they don't learn how to use Vim. Fair enough, but there should be a way for a non-vi user to enter a command telling Vim I'm one of those 95% of people who use a modern PC - please switch to a useful mode. I had the experience of advising a very competent programmer who got a job working on virtual memory in the Linux kernel (previously he had only dabbled in Linux, and had developed under Windows). At the time, we couldn't meet, and I was restricted to providing advice via email. Let me tell you, it is pretty well impossible to convince someone to use Vim via email. The guy wanted to do stuff right now, and I would send some 100-line email with instructions on how he could do this and that to vimrc, and then everything would be simple. One problem was how search highlighting is persistent (which is great), but it is very distracting to some people when you want to turn your attention to another issue. Telling him how to map a key to do ':nohl' is just unnecessary mumbo jumbo. John
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: Make an easy way to encrypt a secret within a line. [Really complex scheme to implement this.] Why is it not enough to simply implement a function that encrypts/decrypts a range of text, much like g? ROT13s a range of text? Because the scheme needs to be simple to use. Once you have that, you have the danger that you will accidentally encrypt or decrypt twice ... then you can lose data. You need some safety checks from a carefully-written program ... although I suppose you could incorporate all that in your hypothetical function. John
Re: BOF Vim 8 - EncryptLine
Bram Moolenaar wwrote: Suggested new feature: Make an easy way to encrypt a secret within a line. This is very a specific feature. You should implement this in a script, this doesn't sound like something Vim should support internally. OK. I just thought I would mention the concept because I find it useful, and AFAIK it's a novel idea that might have appealed. John
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: 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 Let's not start a religious war, but FWIW many authorities have changed their mind and no longer advocate the don't write down a password advice. In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). John
Re: BOF Vim 8 - Suggestions
Bram Moolenaar wrote: Mostly PageUp and PageDown do the reverse of each other. If you mean that the cursor has moved, that is a completely different thing. I'm not sure what completely different thing adds. I'm just trying to respond to your call for suggestions on how to make Vim more attractive to new users. I know a couple of people who don't like the fact that, in Vim, PageUp does not reverse PageDown. Naturally I am talking about the cursor moving. Switching off search highlighting is part of the tutor. People who skip the vimtutor are going to run into trouble anyway. OK - but you could make Vim more attractive if (when enabled by some new option) pressing Escape in Normal mode cleared search highlights and cleared the message line. I do agree that good defaults are important. But backwards compatibility is also important. It's not always easy to make a choice. Suggestion: Provide a simple way for a user to invoke a standard set of predefined mappings. In fact, there could be various predefined themes that insert useful settings into vimrc. Then, I could write an email to a friend saying Run gvim and do stuff to select a theme. Then you can press F11 to do clever thing. For example, perhaps F11 = :cn, Shift-F11 = :cp. Naturally there would be a lot of different opinion on what should be included. Anything would be better than the current situation where I have to convince a prospective new user to become a guru before they can use some of Vim's brilliant features. John
Re: Odp: BOF Vim 8 - Suggestions
Nikolai Weibull wrote: Perhaps a better way is to leave 'hlsearch' off and provide a binding that toggles it on and off. That way you don't get the distracting highlighting until you actually request it. OK but I imagine most people would like hlsearch on while they are searching (I certainly do). I am trying to make a slightly different point: 1. Bram has asked for ideas on how to popularise Vim. 2. I think better default behaviour would be best. IMHO it is quite idiotic that Vim has the really great feature of globally highlighting searches, but the user has to learn how to map keys to make it work in a sensible way. I suppose there are people who don't mind the distracting highlights once they've finished looking at them, but I'm pretty confident that most people here have a mapping to deal with the situation. All of what I am saying it totally irrelevant if there is no desire to popularise Vim. John
Re: Odp: BOF Vim 8 - Suggestions
A.J.Mechelynck wrote: I sense an attitude here that it's just the luser's loss if they don't learn how to use Vim. Fair enough, but there should be a way for a non-vi user to enter a command telling Vim I'm one of those 95% of people who use a modern PC - please switch to a useful mode. Easy Vim and mswin.vim were written for exactly that purpose, and IMHO they cripple Vim to almost complete _un_usefulness. Vim is a very powerful editor, but to be able to use it, you need at the very least to understand the difference between Normal mode and Insert mode. To use it like the fine tool it is, you need to study, just like one needs to study to become a concert pianist. If you're one of those 95% of users who need to be led by the hand by their OS and editor, and are too dumb for a modal editor, go use Notepad and stop bugging us. I accidentally said mode with the unintended suggestion that I was whining about Normal mode etc. Sorry. I totally agree that a Vim user has to work with Vim, and not try to pretend it is something different. Normal and Insert modes are fine by me. By a useful mode I meant a more accessible implementation of core features. Take searching. Incremental search and global search highlighting are sensational. But new users are going to want to turn the highlighting off (gedit has a menu item for this). It's obvious that most people are going to want a key mapping. So why not provide a standard mapping? OK, I can understand that you may not want the standard mappings enabled by default. So provide some new command to enable them. Why not just type :noh at the keyboard then, if you can't use a mapping? Are you suggesting this in the context of my proposal to improve the experience for new Vim users, in order to popularise Vim? There has to be an EASY way to turn off search highlights! John
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. I don't understand what you're trying to say in the first part of your sentence. I promise the list that I won't post about this again, but FWIW I'm not telling you how I work, I'm describing how most people in the business say they work (from talking to people, and following lists etc). Most networks have lots of devices which require accounts. A router, a firewall, a mail server, ten other servers, etc. Then there are your various email accounts - some important, some junk. Single sign-on can integrate many, or even most of these. But not all. So, most network admins need to record all the account details, possibly with notes, e.g. just how do you log on to that wireless access point that you last configured six months ago. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). Which defeats the whole point of having multiple passwords, as if someone figures out the master password then the other passwords will also be available. Given that you're going to reveal the password to anyone with a knife, there doesn't seem to be much point in having bullet proof security. I'm sure many people do as you suggest, but take it from me that many other people do not use the same password on their firewall and their mail server etc. So it's better to use one good password/passphrase and stick with it. Diceware is a really nice system: http://www.diceware.com/ John
Re: Odp: BOF Vim 8 - Suggestions
Nikolai Weibull wrote: Well, hlsearch only kicks in /after/ you've completed your search, whether you're using 'incsearch' or not. I once thought this was a nice feature, but I've realized that I rarely need to have other matches highlighted. I mean, either I've found what I want using 'incsearch', or I have failed to find the text location that I wanted, and highlighting the other matches won't really help much. Narrowing your search using 'incsearch' is often a lot quicker than doing a quick search and pressing 'n' a bunch of times to get to the right match. What you describe works well in many circumstances. But I find that the global highlighting is invaluable when programming. Built-in to Vim is the fact that pressing * searches for the current word. Programmers love this. IMHO they would appreciate a simple way to clear the highlights _and_ the message line when turning attention to something else. Searching for non-existent junk is just too distracting to my mental process. John
Re: BOF Vim 8 - Suggestions
Ilya Bobir wrote: If you think that you can provide a better defaults for novice users you can just write a script that will adjust vim the way you see it and ask Bram to add it into the distribution along with a note in the tutor OK. Perhaps that would handle the issue. I don't care how it's done, my aim is just to make the suggestion that to popularise Vim, it would be helpful to provide easily-accessible and well-thought-out defaults for some of Vim's more clever features. John
Re: BOF Vim 8 - Suggestions
Bram Moolenaar wrote: No, I don't want that. Pressing ESC is to get back to Normal mode, it should not have side effects like this. OK. But my suggestion was not that ESC would go to Normal mode _and_ clear highlighting. My proposal was that if I start in Insert mode, then press ESC I would be in Normal mode (as normal :), but if I press ESC again then highlighting and message text would be cleared. I'm happy so long as you've heard my idea. A couple of people here seem to think that _I_ want these suggestions. Not at all. I'm fluent in Vim and don't need any of my proposals for myself. But my recent experience of trying to make Vim attractive to a programmer moving into Linux showed me that some simple changes to Vim might make it a lot more attractive to new users. You appear to assume that what you want is what everybody wants. No! For posterity let me record that I am not one of those people. I'm only making these suggestions because I know you want to promote Vim usage, and some way to easily invoke a pre-defined set of behaviour for a modern PC would help IMHO. Imagine how many exceptions we need to handle in the documentation: if you use theme X then this doesn't work and you need to type XYZ. I take your point and agree. But I will make one final suggestion: Do not hide how Vim works. Tell users about vimrc, and what a mapping is, etc. People who would use Vim are smart, and can instantly understand that there is a config file, and that keys can be mapped. But a new user will probably not want to take the time to work out the details and their optimum settings right now. Take the wonderful quickfix window (which I use mainly for vimgrep). Using quickfix with ':copen' etc just doesn't work for me. I don't mind typing a few commands, but in this situation, the commands interfere too much with my thoughts. Once I mapped keys for :copen, :cn and :cp, quickfix was a magnificent feature. My vague concept about a theme is that it would insert text into vimrc. The user would be told this, and they could modify the text to taste. Right now, it is pretty easy to get BufExplorer working, and then \be is the default key sequence to start it. That's like what I am proposing for other killer features of Vim. You can always tell someone to download your script and use it. There are too many tips and scripts already. I was hoping (*not* for me!) to integrate some of the best work procedures into one or two pre-defined behaviours. John
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
