Re: Apparent Vim 7.0 bug (re comments)
A.J.Mechelynck wrote: Robert Lee wrote: I have a gvim 7.0 (win32 with +comments) that seems to be ignoring the set comments line in my .vimrc file. I can submit the entire .vimrc file if desired but the relevant line is: set comments=s:/**,mb:*,ex:*/ What I get is this (vim default?): /* ** ** */ and what I expect is this (phpdoc standard syntax): /** * * */ This seems to indicate that vim was compiled without +comments but according to :version (posted below), this directive was included. This is an unmodified gvim binary as downloaded very recently from vim.org. I doubt that this is a bug, but I don't see what else could be causing this. Thanks for any help! -Robert I haven't delved very deep into the 'comments' options. In CSS files it is set (by the ftplugin, I guess) to comments=s1:/*,mb:*,ex:*/ and I get /* * * */ With your settings, I see /** *__ *__ */ where the underscores represent spaces which are removed if I add no text; but there must be some other relevant settings, because I see it if I do it after :set ft=css but not in a virgin [No Name] buffer, where Vim adds no comment leader. -- Are you sure you typed _both_ asterisks after the slash in the first comment line? Best regards, Tony. Tony, thanks for your help. I discovered that the problem was caused by the lines: au BufWinLeave * mkview au BufWinEnter * silent loadview Apparently the view file that is created contains a copy of the vimrc settings. This prevents changes to the vimrc to be honored once a file has been opened. The temporary fix was to clean up the vimfiles/view directory. I think the right fix is to move these files to the very top of the vimrc file, but I am skeptical that this will help at all. I wish mkview only saved folds/marks/cursor position information instead of a full vimrc copy. I also discovered an unrelated error caused by these lines, which is fixed by using: au BufWinLeave *.* mkview au BufWinEnter *.* silent loadview ...instead. Hope some of this helps someone else with similar problems (e.g. vimrc changes being ignored for existing files). -Robert
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
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: BOF Vim 8 - EncryptLine
John Beckett wrote: 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 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. -Robert
Vim 8.0 Suggestion
I'd like to see an external .vimrc editor shipping with gVim and directly accessible from within easy mode (e.g. on the tools menu). The editor would likely be a totally separate binary though, so maybe a separate project is called for. What I have in mind is a tabbed dialog (depending on platform), that behaves like any native dialog on the target platform. So under windows you would have OK, Apply and Cancel (assuming that applying .vimrc changes to an active vim window is even possible). Only the most basic settings would be provided (obviously). This is intended for users absolutely new to gVim. Tabs might include: - Shortcuts (mappings), grouped by mode, sorted by keystrokes - Abbreviations, similar to above (a.k.a. Auto-correct or Auto-complete) - Per-language settings (smartindent, formatoptions, textwidth) - Appearance (colors, fonts, line numbering, titlebar text, tabbar text, status bar text, window chrome features) - Syntax Highlighting Colors (a.k.a. a colorscheme editor) - Behaviors (search behavior, mouse behavior, command history, scroll offset, foldmethod, etc) Also, it would be nice to have native Win32 help (chm). This would annoy most of us but new users would really like to see this I think. Again, this can be an external project. Also, a real built in file browser would be nice (e.g. a sidebar similar to that in EasyEdit). Actually an optional Browser Tabpage showing a Windows Explorer-like view would be killer on Win32. Oh, and the ability to add a New Tab button to the tab bar. Double-clicking does not work properly when you are using a text-mode tab bar. Just brainstorming. -Robert
Re: replace VimScript
Nikolai Weibull wrote: On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. What plugins/functionality are we missing that require better efficiency? Efficiency is definitely important. VimScript is probably in the order of 10^6 times slower (if not more) than C, and yet we have loads and loads of usable plugins. And what about the size of, for example, Tamarin. It's quite a big piece of software. That would certainly incur a memory penalty. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? Microsoft has, though hardly to any real degree of success, always pushed for VBA. Sure it has JScript as well and many languages could be used for application automation of windows applications. There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Wasn't that sort of my argument? Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? I don't see why you have to replace VimScript with ECMAScript to get ECMAScripts do what can be done with the, for example, Ruby bindings. As for following the leader, you are on shaky ground. No, but the following argument certainly is: Vim followed in the footsteps of vi just as Linux followed in the footsteps of Unix. Do you see something wrong with adopting good choices simply because other people are making the same good choices? I think that recognizing good choices being made by others and benefiting from them is a pretty good idea. Yes, Vim took over where vi had stagnated. Linux was created as a free version of a Unix-like operating system. I don't see how that has anything to do with rip out all the internals of Vim and replace them with a spider-monkey-type-thingy. I mean, it's not like Bram had Vi, removed insert mode and replaced it with virtual replace mode and made a better editor. (Yes, straw-man that if you like.) And just because companies like Adobe and software foundations like Mozilla have chosen JavaScript (and most Adobe applications have a COM interface, so their not usually limited to just JavaScript) for their extension languages doesn't mean it makes sense for others. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. The same applies to Intercal. I don't see the relevance. You seem to have a particularly hostile view toward ECMAScript, beyond a simple preference for the status quo, and I'm not sure why. Would you like me to talk about why I like it as a language, rather than why I think it would benefit Vim? Would you like it if I talked condescending to you? The only question that is really relevant here is: why it isn't enough with having an ECMAScript extension instead of having it replace VimScript? The following arguments have been given: 1. Because people wouldn't have to learn another language 2. Because it is standardized 3. Because lots of people are working on efficient implementations Argument 1) fails because not all people know ECMAScript in the first place. Arguably there are many other choices for languages that more people know than ECMAScript. This is completely true. EMCAScript, however, is never going away and is known by a very large number of users (both technical and non-technical). Frankly, one of Vim's greatest barriers-of-entry is the learning curve. I think much of this is due to its use of proprietary scripting formats. I think there is probably a great deal of overlap between Vim users and current EMCAScript (a.k.a. JavaScript) users. For example, I'd imaging that many PHP developers use Vim as their primary editor (such as myself)...and that most of those users use JavaScript on the client. Argument 2) fails because using a standardized language instead of a application-specific language gives us no advantages. On can also
Re: surprised by beta
Edward L. Fox wrote: On 5/8/07, scott [EMAIL PROTECTED] wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me i am not asking any questions here, it's more like i'm warning those who may prefer to stay with a stable version No, there won't be any tags, branches here, every thing is just going linearly, giggling. I just stumbled upon the svn update to disaster myself. Maybe its time to start getting a bit serious about project management? To the svn maintainer: The best practice is for the repository root to look something like this: /trunk (mirror of CVS, as usual) /tags (contains 7.0/ and 7.1a/ folders -- obviously these folders are static) /branches (possibly used for contribs such as patches that didn't make it into trunk (Bram's version) yet) To anyone else afflicted: To downgrade back to 7.0-stable, just do an svn update -r NNN where NNN is the revision you want to downgrade to. Check the logs for the exact revision, I don't know off hand. Cheers, -Robert
Re: surprised by beta
Bram Moolenaar wrote: Mr Toothpik wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me What errors? Bram, The SVN Repos has conflict markers left in the file filetype.vim, effectively causing syntax errors. This issue is specific to the SVN repository (CVS/FTP users unaffected). I think a conflict occurred when the 7.1a patch 1 was merged in, and that conflict was never resolved by the SVN maintainer. This conflict can be trivially fixed be removing the conflict markers (, and ==). I didn't take a close look at the issue though. -Robert
Re: surprised by beta
Stefano Zacchiroli wrote: On Tue, May 08, 2007 at 04:50:36PM -0500, Robert Lee wrote: The SVN Repos has conflict markers left in the file filetype.vim, Sorry for the silly question, but the answer is not clear to me from your text: is your working copy that has conflict markers or the last committed version in the repository which has been committed without removing conflict markers? I assumed the repository as I make no local changes to my checkout and didn't get any errors back from svn update. I ran the update yesterday and got r263. Everything compiled smooth, but I got errors on startup. I did an svn update -r 260 without thinking much of it (I thought maybe I compiled wrong -- and maybe I did). Revision 260 is what I was running before I did the update yesterday and is running again now without a hitch. To be honest, I never investigated the issue enough to know the exact problem, but whatever it was, it was either caused by me and is unrelated to Scott's issue, or is in the repository somewhere between r260 and r263. Based on the specific information provided by Scott, I assumed that there are markers left in the file in the repository. To check for myself, I just did a fresh checkout into a new folder of r263 and I see no markers there, so maybe I did compile wrong after all. The diff of 262:263 is gigantic at over 2mb (Bram, you've been busy!), so I don't know if I want to pour over it too much more than I have already. Scott: Do you still have the version of filetype.vim with the markers in it? I overwrote the r263 checkout I had trouble with :(. By the way, to get out of 7.1a.001 and back to 7.0.243 (which I assume is what you wanted to begin with), just use: svn update -r 261 and recompile. -Robert
Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
A.J.Mechelynck wrote: Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. Tony, Out of curiosity, what would vim do in this case: cp -f /dev/null ~/.viminfo chmod 400 ~/.viminfo ? Would it give any write errors? Would it delete and recreate? Would the file be left blank on exit? I guess intuitively I would expect the file to be left blank (unmodified) without vim giving me any errors. But IIUC, vim would, on exit, actually silently delete the blank file, and create a new one with new contents with the permissions set to r. Is this correct? Thanks! -Robert
Re: VimWiki - released finally
Sebastian, Why not utilize the talk: pages for the comments (see discussion tab at top of each wiki page)? Just curious. -Robert Sebastian Menge wrote: [cross-posted to vim, vim-dev, vim-announce, wikia-l] Hi all Finally I have imported all the vim tips from http://vim.org/tips to http://vim.wikia.com and set up a minimal infrastructure to keep things going. Not everything is perfect, but I think it is usable now. Thanks to all the support from [EMAIL PROTECTED] and especially to the very kind wikia community (#wikia on freenode and the mailing list, Greetings!). Some words on contribution: A good wiki depends on two main factors: Excellent content and a lively community. We have a lot of good content now, but to make it excellent we need You! If you ever posted a tip or a comment to the old tips database, please have a look at it on the wiki, and review the page. Every little bit helps! See you on the wiki, Sebastian.
