Re: Syntax file problem
Hi again,
I solved my self-posed problem. I had to extend some Tex
syntax clusters.
A working version of an R noweb syntax file is attached.
R noweb files (aka Sweave files) can have the extension .Rnw,
.rnw, .Snw or .snw, although .Rnw is probably predominant.
Cheers,
Johannes
* Johannes Ranke [EMAIL PROTECTED] [060411 23:54]:
Hi all,
Maybe someone could shed some light on why the attached syntax file does
not work, i.e. R code is not highlighted in code chunks embedded in
Latex files?
I am attaching an example file as well.
Best regards,
Johannes
--
Dr. Johannes Ranke [EMAIL PROTECTED]
UFT Bremen, Leobenerstr. 1 +49 421 218 8971
D-28359 Bremen http://www.uft.uni-bremen.de/chemie/ranke
Vim syntax file
Language:R noweb Files
Maintainer: Johannes Ranke [EMAIL PROTECTED]
Last Change: 2006 Apr 13
Version: 0.2
Remarks: - This file is inspired by the proposal of
Fernando Henrique Ferraz Pereira da Rosa
[EMAIL PROTECTED]
http://www.ime.usp.br/~feferraz/en/sweavevim.html
- It extends some clusters from syntax/tex.vim
(version 33,
March 06 2006) and therefore depends on some
contents
of this file
- Sweave/Rweave option commands are not differentiated
Maintainer: Johannes Ranke [EMAIL PROTECTED]
Last Change: 2006 Apr 11
Version Clears: {{{1
For version 5.x: Clear all syntax items
For version 6.x and 7.x: Quit when a syntax file was already loaded
if version 600
syntax clear
elseif exists(b:current_syntax)
finish
endif
syn case match
Tex regions {{{1
runtime syntax/tex.vim
unlet b:current_syntax
syn cluster texDocGroup contains=texPartZone,@texPartGroup,@rnoweb
syn cluster texPartGroup
contains=texChapterZone,texSectionZone,texParaZone,@rnoweb
syn cluster texChapterGroup
contains=texSectionZone,texParaZone,@rnoweb
syn cluster texSectionGroup
contains=texSubSectionZone,texParaZone,@rnoweb
syn cluster texSubSectionGroup
contains=texSubSubSectionZone,texParaZone,@rnoweb
syn cluster texSubSubSectionGroup contains=texParaZone,@rnoweb
syn cluster texParaGroupcontains=texSubParaZone,@rnoweb
Highlighting of R code using an existing r.vim syntax file if available {{{1
syn include @rnowebR syntax/r.vim
syn region rnowebChunk matchgroup=rnowebDelimiter start=^.*=
matchgroup=rnowebDelimiter end=^@ [EMAIL PROTECTED]
syn region rnowebSexpr matchgroup=Delimiter start=\\Sexpr{
matchgroup=Delimiter end=} [EMAIL PROTECTED]
Sweave options command {{{1
syn region rnowebSweaveopts matchgroup=Delimiter start=\\SweaveOpts{
matchgroup=Delimiter contains=rnowebOpts
rnoweb Cluster {{{1
syn cluster rnoweb contains=rnowebChunk,rnowebDelimiter,rnowebSexpr
Highlighting {{{1
hi def link rnowebDelimiter Delimiter
let b:current_syntax = rnoweb
vim: foldmethod=marker:
Vim 7.0d02
Hello, On Windows XP, the following line throws an error in my _vimrc: set sessionoptions-=options sessionoptions-=folds sessionoptions-=resize sessionoptions-=buffers sessionoptions+=slash,unix It's probably caused by the new tab page option added to sessionoptions (it isn't the first -= setting in my _vimrc). Thank you, Salman.
Re: netrw 'filetype'
Hari Krishna Dara wrote: I am wondering if we can have netrw set the 'ft' of the buffer to 'netrw' at the end of generating the directory listing... Its already netrwlist; I named it that quite awhile ago so as to reduce the danger that someone might move syntax/netrw.vim atop plugin/netrw.vim. It seems like it'd be better for it to simply be netrw, so I'll do that. Couple of other comments about netrw: - In the vim7 beta2, netrw seems to generate bunch of 1 more line messages (I have report=0). Can we put a :silent in front of those lines that add lines, please? - The loaded_netrw variable is set to say v52, but it will be much easier to do version checks if it is just a number, such as 52. I don't see any benefit of prefixing the number with a v. Hmm --- I sent netrw v87 to Bram yesterday, and I've got a v88b that I've uploaded to my website. That b, by the way, shows one reason why the version isn't simply a number. Another reason: I have scripts that automatically update my website with the latest ASTRO-ONLY versions of my scripts, including updating the release version number shown on the website. Its safer to have that 'v\d\+\a*' pattern for such automated updating. Doing version checks just simply means doing the removal of the leading v and then comparing. (strpart(), substitute(), etc). Vim 7 beta2 has a much more recent version of netrw than v58. Do you happen to have an older netrw hanging around in your plugin directory? The newer netrw's work better with report=0. Regards, Chip Campbell
:!gvim does not work
I just tried :!gvim and all I got was Vim: Caught deadly signal SEGV Vim: Finished. Command terminated Press ENTER or type command to continue I am using vim 7.0d on Linux (FC2). I get the same result running vim (in a gnome-terminal) or gvim. --Benji Fisher
Re: Fwd: Bug#292397: vim freezes on swap file prompt
Pierre Habouzit wrote:
in certain conditions, vim was freezing on swap file prompt. One of our
users tracked that bug down, and a patch is attached.
look http://bugs.debian.org/292397
for more explanations !
[...]
Subject: Bug#292397: vim freezes on swap file prompt
Date: Jeu 13 Avril 2006 13:55
From: Bas Zoetekouw [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
[...]
If I set a breakpoint on line 3026 of misc1.c (just after the
ui_inchar() call), I can verify that indeed a special key code is
returned (i.e. the cursor I pressed). Specifically, the key code
returned is 0x80 0x8a 0x95 (\eku, which I guess means the uparrow).
However, this key is not handled at all: in the FEAT_MBYTE ifdef on
line 3084, the continue is called, and the loop progresses to the
next iteration, after which the key is never returned anymore by
get_keystroke().
So, the problem seems to be that the special sequences that are
generated by the cursor keys are mistaken for an incomplete multibyte
sequence; the check for such a special sequence is only done in
do_diaglog(), after get_keystroke() has returned.
The following patch solves this, and works fine here. Please include
it in the debian packages and also send it upstream.
--- vim/src/misc1.eerst 2006-04-13 13:45:37.0 +0200
+++ vim/src/misc1.c 2006-04-13 13:48:10.0 +0200
@@ -3082,7 +3082,9 @@
}
}
#ifdef FEAT_MBYTE
- if (has_mbyte)
+ /* if n0, this is a special key (eg cursor) which should
+ * not be mistaken for an incomplete multibyte sequence */
+ if (has_mbyte n=0)
{
if (MB_BYTE2LEN(n) len)
continue; /* more bytes to get */
I think a simpler solution is to add a break in the situation that
K_SPECIAL is seen and the special key is not ignored:
*** misc1.c~Thu Apr 13 15:42:20 2006
--- misc1.c Thu Apr 13 16:56:51 2006
***
*** 3085,3090
--- 3085,3091
mch_memmove(buf, buf + 3, (size_t)len);
continue;
}
+ break;
}
#ifdef FEAT_MBYTE
if (has_mbyte)
--
hundred-and-one symptoms of being an internet addict:
75. You start wondering whether you could actually upgrade your brain
with a Pentium Pro microprocessor 80. The upgrade works just fine.
/// 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://www.ICCF.nl ///
Re: :!gvim does not work
On Thu, Apr 13, 2006 at 09:16:17AM -0700, Yegappan Lakshmanan wrote: Hi Bram, On 4/13/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Benji Fisher wrote: I just tried :!gvim and all I got was Vim: Caught deadly signal SEGV Vim: Finished. Command terminated Press ENTER or type command to continue I am using vim 7.0d on Linux (FC2). I get the same result running vim (in a gnome-terminal) or gvim. Works fine for me... Check what program is actually executed, perhaps in a :! shell $PATH is different. I am able to reproduce this crash only in the GTK version of gvim. In the Motif and Win32 versions, it works fine. - Yegappan I do not think there is anything funny about the shell I get with :! . I tried :! echo $PATH :! echo $HOME :! which gvim :! gvim --version and got the expected results. It may have something to do with GTK. I am running the default build of vim on FC2, which means GTK2 GUI. Now for the odd part. Someone else suggested that it might be a script problem, so I tried -u NONE and other things. :!gvim SEGV :!gvim -u ~/.vimrc -U ~/.gvimrc no problem Yegappan, do you get the same result? Anyone else on GTK? --Benji Fisher
Re: invisible bar in help tags
Hi! In vim 7.0d02 I'm unable to see the '|' which usually surround tag in vim's help file (e.g. around 'usr_01.txt' in the first help page opened by ':helpCR'). This is not a bug, but a feature. The name of the highlight is 'Ignore'. The foreground color highlight 'Ignore' is set to the value of the background color in nearly all color schemes, which is exactly the purpose of the highlight 'Ignore'. That is, the bars are not to be seen. IMHO this looks much nicer than before. Best wishes, Georg ___ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
Re: netrw 'filetype'
Hari Krishna Dara wrote: This is exactly the reason, I didn't suspect this at all. I had netrw in my plugin directory for use with 6.3 Vim. Now, how do I make sure I can use the same plugin directory for both 6.3 and 7.0? I think the g:loaded_xxx variable should be different for these two so that we can control them independently. Since it took the role of explorer plugin in 7.0, how about using the loaded_explorer instead of loaded_netrw in 7.0 (unless there is a better solution)? Vim 7.0 introduces the notion of autoload -- basically only a small skeleton of code, generally just the user interface commands and maps, is present in the plugin. However, the commands and maps defined therein can call upon functions with the format funcfile#Function(...) If the function hasn't been loaded yet, then Vim 7.0 will attempt to source it in from the system's or user's autoload/ directories, using funcfile.vim to do so. Thus the user gains full functionality without having to pay a startup price by loading everything whether or not it gets used this time around. One problem: vim 6.x not only doesn't understand this, it complains about it. Hence, vim7.0 can understand and use vim6.x (and earlier) plugins, but plugins using vim 7.0's autoload will be incompatible with vim 6.x. Bottom line: there's no point. Netrw, now a vim 7.0 autoload-using plugin, just isn't compatible with 6.x. Attempts to use vim 6.x with 7.0-plugins is going to result in lots of errors. Regards, Chip Campbell
Re: invisible bar in help tags
Sorry, but to be totally lost is something completely different, the user just has to move the cursor. There are not many invisible characters anyway. Not that easy: if you are in the main help page you can have plenty of invisible characters on the same column and then only moving right will reveal where the cursor is, moving the other three directions wont. What you call 'totally lost' is only a minor problem compared to that, what 'totally lost' means in reality. Are you sure that you know, what it means to be totally lost? It's my belief that the cursor should always be visible on the screen. Then feel free to change your terminal settings and/or your cursor settings such that you can see your cursor everywhere. Other people don't seem to have that problem, so it might be a problem of your configuration and not a general one. Best wishes, Georg ___ Yahoo! For Good - Sponsor a London Marathon runner - http://uk.promotions.yahoo.com/charity/london-marathon
Re: invisible bar in help tags
On Thu, Apr 13, 2006 at 11:26:02PM +0200, Georg Dahn wrote: What you call 'totally lost' is only a minor problem compared to that, what 'totally lost' means in reality. Are you sure that you know, what it means to be totally lost? Let's distinguish: are you nitpicking about my word choice or actually stating that there's no problem at all? If you want me to change my word choice: ok, 'totally lost' was an exaggeration, but 'lost' it is not. If looking at a screen I could not discover where my cursor is, then I feel lost. It's an annoying absence of feedback. It's my belief that the cursor should always be visible on the screen. Then feel free to change your terminal settings and/or your cursor settings such that you can see your cursor everywhere. Other people don't seem to have that problem, so it might be a problem of your configuration and not a general one. Well, I'm playing with the vim Debian package I (co-)maintain and the problem is there with the latest gnome-terminal, dark background, bg=dark, default Debian configuration. Just to sure I just made some more test and the problem is there even with xterm, light background, bg=light, default Debian configuration. You can claim our default configuration is buggy, I would be happy to discover so and fix it. But I'm quite sure the problem will affect a lot of Debian user as soon as vim7 will be released and that I will receive a bug report about this. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: netrw 'filetype'
On Thu, 13 Apr 2006 at 4:46pm, Charles E Campbell Jr wrote: Hari Krishna Dara wrote: This is exactly the reason, I didn't suspect this at all. I had netrw in my plugin directory for use with 6.3 Vim. Now, how do I make sure I can use the same plugin directory for both 6.3 and 7.0? I think the g:loaded_xxx variable should be different for these two so that we can control them independently. Since it took the role of explorer plugin in 7.0, how about using the loaded_explorer instead of loaded_netrw in 7.0 (unless there is a better solution)? Vim 7.0 introduces the notion of autoload -- basically only a small skeleton of code, generally just the user interface commands and maps, is present in the plugin. However, the commands and maps defined therein can call upon functions with the format funcfile#Function(...) If the function hasn't been loaded yet, then Vim 7.0 will attempt to source it in from the system's or user's autoload/ directories, using funcfile.vim to do so. Thus the user gains full functionality without having to pay a startup price by loading everything whether or not it gets used this time around. One problem: vim 6.x not only doesn't understand this, it complains about it. Hence, vim7.0 can understand and use vim6.x (and earlier) plugins, but plugins using vim 7.0's autoload will be incompatible with vim 6.x. Bottom line: there's no point. Netrw, now a vim 7.0 autoload-using plugin, just isn't compatible with 6.x. Attempts to use vim 6.x with 7.0-plugins is going to result in lots of errors. Regards, Chip Campbell I think my question was not clear. What I was saying is that for 6.3, netrw needs to be a user plugin, so I have to put it in say, ~/.vim/plugin, but if I do that, this will override the global netrw plugin in 7.0. How do I solve this without modifying the older netrw itself? One solution is to not to put netrw.vim in plugin directory and conditionally source it from vimrc, if the version is 7.0. What I was suggesting is that if you change the name of the control variable for the new version to say, loaded_explorer, then I can have something like this in my vimrc: if v:version 700 Vim 7.0 already comes with netrw, so the user plugin. let loaded_netrw = 1 fi For netrw users transitioning from Vim 6.x to 7.0, I think this will be useful. It just occurred to me that having the older netrw.txt in the user doc directory will confuse or override the global one. I don't know what the right solution is such that it will work in 6.x transparently and not interfere in 7.0. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: netrw 'filetype'
On Thu, 13 Apr 2006 at 2:26pm, Gary Johnson wrote: On 2006-04-13, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Hari Krishna Dara wrote: This is exactly the reason, I didn't suspect this at all. I had netrw in my plugin directory for use with 6.3 Vim. Now, how do I make sure I can use the same plugin directory for both 6.3 and 7.0? I think the g:loaded_xxx variable should be different for these two so that we can control them independently. Since it took the role of explorer plugin in 7.0, how about using the loaded_explorer instead of loaded_netrw in 7.0 (unless there is a better solution)? Bottom line: there's no point. Netrw, now a vim 7.0 autoload-using plugin, just isn't compatible with 6.x. Attempts to use vim 6.x with 7.0-plugins is going to result in lots of errors. In light of that, is there a preferred method for using both 6.x and 7.x plugins, for those of use who will be using both versions for possibly quite a while? My thought was to create two new .vim directories, ~/.vim_6_only and ~/.vim_7_only, for those plugins that will work with only one version or the other. Then put this in your ~/.vimrc if v:version = 700 let rtp = $HOME/.vim_7_only, . rtp . ,$HOME/.vim_7_only/after else let rtp = $HOME/.vim_6_only, . rtp . ,$HOME/.vim_6_only/after endif Gary Yep, this was my question too. I think your suggestion is good, though it would require continuous reorganization. Say, you are using plugin X which is currently designed for 6.3, but is forward compatible to 7.0, so you would keep it in you plugin directory. Later the author releases improved version which is only compatible with 7.0, which means, you have to move the existing file to under .vim_6_only/plugin and then put the new file .vim_7_only/plugin. Hopefully the issue is limited to only during the transition between two versions, or it will become a pain. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [vim 70d] switching tab pages
On Fri, Apr 14, 2006 at 01:18:19AM +0200, Wojciech Pilorz wrote: 2006/4/13, Bram Moolenaar [EMAIL PROTECTED]: Wojtek Pilorz wrote: I have build gvim 7.0d on Fedora Core 4 as 'Big version with GTK2 GUI.' I have noticed the following behaviour with multple tab pages (gvim); 1. You can switch with Ctrl-Pgup - Ctrl-PgDown when in normal mode; In insert and replace mode you need to type Ctrl-O Ctrl-Pgup/PgDown (perhaps should be documented?) It is documented. I could not find that, at least in tabpage.txt. And I do not think it is obvious. I find this no less obvious than not being able to switch windows or buffers while in insert mode. It's called insert mode for a reason. Beginners may be confused by this, but I think that's more because they usually haven't fully grasped the concept of Vim being a modal editor. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: has anybody done syntax highlighting for linux Kconfig files ?
On 4/12/06, Nikolai Weibull [EMAIL PROTECTED] wrote: On 4/12/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/11/06, Nikolai Weibull [EMAIL PROTECTED] wrote: On 4/11/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/11/06, Nikolai Weibull [EMAIL PROTECTED] wrote: As per your request, here's a syntax/kconfig.vim. Nice job Nikolai, thanks. I went though all 2.6 Kconfig files and noticed some mishighlightings. As a solution I've made a light version of the kconfig syntax to use as a default. The heavy one previously defined can be enabled by :let g:kconfig_syntax_heavy = 1 Light version suffers from this big problem: the apostrophe in help text scrambles highlighting for many following paragpaphs (like won't ). Heavy version doesn't suffer from this problem. Both in light and in heavy version: keywords (if, source ) are highlighted in help texts. Keywords probably shall not be highlighted in help texts. OK, this and some syncing issues has been fixed. Hi Nikolai, Thanks for a great job. The apostrophe in helptexts mostly works. I found two cases though where it does not work (see below), Also, when helptext with apostrophe is top line of the screen, all screen is painted same color (probably a syncing issue). Thanks Yakov case1 -- config ARCNET_CAP tristate Enable CAP mode packet interface depends on ARCNET help ARCnet cap mode packet encapsulation. Used to get the hardware acknowledge back to userspace. After the initial protocol byte every packet is stuffed with an extra 4 byte cookie which doesn't actually appear on the network. After transmit the driver will send back a packet with protocol byte 0 containing the status of the transmition: 0=no hardware acknowledge 1=excessive nak 2=transmition accepted by the reciever hardware Received packets are also stuffed with the extra 4 bytes but it will be random data. Cap only listens to protocol 1-8. - case 2 -- # ARM925T config CPU_ARM925T bool Support ARM925T processor if ARCH_OMAP1 depends on ARCH_OMAP15XX default y if ARCH_OMAP15XX select CPU_32v4 select CPU_ABRT_EV4T select CPU_CACHE_V4WT select CPU_CACHE_VIVT select CPU_COPY_V4WB select CPU_TLB_V4WBI help The ARM925T is a mix between the ARM920T and ARM926T, but with different instruction and data caches. It is used in TI's OMAP device family. Say Y if you want support for the ARM925T processor. Otherwise, say N. --
execute macro on pattern
dear vimmers, i have some macros defined, ie some registers (a, i, d, etc) contain commands. i execute them via @a, @m, and so. how to execute a particular macro for every line that matches a pattern? Something like: : g/pattern1/macro a : g/pattern2/macro b : g/pattern2/macro g i'm using vim 6.4. thank you for your help best regards zbigniew kowalski
bug? abbreviate does not work properly gvim-70d02
Hi All, I defined an abbrevation :ab NK Newton-Kaskade , but to my surprise this abbrevation is not expanded in Insert Mode after typing Space, (but was expanded with Tab or Esc.) Actually it works properly only if I use iab NK Newton-Kaskade. This phenomena only occurs when I use gvim7 but neither in a terminal vim7 nor in any (gui or non-gui) prior version of vim (6.4.7). Is this a bug in gvim7? Thanks for any answer/help. Andre -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Re: bug? abbreviate does not work properly gvim-70d02
On Thu, Apr 13, 2006 at 02:50:28PM +0200, André Massing wrote: Hi All, I defined an abbrevation :ab NK Newton-Kaskade , but to my surprise this abbrevation is not expanded in Insert Mode after typing Space, (but was expanded with Tab or Esc.) Actually it works properly only if I use iab NK Newton-Kaskade. This phenomena only occurs when I use gvim7 but neither in a terminal vim7 nor in any (gui or non-gui) prior version of vim (6.4.7). Is this a bug in gvim7? I cannot confirm this. Did you check for conflicting abbreviations and trailing spaces in the :ab command? HTH --Benji Fisher
Re: Folding of C preprocessor lines.
Adam Krolnik wrote: Thanks for the tip Yakov; It turns out that setting foldignore to add the # once the file is in the editor does not redo the folding, even if zR, zM is run. Only if I set it in the vimrc file does it take effect. I'll make the folds updated when 'foldignore' is set. To work around the problem you can force an update of folds by setting 'foldmethod' to indent again. -- hundred-and-one symptoms of being an internet addict: 77. The phone company asks you to test drive their new PBX system /// 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://www.ICCF.nl ///
Re: Delivering text to vim.
Dnia środa, 12 kwietnia 2006 19:45, Halim, Salman napisał: Redir doesn't work for commands that don't post their output in the Vim window (such as system commands). If it is your intention to post the For me ls worked. output of a system command into your buffer, you can instead do: :r!ls But I misread OP - I thought in lines delivering system output to Vim script not file :) m.
Re: bug? abbreviate does not work properly gvim-70d02
Benji Fisher schrieb: On Thu, Apr 13, 2006 at 02:50:28PM +0200, André Massing wrote: Hi All, I defined an abbrevation :ab NK Newton-Kaskade , but to my surprise this abbrevation is not expanded in Insert Mode after typing Space, (but was expanded with Tab or Esc.) Actually it works properly only if I use iab NK Newton-Kaskade. This phenomena only occurs when I use gvim7 but neither in a terminal vim7 nor in any (gui or non-gui) prior version of vim (6.4.7). Is this a bug in gvim7? I cannot confirm this. Did you check for conflicting abbreviations and trailing spaces in the :ab command? HTH --Benji Fisher Yes I did, there were no other abbrevations and no trailing spaces. Actually I realizied that some problems occur with my settings if I load an old session via source. Last time when I started with an old sessin, my textwidth were not recognized and although set tw? showed me the assigned value, vim did not break any line automatically. But it broke lines with the gq command. Starting a new gvim7, everything worked fine (tw, abbrevations and so on). That seems rather strange to me. Any suggestions how I could investigate this problem since this phenomena prevents me from using sessions and forces me to remember and reopen all my files I had worked on (which is sometimes quite hard for me :-) ) Best wishes Andre
Re: bug? abbreviate does not work properly gvim-70d02
Andre Massing schrieb: Benji Fisher schrieb: On Thu, Apr 13, 2006 at 02:50:28PM +0200, André Massing wrote: Hi All, I defined an abbrevation :ab NK Newton-Kaskade , but to my surprise this abbrevation is not expanded in Insert Mode after typing Space, (but was expanded with Tab or Esc.) Actually it works properly only if I use iab NK Newton-Kaskade. This phenomena only occurs when I use gvim7 but neither in a terminal vim7 nor in any (gui or non-gui) prior version of vim (6.4.7). Is this a bug in gvim7? I cannot confirm this. Did you check for conflicting abbreviations and trailing spaces in the :ab command? HTH --Benji Fisher Yes I did, there were no other abbrevations and no trailing spaces. Actually I realizied that some problems occur with my settings if I load an old session via source. Last time when I started with an old sessin, my textwidth were not recognized and although set tw? showed me the assigned value, vim did not break any line automatically. But it broke lines with the gq command. Starting a new gvim7, everything worked fine (tw, abbrevations and so on). That seems rather strange to me. Any suggestions how I could investigate this problem since this phenomena prevents me from using sessions and forces me to remember and reopen all my files I had worked on (which is sometimes quite hard for me :-) ) Best wishes Andre Okay, now I realized that there is no connection with my sourced session but rather with some (LaTeX) files. So simply loading a (special) LaTeX File breaks some settings (both in vim and gvim, version 6 and 7). Andre
Re: Tlist and autocmd
Hello, On 4/6/06, Eddy Petrişor [EMAIL PROTECTED] wrote: The TlistOpen command is already supported by the taglist plugin in the latest version (4.0b3). You can use the following taglist commands: TlistOpen - Open the taglist window TlistClose - Close the taglist window TlistToggle - Open/Close (Toggle) the taglist window I have uploaded another beta version of the taglist plugin (4.0b4). You can get it from: http://vim.sourceforge.net/scripts/script.php?script_id=273 In this version, a new 'Tlist_GainFocus_On_ToggleOpen' option setting is supported. When this variable is set, when opening the taglist window using the ':TlistToggle' command the cursor will be moved to the taglist window. Any stable release soon? If there are no problems, then I will release the 4.0 version of the taglist plugin in a few weeks. - Yegappan
Re: a question
On Fri, Apr 14, 2006 at 08:39:29AM +0800, [EMAIL PROTECTED] wrote: linda.s [EMAIL PROTECTED] wrote on 2006.04.13 19:48:22: On 4/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: linda.s [EMAIL PROTECTED] wrote on 2006.04.13 16:02:44: I have both vim and gvim app under my applications in the Mac. Both work fine. I typed vim in the terminal and it successfully went yo VIM interface. However, if I typed gvim, there came an error message -bash: gvim: command not found. If I want to launch gvim from the terminal, what to do try: vim -g vim -g E25: GUI cannot be used: Not enabled at compile time Then IMO it's a good idea to re-compile the vim to have GUI-support. That is not necessary: the OP already mentioned that she has vim and gvim app, meaning (I think) Vim.app and gvim.app . The problem is which vim (pun intended) is invoked. Perhaps you missed my previous note on this thread since I changed the subject line. HTH --Benji Fisher
Re: Vim Job board?
Bertram Scharpf wrote: Hi, first thank you all very much for the backings. I'm on the way losing trust in my own mind. Could this be normal? I've been in two jobs during the past year and not one of these well-paid colleagues calling themselves degreed software engineers does even know about Vim (neither Emacs). None of them is having Linux at home. Extrapolating from this I don't expect my next job being much better. Is this a problem typical to Germany? On my first job, my supervisor described a problem they were having with their database files. The issue arose from the fact that integer values were sometimes stored rationally (as 32-bit quantities), and sometimes stored as character strings. The proposed solution was to always store them as character strings. Although that strikes me as a bizarre solution, the worst part was his description of the problem. He said something along the lines of, sometimes our numbers are stored in this weird format, by which he was referring to the concept of binary representation of numbers. He didn't understand the basic concept of counting in base 2. How can a person working professionally with a computer not understand something so fundamental? Getting back to your original post, I am constantly amazed at the number of people who criticize me for using vim, but can't even use their own editor with any degree of competence. Just watching them navigate in a buffer is painful. With regard to your boss wanting to force you to use a new tool, maybe you could suggest a friendly competition. If you can demonstrate that you can edit files more efficiently, maybe he'll force the rest of the office to switch to vi! (Highly unlikely, and undesirable, but at the very least you might be able to demonstrate that making you change is just friggin' stupid.)
