patch: automatically enter paste mode
Pasting code into vim and forgetting to set paste can have annoying
results. This patch detects the 'really fast typing' that happens when
something is pasted in, and turns on paste mode. It provides an option
'autopaste' (default false) which controls the behavior.
Patch is attached. Hope this is useful.
--
Ian Kilgore
`echo "[EMAIL PROTECTED]" | tr pzfwxt ikagno`
diff -cr vim70.orig/src/getchar.c vim70/src/getchar.c
*** vim70.orig/src/getchar.c2006-09-12 21:47:30.0 -0400
--- vim70/src/getchar.c 2006-09-12 21:53:35.0 -0400
***
*** 1495,1500
--- 1495,1507
int
vgetc()
{
+ static time_t last_call = 0;
+ static int cps = 0;
+ char_u sPaste[] = "paste";
+ time_t now;
+ if (p_apa)
+ now = time(NULL);
+
int c, c2;
#ifdef FEAT_MBYTE
int n;
***
*** 1502,1507
--- 1509,1527
int i;
#endif
+ if (p_apa && !p_paste) {
+ if (last_call == now)
+ ++cps;
+ else
+ cps = 0;
+ if (cps >= 30) {
+ cps = 0;
+ do_set(&sPaste, 0);
+ showmode();
+ }
+ last_call = now;
+ }
+
/*
* If a character was put back with vungetc, it was already processed.
* Return it directly.
diff -cr vim70.orig/src/option.c vim70/src/option.c
*** vim70.orig/src/option.c 2006-09-12 21:47:30.0 -0400
--- vim70/src/option.c 2006-09-12 21:54:07.0 -0400
***
*** 529,534
--- 529,537
{"autoindent", "ai", P_BOOL|P_VI_DEF,
(char_u *)&p_ai, PV_AI,
{(char_u *)FALSE, (char_u *)0L}},
+ {"autopaste", "apa", P_BOOL|P_VI_DEF,
+ (char_u *)&p_apa, PV_NONE,
+ {(char_u *)FALSE, (char_u *)0L}},
{"autoprint", "ap", P_BOOL|P_VI_DEF,
(char_u *)NULL, PV_NONE,
{(char_u *)FALSE, (char_u *)0L}},
diff -cr vim70.orig/src/option.h vim70/src/option.h
*** vim70.orig/src/option.h 2006-09-12 21:47:30.0 -0400
--- vim70/src/option.h 2006-09-12 21:54:23.0 -0400
***
*** 312,317
--- 312,318
#if defined(FEAT_GUI) && defined(MACOS_X)
EXTERN int*p_antialias; /* 'antialias' */
#endif
+ EXTERN int p_apa; /* 'autopaste' */
EXTERN intp_ar; /* 'autoread' */
EXTERN intp_aw; /* 'autowrite' */
EXTERN intp_awa; /* 'autowriteall' */
signature.asc
Description: Digital signature
Bug or feature? CursorLine/CursorColumn hihlights vs. other highlights
I have enabled CursorLine and CursorColumn highlights as follows:
(~/.vimrc):
[...]
colorscheme almost-default
[...]
if exists("+cursorcolumn")
set cuc cul
endif
[...]
(~/.vim/colors/almost-default.vim):
[...]
if has("gui_running")
hi clear CursorLine
hi CursorLine guibg=#F4F4F4
" leave it underlined (default) in cterm
endif
hi clear CursorColumn
hi link CursorColumn CursorLine
[...]
However, I notice that their interaction with other highlights is not
always the same, even though they are linked to each other: all the
following is in the GUI:
- most syntax highlights change only the foreground, which is respected;
- a few, for instance helpNote (linked to Todo) and htmlError (linked to
Error), change the background, which is changed to pale grey on both the
cursor line and the cursor column;
- neither the status line, the (text-style) tab line, nor text in
another window than the current one, are affected.
I suppose the above can be regarded as normal. But:
- Search highlight sets the background to yellow; this is changed to
pale grey on the cursor column but not on the cursor line;
- SpecialKey sets the foreground to blue and NonText sets it to bold
blue: these are changed to unbold and bold black (respectively) on the
cursor line but not on the cursor column.
The fact that in these cases, highlights linked to each other do not
behave identically, strikes me as weird. Bug or feature?
Best regards,
Tony.
Re: Patch 7.0.096
On Tue, 12 Sep 2006 at 1:56pm, A.J.Mechelynck wrote:
> Hari Krishna Dara wrote:
> [...]
> > Yes, that is what I am doing. Is fnamemodify() an expensive operation
> > involving OS calls?
> >
>
> From the description of what it does, fnamemodify() _seems_ to involve
> only string manipulation, possibly checking $HOME and/or the current
> window's current directory depending on the {mods} argument. There may
> be one OS call on Unix or VMS if ~user/ (not just ~ which is $HOME) is
> used in conjunction with ":p".
>
> I haven't checked the C code however.
>
>
> Best regards,
> Tony.
That is what I was hoping. At least for simple modifications not
involving special character expansion, it is probably simple string
manipuations and will not be expensive.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Patch 7.0.101
Patch 7.0.101
Problem:When the "~/.vim/spell" directory does not exist "zg" may create
a wrong directory. "zw" doesn't work.
Solution: Use the directory of the file name instead of NameBuff. For "zw"
not only remove a good word but also add the word with "!".
Files: src/spell.c
*** ../vim-7.0.100/src/spell.c Mon Sep 11 21:37:27 2006
--- src/spell.c Tue Sep 12 20:21:01 2006
***
*** 9347,9366
fclose(fd);
}
}
! else
{
fd = mch_fopen((char *)fname, "a");
if (fd == NULL && new_spf)
{
/* We just initialized the 'spellfile' option and can't open the
* file. We may need to create the "spell" directory first. We
* already checked the runtime directory is writable in
* init_spellfile(). */
! if (!dir_of_file_exists(fname))
{
/* The directory doesn't exist. Try creating it and opening
* the file again. */
! vim_mkdir(NameBuff, 0755);
fd = mch_fopen((char *)fname, "a");
}
}
--- 9347,9373
fclose(fd);
}
}
!
! if (!undo)
{
fd = mch_fopen((char *)fname, "a");
if (fd == NULL && new_spf)
{
+ char_u *p;
+
/* We just initialized the 'spellfile' option and can't open the
* file. We may need to create the "spell" directory first. We
* already checked the runtime directory is writable in
* init_spellfile(). */
! if (!dir_of_file_exists(fname) && (p = gettail_sep(fname)) != fname)
{
+ int c = *p;
+
/* The directory doesn't exist. Try creating it and opening
* the file again. */
! *p = NUL;
! vim_mkdir(fname, 0755);
! *p = c;
fd = mch_fopen((char *)fname, "a");
}
}
*** ../vim-7.0.100/src/version.cMon Sep 11 21:37:27 2006
--- src/version.c Tue Sep 12 21:47:21 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 101,
/**/
--
ARTHUR: Did you say shrubberies?
ROGER: Yes. Shrubberies are my trade. I am a shrubber. My name is Roger
the Shrubber. I arrange, design, and sell shrubberies.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Patch 7.0.096
Hari Krishna Dara wrote: > > > I could always explicitly do a fnamemodify() on each of the files, > > > so it is not a big deal, but I am wondering how efficient > > > fnamemodify() is, if it involves simple string manipulation or OS > > > calls. > > > > Normally relative file names work just fine. If you need a full path > > you can use fnamemodify() in a map() to change it. > > Yes, that is what I am doing. Is fnamemodify() an expensive operation > involving OS calls? It depends on what you are doing, what the file name is and what system you are on. Mostly for turning a relative name into a full path an OS call is needed. You'll have to try it out. -- Q: What do you call a fish without an eye? A: fsh! Q: What do you call a deer with no eyes? A: no eye deer. Q: What do you call a deer with no eyes and no legs? A: still no eye deer. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Patch 7.0.094
* Bram Moolenaar <[EMAIL PROTECTED]> [060909 08:53]: > > Patch 7.0.094 > Problem:When a hidden buffer is made the current buffer and another file > edited later, the file message will still be given. Using > ":silent" also doesn't prevent the file message. (Marvin Renich) > Solution: Reset the need_fileinfo flag when reading a file. Don't set > need_fileinfo when msg_silent is set. > Files:src/buffer.c, src/fileio.c > Thanks! This fixes my problem. ...Marvin
Re: Possible addition to the c.vim and perl.vim syntax files
Mike Williams wrote: mwoehlke did utter on 11/09/2006 18:37: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive="TRUE"', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. Mea culpa, you are right. Add an ll to the above list. What are not valid is lul. Ah, whew, my faith in standards is restored. :-) Thanks for following up. -- Matthew Ok, so the quotes aren't entirely original.
Re: Patch 7.0.096
Hari Krishna Dara wrote:
[...]
Yes, that is what I am doing. Is fnamemodify() an expensive operation
involving OS calls?
From the description of what it does, fnamemodify() _seems_ to involve
only string manipulation, possibly checking $HOME and/or the current
window's current directory depending on the {mods} argument. There may
be one OS call on Unix or VMS if ~user/ (not just ~ which is $HOME) is
used in conjunction with ":p".
I haven't checked the C code however.
Best regards,
Tony.
Anim8or scripting language.
There is a free, but not open source, 3d modelling package called
Anim8or at http://www.anim8or.com/ which, in the new beta release
has a scripting language. Anim8or also has modelling files, so
there are really two different syntaxes associated with this.
The modelling files are something I have not tried to make Vim
support, so in the attached patch I have named the file a8s.vim
rather than anim8or.vim.
The patch is a clumsy hack (with a blunt instrument, so to speak) at
the C syntax file, to get it to support the a8s syntax. It is definitely
buggy:
#parameters("this",
"that",
"the other)
fails with a syntax error on the last bracket and the colouring for
it doesn't work as I'd expect from hacking the #define directive in
C. That may not even be the right approach, given the semantics.
I tried to provide support the highlighting $variables, but couldn't
understand how this was done in perl.vim or sh.vim to get it right,
so I've left that for now.
Anyway, I'm putting this forward in the hope that someone more fluent
in vim scripting, syntax, etc can [help me?] make something presentable
out of it, and the hope that others find it of some use.
I've created a small web page about this at
http://www.eng.cse.dmu.ac.uk/~hgs/anim8or/
from which you can get the attached patch and the syntax file itself.
Thank you,
Hugh
--- vim70/filetype.vim.orig 2006-05-07 15:13:38.0 +0100
+++ vim70/filetype.vim 2006-09-12 10:38:16.34575 +0100
@@ -95,6 +95,9 @@
" AMPL
au BufNewFile,BufRead *.runsetf ampl
+" Anim8or Script
+au BufNewFile,BufRead *.a8ssetf a8s
+
" Ant
au BufNewFile,BufRead build.xmlsetf ant
--- vim70/syntax/a8s.vim.orig 1970-01-01 00:01:00.0 +
+++ vim70/syntax/a8s.vim2006-09-12 11:33:58.62700 +0100
@@ -0,0 +1,268 @@
+" Vim syntax file
+" Language:Anim8or Script
+" Maintainer: Hugh Sasse <[EMAIL PROTECTED]>
+" Last Change: 2006 Sep 11
+
+" Quit when a (custom) syntax file was already loaded
+if exists("b:current_syntax")
+ finish
+endif
+
+" A bunch of useful C keywords
+syn keyworda8sStatementbreak return continue
+syn keyworda8sLabelcase default
+syn keyworda8sConditional if else switch
+syn keyworda8sRepeat while for to do
+
+syn keyworda8sTodo contained TODO FIXME XXX
+
+" a8sCommentGroup allows adding matches for special things in comments
+syn clustera8sCommentGroup contains=a8sTodo
+
+" String and Character constants
+" Highlight special characters (those which have a backslash) differently
+syn match a8sSpecial display contained "\\\(x\x\+\|\o\{1,3}\|.\|$\)"
+if !exists("a8s_no_utf")
+ syn matcha8sSpecial display contained "\\\(u\x\{4}\|U\x\{8}\)"
+endif
+if exists("a8s_no_cformat")
+ syn region a8sString start=+L\="+ skip=+\|\\"+ end=+"+
contains=a8sSpecial,@Spell
+ " a8sCppString: same as a8sString, but ends at end of line
+ syn region a8sCppStringstart=+L\="+ skip=+\|\\"\|\\$+ excludenl
end=+"+ end='$' contains=a8sSpecial,@Spell
+else
+ if !exists("a8s_no_c99") " ISO C99
+syn match a8sFormat display "%\(\d\+\$\)\=[-+'
#0*]*\(\d*\|\*\|\*\d\+\$\)\(\.\(\d*\|\*\|\*\d\+\$\)\)\=\([hlLjzt]\|ll\|hh\)\=\([aAbdiuoxXDOUfFeEgGcCsSpn]\|\[\^\=.[^]]*\]\)"
contained
+ else
+syn match a8sFormat display "%\(\d\+\$\)\=[-+'
#0*]*\(\d*\|\*\|\*\d\+\$\)\(\.\(\d*\|\*\|\*\d\+\$\)\)\=\([hlL]\|ll\)\=\([bdiuoxXDOUfeEgGcCsSpn]\|\[\^\=.[^]]*\]\)"
contained
+ endif
+ syn matcha8sFormat display "%%" contained
+ syn region a8sString start=+L\="+ skip=+\|\\"+ end=+"+
contains=a8sSpecial,a8sFormat,@Spell
+ " a8sCppString: same as a8sString, but ends at end of line
+ syn region a8sCppStringstart=+L\="+ skip=+\|\\"\|\\$+ excludenl
end=+"+ end='$' contains=a8sSpecial,a8sFormat,@Spell
+endif
+
+syn match a8sCharacter"L\='[^\\]'"
+syn match a8sCharacter"L'[^']*'" contains=a8sSpecial
+if exists("a8s_gnu")
+ syn matcha8sSpecialError "L\='\\[^'\"?\\abefnrtv]'"
+ syn matcha8sSpecialCharacter "L\='\\['\"?\\abefnrtv]'"
+else
+ syn matcha8sSpecialError "L\='\\[^'\"?\\abfnrtv]'"
+ syn matcha8sSpecialCharacter "L\='\\['\"?\\abfnrtv]'"
+endif
+syn match a8sSpecialCharacter display "L\='\\\o\{1,3}'"
+syn match a8sSpecialCharacter display "'\\x\x\{1,2}'"
+syn match a8sSpecialCharacter display "L'\\x\x\+'"
+
+"when wanted, highlight trailing white space
+if exists("a8s_space_errors")
+ if !exists("a8s_no_trail_space_error")
+syn match a8sSpaceError display excludenl "\s\+$"
+ endif
+ if !exists("a8s_no_tab_space_error")
+syn match a8sSpaceError display " \+\t"me=e-1
+ endif
+endif
+
+"catch errors caused by wrong parenthesis and brackets
+" also accept <% for {, %> for }, <: for [ and :> for ] (C99)
Re: Binary, Octal, Decimal, Hex!
Mark Manning wrote: Yakov Lerner wrote: On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: > >> It is fairly easy to check for inconsistencies in Binary, Octal, and Hex > > > I'm afraid C does not notion of binary numbers. > > Yakov > On some systems that answer is correct. On others it is not. :-) I'm aware of binary numbers in perl (0b101010101). But in C ? What exactly is syntax of "binary numbers in C" ? How does it look ? On which systems ? I never heard of "binary numbers in C" ... I am very curious to hear from you all details that you can provide. What exactly are those systems and how exactly the syntax looks ? Yakov Since I've been working with computers since the early 1970s and since I used B (the predecessor of C which was [and possibly still is] used in Canada), it is more than most likely that I am mixing and matching my languages or remembering an outdated version of C. Also, since at NASA (I was at NASA JSC in ClearLake/Houston) we had to do a lot of our own coding for various items (like a control chair so simulations could be done with the astronauts, or the fixed and motion based simulators, etc...) it is also likely that I was using macros someone else wrote to allow for binary input of numbers. (This was necessary in some cases because the hardware would only accept binary information some times. In many cases we would do inline assembly language within the C programs too.) The 70's and even the 80's were a dark time in computer programming because there were very few standards and not a lot of company's used them. (This is one of the really few things that Microsoft and Apple Computer helped to change. They do try to enforce the standards - on everyone else of course. Even though it seems they both also break their own standards every chance they get.) Like SGI which had it's own special interface for their graphic computers until X-Windows came along and then SGI switched to Linux as their OS basis. There were some "special" items to SGI's C to help handle the graphics in the pre-X-Windows days. Things became more standardized with X-Windows and then the Linux OS helped out even more. So take your pick. Don't really care. But there probably are still systems out there that have binary capabilities in their C languages to help out with whatever. Check out Sony's PlayStation 3. People are having to write very low-level code to get it to work. Makes me wonder if people are using C and if those compilers have special additions to them that would allow someone to write binary information directly to a part of the hardware to help boost the speed of it. If so, they might extend the C language via macros or a direct change to the compiler in order for everyone to get the most out of the computer. Still, I'm not going to rack my brain for exactly which system and where just because you want to know. It is not worth the time or effort on my part. Have fun! :-) Mark I suppose that with inline assembly, assembly-language syntax blocks could be included within C syntax (like mzscheme, perl, python, ruby and tcl syntax blocks within vim syntax) but that should be handled by the appropriate assembly-language syntax script, which ought to allow (e.g., for MASM) 11010011B (binary), 0D3H (hex), 343O or 343Q (Octal; my memory is failing) as well as 211D (decimal) and 211 (decimal by default) as synonymous; IIRC it also has floating-point numbers in decimal-point or exponential notation for use with the arithmetic coprocessor. Best regards, Tony.
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke did utter on 11/09/2006 18:37: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive="TRUE"', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. Mea culpa, you are right. Add an ll to the above list. What are not valid is lul. TTFN Mike -- Sign at Proctologist's office: "Parking in Rear"
