Re: collapsing single lines of html tag attributes via plugin??
On Fri, 1 Jun 2007 15:25:25 -0600, fREW [EMAIL PROTECTED] wrote: On 6/1/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Sounds like Vince Negri's conceal patch to vim would come in handy for this. [snip] I would use conceal if it were in standard vim. Definitely. So would I. It's only nervousness at using unofficial patches that puts me off. I'd also be interested in a view-only mode that conceals characters in the current line as well, if that's possible. (I have some large report files for which I use Vim to colour the text for easy reading, but that means some space in the file is taken up with marker characters to trigger the highlighting. It'd be nice to be able to collapse all the markers.) -- Matthew Winn
Re: JSVI: Vi implemented in Javascript
On Wed, 30 May 2007 14:21:27 -0400, Kevin Old [EMAIL PROTECTED] wrote: Not sure if everyone's seen this, but it's definitely cool and quite accurate. http://ajaxian.com/archives/jsvi-you-love-vi-you-love-javascript-now-you-have-both Unfortunately, in Opera it detects shift-presses as extra keys in their own right instead of modifiers, so something like :%s/a/b/g fails because the % is preceded by the extra character. I once created a single-line emulation of vi in Perl for a terminal- oriented program I was writing. It's surprising how little code you need to implement the basic editing commands. I think it's because once you've provided w to move to the next word you get cw and dw almost for free, and so on for other movements. -- Matthew Winn
Re: Why bottom-posting is prefered on Vim Mainling List?
On Tue, 29 May 2007 21:29:57 +0200, David Ne?as (Yeti) [EMAIL PROTECTED] wrote: On Tue, May 29, 2007 at 09:14:43PM +0200, Tobias Klausmann wrote: PS: On another note: how do you (as in y'all) feel about somebody re-arranging your text when quoting you? I guess the simple parts (everything for example gw} does) are okay with just about everyone. But what about the order of points made? Anything that improves the context of the reply and makes it easier to follow (wrt to the replied-to post) is good. I agree. So long as the meaning of the quotes isn't altered in a way that reflects badly on the earlier posters, I don't have a problem with rearranging quotes to deal with points in a better order. Really, what it all comes down to is making your point as clearly as possible, taking into account not only that you have the post to which you're replying fresh in your mind but other readers may not, but also that by the time your response is read it may be separated from its parent by many intervening posts. Everything that's considered good posting style follows logically from that. -- Matthew Winn
Re: breakindent, take 2
On Mon, 28 May 2007 16:04:17 +0200, A.J.Mechelynck [EMAIL PROTECTED] wrote: With this change plus 'linebreak' on, it could be made to simulate French paragrah style for text, where the first line of a paragraph starts maybe 1em or so right of the left margin (but with no blank line, unlike American paragraph style which uses flush-left alignment with a blank line between paragraphs). That would be useful. Would there be any benefit from making it a string option that accepted numbers only, so there could be three styles? breakindent=nabsolute positioning or broken lines breakindent=+n broken lines have additional indentation breakindent=-n broken lines have reduced indentation -- Matthew Winn
Re: Why bottom-posting is prefered on Vim Mainling List?
the entire thread they can look at other messages or consult an archive. Quoting is used merely so they don't _need_ to check other messages in order to understand the current one.) On one usenet group I use there are two posters who regularly get into childish and pointless fights. Both of them bottom-post and neither one trims their quotes, which means that in the end both are posting 500-line messages with one or two lines of insults at the end. Most regulars find their squabbles easy to recognise so nobody reads the messages anyway, but it does serve as an illustration that everyone should think carefully about what they quote, not simply leave the entire quoted message there because that's how the software sets up the response. Well, since no one could convice another, I'll stick to the community rule. That's the wrong attitude. This is the Internet. You're supposed to insist that you know better than everyone else even if they've been using the Internet for decades, and you have loads of lurkers who support your point of view but they're all too scared of The Clique to speak up, and when you're in charge you'll Show Us All. That's the Internet Way. People aren't supposed to be reasonable. (Dammit, there's not even a single !!!1!!1! or a LOLOL in this thread. What's wrong with you people? Have I fallen into an alternate universe where there's intelligence on the Internet?) -- Matthew Winn
Re: Why bottom-posting is prefered on Vim Mainling List?
On Tue, 29 May 2007 06:25:40 -0400, Michael Henry [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Matthew Winn [EMAIL PROTECTED] 2007-05-29 16:10:57: That's the wrong attitude. This is the Internet. You're supposed to insist that you know better than everyone else even if they've been using the Internet for decades, and you have loads of lurkers who support your point of view but they're all too scared of The Clique to speak up, and when you're in charge you'll Show Us All. I feel you're talking friendly and for good. But due to my poor English proficiency I don't seem to catch what you said. I think your English is good. Even native speakers sometimes have difficulty detecting sarcasm[1], which is notoriously easy to overlook in written language. I'm quite sure Matthew was being sarcastic here, and was actually complimenting your behavior by stating the opposite of the intended meaning (as the Wikipedia article on sarcasm explains it). I was; it hadn't occurred to me that it might not be clear to everyone whose first language isn't English. The point I was making is that the Vim list is civilised about discussions like this, unlike most places. I've seen similar debates elsewhere where the top-poster's response has been along the lines of This is my Internet on my computer; I'm going to behave how I want and I don't care how much trouble I cause for other people. -- Matthew Winn
Re: weird defaults in Feisty
On Tue, 22 May 2007 15:51:29 -0700, Micah Cowan [EMAIL PROTECTED] wrote: As at least one person has noted, there are many users who expect a vi-compatible program when they type vi at the command-line. When this isn't what you want, you really should consider changing your habit to use vim, as that way you are sure to get a featureful vim, if one is installed (vi could get you any one of a number of programs, depending on the system you're on). When I first used Vim I hated the way it made the text I was replacing vanish instead of showing me what I was overwriting, and I almost gave up on Vim before I discovered that it was possible to make it preserve the behaviour I was accustomed to. When using Vim on Unix I never rely on the system vimrc. I make a point of setting every option I want in my personal configuration files. I also have my own zsh alias from vi to vim so I know exactly what I'm getting. -- Matthew Winn
Re: C-X C-F completion and paths with spaces
On Sat, 19 May 2007 19:43:46 +0200, A.J.Mechelynck [EMAIL PROTECTED] wrote: It seems that the 'isfname' option doesn't include a space by default. But is that right? On both Windows and Unix, a filename may include spaces (though special steps must be taken to include such names in a command-line). Having a space in isfname by default would cause problems when trying to use gf. Vim would try to treat both the intended filename and all the surrounding spaces and words as part of the name. On Unix a filename may contain any character apart from slash or null, but the potential for problems is avoided by an informal policy of never creating names containing characters that are regularly used as delimiters. I can't begin to imagine why Microsoft thought it would be a good idea to put spaces in the names of system directories, but I guess the environment was probably something like the final panel of http://www.giantitp.com/comics/oots0130.html. -- Matthew Winn
Re: How to wrap sentences?
On Fri, 18 May 2007 20:24:17 -0600, Russell Bateman [EMAIL PROTECTED] wrote: As far as I know, Vim won't autowrap blocks of text you paste in. Something could be written I suppose, but I don't know of something already doing it. It depends how you paste. If you type +p in normal mode then the contents of the clipboard are pasted verbatim, but if you type ^R+ while in insert mode then the clipboard contents are wrapped in the same way as any other inserted text. -- Matthew Winn
Re: Vim version 7.1a BETA has been released
On Sun, 06 May 2007 14:46:22 +0200, A.J.Mechelynck [EMAIL PROTECTED] wrote: Michael Henry wrote: Gary Johnson wrote: On 2007-05-05, A.J.Mechelynck [EMAIL PROTECTED] wrote: (Warning: In the ln command as used here, the target name comes before the link name. I find this counter-intuitive.) It's not just me then. I have to think carefully about that every time I use ln. I used to find this hard to remember until I realized that 'ln' and 'cp' are very similar. The 'cp' command copies one or more sources to a destination; the 'ln' command links one or more sources to a destination as well. I tend to think of 'ln -s' as copy using symlinks. The order and meaning of the arguments is the same between the commands, which I now find consistent and intuitive. The problem is, cp -v file1 file2 outputs `file1' - `file2' (the data has been copied from file1 to file2) but ln -sv file1 file2 outputs file2 - file1 (file2 is now a link pointing to file1). I still have to call up the help or the manual every time I invoke it. Just remember that for all of cp, ln and mv, the existing file comes first. I think the confusion arises because people think of ln as create a link, so they see ln x y as create a link x..., which it isn't. It makes more sense if you think of it this way: mv x ymove file x to file y cp x ycopy file x to file y ln x ylink file x to file y -- Matthew Winn
Re: Favorite little-known feature
On Fri, 04 May 2007 21:37:21 -0500, Tim Chase [EMAIL PROTECTED] wrote: -dark corners of the regexp engine...especially back-references if you've never used them before; and the power of the :s command, along with the \= replacement for expression evaluation. I would say that if there's one single thing everyone should do to become a power user it is to become comfortable with regular expressions. Many tasks that might take hours by hand become no more than a couple of minutes work with Vim, sed or Perl and a suitable regular expression. Many people are deterred by the jumble of punctuation that makes regular expressions look like line noise, but they're well worth learning. The only disadvantage of regular expressions is that once you've learned to use them you tend to look scathingly at anything that doesn't provide them as a core feature. -- Matthew Winn
Re: feedkeys() allowed in sandbox
On Tue, 1 May 2007 19:42:02 +1000, John Beckett [EMAIL PROTECTED] wrote: 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. What constitutes a reasonable length? Vim has to load the entire document including its modeline into memory anyway, so there's no denial-of-service implications in allowing unlimited modelines. Your suggestion amounts to I won't use a modeline longer than X, so nobody will use a modeline longer than X. 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. It's a worthless measure that can't achieve anything useful and can only get in the way of legitimate uses. Any modeline long enough to be useful for a legitimate purpose must also be long enough to be useful for a hostile one. 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. Where do you draw the line between absurd and reasonable? When I write options I spell out the names in full so they're easier to understand for someone who doesn't know Vim well. That means that my modelines are quite long. But someone who wanted to save space could use the abbreviated form of an option. That means that if a modeline can be long enough to satisfy me it would give an attacker the ability to use several times as many options to craft their exploit as are needed for general use. 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. Why? In some places there are good reasons for limiting sizes. For example, RFC2822 places a limit of 998 characters on the length of a line. The reason for this is so that RFC2822-conforming applications don't have to deal with data of arbitrary length and allocate unlimited buffers to handle it. They can allocate a buffer 1001 characters long and discard anything that won't fit in the buffer, thereby preventing the possibility of denial-of-service attacks from someone sending a line several hundred megabytes long. Vim doesn't have that issue because it must load the entire file into memory anyway. Vim already knows how to deal with long lines, so there's no extra penalty incurred by a multi-megabyte modeline. 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. I've been working with computer security for over two decades. I know about standard security stuff. I also know that security that doesn't work is worse than no security at all, because it creates an illusion of protection where none exists. 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. That's what I meant, and that's exactly what Vim needs as well. Both applications read data from a source that can't be trusted, and both need to ensure that untrusted data can't be used in a situation where it could be dangerous. In Vim's case it needs to make sure that an expression used in an option set from a modeline can't be used later in a way that would cause harm, such as executing a command. Take a look at the original message. It sets foldmethod to something that triggers the execution of an external command after the modeline has been processed. Imagine you have a web page that contains the following (with the real command removed so it can't cause problems, just in case someone does view this in Vim; think of rm -rf /): !-- vim: fdm=expr fde=feedkeys(\\:!dangerous-command-here\\cr) -- Now imagine that someone uses Vim as their browser's view source application. That's _exactly_ the thing Perl's
Re: feedkeys() allowed in sandbox
On Sun, 29 Apr 2007 19:10:55 +1000, John Beckett [EMAIL PROTECTED] wrote: 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. It doesn't matter how many bytes are accepted. Security that depends on the assumption that an exploit can't be written in less than an arbitrarily chosen number of bytes is no security at all. Take a look at some of the coding golf competitions that take place online, where the object is to perform some complex task in the minimum number of characters. 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. Would someone who wants a modeline longer than 100 bytes please show us an example. How about a 200-byte limit? Oh, so nobody will need a long modeline? Just like they will never need more than [insert your favourite inaccurate prediction about the maximum amount of computing power anyone would ever need here]. 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!. 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. What you're suggesting isn't much different from security through obscurity. You're relying on the hope that nobody would ever be able to craft an exploit in under 100 bytes. Security doesn't work like that. Security needs to be something people can rely on to work every time, not something that depends on Well, let's hope nobody thinks of this. If Vim's modeline security is written correctly and securely then the length of modeline it can handle safely would depend only on the amount of memory it wants to allocate to hold it. If it isn't able to do that then there's no security at all. 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. ABSOLUTELY NOT! Are you honestly suggesting that to enter a long modeline you have to disable security? I wouldn't touch an editor like that. 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. 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.) -- Matthew Winn
Re: feedkeys() allowed in sandbox
On Sat, 28 Apr 2007 22:43:23 +1000, John Beckett [EMAIL PROTECTED] wrote: 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. I don't like the idea of preventing modelines over 100 bytes. To start with, there's no real logic behind it: it's an arbitrary number pulled out of thin air, and I put it in the same category as saying it's OK to use gets() so long as you use a long enough buffer that it'll never overflow. A modeline that's long enough to allow useful things to be done is long enough to allow unpleasant things to be done. Furthermore, what am I supposed to do if I want a long, complicated but legitimate modeline? 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. Tainted information cannot be used in unsafe operations, ever. From what I've read in this thread Vim does something similar, but in a way that's less complete. That's the right way to go about it. Setting an arbitrary limit and hoping it'll have the effect of improving security is far too optimistic for my tastes. -- Matthew Winn
Re: button t useless?
On Thu, 26 Apr 2007 09:06:01 -0700 (PDT), Arun Easi [EMAIL PROTECTED] wrote: In mapping. bdw cannot be used generically to delete the word under cursor. Single letter objects is one case. Other one is when the cursor is at the start of the word (I know you are talking when cursor is in the middle). When you are doing the operation visually, I do not see much advantage with one over the other. dw deletes to the start of the next word, while diw deletes the word but leaves any space beyond it intact. In most cases I find I want to remove a word completely, including pulling the next word over to the cursor, so dw is better for me. Starting from the middle of a word, it's a choice of bdw or diwdw. -- Matthew Winn
Re: blank line at end of file
On Mon, 23 Apr 2007 09:47:21 -0500, Tim Chase [EMAIL PROTECTED] wrote: I use vim7 on Win32 and every time I save a file, vim adds a new blank (CR+LF) line at the end of the file although it is not visible when in vim. Is there an option to disable this behaviour? yes, there is a way to break expectations :) To expand on that, the CRLF (or LF on Unix or CR on Mac) is a line _terminator_, not a line _separator_, even though many people refer to it as a separator. Every line in a text file should end with the correct end of line sequence, including the last line. If some other editor misinterprets a final CRLF to mean that there's an empty blank line at the end of the file then that editor is broken. Some products will consider a file without a terminator on the final line to have been truncated, and will report it as a potential problem because from the product's point of view the input has terminated unexpectedly in the middle of a line. I used to have this problem at work when people edited scripts with Notepad and then passed them to Oracle's SQL*Plus, resulting in a complaint about truncated input on every script. -- Matthew Winn
Re: VimWin
On Sun, 22 Apr 2007 21:48:58 +0200, A.J.Mechelynck [EMAIL PROTECTED] wrote: - virtual desktops. This may need some explaining to Windows-only people: On Windows there is one desktop, period. On X11, at least with some window managers, you may have up to 20 virtual desktops (you choose how many), arrange your windows at one or two per desktop in an uncluttered way, and switch desktops with one mouseclick or keypress. There is a small widget for each defined desktop in the taskbar, next to the buttons for the currently running tasks. People who like virtual desktops but are forced to use Windows should look into installing MSVDM. It's a Microsoft PowerToy that provides four virtual desktops for Windows XP. -- Matthew Winn
Re: Troubles configuring vim (multi-questions)
On Fri, 13 Apr 2007 08:44:26 -0700 (PDT), OnionKnight [EMAIL PROTECTED] wrote: No it didn't make a difference. When you put the cursor in normal mode over a tab character, which spans several characters, the cursor will be displayed at the end of that area whereas insert mode will put the cursor at the beginning of it. By default Vim (and vi) has always put the cursor on the end of a character that occupies multiple spaces on the screen. I don't know why this decision was taken, unless it was to make it easier to spot the difference between lines indented with tabs and those indented with spaces, but the cursor has to appear somewhere and it might as well be at the end as anywhere else. You can :set virtualedit=all to allow the cursor to be placed anywhere on the tab, but you need to take care not to damage your tab. If you start inserting in front of the tab then the text goes before the tab and the tab is shifted to the right as you'd expect, but if you insert in the middle of the tab the tab is expanded into spaces before the text is inserted. -- Matthew Winn
Re: Silly Question
On Fri, 06 Apr 2007 14:37:30 -0400, Mitch Wiedemann [EMAIL PROTECTED] wrote: I'm unlucky enough to have 'i' as the second letter in both my first and last names... So I get a jump to the middle of the screen, or to the first word in the line, and then boring ol' text insertion... I'm almost exactly the same, except that the end of my forename is placed one character to the right of yours. If I stick to lower case then it's a bit more interesting because the a becomes a mark, and the rest of my name makes the cursor stagger along the line without changing anything, ending up at the start of the word following the word containing the next t. Vowels are a problem. Unless you have an escape in your name, a, i and o are boring letters. I know someone named Veerle and her name is actually quite destructive, overwriting an entire line with l. What's the most interesting name anyone can find, and also the most damaging? -- Matthew Winn
Re: How to modify code so that only one space is between two characters or words?
On Fri, 06 Apr 2007 05:52:33 +, Eric Leenman [EMAIL PROTECTED] wrote: :%s/:\s\+in/: in/g This works for all lines containing one or more spaces. Why doesn't it work for lines which have no space between : and in? Use :%s/:\s*in/: in/g instead (replace the \+ with *: \+ means one or more, * means zero or more). -- Matthew Winn
Re: how to replace ESC to some other key?
On Thu, 05 Apr 2007 09:08:43 -0400, wangxu [EMAIL PROTECTED] wrote: but in this situation,is there any way to auto-indent *.py? I wouldn't have thought so, since the meaning of the code is implied by the indentation rather than vice versa. Personally I always indent using the basic autoindent option along with ^T and ^D. I format my code for the benefit of human readers (mainly myself), so I lay it out to maximise the clarity. Manual indentation works best for that, and after nearly two decades of practice my use of ^T and ^D as required has become automatic. -- Matthew Winn
Re: quick query about moving a selection
On Wed, 4 Apr 2007 10:23:49 -0400, Gene Kwiecinski [EMAIL PROTECTED] wrote: i know with i can move a selection to the right by one indent, how can i move a selection just one space ? Well, if you want to move by one indent, you can :set sw=1 ts=1 et which will then make and indent by one space (not one tab) or, you can I might've just forgotten to set sw=2, but I noticed that when I was editing a file and didn't want nested tabs being tabbed over to pretty much the right side of the screen, one little '' would tab it over 4 tabs (for ts=2) instead of just 1. Thought that was odd. You must have had shiftwidth at its default of 8. The indent used by and is affected only by the setting of shiftwidth and doesn't depend on the tabstop in any way. (The TYPE of whitespace added by depends on the tabstop option, but the amount of indentation isn't affected by it.) -- Matthew Winn
Re: Customizing vim: How to change the char before commands
On Sat, 24 Mar 2007 19:47:40 +1200, John Little [EMAIL PROTECTED] wrote: I suspect that on Bill Joy's original keyboard a colon was not a shifted key press. Ex's command prompt was a colon. When the vi(sual) command was added to ex it made sense for the temporary escape to ex mode to be a colon as well. I don't see a problem with having to use shift. There are really only two types of ex command used from vi: the infrequently used commands like :quit and :set, which occur only once or twice a session, and commands like :s that are capable of making so many changes at once that the overhead of having to use the shift key is small for the amount of work done. -- Matthew Winn
Re: Copying a Massive amount of text to the clipboard
On Wed, 21 Mar 2007 07:45:39 +0100, A.J.Mechelynck [EMAIL PROTECTED] wrote: Method II: If you know exactly the line numbers you want: :3,90003y + For Method II, see :help :y. And if you don't know the line numbers (and don't want to find out and remember them) you can go to the first line and create a mark (ma), go to the last line, and do :'a,.y + (This style of address specification works for vi too, though the + doesn't.) -- Matthew Winn
Re: improving encryption in vim
On Mon, 19 Mar 2007 09:22:08 -0600, Josh [EMAIL PROTECTED] wrote: There are no patent issues, but there is export issues, I live in the US The reason I suggested Rijndael is because there are no US export issues. Not only was it developed in Flanders so implementations outside the US abound, but also as Rijndael was the winning AES candidate the export of Rijndael implementations from the US is explicitly permitted. See the final paragraph of http://csrc.nist.gov/CryptoToolkit/aes/aesfact.html -- Matthew Winn
Re: improving encryption in vim
On Sun, 18 Mar 2007 15:57:33 -0600, Josh [EMAIL PROTECTED] wrote: The main problem that I see is that adding a strong encryption function can have regulation issues. That was the only reason that I thought about using the external library is to get around this. With an algorithm like Rijndael there are no patent issues (and there is even unencumbered public source code available), and the only problem is with countries that forbid the use of encryption software. I imagine that can be solved in the same way as other conditional compilation matters are tacked in Vim: putting the code in a separate file and using a compile-time option to include it where available. How secure does the encryption need to be? Considering that Rijndael offers 128-bit, 192-bit and 256-bit security with very fast and simple code, it's more a matter of: why would you bother with anything less than the best encryption you can get? -- Matthew Winn
Re: To imap or to iabbr
On Tue, 06 Mar 2007 15:45:48 -0600, Tim Chase [EMAIL PROTECTED]
wrote:
Multi-character mappings also have a slight delay in them, so in
the preceeding example, after I type HELI, there's a slight
pause while Vim sees if I am going to type U, or if I type
something else, so it knows how to behave.
Things get slightly more complex if you're writing code-block
expansions such as wanting IF to expand to
if (|) {
} else {
}
and put the cursor where the | is. It involves an expansion
(and thus suggests an :iab for the expansion) but also involves
moving the cursor to a particular position. I've not had luck
doing those as :iab expansions, so I resort to mappings...usually
prefixing them with an infrequently used character such as
control+G or a tilde as fits.
Abbreviations don't have the delay that mappings do, but they do mean
that Vim must wait until the character after the abbreviation has been
typed so it can distinguish between IF and IFFY, only expanding
the abbreviation in the first case.
I've never made much use of abbreviations. I did try using them back
when I first started using vi but I found that I had to choose arcane
abbreviation sequences in order to avoid expansions when I didn't want
them, and it eventually dawned on me that it was taking me longer to
recall the correct abbreviation than it would have taken to type out
the abbreviated phrase in full. So now I mainly use maps and function
keys for insert-time replacements.
One situation in which abbreviations work well is if you're writing
text and the house style is to write (say) National Aeronautics and
Space Administration in full rather than NASA. They're also useful
for fixing common typing errors: I often type adminsitration because
after being left out of the action for three letters my left hand gets
impatient and bounces off the s early to give it more time to head
t-wards, so an abbreviation to replace that with what I intended to
type is useful.
--
Matthew Winn
Re: Unicode U+2028 line separator
On Fri, 02 Mar 2007 20:24:44 +0100, A.J.Mechelynck [EMAIL PROTECTED] wrote: Bill Moseley wrote: I have a utf-8 file that uses the unicode line separator. Not something I've come across very often. In utf-8 the sequence is: 0xE2 0x80 0xA8 (e280a8) In a uxterm vim correctly reads (and sets) the file encoding as utf8 (there's no BOM on the file), but the U-2028 character is displayed as an un-displayable character and not displayed as a new line. That is, all the text is displayed as a single line. Can anyone educate me a bit on the use of the Line Separator character and if or how it can be supported in Vim? I may be wrong, but IIUC this codepoint plays the same role as the HTML br tag: it does not define an end of line in the text file which contains it, but it means that, when rendered typographically, as in a browser or a WYSIWYG editor (neither of which Vim is, or tries to mimic), the rendered output must have a linebreak at this point. IOW: I think it's a feature, not a bug. You can add a linebreak after every occurrence of that codepoint by using :exe %s/\Char-0x2028/ . '\0\r/g' Note that I intentionally use double quotes in the first part and single quotes in the second part. According to http://www.unicode.org/reports/tr13/tr13-9.html the correct way to treat U+2028 and U+2029 (paragraph separator) is to translate them into the platform's standard sequence for representing the end of a line. (What it actually says is that if the purpose of the line break is unambiguously known -- that is, whether it is the end of a line or the end of a paragraph -- then the corresponding Unicode character should be used. But Vim is a text editor and knows nothing of paragraphs, so I would expect both these characters to be translated into the platform's end-of-line representation.) However, this would be lossy, so if this were to be implemented I suspect an option would be required for the benefit of people who want to edit Unicode text without losing the distinction between line and paragraph endings. -- Matthew Winn
Re: pulling text to the right?
On Wed, 28 Feb 2007 12:55:23 -0800, Lev Lvovsky [EMAIL PROTECTED] wrote: That sort of does what I want, but it ends up moving the INT right along with it. I guess what I'm looking for is a combination of key strokes: COL1 INT, COL2 INT, COL3 INT, ^ I put my cursor at the column of the '^', on line 3 and press that keystroke, which would simultaneously go to the beginning of the line, space, go back to the '^', and 'x' from that position, to bring the INT back a space. The real goal of this formatting is to create text that looks like this: SOME_COL VARCHAR(32), SOME_COL12 INT, BLAH_BLAH1 BOOL, I would suppose that this can be made with a vim function right? I'd think it was likely, given that two days ago I posted a mapping that does exactly that. In fact you can do it exactly as you describe above by mapping something to maI Esc`ax. (Unlike my first try, this one won't stop when it runs out of spaces under the cursor.) -- Matthew Winn
Re: pulling text to the right?
On Mon, 26 Feb 2007 16:30:09 -0800, Lev Lvovsky [EMAIL PROTECTED]
wrote:
I'm sure there's a fancy word for this, but is there any way to pull
text to the right?
suppose I have the following:
COL1 INT,
COL2 INT,
COL3 INT,
I'd like to get COL3 aligned to COL1 and COL2, but to do that,
I need to put the cursor behind COL3, hit space several times, and
then align INT with the other INTs. Can I put my cursor to the
right of COL3, and pull it over to INT on the right?
I wouldn't bother with anything more than basic editing commands for
a single change like this. Just press I (to start inserting to the
left of the COL3), type spaces until the column is aligned, then Esc
kwwj (to put you in the right place for the INT) and dw (to remove the
unwanted spaces).
If you have tabs in the middle of the lines you may also need to press
i and some more spaces because the dw may remove too much.
Alternatively, this crude mapping will pull things over towards the
cursor. It works by transferring one whitespace character from one
side of the COL3 to the other:
:map [whatever]
:s/^\\(\\s*\\)\\(\\S.\\{-}\\)\\(\\s\\)\\(\\s*\\)\\%#/\\1\\3\\2\\4/CR``
Debackslashed, that expression is:
s/^\(\s*\)\(\S.\{-}\)\(\s\)\(\s*\)\%#/\1\3\2\4/
That is, match the leading spaces (if any), one or more words,
a single space, and then any additional spaces up to the cursor
position, and replace them but moving the single space to just
before the words.
--
Matthew Winn
Re: moving buffer changes to new file?
On Sun, 25 Feb 2007 10:06:18 +0300, Pavel Shevaev [EMAIL PROTECTED] wrote: :h :saveas BTW, is it possible somehow to rename file not save as? If you mean is it possible to change the name of a buffer without actually saving anything, then the answer is yes. Use :f new-file-name The new name will be used the next time the file is saved. If there's already an existing file with the new name then you'll have to use :w! (or :x!) to overwrite the existing file. -- Matthew Winn
Re: Insert mode and arrow keys philosophy
On Tue, 20 Feb 2007 17:28:37 -0500, Gene Kwiecinski [EMAIL PROTECTED] wrote: Pretty much so. Early dumbterminals (think ADM-3a and similar critters) didn't have arrow keys, but they *did* go so far as to have little arrow marks on the keycaps themselves, underneath the letters, on -- you guessed it -- h/j/k/l. I remember using that sort of terminal. At one point I also had to use one where the escape key was so far from the rest of the keys that I almost had to get up and walk across the room to reach it, so for a long time I was accustomed to using Ctrl-[ in place of escape. As for getting into the correct habits, I don't think it matters. Use whatever works. If you're frequently moving between keyboards with different layouts then it helps to stick with the main key block as much as possible, but otherwise use what is the most comfortable. When editing a file I usually use hjkl for movement, but if all I'm doing is viewing a file then I rest my right hand next to the cursor keys and use them instead, as I find it to be a more relaxed position. If there is a vi philosophy it's a matter of being familiar with all the ways of moving around and being able to use them. For example, if you're on the word moving in the previous sentence and want to add something before the full stop then a vi master will type f.i or t.a to get there, while someone less advanced might hit w until they're in the right place, then i. The wrong way to do it is to hit the right arrow key over and over again or to reach for the mouse: that's the notepad way of working, and it tarnishes the soul. -- Matthew Winn
Re: perl questioin.
On Mon, 19 Feb 2007 23:28:08 -0800, ayoub890 [EMAIL PROTECTED] wrote: I am running a perl script in a command inside make. I am trying to pass an environment variable to perl, modify it inside perl and see it changed inside make after returning from the perl script. What is happening is that perl see the environment variable and tries to modify it but make sees no change in the value of the environment variable after return from the perl script. Can someone tell me what I am doing wrong? Environment variables don't work in the way you think they do. They're not global. Each process has its own copy of the environment that is inherited from its parent at the time the process is created. If you change an environment variable in process A and then create a new child process B, both will have the same value for the variable. But now each process can change the variable separately: B's value came from the value that A had at the time B started, but there's no longer any connection between them. If you want to pass a value back from the child to the parent then you have to do it yourself, sending it back on standard output or storing it in a file somewhere and having the parent read it. -- Matthew Winn
Re: :wq vs ZZ
On Tue, 13 Feb 2007 18:22:34 -0500, Theerasak Photha [EMAIL PROTECTED] wrote: On 2/13/07, Gene Kwiecinski [EMAIL PROTECTED] wrote: I imagine there is a rationale for 'ZZ', but it's not readily apparent. (Something to do with C-z in DOS, or the end of the alphabet?) 'z' is already used, and the shift and z keys are adjacent on Murrrcan keyboards, so you can easily just quit out of the editor in almost a single hand-action. I understand the ergonomic value. Mentally it doesn't make as much sense though. It's supposed to make sense ergonomically, not mnemonically. When starting to use a new product you learn the keys once and use them many times. The vi approach was to make the useful commands easy to type rather than easy to remember, hence hjkl to move the cursor instead of ldur, and ZZ to save changes. Once you've learned the keys there's no longer any advantage to mnemonics so why punish your fingers with unnecessarily awkward keystrokes? (Looking over the keyboard and seeing that just about every key has a useful function, it seems to me that the ultimate goal of vi evolution is for a cat to be able to walk across a keyboard and type nothing but valid editing commands.) -- Matthew Winn
Re: do not match the longest pattern
On Thu, 08 Feb 2007 13:50:51 +0800, Bin Chen [EMAIL PROTECTED]
wrote:
In the help page:
If a - appears immediately after the {, then a shortest match
first algorithm is used (see example below). In particular,
\{-} is
the same as * but uses the shortest match first algorithm. BUT: A
match that starts earlier is preferred over a shorter match:
a\{-}b
matches aaab in xaaab.
What's the meaning of the BUT clause? If the \{-} function as above, the
a\{-}b should match ab not aaab.
Regular expression matchers work by starting at the beginning of the
string to be matched and seeing if it is possible to match the pattern
against the string at that point. If no match is possible then the
first character of the string is discarded and a match against the
pattern is attempted starting at the second character, then the third,
and so on.
But this continues only as long as no match is found. As soon as a
match is found the search ends and that match is returned, which means
that the match is always as far to the left as possible. If you are
interested in any other matches then you have to do the programming
yourself: for example, if you want the shortest match no matter where
it appears in the string then you'd have to save all possible matches
and look for the shortest one afterwards.
--
Matthew Winn
Re: replace with a number sequence
On Wed, 31 Jan 2007 15:23:36 +, Tom Whittock [EMAIL PROTECTED] wrote: the ex (colon) commands are one of the major parts of vim - I would highly recommend learning them a bit more, if you want to get the most out of the program. For me, without ex there would be very little point in using vim at all - I couldn't even write to a file ;) Unless you use ZZ. -- Matthew Winn
Re: BOF Vim 8 - EncryptLine
On Thu, 18 Jan 2007 11:04:00 +0100, Nicolas Weber
[EMAIL PROTECTED] wrote:
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.
Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner.
--
Matthew Winn
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: Reformat in visual area - vmap question
On Tue, 09 Jan 2007 17:45:56 +0200, Albie [EMAIL PROTECTED] wrote: First, run (in normal mode): :let mapleader That command will reveal the key you currently have configured to be your Leader. Assuming the output of the above command is: mapleader , You should then be able to execute the first command by going: v [moving around for selection] ,= For the second command, replace ,= above with ,g=. The Leader defaults to \ on some installations, I believe. \ is the default value, and that's the value used if mapleader is empty. It's a bad idea to set mapleader to , unless you have a keyboard where \ is hard to type, as , is already a Vim command. -- Matthew Winn
Re: c-wc-s on *nix vim
On Thu, 28 Dec 2006 19:43:27 +0100, DervishD [EMAIL PROTECTED] wrote: Usually, under UNIX, the c-s combination stops the TTY and c-q resumes it. For example, under Linux c-s has the same effect of pressing Scroll-Lock, and c-q does the opposite. Typing stty -ixon -ixoff at the shell prompt will disable this type of flow control if you don't want to use it. The original purpose of this was to regulate the flow of data over serial lines, so a computer wouldn't send data to a terminal faster than the terminal could display it. These days it's rarely necessary to use it: most connections to Unix are over TCP/IP or serial lines with hardware flow control, and the only remaining use of ^S/^Q is as a way of manually pausing output. If you never need it, feel free to turn it off. -- Matthew Winn
Re: Re[2]: vim-display problem?!
On Tue, 12 Dec 2006 17:20:15 +0800, mbbill [EMAIL PROTECTED] wrote: Hello Matthew, Tuesday, December 12, 2006, 5:00:30 PM, you wrote: ?On Mon, 11 Dec 2006 19:00:27 +0800, [EMAIL PROTECTED] wrote: ?No, this is not a problem. This is a feature... ;-) ?It's not even a feature. It's the right way of doing things. ?The character (or characters, if it's a DOS file) at the end of each ?line aren't line _separators_ but line _terminators_. Every line ?should end the same way, including the final one. That notepad doesn't ?do this is a long-standing bug in notepad, and is just one of the ?many, many reasons why nobody should use notepad for anything. But Emacs does not have the feature either . Then Emacs is wrong too. A text file is DEFINED as having lines terminated by a line termination sequence. On Unix this is a line feed, on DOS it's a carriage return/line feed pair, and on a Mac it's a carriage return. But this terminator IS NOT OPTIONAL. It's not All lines must be terminated by a line terminator except the last one. You can no more omit the line terminator on the final line than you can on any other line. If you do omit the final terminator the result is no longer a text file. If you really do want to omit the final line terminator then Vim will allow it if you set binary noendofline, but you should be aware that many programs that expect to read text files will break when using such a file as input because they don't contain extra code to deal with the special case of the last line of the input having no terminator. (Oracle's SQL*Plus, for example, throws a warning about truncated input. This is reasonable behaviour because an unterminated line is exactly what you'd get if the input was truncated.) -- Matthew Winn
Re: vim-display problem?!
On Mon, 11 Dec 2006 19:00:27 +0800, [EMAIL PROTECTED] wrote: No, this is not a problem. This is a feature... ;-) It's not even a feature. It's the right way of doing things. The character (or characters, if it's a DOS file) at the end of each line aren't line _separators_ but line _terminators_. Every line should end the same way, including the final one. That notepad doesn't do this is a long-standing bug in notepad, and is just one of the many, many reasons why nobody should use notepad for anything. -- Matthew Winn
Re: vim is too smart for its own good
On Thu, 31 Aug 2006 14:49:32 -0500, Tim Chase [EMAIL PROTECTED]
wrote:
There's always ed...
-more ubiquitous in its presence
-consistent in its behavior
-powerful
-tools like diff interoperate with it
-it can be used on a slow TTY
-can be used on with a one-line display
-smaller executable size
-easier to remember: *ed*itor, not *vi*sual editor
-no time or machine cycles wasted on screen refreshes
-historically significant
so many other bountiful blessings to using ed. ;)
Granted, I haven't come across an ed users mailing list, let
alone one as helpful as this list.
Hmmm...I wonder how hard it would be to add syntax highlighting
to ed... ;)
The wonderful thing about ed is that it encourages you to learn about
the power of regular expressions really, _really_ quickly, mainly
because there's no other way to make changes within a line.
In the late 1980s I used the Georgia Tech screen editor, which was a
sort of visual ed. You entered commands just like ed, but the top
of the screen was used to display twenty or so lines of your buffer
around the area you were editing. Each displayed line had a capital
letter associated with it and you could use this letter as a line
address instead of the line's number. An example of its display taken
from the manual:
A|
B|#include stdio.h
C|
D *|register int i;
E|
. - |for (i = 1; i = 12; i++)
G|putc ('\n', stderr);
$|
cmd |_
11:39 myfile ...
You can still get it, if you want to remember the good old days:
http://hpux.cs.utah.edu/hppd/hpux/Editors/se-1.3/
--
Matthew Winn
Re: Looking for the difference of two files, linewise
On Fri, 25 Aug 2006 16:58:38 -0400, Kamaraju Kusumanchi
[EMAIL PROTECTED] wrote:
On Friday 25 August 2006 14:04, Mike wrote:
On Fri, 25 Aug 2006, William O'Higgins Witteman might have said:
I have two files, one very long and the other much shorter. Every line
in the short file is also in the long file. What I need is a file with
every line in the long file *not* in the short file. Is there an easy
way to have vim provide me with my desired complementary file?
$ man comm
Sorry for the nitpicking. But this sometimes might not work. For example
$cat temp1.txt
temp3
temp1
$cat temp2.txt
temp2
temp3
temp4
temp1
temp5
$comm -3 temp1.txt temp2.txt
temp2
temp1
temp4
temp1
temp5
$diff temp1.txt temp2.txt | grep '^' | cut -f 1 -d ' ' --complement
temp2
temp4
temp5
The OP did not mention that his files were sorted. So comm command might not
be applicable for his case.
Alternatively, Perl offers a solution for files where the lines may be
in any order:
$ cat longfile
one
two
three
four
five
six
seven
eight
nine
ten
$ cat shortfile
nine
six
three
$ perl -e 'open S, $ARGV[0] or die $ARGV[0];
%lines = map { $_ = 1 } S;
close S;
open L, $ARGV[1] or die $ARGV[1];
while (L) { print unless exists $lines{$_} }
close L;' shortfile longfile
one
two
four
five
seven
eight
ten
--
Matthew Winn
Re: Re[2]: filename completion and filereadable
On Wed, 9 Aug 2006 23:03:12 -0400, Alan G Isaac [EMAIL PROTECTED] wrote: On Thu, 10 Aug 2006, A.J.Mechelynck apparently wrote: What is the raw string notation from Python ? IMHO it would only create one additional type of string. We already have single-quoted 'raw' strings in Vim, yet many people constantly forget that double-quoted strings in Vim are cooked. Yes, that is my point: Many people forget the difference between single and double quoted strings. Indeed when reading vimscript the difference is not immediately obvious (easily forgettable), which is unfortunate. Taking the Python approach that values explicitness, http://docs.python.org/ref/strings.html a raw string can be created r'like this' or rlike this. But ... versus '...' is just as explicit. It's also something shared by every Unix shell I've used, along with quite a few other languages such as Perl. In fact, apart from Python and XML I can't think of any languages that don't make a distinction between double and single quotes, as it's an extremely useful difference and it's a waste of a limited character set to ignore it. -- Matthew Winn
Re: Search and Replace with a Regular Expression
On Fri, 4 Aug 2006 09:07:35 -0400, striker [EMAIL PROTECTED] wrote: I agree with Chip and have a recommendation. Since you have been using Vim, Perl will be much easier to learn. A very good beginning book on Perl is located at http:// learn.perl.org/library/beginning_perl/ . It is not as thorough as the 'Camel' book, but has a lot of good info. and the price is right! When I first began studying programming Perl was over my head and seemed very difficult. I found it incredibly easy to learn Perl. I was faced with a large data-reformatting program written in uncommented C that needed to be adapted to a new input format. I started to work on it but it soon became clear that fixing the program would take a couple of weeks. I had vague memories of a language named Perl that was good for that sort of text processing, so at the weekend I went into London, bought the Camel book, skimmed through it on the train home, went into work on Monday and rewrote the entire application in Perl. Not only did it take me less than half the time to rewrite the code as it would have taken to fix it, but the Perl version ran three times faster than the original C. After using Vim for only a short time, Perl all of a sudden made a lot more sense. An excellent grasp of regular expressions is essential to get the best out of both. It's a pity that regular expressions look so much like line noise that most people are scared away from them, because regular expressions are where most of the power of both Perl and Vim is to be found. Perl 6 has tried to create a new type of regular expression that is clearer and easier to use, but to the novice it still looks like line noise only now it takes up twice as much room. -- Matthew Winn
Re: vim -S
On Mon, 31 Jul 2006 16:19:28 -0300, Rodolfo Borges [EMAIL PROTECTED] wrote: I made a file with vim commands, starting with #!/usr/bin/vim -S so I can execute the file directly, instead of using vim -S file. The problem is that vim tries to execute this first line too. Can we have a workaround on this? Like, ignoring #! at the start of a command, instead of giving the no ! allowed error? Or am I having it all wrong? One way is to create a file that is both a valid shell script and a valid Vim script by starting the file with the following line: exec vim -S $0 $@ [vim commands go here] (That's a dollar-zero after the -S, not dollar-capital-O.) When the shell runs this file it sees the exec command and runs Vim. Because $0 is the name of the script Vim opens the script and executes it, but it ignores the first line because it sees it as a comment. -- Matthew Winn
Re: scrolloff enhancement wish
On Fri, Jul 21, 2006 at 10:02:10AM +0200, Bram Moolenaar wrote: Yakov Lerner wrote: How about adding the option 'scrollfix' [to the todo.txt], which would fix the cursor on fixed line, in percantage 0-100. Value ':set scrollfix=50' would work like ':set scrolloff=999'. Value ':set scrollfix=67' would fix cursor 2/3 from top of screen. Value ':set scrolloff=0' would keep cursor at top line of screen. Value ':set scrolloff=100' would keep cursor at bottom line of screen. As you say, you can already do most of this by setting 'scrolloff' to a large number. If the cursor is really fixed at one position then using j would mean that the cursor remains in the same position and the text scrolls. That goes against what most people expect. I think it's not all that useful. I've had some situations where such a feature would be useful. A few weeks ago I was working with a large file containing many long SQL statements mixed in amongst other stuff. I was searching for the start of each statement, and it would have been very useful if I could have arranged it so that each search resulted in the cursor appearing a couple of lines from the the top of the screen with the SQL statement filling the space below it. In this case I set scrolloff to 100 so the start of each SQL statement was centred, but that gave me half a screen of context above the cursor when only two or three lines would have done, and caused the ends of the longest SQL statements to disappear below the bottom of the screen. I suppose there might be some way to map all the movement commands to reposition the current line to a certain place on the screen, but at the time I was doing all this it was quicker to scroll the text each time than it would have been to write all the necessary mappings. And we have too many options already... Too many options? Is that possible? -- Matthew Winn ([EMAIL PROTECTED])
Re: :edit {file} question
On Wed, Jul 19, 2006 at 06:10:43PM -0700, [EMAIL PROTECTED] wrote: What is the easiest way to edit a file that is in the same directory as the current file? E.g. I open a file like this: vim /x/y/z/w/file1.c and want to now open /x/y/z/w/file2.c? I just type :e ^R% to get the current filename, followed by enough ^Ws to remove the trailing parts I don't want. -- Matthew Winn ([EMAIL PROTECTED])
Re: Motions in visual(line|block)
On Fri, Jul 14, 2006 at 06:48:57AM -0700, Scott LaBounty wrote:
OK, I'll bite. What does =a{ do? The = is a format, and the {
moves to the start of a class (at least that's what is does in the ruby
file I tested this on). So, what's the a do in this command?
a{ selects the nearest {...} block to the cursor. You can see the
effect if you type va{.
Lord knows, anything that annoys my Visual Studio colleagues is all right
with me.
Leaning over their shoulders while they're coding and saying you could
do that in three lines with Perl often does the trick. Or you could
watch them for a while and then say Oh, you use the cursor keys when
editing. How ... quaint.
Giggling every time you walk past them works too.
--
Matthew Winn ([EMAIL PROTECTED])
Re: Register size
On Wed, Jun 21, 2006 at 12:48:48PM +0300, Anatoli Sakhnik wrote: Can anyone tell me how big a vim register is? It's very unpleasant, when I yank some piece of text in the source and can paste only part of it. Is there a restriction? I'm not aware of any restriction, providing you remain within Vim when moving text around. If you quit Vim and restart it on a different file then only part of the register will be saved. See :help 'viminfo'. -- Matthew Winn ([EMAIL PROTECTED])
Re: All mails lost
On Wed, Jun 07, 2006 at 11:33:09AM +0200, Mathias Michaelis wrote: My emails are systematically filtered out. I can't even unsubscribe (why be on a list where own, very carefully composed contributions aren't desired?). I already have phoned to my ISP, and he's innocent. I'm seeing your messages on the list. There have been situations in the past where the list has silently discarded messages because they don't match some arbitrary unpublished criterion, but that doesn't appear to be the case here. [cc'd to poster to be certain the message gets through] -- Matthew Winn ([EMAIL PROTECTED])
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
On Tue, Jun 06, 2006 at 10:04:14PM -0700, Mun Johl wrote: GK Aha! That beta is actually a German SS, szlig; (sz ligature) iirr. GK GK The 'X' is a math times (times; no?). GK GK All the other (usually) vowels have similar compounding, eg, GK [aeiou] with accents of various types (try typing a' or a:, GK ferinstance), Polish l/ (slashed-ell, don't know the sgml entity GK offhand), Spanish n~ (en-tilde, ntilde;), and so on. Very interesting observation! Did nobody notice when I made much the same observation on Monday morning? Hello? Can anyone hear me? -- Matthew Winn ([EMAIL PROTECTED])
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
On Fri, Jun 02, 2006 at 03:21:26PM -0400, Karl Guertin wrote: On 6/2/06, Mun Johl [EMAIL PROTECTED] wrote: abbcdeffgghijjkklmmnopqqrßtuvvww×yzz ^ this is the greek Beta character (in case it got lost in the transmission) That's not a beta, that's a german double s (forget what it's called). Also, the character that falls between the w and the y is not an x, but a multiplication sign. It looks as through there's some sort of automatic digraph processing going on, and it may not be coincidence that most of the letters that are lost are those that have accented or similar forms in western and eastern European languages. -- Matthew Winn ([EMAIL PROTECTED])
Re: OT: test
On Fri, May 26, 2006 at 11:52:42AM +0200, Meino Christian Cramer wrote: Please ignore... If you're going to send test messages at least put in something amusing or interesting for people to read. Something like the following (a fortune that turned up a few days ago; anyone who's used Oracle -- or any other software -- will know the feeling): [Taken from Oracle's own JDBC FAQ. Really.] 8.1.7 (8i r2) Is DML Returning Supported ? Not in the current drivers. However, we do have plans to support it in post 8.1.7 drivers. 9.0.1 (9i) Is DML Returning Supported ? Not in the current drivers. However, we do have plans to support it in post 9.0.1 drivers. 9.2.0 (9i r2) Is DML Returning Supported ? Not in the current drivers. However, we do have plans to support it in post 9.2.0 drivers. 10.1.0 (10g r1) Is DML Returning Supported ? Not in the current drivers. However, we do have plans to support it in post 10.1.0 drivers. We really mean it this time. 10.2.0 (10g r2) Is DML Returning Supported ? YES! And it's about time. See the Developer's Guide for details. -- Matthew Winn ([EMAIL PROTECTED])
Re: Visual Block: $ vs. ^ inconsistency?
On Fri, May 19, 2006 at 07:47:41AM -0700, Suresh Govindachar wrote: In visual block mode (C-V) one can get jagged right edges by hitting $. But hitting ^ does not result in jagged left edges. Why the inconsistency? Is it something in my set-up? It's probably inconsistent because nobody's ever asked for ragged-left selection. When lines are ragged-left there's usually significance in the level of indentation, and in the rare cases where that indentation is not needed it's trivial to remove so there's nothing that ragged-left selection could achieve that can't already be done. In contrast, ragged- right selection is necessary in order to do block selection of the end of a set of lines when the longest line is in the middle of the block. -- Matthew Winn ([EMAIL PROTECTED])
Re: Multiline file appearing in one line under Vim
On Wed, May 17, 2006 at 03:19:39PM +0200, Baha-Eddine MOKADEM wrote: I have a file which behaves differently whether edited with win32 Notepad and gVim. When opened in notepad I got several lines, which is the most convenient layout for me, but when opened in gVim I got the file in only one line. Is it really several lines in Notepad, or is it one long line that has wrapped? If the latter then the following will help: :set wrap linebreak :map Up gk :map Down gj -- Matthew Winn ([EMAIL PROTECTED])
Re: Shell support in Vim?
On Fri, May 12, 2006 at 04:52:16AM +0200, A.J.Mechelynck wrote: François Pinard wrote: I prefer Vim to stay clean and efficient like it is. Yet, I regret not having its syntax highlighting abilities over my shell output... - To use Vim coloring on shell output (but not in realtime): redirect stdout to a logfile and view that (with a proper filetype syntax script). I don't see how colouring of shell output could be achieved in any useful way, because by the time Vim was able to see the output all the meaning of that output would have been lost. When the output of one command is directed to a file and then viewed in Vim the type of that file can be set so that the colouring is appropriate to the data. If the command provides its own colouring (as some versions of ls do) then the colouring can represent additional information not otherwise visible in the output. But with general colouring of undifferentiated output text I can't see how anything useful could be conveyed. All you can do is make the terminal look pretty. -- Matthew Winn ([EMAIL PROTECTED])
Re: Question about using variable with RegEx counter
On Thu, May 11, 2006 at 10:12:32AM -0400, Benji Fisher wrote:
On Wed, May 10, 2006 at 02:53:20PM -0600, Shaun Cummins wrote:
I would like to use a variable within a regular expression counter. I
tried the following, but it gave me a syntax error:
:syntax region Keyword start=^\w\+\s\+\z(\d\+\)
end=#\(\s*\(.\+\|'.\+'\).*\n\)\{\z1\}#
[snip]
I do not think I can answer this, and there may not be a way to do
what you want, but I want to clarify the question. Is your intention to
match the STALIST 6 with the start pattern and, since it ends in 6,
match the next 6 lines with the end pattern?
If that's the case I suspect the only way to do it is to set up
a separate syntax entry for each possible number, so it would be
syntax region Keyword start=^\w\+\s\+1\ end={pattern for one line}
syntax region Keyword start=^\w\+\s\+2\ end={pattern for two lines}
and so on. Perhaps syntax match would be better, depending on the
precise requirements. It's bad news if the number can go as high as
2000 but I can't think of an easier way to do it.
--
Matthew Winn ([EMAIL PROTECTED])
Re: 7.0 administrivia
On Tue, May 09, 2006 at 04:44:32PM +0200, Nikolai Weibull wrote:
On 5/9/06, Matthew Winn [EMAIL PROTECTED] wrote:
On Tue, May 09, 2006 at 02:02:24PM +0200, Nikolai Weibull wrote:
Well, there's always the following algorithm to consider:
if (bram_is_unreasonable) {
int new_child = fork();
if (new_child) {
// Let Bram continue in his thought-process
return;
}
// Ah, this is now our little baby
:
:
}
And if fork() returns -1?
It's obvious, isn't it?
Yes. The poor little baby never gets conceived. You should at least
issue a warning, or possibly loop until conception occurs.
P.S. Don't try this with vfork().
--
Matthew Winn ([EMAIL PROTECTED])
Re: regex @vim, negating a group
On Thu, May 04, 2006 at 08:56:41AM +0300, Yakov Lerner wrote: 3) The 'old' way. That's what I'd use before the \@ stuff to match words not ending with 'ion': /\\(\w*[^n]\|\w*[^o]n\|\w*[^i]on\)\ Not much fun if you want to match all words not ending in ification. :-) This is where negative lookahead and negative lookbehind really come into their own. -- Matthew Winn ([EMAIL PROTECTED])
