Excuse the dumb question, but I can't find the answer in the docs...
I see you can /text to search, and do * to find the next occurrence
of the word under the cursor, but how do you paste text that you've just
yank'd, into the search line after you press / without using the mouse?
Thanks
C
I see you can /text to search, and do * to find the next
occurrence of the word under the cursor, but how do you paste
text that you've just yank'd, into the search line after you
press / without using the mouse?
You can use control+R followed by / to insert the text of the
last search.
Tim Chase wrote:
I see you can /text to search, and do * to find the next
occurrence of the word under the cursor, but how do you paste
text that you've just yank'd, into the search line after you
press / without using the mouse?
You can use control+R followed by / to insert the text of the
to find it anywhere. This seems like a cool concept that we
can get a function tree.
Your help is greatly appreciated.
--
View this message in context:
http://www.nabble.com/flist-tree-question-tf3836009.html#a10860821
Sent from the Vim - General mailing list archive at Nabble.com.
onesupermanone wrote:
I am a newbie at using gvim. I am using gvim ver 6.4 on linux. I wanted to
set up the flist tree on my machine. Dr Chip initially wrote this script.
The explaination is at the following site
mysite.verizon.net/astronaut/vim/index.html under title C/C++ Functions:
On 5/25/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
John Beckett wrote:
A.J.Mechelynck wrote:
What about a different function to return, say, the number of
1K blocks (or the number of times 2^n bytes, with a parameter
passed to the function) that a file uses?
Yes, that's a much
John Beckett wrote:
A.J.Mechelynck wrote:
What about a different function to return, say, the number of
1K blocks (or the number of times 2^n bytes, with a parameter
passed to the function) that a file uses?
Yes, that's a much more general and better idea.
Since there's probably not much
A.J.Mechelynck wrote:
I'm not sure what varnumber_T means: will st.stsize (the dividend) be
wide enough to avoid losing bits on the left?
varnumber_T is int (long if an sizeof(int) = 3).
st.stsize 's size depends on whether 32bit or 64bit integers are available.
So, its possible to lose
, that's the fstat function.
This function returns a pointer to a struct stat; the member in question
is: st_size.
(off_t st_size;/* total size, in bytes */)
So, st_size is an off_t.
Under linux, an off_t is typedef __kernel_off_toff_t
So, I suspect that st_size will be sized
Charles E Campbell Jr wrote:
A.J.Mechelynck wrote:
I'm not sure what varnumber_T means: will st.stsize (the dividend) be
wide enough to avoid losing bits on the left?
varnumber_T is int (long if an sizeof(int) = 3).
st.stsize 's size depends on whether 32bit or 64bit integers are available.
Yakov Lerner wrote:
[...]
stat() on Linux has 32-bit st_size field (off_t is 32-bit). There is
stat64()
syscall which uses 'struct stat64' structure where st_size is 64-bit. By
defining __USE_LARGEFILE64 at compile-time, stat() is redirected to
stat64(). I don't know whether default Linux vim
Charles E Campbell Jr wrote:
I've attached a patch to vim 7.1 which extends getfsize()
As I've mentioned, I think further testing will be needed before
patching Vim for 64-bit file lengths.
Here is a possible interim workaround to allow Dr.Chip's
LargeFile.vim script to accurately detect
Charles E Campbell Jr wrote:
I'm also under the impression that ls itself uses fstat(),
so its not likely to be any more informative.
That's likely on some systems, but 'ls -l' gives correct results
for files over 4GB on Fedora Core 6 using x86-32.
John
On 5/25/07, John Beckett [EMAIL PROTECTED] wrote:
A.J.Mechelynck wrote:
What about a different function to return, say, the number of
1K blocks (or the number of times 2^n bytes, with a parameter
passed to the function) that a file uses?
Yes, that's a much more general and better idea.
On 5/25/07, Yongwei Wu [EMAIL PROTECTED] wrote:
On 24/05/07, Robert M Robinson [EMAIL PROTECTED] wrote:
On Wed, 23 May 2007, fREW wrote:
|Someone recently was emailing the list about looking at a small
|section of DNA with vim as text and it was a number of gigs. I think
|he ended up using
On 5/25/07, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/25/07, Yongwei Wu [EMAIL PROTECTED] wrote:
On 24/05/07, Robert M Robinson [EMAIL PROTECTED] wrote:
On Wed, 23 May 2007, fREW wrote:
|Someone recently was emailing the list about looking at a small
|section of DNA with vim as text
No, I implied vim has more uses than any one person could possibly imagine.
I also meant any question like Why would anyone want ...? really just
means I can't imagine wanting , so if that isn't what you meant to
say you might want to rephrase your question. I would ask why anyone
would
Yakov Lerner wrote:
9-digit number can still be larger than 2^32-1, or than
2^31-1.
Just for the record:
2^30 = 1,073,741,824
So 999,999,999 (largest 9-digit number) won't overflow a 32-bit
signed integer.
John
Charles E Campbell Jr wrote:
Sounds like the filesize is getting stored in a 32bit signed
number, and overflowing.
Yes, definitely.
Please let me know what getfsize() is actually returning
The return value is the bit pattern for the low 32 bits of the
true 64-bit file size:
Yongwei Wu wrote:
Even FAT32 supports files much larger than 4GB.
Not true. FAT32 supports files up to 4 GB.
Sorry I shot my mouth off there - I realised my blunder about ten
minutes after sending. I haven't actually used a FAT32 partition
for over ten years, and was confusing the maximum
panshizhu wrote:
Yes, but on all systems, vim script could not take 64-bit
integers
I know that. My proposal is for a new Vim script function:
islargefile({fname}, {limit})
which would return nonzero if the size of the file is greater
than the 32-bit signed {limit} argument.
Vim could
John Beckett wrote:
Charles E Campbell Jr wrote:
Sounds like the filesize is getting stored in a 32bit signed
number, and overflowing.
Yes, definitely.
Please let me know what getfsize() is actually returning
The return value is the bit pattern for the low 32 bits of the
true 64-bit file
John Beckett wrote:
Yongwei Wu wrote:
Even FAT32 supports files much larger than 4GB.
Not true. FAT32 supports files up to 4 GB.
Sorry I shot my mouth off there - I realised my blunder about ten
minutes after sending. I haven't actually used a FAT32 partition
for over ten years, and was
A.J.Mechelynck wrote:
What about a different function to return, say, the number of
1K blocks (or the number of times 2^n bytes, with a parameter
passed to the function) that a file uses?
Yes, that's a much more general and better idea.
Since there's probably not much need for this, I think
Op woensdag 23 mei 2007, schreef fREW:
Another thing that might help with speed that was mentioned a month
or so ago is the following script specifically aimed at increasing
speed for large files:
http://www.vim.org/scripts/script.php?script_id=1506.
Indeed, among other things, this disables
Peter Palm wrote:
http://www.vim.org/scripts/script.php?script_id=1506.
Indeed, among other things, this disables the swap file for
'large' files, which should really speed up things.
I was going to report the following issue to vim-dev after I got
a chance to investigate it a little
John Beckett [EMAIL PROTECTED] 写于 2007-05-23 18:39:22:
The result was really ugly. The script failed to notice that 3GB
was large because the Vim function getfsize(f) returned a
negative number.
I haven't checked getfsize() on 32-bit Linux yet, nor am I
sufficiently patient to try opening
panshizhu wrote:
As far as I know, Windows does not support files larger than
4GB. So its okay to use unsigned 32-bit for filesize in
windows.
It's not as bad as that! Even FAT32 supports files much larger
than 4GB.
The Win32 API includes function _stati64() to get a 64-bit file
size (the API
John Beckett [EMAIL PROTECTED] 写于 2007-05-23 19:32:25:
On many systems, the calculation could use 64-bit integers.
John
Yes, but on all systems, vim script could not take 64-bit integers:
see eval.txt line 38:
1.1 Variable types ~
*E712*
There are
Robert M Robinson wrote:
That brings me to my question. I have noticed that when editing large
files (millions of lines), deleting a large number of lines (say,
hundreds of thousands to millions) takes an unbelieveably long time in
VIM--at least on my systems. This struck me as so odd, I
John Beckett wrote:
Peter Palm wrote:
http://www.vim.org/scripts/script.php?script_id=1506.
Indeed, among other things, this disables the swap file for
'large' files, which should really speed up things.
I was going to report the following issue to vim-dev after I got
a chance to
In that case, I'll have to thank Bram for fixing my problem before I even
asked him to do so! Thanks Gary, when I get a chance I'll download vim 7.
To those of you who provided links to work-around scripts etc., thank you
for your help. If any of you are having trouble with large files I'd
Robert Maxwell Robinson wrote:
In that case, I'll have to thank Bram for fixing my problem before I
even asked him to do so! Thanks Gary, when I get a chance I'll download
vim 7.
To those of you who provided links to work-around scripts etc., thank
you for your help. If any of you are
Charles E Campbell Jr [EMAIL PROTECTED] 写于 2007-05-23 21:38:27:
Sounds like the filesize is getting stored in a 32bit signed number, and
overflowing.
Is the negative number -1 (that would mean file can't be found)? If
not, then perhaps
that fact could be used to extend the LargeFile's
On 23/05/07, John Beckett [EMAIL PROTECTED] wrote:
panshizhu wrote:
As far as I know, Windows does not support files larger than
4GB. So its okay to use unsigned 32-bit for filesize in
windows.
It's not as bad as that! Even FAT32 supports files much larger
than 4GB.
Not true. FAT32
Yongwei Wu [EMAIL PROTECTED] 写于 2007-05-24 11:28:06:
Who really want to edit TEXT files as large as that? I cannot think of
scenarios other than log files. Maybe Vim does not fit in this role.
Best regards,
Yongwei
--
Yes it fits in this role, and frankly speaking this was the reason I
On 5/23/07, Yongwei Wu [EMAIL PROTECTED] wrote:
On 23/05/07, John Beckett [EMAIL PROTECTED] wrote:
panshizhu wrote:
As far as I know, Windows does not support files larger than
4GB. So its okay to use unsigned 32-bit for filesize in
windows.
It's not as bad as that! Even FAT32 supports
department was loading
so many people on the VAXen that EDT was rendered unusably slow. I still like
VIM largely because I can do so much with so little effort in so little time.
That brings me to my question. I have noticed that when editing large files
(millions of lines), deleting a large
our computer
science department was loading so many people on the VAXen that EDT was
rendered unusably slow. I still like VIM largely because I can do so
much with so little effort in so little time.
That brings me to my question. I have noticed that when editing large
files (millions
That brings me to my question. I have noticed that when
editing large files (millions of lines), deleting a large
number of lines (say, hundreds of thousands to millions) takes
an unbelieveably long time in VIM--at least on my systems.
The issue of editing large files comes up occasionally
Thanks, Tim. I'll look at the options you recommended--and those you
didn't, so I may not need to ask next time. :)
Cheers,
Max
On Tue, 22 May 2007, Tim Chase wrote:
The issue of editing large files comes up occasionally. A few settings can
be tweaked to vastly improve performance.
Well, I don't mean to. :set says this:
--
autoindent helplang=en scroll=11 t_Sb=Esc[4%dm
backspace=2 history=50 ttyfast t_Sf=Esc[3%dm
cscopetag hlsearchttymouse=xterm
cscopeverbose ruler viminfo='20,50
Do you have syntax highlighting enabled? That can really slow vim
down.
Well, I don't mean to. :set says this:
It can be toggled via
:syntax on
and
:syntax off
To see what flavor of syntax highlighting you currently have, you
can query the 'syntax' setting:
I just tried deleting 1133093 lines of a 1133093+1133409 line file, after
typing :syntax off. It took about 3 minutes.
Max
On Tue, 22 May 2007, Tim Chase wrote:
Do you have syntax highlighting enabled? That can really slow vim
down.
Well, I don't mean to. :set says this:
It can be
:set syntax? replies syntax=. I don't think it's syntax highlighting.
I've used that with C and Prolog code before; I gave it up because it was
too slow. I'm editing text output from one of my programs; truncating the
output of a day-long run to match a run in progress for testing purposes,
of mine had ported it), when our
computer science department was loading so many people on the VAXen
that EDT was rendered unusably slow. I still like VIM largely because
I can do so much with so little effort in so little time.
That brings me to my question. I have noticed that when editing
unusably slow. I still like VIM largely because I can do so
much with so little effort in so little time.
That brings me to my question. I have noticed that when editing large
files (millions of lines), deleting a large number of lines (say,
hundreds of thousands to millions) takes
On 2007-05-22, Robert Maxwell Robinson [EMAIL PROTECTED] wrote:
:set undolevels=-1 caused my test to run in less than 15 sec, with no
other options fiddled with. Thanks Tim, now I have a work-around!
Now, does having the undo facility available _necessarily_ mean deleting a
large
Hmm, interesting. I've noticed before that the CPU is pegged when I'm
deleting, but I don't think my machine's behavior is due to CPU load; the
machine has two CPUs, I'm typically the only (serious) user, as top has
confirmed is the case now, and I get the same behavior whether I'm running
On 2007-05-22, Robert Maxwell Robinson [EMAIL PROTECTED] wrote:
Hmm, interesting. I've noticed before that the CPU is pegged when I'm
deleting, but I don't think my machine's behavior is due to CPU load; the
machine has two CPUs, I'm typically the only (serious) user, as top has
On 5/22/07, Gary Johnson [EMAIL PROTECTED] wrote:
On 2007-05-22, Robert Maxwell Robinson [EMAIL PROTECTED] wrote:
Hmm, interesting. I've noticed before that the CPU is pegged when I'm
deleting, but I don't think my machine's behavior is due to CPU load; the
machine has two CPUs, I'm
AFAIK Vim 7 has a different way of handling undo levels.
Have you tried with Vim 6 instead? I had used Vim 6 to edit a text file
(3Gbytes) and do things within seconds.
--
Sincerely, Pan, Shi Zhu. ext: 2606
Robert Maxwell Robinson [EMAIL PROTECTED] 写于 2007-05-23 05:59:20:
:set undolevels=-1
Hi,
I may become blinded by to often looking for too long
onto my monitor, but...
I am trying to write a simple function, which searches through
the whole buffer to fund a certain pattern and stops searching
when found the first match. I also want the function to
return a matched/not
I am trying to write a simple function, which searches through
the whole buffer to fund a certain pattern and stops searching
when found the first match. I also want the function to
return a matched/not matched return code and given the caller
the line/column of the match if found.
/OmniCppComplete-question-tf3780665.html#a10691989
Sent from the Vim - General mailing list archive at Nabble.com.
this message in context:
http://www.nabble.com/OmniCppComplete-question-tf3780665.html#a10691989
Sent from the Vim - General mailing list archive at Nabble.com.
I am running gvim version 7.0.235 on FC6. I have a slight problem
where everytime I open a gvim session, the gvim window is placed behind
all of my terminals. Would anyone have an idea why this is happening and
how I may correct it?
While I don't know enough about your setup to give
Thanks Tim. I'll check it out,
Sean
Tim Chase wrote:
I am running gvim version 7.0.235 on FC6. I have a slight problem
where everytime I open a gvim session, the gvim window is placed behind
all of my terminals. Would anyone have an idea why this is happening and
how I may correct it?
Hello,
I am running gvim version 7.0.235 on FC6. I have a slight problem
where everytime I open a gvim session, the gvim window is placed behind
all of my terminals. Would anyone have an idea why this is happening and
how I may correct it?
Thanks in advance,
Sean
Hey there all,
i really dig the zz function to get me in the middle of the screen.
i was wondering if there were an insert mode ability to do the same thing.
So if i am writing a long function and get to the bottom of the screen
i can move where i am at to the middle of the screen while still in
yep, that helps,
just did the map, exactly what i was looking for, thanks
shawn
On 5/4/07, Tim Chase [EMAIL PROTECTED] wrote:
i really dig the zz function to get me in the middle of the screen.
i was wondering if there were an insert mode ability to do the same thing.
So if i am writing a
shawn bright wrote:
Hey there all,
i really dig the zz function to get me in the middle of the screen.
i was wondering if there were an insert mode ability to do the same thing.
So if i am writing a long function and get to the bottom of the screen
i can move where i am at to the middle of the
the
original behaviour.
Hope this helps,
Salman.
-Original Message-
From: A.J.Mechelynck [mailto:[EMAIL PROTECTED]
Sent: Friday, May 04, 2007 11:28 AM
To: shawn bright
Cc: vimlist
Subject: Re: question about insert mode and zz
shawn bright wrote:
Hey there all,
i really dig the zz
shawn bright wrote:
Hey there all,
i really dig the zz function to get me in the middle of the screen.
i was wondering if there were an insert mode ability to do the same
thing.
So if i am writing a long function and get to the bottom of the screen
i can move where i am at to the middle of
On some of the other mailing lists to which I subscribe, I have
the ability to set an option that sniffs the headers and doesn't
send a duplicte copy to me if I'm already in the TO:/CC: headers.
Most of these use the majordomo software, IIUC.
Is there a way to do the same thing with the Vim
Tim Chase wrote:
On some of the other mailing lists to which I subscribe, I have
the ability to set an option that sniffs the headers and doesn't
send a duplicte copy to me if I'm already in the TO:/CC: headers.
Most of these use the majordomo software, IIUC.
Is there a way to do the same
Hale Boyes, Kevin wrote:
How do I search in a document to the next line that doesn't contain a
specific string? Something along the lines of grep -v.
If you need all lines that don't contain pattern, try :v/pattern/
If you want to jump to the next line that does not match pattern,
you could
Subject: [Fwd: Latex Suite - question about font shortcut FMD]
Date: Thu, 15 Feb 2007 14:44:35 +0100
From: Robert Cussons [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Tried your old e-mail address first ;-)
Original Message
Subject: Latex Suite - question
* Robert Cussons on Wednesday, April 18, 2007 at 09:22:13 +0200:
I work with a nuclear physics model called FMD, so as you can imagine,
each time I type FMD I would prefer it if latex suite didn't interpret
that as an abbreviation for \textmd{}++ :-)
I found the following lines in the
Hi, Dr. Chip and Vimmer,
Just found that after I updated the manpageview.vim plugin
(http://www.vim.org/scripts/script.php?script_id=489)
to the latest one, pressing K in some codes like printf(foo),
when the cursor is under the word printf, will show me an error
message like:
***warning***
Zhaojun WU wrote:
Just found that after I updated the manpageview.vim plugin
(http://www.vim.org/scripts/script.php?script_id=489)
to the latest one, pressing K in some codes like printf(foo),
when the cursor is under the word printf, will show me an error
message like:
***warning***
How do I search in a document to the next line that doesn't contain a
specific string? Something along the lines of grep -v.
Thanks,
Kevin.
Using Vim/Gvim 7.0
This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for
Hale Boyes, Kevin wrote:
How do I search in a document to the next line that doesn't contain a
specific string? Something along the lines of grep -v.
I suggest trying the LogiPat plugin. To do what you're asking with it:
:LP !string
It takes Boolean logic (!=not |=or =and ()s ) plus
Tim Chase wrote:
In general, the safest keys to use for the {lhs} (left-hand
side) of mappings are the F keys. Almost everything else
already has a function in Vim. Among
Worth knowing. Thanks. What about when using a leader such as
, or / ?
The comma does a reverse-search of the last thing
One other candidate might be the underscore, though it's a
shifted key which makes it a little more difficult, it is
usually in a pretty predictable place (unlike the
backslash/pipe key which I find all over the keyboard
depending on whose machine I'm using...makes typing DOS
file-paths a pain).
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?
I think my friend
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?
I think my friend
Tim Chase wrote:
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
On 4/11/07, Gene Kwiecinski [EMAIL PROTECTED] wrote:
What's the most interesting name anyone can find, and also the most
damaging?
I think my friend :1,$d would win that particular contest...
I was going to make a joke about my middle name being :!chmod -R 0 /
and causing confusion as a
Hi All,
On my gvim 7 running on Win Xp none of the following work to move to
another window (I'm actually using the project plugin, but I don't
think that's relevant)..
CTRL-W Left *CTRL-W_Left*
CTRL-W CTRL-H *CTRL-W_CTRL-H*
Samuel Wright wrote:
Hi All,
On my gvim 7 running on Win Xp none of the following work to move to
another window (I'm actually using the project plugin, but I don't
think that's relevant)..
CTRL-W Left*CTRL-W_Left*
CTRL-W CTRL-H*CTRL-W_CTRL-H*
CTRL-W BS
Albie Janse van Rensburg wrote:
Samuel Wright wrote:
Hi All,
On my gvim 7 running on Win Xp none of the following work to move to
another window (I'm actually using the project plugin, but I don't
think that's relevant)..
CTRL-W Left*CTRL-W_Left*
CTRL-W CTRL-H
Samuel Wright wrote:
Guys,
Thanks for the response!
Albie, yes I was talking about split windows. not vim tabs or windows
apps...
Tony, thanks for reminding me of :map to check what a mapping does.
Yes, it was mapped in an obscure corner of my vimrc, that will teach
me to cut and paste
On 10/04/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
In general, the safest keys to use for the {lhs} (left-hand side) of mappings
are the F keys. Almost everything else already has a function in Vim. Among
Worth knowing. Thanks. What about when using a leader such as , or / ?
Hit any key to
In general, the safest keys to use for the {lhs} (left-hand
side) of mappings are the F keys. Almost everything else
already has a function in Vim. Among
Worth knowing. Thanks. What about when using a leader such as
, or / ?
The comma does a reverse-search of the last thing you searched
for
On 10/04/07, Tim Chase [EMAIL PROTECTED] wrote:
The comma does a reverse-search of the last thing you searched
for using t/T/f/F which many folks don't use (so they use it for
leader), but I use regularly.
Yes, have seen , used as leader before. Will look at the other usage
though, as it is
On 4/7/07, Matthew Winn [EMAIL PROTECTED] wrote:
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
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
Has anyone else heard of the vi name game?
I was talking to an old crusty developer, and he said they used to
open a random (unimportant) text file in vi. Then before typing in
their name (and only their name, no going into insert mode first),
they would have to guess what their name would tell
-Original Message-
From: Dudley Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 8:50 AM
To: vim@vim.org
Subject: Silly Question
Has anyone else heard of the vi name game?
I was talking to an old crusty developer, and he said they used to
open a random (unimportant) text file
On piątek 06 kwiecień 2007, vim@vim.org wrote:
Has anyone else heard of the vi name game?
Sure :)
Mikolaj just inserts kolaj at the beginning of middle line of screen.
m.
brendon i lucked out, i just got errors :)
Jason joins the current line and the next, then insert son before
the start of the appended line.
even
learned something new from a silly question. What a great mailing
list!
Enjoy,
Dudley
Yakov (without quotes) inserts kov after the 1st
char.
Now, who won ?
know about the M command. I never needed it before. I even
learned something new from a silly question. What a great mailing
list!
H and L are even more useful :)
m.
On 4/3/07, Thomas [EMAIL PROTECTED] wrote:
Maybe I misunderstand the problem but can't you change those lines
with just blanks to empty lines?
Sure I can remove the whitespace characters. But I'd rather simply not
have to care about them (but this is filetype-dependent because for some
autocmd BufRead,BufWrite * if ! bin | silent! %s/\s\+$//ge | endif
Thanks. I think this is about what I was looking for.
Regards,
Thomas.
Hi,
This is something that I found annoying quite a time now and I'm
pretty sure there is a simple solution for this problem.
Paragraphs are defined as:
A paragraph begins after each empty line, and also at each of a set of
paragraph macros, specified by the pairs of characters in the
On Tue, Apr 03, 2007 at 02:00:59PM EDT, Thomas wrote:
Hi,
This is something that I found annoying quite a time now and I'm
pretty sure there is a simple solution for this problem.
Paragraphs are defined as:
A paragraph begins after each empty line, and also at each of a set of
1 - 100 of 448 matches
Mail list logo
