Am 22.10.2011 08:35 schrieb <[email protected]>: > Today's Topic Summary > > Group: http://groups.google.com/group/vim_use/topics > > - drawing and column editing in vim <#1332a5715d440cff_group_thread_0>[3 > Updates] > - One line without EOL <#1332a5715d440cff_group_thread_1> [7 Updates] > - gvim64/win7 claims error on unzip, but unzip get no error, > why?<#1332a5715d440cff_group_thread_2>[4 Updates] > - line drawing inside vim <#1332a5715d440cff_group_thread_3> [3 > Updates] > - Syntax highlighting Problem in for > Bash<#1332a5715d440cff_group_thread_4>[3 Updates] > - Tracing Vim into a log file. <#1332a5715d440cff_group_thread_5> [1 > Update] > - :bd makes syntax highlight of the next window > unavailable<#1332a5715d440cff_group_thread_6>[1 Update] > > drawing and column editing in > vim<http://groups.google.com/group/vim_use/t/8282caaa0f4c880e> > > Eric Smith <[email protected]> Oct 21 03:41PM +0200 > > I am using DrawIt to make things like Organograms. > > It becomes messy when removing or inserting an entity. > > Then the parts of the lines to the right either become > pushed to the right or collapse to the left. > > This of course would also happen when editing just text > columns. > > I found some relief by pasting in replace mode. > > What is the solution to make vim behave more like > a graphics application? (which of course it was never designed > for). > > -- > - Eric Smith > > > > > Chris Jones <[email protected]> Oct 21 05:37PM -0400 > > On Fri, Oct 21, 2011 at 09:41:39AM EDT, Eric Smith wrote: > > > > I found some relief by pasting in replace mode. > > > What is the solution to make vim behave more like a graphics > > application? (which of course it was never designed for). > > So don't do it, then... :-) > > You may want to take a peek at: > > :h virtualedit > > I found this mode rather useful when editing rough text-mode tables or > otherwise column-aligned text. > > CJ > > > > > Javier Rojas <[email protected]> Oct 21 09:28PM -0500 > > On Fri, Oct 21, 2011 at 03:41:39PM +0200, Eric Smith wrote: > > What is the solution to make vim behave more like > > a graphics application? (which of course it was never designed > > for). > > You should try asciio. > > -- > Javier Rojas > > GPG Key ID: 0x24E00D68 > > > > One line without > EOL<http://groups.google.com/group/vim_use/t/e2c9a951634bf13a> > > [email protected] Oct 21 05:25PM +0200 > > Hi, > > is it possible to create a line of text with vim which > do not contain any \n, \ra ? > > Or in other words: The line should contain nothing > more than the visible chars. > > I need this to generate test data for testing a VFD... > > How can I accomplish this? > > Thank you very much in advance for any help! > > Best regards, > mcc > > > > > Tony Mechelynck <[email protected]> Oct 21 06:21PM +0200 > > > > Thank you very much in advance for any help! > > > Best regards, > > mcc > > It is possible but definitely not recommended. You must > > :setlocal binary noeol > > in the file before writing it, and it must contain only the one line > (it > is of course not possible to have any line other than the last one end > without an end-of-line mark). > > See > :help 'binary' > :help 'eol' > > > Best regards, > Tony. > -- > Behold the warranty ... the bold print giveth and the fine print taketh > away. > > > > > [email protected] Oct 21 06:38PM +0200 > > > You received this message from the "vim_use" maillist. > > Do not top-post! Type your reply below the text you are replying to. > > For more information, visit http://www.vim.org/maillist.php > > Hi Tony, > > thank you very much. I intended to use this "hack" :) only for testing > purposes. I bought a wonderful rtro looking Flourescenz display (VFD) > and have to explore how to connect this to my embedded linux SOC. > I though "vim is useful for doing thing...one only has to know how..." > so asked how to create testdata to be fed into /dev/ttyS0. Only > the line break was not what I want. > Thanks to your help I now know how to avoid it. > And once again: One only needs vim...and a syste to run it. :) > > Thank you very much! > Have a nice weekend! > Best regards, > mcc > > > > > Taylor Hedberg <[email protected]> Oct 21 12:46PM -0400 > > Another way to do it would be to edit the file normally in Vim and then > pipe its contents through the Unix command `head` in order to strip off > the final byte (i.e. the final newline). Since you're feeding it to > /dev/ttyS0, you could do something like this: > > head -c -1 </path/to/text/file >/dev/ttyS0 > > Personally, I'd prefer this approach over the 'binary' hack required to > make Vim do what you want, since 'binary' has other (probably > undesired) > effects besides enabling you to omit the final newline. > > > > > Ben Fritz <[email protected]> Oct 21 02:20PM -0700 > > > more than the visible chars. > > > I need this to generate test data for testing a VFD... > > > How can I accomplish this? > > The wiki can tell you how to automatically keep the line-ending off of > files which are missing it already: > > http://vim.wikia.com/wiki/VimTip1369 > > Using this tip, you should also be able to simply set 'noeol' to force > a file to save without one. > > > > > "Benjamin R. Haskell" <[email protected]> Oct 21 11:28AM -0400 > > > visible chars. > > > I need this to generate test data for testing a VFD... > > > How can I accomplish this? > > You can use the 'binary' and (no)'eol' options. > > 'eol' tells Vim whether to include the final newline in the file. But, > 'noeol' doesn't work unless 'binary' is also set. > > vim -b +'se bin' filename.oneline > > -- > Best, > Ben > > > > > "Benjamin R. Haskell" <[email protected]> Oct 21 12:01PM -0400 > > On Fri, 21 Oct 2011, Benjamin R. Haskell wrote: > > > > 'eol' tells Vim whether to include the final newline in the file. > But, > > 'noeol' doesn't work unless 'binary' is also set. > > > vim -b +'se bin' filename.oneline > > Whoops, braino: > > vim -b +'se noeol' filename.oneline > > -- > Best, > Ben > > > > gvim64/win7 claims error on unzip, but unzip get no error, > why?<http://groups.google.com/group/vim_use/t/1f6f636f5ed4aeca> > > Linda W <[email protected]> Oct 21 11:02AM -0700 > > I tried to open a .jar file in gvim (7.3). and got an error (which one > has to type in manually, as vim won't let you cut/paste -- a much > maligned user-hindrance, when it was first widely used by Microsoft): > > unzip: cannot find or open C:/Users/lindaw/AppData/Roaming/.... > > So I open up a console window and try the command: > (and)... > ***warning*** (zip#Browse) ... same message as above.... > > > > /Users/lindaw> unzip -l > > > C:/users/lindaw/AppData/Roaming/Mozilla/Firefox/Profiles/lindaw/extensions/{funnynumber}/chrome/file.jar > Archive: > > > C:/users/lindaw/AppData/Roaming/Mozilla/Firefox/Profiles/lindaw/extensions/{funnynumber}/chrome/file.jar > Length Date Time Name > --------- ---------- ----- ---- > 1109 09-29-2011 07:39 content/menucommander.js > 14574 09-29-2011 07:39 content/browser.js > 22524 09-29-2011 07:39 content/script.js > 3416 09-29-2011 07:39 content/install.js > .... > > --- > I.e. works just fine... > > So why didn't it work in Vim? Doesn't make sense. > > My first guess is it is I mistakenly installed broken 32-bit version > and > it couldn't call the right programs or access the right files due to > windows redirection, but I can't think of any of the programs in this > case, that it would have called where it needed a 64-bit version, so > I'm > stumped... > > Why does it work at the shell, but not from Vim? > > > > > Charles Campbell <[email protected]> Oct 21 04:36PM -0400 > > Linda W wrote: > > this case, that it would have called where it needed a 64-bit > version, > > so I'm stumped... > > Why does it work at the shell, but not from Vim? > > Some Qs for you: > * is the path that vim uses for your shell the same as the path your > shell uses? (I'm not at a windows computer; perhaps :!echo %PATH% > * is vim using the shell you expect? :echo &shell > * The message that you're getting, "...cannot find..." is not being > issued directly by zip.vim; does it work if you use backslashes instead > > of slashes? > > Well, that's a start, anyway. > > Regards, > Chip Campbell > > > > > Ben Fritz <[email protected]> Oct 21 02:07PM -0700 > > > I tried to open a .jar file in gvim (7.3). and got an error (which > one > > has to type in manually, as vim won't let you cut/paste -- a much > > maligned user-hindrance, when it was first widely used by Microsoft): > > I'm not sure what this means...I *think* you're saying you're getting > an error from a shell command, in which case it should be in a shell > window, not Vim's fault. Or maybe it's the output of an ex command, in > which case :redir will let you grab the output. > > > > > "Benjamin R. Haskell" <[email protected]> Oct 21 02:22PM -0400 > > On Fri, 21 Oct 2011, Linda W wrote: > > > redirection, but I can't think of any of the programs in this case, > > that it would have called where it needed a 64-bit version, so I'm > > stumped... Why does it work at the shell, but not from Vim? > > My guess would be that you're attempting to use a Cygwin or MSYS > version > of unzip from a Windows-native version of Vim. Or vice versa, > perhaps... Either way you might run into directory separator issues. > > What do you get from unzip -v (or --version, maybe)? > > How about :version (from within Vim -- just the lines up to the start > of > the features)? > > Also, are you typing exactly what's on-screen? Or are you using '/' in > place of '\'? > > -- > Best, > Ben > > > > line drawing inside > vim<http://groups.google.com/group/vim_use/t/e9ddc7770c7d39f1> > > Tim Chase <[email protected]> Oct 21 06:32AM -0500 > > On 10/20/11 17:51, sc wrote: > > for those characters for ages -- thought they were GONE it's > > been so long since i've seen them -- must have spent hours > > scrolling through :dig displays without finding them > > Glad you found it helpful, though the entire list was just a > simple google away. I must say that I used to have a scary > number of those ASCII line-drawing characters memorized for > entering them into DOS programs/source-code. Those brain-cells > have long since been reallocated for other purposes :) > > -tim > > > > > Eric Smith <[email protected]> Oct 21 02:42PM +0200 > > > > * use v11l from > > http://drchip.0sites.net/astronaut/vim/index.html#DRAWIT -- that's > > the most recent one (that's version eleven, letter "l") > > Thanks Chip > > All sweetness and light now. > > Eric > > > > > Ben Fritz <[email protected]> Oct 21 02:13PM -0700 > > > > drawing.vimhttp://www.vim.org/scripts/script.php?script_id=11 > > > sketch.vimhttp://www.vim.org/scripts/script.php?script_id=705 > > > boxdrawhttp://www.vim.org/script.php?script_id=173 > > I think all these could also be enhanced by txtfmt, if you want a > splash of color: > > http://www.vim.org/scripts/script.php?script_id=2208 > > > > Syntax highlighting Problem in for > Bash<http://groups.google.com/group/vim_use/t/61943316bf6968a3> > > Tom Bodine <[email protected]> Oct 21 06:17AM -0700 > > I was bitten by the old > unexpected EOF while looking for matching `"' > error in bash. Where you start a comment some where in the middle of > your script and forget to place a quote mark at the end. After > searching through the text I could not find any string that matched > this criteria. It was only when I loaded the script into SciTE that I > could see that this text was the problem > > <script> > # Syntax.........: libraryCheck [-test] {executable} > # Parameters ....: executable - an Executable and Linkable Formated > file > : -test : just do the test but don't fail on error > # Return values .: 0 on success, exits if libraries not found > > </script> > > Even though the third line appears as executable text to Bash, to me > it looks like part of the comment in the other lines. Vim did not help > me here since it colors the line starting with the colon the same as > the line starting with the hash mark. In order to find the problem I > loaded the script into Scite. > > Where as Scite treats lines starting with colons correctly and leaves > them colored like regular text, Vim colors them the same as comments > ( those lines wich start with hash marks). > > How can I change Vim's syntax coloring to treat lines starting with > colons differently from those starting with hash marks? > > Thanks and Regards Tom Bodine > > > > > Tony Mechelynck <[email protected]> Oct 21 06:12PM +0200 > > On 21/10/11 15:17, Tom Bodine wrote: > > > How can I change Vim's syntax coloring to treat lines starting with > > colons differently from those starting with hash marks? > > > Thanks and Regards Tom Bodine > > In bash (as can be seen with "help :" without the quotes at the bash > prompt) : is a do-nothing command. So it can be regarded as legitimate > to treat it as a comment. Actually, in the current > $VIMRUNTIME/syntax/sh.vim (version 118 dated Aug 16, 2011 and applying > to all three of sh, bash and ksh) these "colon lines" are set to syntax > > group shColon at line 287, then at line 536 the shColon highlight group > > is linked to shComment which is in turn linked to Comment at line 612. > > So a colorscheme could highlight colon lines as something else than a > comment by changing the highlight for the shColon highlight group. > > AFAICT from reading :help ft-bash-syntax there is no setting to change > those default highlights. However the fact that the sh syntax script > makes no provision for quoted strings extending on more than one line > can be regarded as a bug (or as a limitation). I'm CC-ing Charles "Dr. > Chip" Campbell, the current maintainer of that script. > > > Best regards, > Tony. > -- > hundred-and-one symptoms of being an internet addict: > 203. You're an active member of more than 20 newsgroups. > > > > > Gary Johnson <[email protected]> Oct 21 09:58AM -0700 > > On 2011-10-21, Tony Mechelynck wrote: > > > In bash (as can be seen with "help :" without the quotes at the bash > > prompt) : is a do-nothing command. So it can be regarded as > > legitimate to treat it as a comment. > > While it is true that the : command does nothing, its arguments are > still expanded, redirections are performed, and it sets the exit > code to 0, so it is not true that it can be regarded as a comment > line. > > As a practical example, this command tests USER and if it is unset > or empty, sets it to the output of whoami. > > : ${USER:=`whoami`} > > Regards, > Gary > > > > Tracing Vim into a log > file.<http://groups.google.com/group/vim_use/t/229cedf61910dd0d> > > Tony Mechelynck <[email protected]> Oct 21 04:43PM +0200 > > On 21/10/11 00:44, Eddine wrote: > > do, you're bound to get problems sooner rather than later. > > > about the vim log, I mean is there a way to write Vim actions into a > > sperate file of its own ? Not into the file I am editing/reading. > > Ah, OK. The fact that you talked about "editing" the logfile (not about > > "viewing" it) made me think that you tried to modify it in Vim while > the > program writing it was still running. > > See: > :help -w > :help -V > and about the latter: > :help 'verbose' > :help 'verbosefile' > > Best regards, > Tony. > -- > Not far from here, by a white sun, behind a green star, lived the > Steelypips, illustrious, industrious, and they hadn't a care: no spats > in their vats, no rules, no schools, no gloom, no evil influence of the > moon, no trouble from matter or antimatter -- for they had a machine, a > dream of a machine, with springs and gears and perfect in every > respect. And they lived with it, and on it, and under it, and inside > it, for it was all they had -- first they saved up all their atoms, > then they put them all together, and if one didn't fit, why they > chipped at it a bit, and everything was just fine ... > -- Stanislaw Lem, "Cyberiad" > > > > :bd makes syntax highlight of the next window > unavailable<http://groups.google.com/group/vim_use/t/511d7781793ee431> > > Thilo Six <[email protected]> Oct 21 01:21PM +0200 > > Peng Yu wrote the following on 21.10.2011 03:00 > > Hello, > > > Suppose that I open 3 .R files with "gvim -o". All the three .R files > > are correctly syntax highlighted. However, if I use :bd to close one > > window, the next window's syntax highlight will be gone. > -- <snip> -- > > I had the same rescently. > :set hidden > > fixed it for me. > > > Regards, > > Peng > > > Regards, > -- > bye Thilo > > 4096R/0xC70B1A8F > 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F > > > > You received this message because you are subscribed to the Google Group > vim_use. > You can post via email <[email protected]>. > To unsubscribe from this group, send<[email protected]>an > empty message. > For more options, visit <http://groups.google.com/group/vim_use/topics>this > group. > > -- > You received this message from the "vim_use" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php >
-- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
