Re: VimWiki - Page Titles
On 5/27/07, Sebastian Menge [EMAIL PROTECTED] wrote:
Hi
I have prepared a list with problematic page titles. Especially titles
with chars like [/#{}[]*] and the like are problematic since mediawiki
doesnt allow them
Strange. Are you sure? I just created a page on wikia.com, page
titled '/hello/' and it created it without problems. Maybe ...;
encoding is needed ?
With slashes both in title and in summary and in category. You can see it here-
http://scratchpad.wikia.com/wiki//hello/
Page titled '/hello/'
You can try to create such manually and intercept what browser sends in
and the mimic this in the script maybe ? Because with manual submission, wikia
does seem to allow slashes in the title.
If you upload scripts using script, then did you try the ...; encoding ?
Yakov
Re: VimWiki - Page Titles
Sebastian Menge wrote: Find the list (95 entries) here: http://scratchpad.wikia.com/wiki/Errornames Thanks for the good start. FYI there are a couple of lines with broken links: 157 160: 171: Do you know the g/ and g? commands? Above gives: Vim Online Error Couldn't find tip 160. Are you sure it exists? Im not sure howto proceed here. Should we a) find better titles before the import Yes! In option (b), you have to change every '/' to '__OR__', so you may as well change the titles to something good now. Can you readily do something like this: Put each tip in a separate file on your disk. Name them tip0001, tip0002, etc. Put the list of 1500 tip titles in one file, one title per line. Then edit that file to clean up the titles. Then run a script to rename each tip to match the cleaned-up title. or b) replace '/' by sth like '__OR__' and fix the whole title later? Whatever works, but wouldn't this create a whole bunch of problems? I don't understand the internals of wikis but I think your suggestion would create 95 tips with URLs that will later need to be manually edited. Not so easy, and probably involves copying the content from the wiki to a new page, then deleting the old page (I guess). BTW: For the import I will now use WikipediaFS. Wow - amazing. How do you get the wiki format files from the VimTips web site? If you're going to do the work, I don't need this answered, but I'm thinking that you're going to need one of the scripts to convert the existing html to wiki format. I noticed that Charles Campbell's script does appropriate things with common html codes like nonbreaking space. Probably all that processing should be done before the files are uploaded? With your scheme, you're going to get 1500 tip files on your disk. It would be great if you could clean them as much as possible before uploading. It would be pretty easy to find all html markups and '' codes when the files are still on your disk. Easy, but time consuming. Let us know if you want some help. John
Re: VimWiki - Page Titles
Am Montag, den 28.05.2007, 19:32 +1000 schrieb John Beckett: Sebastian Menge wrote: Find the list (95 entries) here: http://scratchpad.wikia.com/wiki/Errornames Thanks for the good start. FYI there are a couple of lines with broken links: 157 160: 171: Do you know the g/ and g? commands? That is fixed now. Was a problem with the script that produced the page. Yes! In option (b), you have to change every '/' to '__OR__', so you may as well change the titles to something good now. That could be done by a regex. Can you readily do something like this: Put each tip in a separate file on your disk. Name them tip0001, tip0002, etc. Put the list of 1500 tip titles in one file, one title per line. Then edit that file to clean up the titles. Then run a script to rename each tip to match the cleaned-up title. One idea was that the editing can be done on the wiki. Just edit the Errornames page :-) or b) replace '/' by sth like '__OR__' and fix the whole title later? Whatever works, but wouldn't this create a whole bunch of problems? I don't understand the internals of wikis but I think your suggestion would create 95 tips with URLs that will later need to be manually edited. Not so easy, and probably involves copying the content from the wiki to a new page, then deleting the old page (I guess). Moving/Renaming is easy in wikis. BTW: For the import I will now use WikipediaFS. Wow - amazing. How do you get the wiki format files from the VimTips web site? If you're going to do the work, I don't need this answered, but I'm thinking that you're going to need one of the scripts to convert the existing html to wiki format. I noticed that Charles Campbell's script does appropriate things with common html codes like nonbreaking space. Probably all that processing should be done before the files are uploaded? With your scheme, you're going to get 1500 tip files on your disk. It would be great if you could clean them as much as possible before uploading. It would be pretty easy to find all html markups and '' codes when the files are still on your disk. The cool thing with the WikipediaFS is that i can do scripting on the pages _as if _ they were on my disk! My general approach: First i downloaded all tips to my machine. I startet with the script vimtips.py and hacked it alot. The script uses a perl-module that converts html to wiki-markup. But I still have problems with some regexes: stable regexes for 1500 pages are not easy to do. I have to clean up the script and will post it here, because I guess there are some regex gurus around ... Thanks, Sebastian.
Re: VimWiki - Page Titles
John Beckett wrote: Sebastian Menge wrote: Find the list (95 entries) here: http://scratchpad.wikia.com/wiki/Errornames Thanks for the good start. FYI there are a couple of lines with broken links: 157 160: 171: Do you know the g/ and g? commands? Above gives: Vim Online Error Couldn't find tip 160. Are you sure it exists? Im not sure howto proceed here. Should we a) find better titles before the import Yes! In option (b), you have to change every '/' to '__OR__', so you may as well change the titles to something good now. Can you readily do something like this: Put each tip in a separate file on your disk. Name them tip0001, tip0002, etc. Put the list of 1500 tip titles in one file, one title per line. Then edit that file to clean up the titles. Then run a script to rename each tip to match the cleaned-up title. or b) replace '/' by sth like '__OR__' and fix the whole title later? Whatever works, but wouldn't this create a whole bunch of problems? I don't understand the internals of wikis but I think your suggestion would create 95 tips with URLs that will later need to be manually edited. Not so easy, and probably involves copying the content from the wiki to a new page, then deleting the old page (I guess). [...] This is where my redirect suggestion comes into play (assuming wiki software compatible to that used at ??.wikipedia.org): First pass: migration proper. For each tip, create *two* wiki pages: - one page with the tip text and a real title, possibly doctored as shown above - one page titled Vim tip 1 Vim tip 2 etc. (url ending in .../Vim_tip_1 etc.) with only a redirect, as follows: (url=something/Vim_tip_1) #REDIRECT [[The super star]] During this first pass, any link vimtip#3456 gets translated to [[Vim tip 3456]] pointing to the redirect page for the link pointed to. At this time the actual name of the link pointed to doesn't have to be known, and in the case of forward comments it _won't_ yet be known. Second pass (after all tips have been migrated and the wiki software has had the time to cycle and reconstruct its indexes) For each redirect page: open it with ?noredirect and get the corresponding What points here page, as delivered by the wiki software. Change links pointing to the redirect into links pointing to the (now known) actual page title. IIUC this can be done by a robot (i.e., a script, not a human). Best regards, Tony. -- If you're not very clever you should be conciliatory. -- Benjamin Disraeli
Re: VimWiki - Page Titles
Am Montag, den 28.05.2007, 16:18 +0200 schrieb A.J.Mechelynck: This is where my redirect suggestion comes into play (assuming wiki software I took your advice silently. Your suggestion is already in the script. Sebastian.
Re: VimWiki - Page Titles
Sebastian Menge wrote: Am Montag, den 28.05.2007, 16:18 +0200 schrieb A.J.Mechelynck: This is where my redirect suggestion comes into play (assuming wiki software I took your advice silently. Your suggestion is already in the script. Sebastian. well, sorry I didn't look at the script, but it seemed to solve John's objection. Best regards, Tony. -- Interpreter, n.: One who enables two persons of different languages to understand each other by repeating to each what it would have been to the interpreter's advantage for the other to have said. -- Ambrose Bierce, The Devil's Dictionary
Re: Replacing newline/carriage returns in a file with spaces
Michael Dacre wrote: hey tim thanks for the advice :) Just for future reference, it's best to use your mailer's Reply To All (or Reply to List) functionality, so that the ML gets copied. My filters flagged your message as junk and moved it into my overflowing junk-mail folder because it came to my vim-ML address but wasn't sent to the list (and you weren't already in a whitelist of Vim-list folks with whom I occasionally correspond off-list). Additionally, my vim domain-knowledge only extends so far. If I don't have the answer, there's a good chance many of the other smart folks on the list can help you out. Or I may get something totally wrong. But if you don't CC the ML, you lose that resource. sorry about my terrible description - wasnt sure how to phrase it. First of all i meant javascript not java - what i am trying to do is create a form in which people can add extra tables by clicking a link. The table is in html but the link is obviously js (i.e. I am using the command newdiv.innerHTML = ...) but to do that it requires that there are no returns. I can remove them manually but it's a pain as I need to do it for a few different forms. Now I'm confused...it sounds like you want to do this in JavaScript, not vim-script. And it also sounds like you want to do this on an automated basis, so that every time a row is added, it cleans up whatever was submitted? If you have a number of files that need to be cleaned up in one pass, you can use the argdo/windo/bufdo/tabdo functions to perform an Ex command across a number of files. Ex commands can take ranges that give you more surgical-strike capabilities if you need them, so you can only change ranges of lines if needed. However, if you have a bunch of files, you can do something like sh$ cd /path/to/files sh$ vim *.txt :set hidden :argdo %j (review your files here, and if they're okay, continue) :wall That %j can be any Ex command, so you can do things like :argdo 1,10j to join the first 10 lines of the file or :argdo g/STARTTEXT/+,/ENDTEXT/-j to every line after STARTTEXT through every line before ENDTEXT. If the text to join is embedded in your HTML/JS files, this might help isolate the contents so you're only joining germane lines. -tim On 5/26/07, Tim Chase [EMAIL PROTECTED] wrote: I have been trying to figure out how I can replace all the new line characters in a text file with spaces - need to do this to make html compatible with java and am too lazy to do it manually every time. Am sure there is a simple way to do it but I have looked and cant figure it out :( Well, if you plan to do it regularly, you can use tr to do exactly what you describe: tr '\012' \040' in.txt out.txt Or, if you want to do it in vim, you can do: :%j which will join all the lines in your file, normalizing whitespace. If you don't want Vim to be smart about it, you can tell it to simply remove the newlines: :%j! Alternatively, you can use :%s/\n/ / which will do the same thing as the tr command, only it will appropriately leave a \n at the end of the file. As a side note, I'm not sure what it meens to make html compatible with java, as they're fairly disjoint languages. One is for markup; the other is for execution. :-/ -tim
Why bottom-posting is prefered on Vim Mainling List?
Hi vimmers: Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Is there any point (or historic reason) choosing bottom-post ? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Why bottom-posting is prefered on Vim Mainling List?
Hi, TOP POST:--- On Tue, 2007-05-29 at 11:00 +0800, [EMAIL PROTECTED] wrote: Hi vimmers: I'll try and explain Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. Most do, but probably shouldn't As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Easier to read for most, easier to insert replies. Probably historical reasons. Is there any point (or historic reason) choosing bottom-post ? -- Sincerely, Pan, Shi Zhu. ext: 2606 BOTTOM POST: On Tue, 2007-05-29 at 11:00 +0800, [EMAIL PROTECTED] wrote: Hi vimmers: Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. I'll try to explain As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Most do, but probably shouldn't Is there any point (or historic reason) choosing bottom-post ? Easier to read for most, easier to insert replies. Probably historical reasons. -- Sincerely, Pan, Shi Zhu. ext: 2606 Which of the above is easier to read? Which would be easier to read after several exchanges? ie you reply to points I made, I reply back, you reply. cheers, -- Mark
Re: Why bottom-posting is prefered on Vim Mainling List?
On May 28, 2007, at 8:00 PM, [EMAIL PROTECTED] wrote: Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Is there any point (or historic reason) choosing bottom-post ? I have seen it explained like this: A: Because it disrupts the flow of the conversation. Q: Why is top-posting deprecated? I don't agree 100% with that pithy example, because quite a few forums, blogs and bulletin boards default to most-recent-message first, which is essentially top-posting. In fact, I work at a company that develops and runs online communities, and many end-users (and some of the clients who hire us to do their communities choose to list threads that way. As for me, I adapt to whatever is the preference of the community. In some, top-posting is a quick trip to a flame-war. In others, it is the norm. Dave
Re: Why bottom-posting is prefered on Vim Mainling List?
On Tue, 2007-05-29 at 11:00 +0800, [EMAIL PROTECTED] wrote: Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Is there any point (or historic reason) choosing bottom-post ? Two different explanations: 1. http://www.american.edu/cas/econ/htmlmail.htm (See under Interlineated responses) 2. (One of my favorite signatures) :: A: Because it's not the order people normally read. :: Q: Why is top-posting such a bad thing? :: A: Top-posting. :: Q: What is the most annoying thing in e-mail? You could say that top posting is easier to write, but bottom posting is easier to read. The extra effort of one poster saves all the readers the same amount of effort. For a group, bottom posting keeps everyone on track. And if done well, individual posts can stand alone in an archive without a peruser having to go paging through a whole thread. -- Steve Hall [ digitect dancingpaper com ]
Re: Why bottom-posting is prefered on Vim Mainling List?
On Tue, 29 May 2007, [EMAIL PROTECTED] wrote: Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. It's usually preferred more than top-posting. Even on the blind Linux users' mailing list they prefer that you don't top-post. As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), In my experience it's more that it can be frustrating to try to automatically position the cursor without the software guessing wrong, and it's not helpful for context replying (see below). In other words, it's better to let the user move the cursor where he wants it. Those email clients that automatically insert your signature above the quoted message are generally considered to be broken--regardless of whether you prefer to top-post--but that's another issue involving its own discussion.[1] and I personally feel top-posting much much easier to read than bottom-posting. This is a matter of opinion and great debate. I've seen the arguments get as heated as the infamous editor wars. Is there any point (or historic reason) choosing bottom-post ? Email etiquette is that you trim the message you're responding to down to the minimum while retaining context, and intersperse your replies to the relevant sections of the original message (as I've done here). Top-posting makes it impossible to do this and makes it unclear exactly what you're responding to, especially if you don't trim--a bad habit I see far more often among top-posters. Occasionally I see a tagline that illustrates it very well: A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? Also, I'd like to point out that just because something is done for historical reasons doesn't make it bad, outmoded, invalid, or whatever. After all, if that were true vi/Vim wouldn't be used any more.[2] There are usually good reasons why things become established conventions, and rarely do those reasons just go away. - Christian [1] In summary, you shouldn't include the signature of the original message in your reply and your signature should always appear at the bottom of your message--preferably after a signature delimiter line (-- (dash, dash, space)). The sig-delimiter allows email clients to automatically strip out the signature when you select reply. [2] Occasionally you'll see people contend that vi is a legacy editor and for that reason shouldn't be used any more, and by extension Vim is flawed because it's based on a legacy editor. -- In specifications, Murphy's Law supersedes Ohm's. Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/ PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
Re: Why bottom-posting is prefered on Vim Mainling List?
Folks, In the spirit contrarianism, I'm going to top-post now. Actually, both parts of Mark's post below were of a _third_ variety: interlinear comments. On many communities, this is the preferred method, especially if the posts tend to be longish and contain many separate points that need to be answered. Thus, you have three choices: - Top-post, the default for many mail clients, as PanShiZhu notes Best known for inciting flame wars in some communities. - Bottom-post, which some say preserves the flow of conversation, and which happens to be the practice of this community. A good way to avoid flame wars on some communities. - Interlinear comments, which allows complex posts to be answered point-by-point. The preferred tool of flame-warriors in many communities, because they can show what an ass their victim is with pin-point precision. Dave On May 28, 2007, at 9:08 PM, Mark Woodward wrote: Hi, TOP POST:--- On Tue, 2007-05-29 at 11:00 +0800, [EMAIL PROTECTED] wrote: Hi vimmers: I'll try and explain Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. Most do, but probably shouldn't As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Easier to read for most, easier to insert replies. Probably historical reasons. Is there any point (or historic reason) choosing bottom-post ? -- Sincerely, Pan, Shi Zhu. ext: 2606 BOTTOM POST:- --- On Tue, 2007-05-29 at 11:00 +0800, [EMAIL PROTECTED] wrote: Hi vimmers: Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. I'll try to explain As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Most do, but probably shouldn't Is there any point (or historic reason) choosing bottom-post ? Easier to read for most, easier to insert replies. Probably historical reasons. -- Sincerely, Pan, Shi Zhu. ext: 2606 Which of the above is easier to read? Which would be easier to read after several exchanges? ie you reply to points I made, I reply back, you reply. cheers, -- Mark
bullet points and paragraph indenting
When I intend to type a list of bullet points, I start with a - . If I type more than one line for that bullet point, the second line is automatically indented 2 spaces, so the text lines up with the first line's text like this: - Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, However if I type more than 2 lines, the third line starts at beginning of line like this: - Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Is there a way to get the whole bullet point item to have that 2 character indent like this? - Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. -- Troy Piggins | http://piggo.com/~troy __ ___ RLU#415538\ \ / (_)_ __ ,-O (o-O \ V /| | ' \ O ) //\ O Vim 7.0.22 \_/ |_|_|_|_| `-O V_/_ OOO
Re: breakindent, take 2
On 5/14/07, Václav Šmilauer [EMAIL PROTECTED] wrote: Hello, I submit patch that implements the 'breakindent' feature. It is on vim todo list, since the moment I tried a few years ago (see e.g. http://marc.info/?l=vim-devm=109921292009721w=1). Picture says what it's about (showbreak is aligned with first non-whitespace): http://beta.arcig.cz/~eudoxos/vim7/breakindent1.png http://beta.arcig.cz/~eudoxos/vim7/breakindent2.png I tried to address all Bram's comments he had to the original patch, like coding style, functionality in diff mode, selections etc. I had to change a few prototypes to pass line number. There is one bug and some (easily fixable) limitations: * BUG: there is some weird interaction with quickfix window, where very rarely there is the ml_get(): invalid line number error. I think it is caused by passing wrong line number thgouth the *chartabsize* family routines (line in the main buffer interpreted as line in the quickfix window or something like that), but I am not sure. * No test case. This will be added once there is enough interest from developers (there _is_ documentation). * The bri_min variable is not exposed to userspace yet, is set to 20 in the code. If the rest is considered ready for inclusion, I will add a user-serrable variable for that. The patch is against current svn (vim7, rev. 288). Any comments are welcome. Nice feature. I hope Bram includes it. Yakov
Re: breakindent, take 2
On 5/14/07, Václav Šmilauer [EMAIL PROTECTED] wrote: Hello, I submit patch that implements the 'breakindent' feature. It is on vim todo list, since the moment I tried a few years ago (see e.g. http://marc.info/?l=vim-devm=109921292009721w=1). Picture says what it's about (showbreak is aligned with first non-whitespace): http://beta.arcig.cz/~eudoxos/vim7/breakindent1.png http://beta.arcig.cz/~eudoxos/vim7/breakindent2.png I tried to address all Bram's comments he had to the original patch, like coding style, functionality in diff mode, selections etc. I had to change a few prototypes to pass line number. There is one bug and some (easily fixable) limitations: * BUG: there is some weird interaction with quickfix window, where very rarely there is the ml_get(): invalid line number error. I think it is caused by passing wrong line number thgouth the *chartabsize* family routines (line in the main buffer interpreted as line in the quickfix window or something like that), but I am not sure. * No test case. This will be added once there is enough interest from developers (there _is_ documentation). * The bri_min variable is not exposed to userspace yet, is set to 20 in the code. If the rest is considered ready for inclusion, I will add a user-serrable variable for that. The patch is against current svn (vim7, rev. 288). Any comments are welcome. I played with the patch. Works smoothly, I did not find any deficiencies. I have one wish though. It would be nice if I could specificy additional indent for continuation lines. You make indent for continuation line *EQUAL* to indent of the 1st screen line. Let's say you have 3 consequitive long lines with same indent, and each lines wrapped into 4 screen lines. With current 'breakindent' patch, you see 8 lines with *same* indent. It's not that easy to see beginning of each long lines. If breakindent would be numeric value N which meant assign indent K+N to continuation indent, where K is indent of the line itself. Current breakindent corresponds to N==0. But I'd probably prefer N=1 or N==2. Just my 2 cents Thanks Yakov ** nobreakindent line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=0 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=2 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line **
Re: Proposal: adding an extra hook into vim's search
On 26/05/07, Iain Murray [EMAIL PROTECTED] wrote: On 26/05/07, Yakov Lerner [EMAIL PROTECTED] wrote: I believe you can achieve what you want using 'cmap expr' cleverly. ... I might still attempt a patch. Having the space replacement actually appear is visually distracting and makes the resulting search string hard to read. Having had a more detailed look at the code I'm bailing out of attempting this for now. Making the search history still work and be uncluttered of '\_s\+' seems fiddly. The natural way to do this seems to be making the magic types more flexible. The changes would be somewhat further reaching than I had initially anticipated and I wouldn't be happy doing it without there being consensus out there on a specification. Thanks again Yakov for the partial fix. Iain.
Re: Proposal: adding an extra hook into vim's search
On 5/28/07, Iain Murray [EMAIL PROTECTED] wrote: On 26/05/07, Iain Murray [EMAIL PROTECTED] wrote: On 26/05/07, Yakov Lerner [EMAIL PROTECTED] wrote: I believe you can achieve what you want using 'cmap expr' cleverly. ... I might still attempt a patch. Having the space replacement actually appear is visually distracting and makes the resulting search string hard to read. Having had a more detailed look at the code I'm bailing out of attempting this for now. Making the search history still work and be uncluttered of '\_s\+' seems fiddly. The natural way to do this seems to be making the magic types more flexible. The changes would be somewhat further reaching than I had initially anticipated and I wouldn't be happy doing it without there being consensus out there on a specification. Thanks again Yakov for the partial fix. I believe you can have uncluttered view of the regex AND incremental search at the same time using getchar() in vimscript, but that would be tons of vimscript programming. Yakov
Re: breakindent, take 2
Yakov Lerner wrote: On 5/14/07, Václav Šmilauer [EMAIL PROTECTED] wrote: Hello, I submit patch that implements the 'breakindent' feature. It is on vim todo list, since the moment I tried a few years ago (see e.g. http://marc.info/?l=vim-devm=109921292009721w=1). Picture says what it's about (showbreak is aligned with first non-whitespace): http://beta.arcig.cz/~eudoxos/vim7/breakindent1.png http://beta.arcig.cz/~eudoxos/vim7/breakindent2.png I tried to address all Bram's comments he had to the original patch, like coding style, functionality in diff mode, selections etc. I had to change a few prototypes to pass line number. There is one bug and some (easily fixable) limitations: * BUG: there is some weird interaction with quickfix window, where very rarely there is the ml_get(): invalid line number error. I think it is caused by passing wrong line number thgouth the *chartabsize* family routines (line in the main buffer interpreted as line in the quickfix window or something like that), but I am not sure. * No test case. This will be added once there is enough interest from developers (there _is_ documentation). * The bri_min variable is not exposed to userspace yet, is set to 20 in the code. If the rest is considered ready for inclusion, I will add a user-serrable variable for that. The patch is against current svn (vim7, rev. 288). Any comments are welcome. I played with the patch. Works smoothly, I did not find any deficiencies. I have one wish though. It would be nice if I could specificy additional indent for continuation lines. You make indent for continuation line *EQUAL* to indent of the 1st screen line. Let's say you have 3 consequitive long lines with same indent, and each lines wrapped into 4 screen lines. With current 'breakindent' patch, you see 8 lines with *same* indent. It's not that easy to see beginning of each long lines. If breakindent would be numeric value N which meant assign indent K+N to continuation indent, where K is indent of the line itself. Current breakindent corresponds to N==0. But I'd probably prefer N=1 or N==2. Just my 2 cents Thanks Yakov ** nobreakindent line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=0 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=2 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** 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). Thus breakindent=0 flush left (as above) breakindent=-3 French style with first line indented 3 spaces, as follows: The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. Line two starts here; neither line goes back to the left margin of the Vim window. The lazy dog is jumped over by the quick brown fox. The lazy dog is jumped over by the quick brown fox. The lazy dog is jumped over by the quick brown fox. breakindent=2 all lines except the first indented 2 spaces (as you show above) A single option cannot be both boolean and integer; if a negative number is greater than the 1st line indent, don't go back farther left than the left margin of the window; thus breakindent=-999 would agree with your first example. Best regards, Tony. -- Sex is a natural bodily process, like a stroke.
