Am 22.10.2011 08:35 schrieb <vim_use@googlegroups.com>:
-- Group: http://groups.google.com/group/vim_use/topics
- drawing and column editing in vim [3 Updates]
- One line without EOL [7 Updates]
- gvim64/win7 claims error on unzip, but unzip get no error, why? [4 Updates]
- line drawing inside vim [3 Updates]
- Syntax highlighting Problem in for Bash [3 Updates]
- Tracing Vim into a log file. [1 Update]
- :bd makes syntax highlight of the next window unavailable [1 Update]
Eric Smith <es@fruitcom.com> 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 <cjns1989@gmail.com> 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 <jerojasro@devnull.li> 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
meino.cramer@gmx.de 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 <antoine.mechelynck@gmail.com> 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.
meino.cramer@gmx.de 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 <tmhedberg@gmail.com> 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 <fritzophrenic@gmail.com> 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" <vim@benizi.com> 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" <vim@benizi.com> 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
Linda W <vim@tlinx.org> 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 <Charles.E.Campbell@nasa.gov> 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 <fritzophrenic@gmail.com> 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" <vim@benizi.com> 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
Tim Chase <vim@tim.thechases.com> 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 <es@fruitcom.com> 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 <fritzophrenic@gmail.com> 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
Tom Bodine <freeislandguy@gmail.com> 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 <antoine.mechelynck@gmail.com> 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 <garyjohn@spocom.com> 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
Tony Mechelynck <antoine.mechelynck@gmail.com> 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"
Thilo Six <T.Six@gmx.de> 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.
To unsubscribe from this group, send an empty message.
For more options, visit 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
No comments:
Post a Comment