'cursorline' and screen redrawing problem
When I have 'cursorline' set and change some text with "C", for example, the altered text is not updated until the operation is complete. This problem occurs for every line in the file except the first. Can anyone else confirm this? Regards, Doug
Re: ezmlm is broken; it can't unsibscribe me, it seems
On Wed, Apr 12, 2006 at 02:26:43PM -0400, Eben Oldmixon wrote: > Here's the very top of the "blah-blah" (Eudora's term for it ...) > material in the header: > === > Return-path: <[EMAIL PROTECTED]> > Received: from mta30.srv.hcvlny.cv.net > (mta30.srv.hcvlny.cv.net [167.206.5.101]) by mstr8.srv.hcvlny.cv.net > (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) > with ESMTP id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED]; Wed, 12 Apr 2006 03:15:51 -0400 (EDT) > Received: from foobar.math.fu-berlin.de > (foobar.math.fu-berlin.de [160.45.45.151]) by mta30.srv.hcvlny.cv.net > (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) > with SMTP id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED] (ORCPT [EMAIL PROTECTED]); Wed, > 12 Apr 2006 03:15:50 -0400 (EDT) > === > > I do not know how to interpret email headers --- let me admit that up > front. However, does that ORCPT term suggest something along the > lines you mention? Note, though, that there is no other account > involved now except for <[EMAIL PROTECTED]>. Those headers look correct to me, so it does seem as though the mailing list thinks your address is the one you're currently using. Oh well, it was just an idea and it turned out to be wrong :-( I think you're going to need to be removed from the list manually. -- Matthew Winn ([EMAIL PROTECTED])
Re: 'cursorline' and screen redrawing problem
On Thu, Apr 13, 2006 at 05:10:31PM +1000, Doug Kearns wrote: > When I have 'cursorline' set and change some text with "C", for example, > the altered text is not updated until the operation is complete. This > problem occurs for every line in the file except the first. > > Can anyone else confirm this? I just noticed that CVS is a little behind and this problem isn't occurring in 7.0d... Regards, Doug
List behavior
Hi Bram and others, I am wondering if its just me who feels that the restrictions placed on some of the List functions are not such a great idea. 1. a[:5] in python returns the first five elements of a if len(a) > 5 or all elements if len(a) < 5. In VimL, a[:4] is an error if len(a) < 5. Right now, we have to do something like: a[:(min(5,len(a))-1)] to get the same behavior. It seems to be a common enough behavior to want to get the first so many elements (or less) of a list that I have found myself doing this at least 5-6 times already... Python seems to have gotten this right IMHO. 2. In VimL, a[N:M] is an error if M
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:
Re: console menus priority
Xavier de Gaye wrote: > When running Vim 7.0d on FC3 as: > > $ gvim -u cfg.vim > > with cgf.vim as: > > "= > " some sample menus with priorities > an 01.100 To.up R > an 01.200 To.down r > > an 02.100 Session.getsession:source ~/.vim/wk/ > an 02.200 Session.mksession :mksession! ~/.vim/wk/ > > " setup for console menus > set guioptions=acgirLtMe > set wildmenu > set cpo-=< > set wcm= > map :emenu > "= > > The console menus (displayed after hitting ), are ordered using > alphabetical order instead of the configured priorities. This is a > different behavior from the behavior in vim6.4. > > After setting 'set guioptions+=m', one can see that the GUI menus > priorities are set correctly with the configured priorities, though. The generic completion function is now sorting the matches. I can see you don't want this for ":emenu". How about the other ":*menu" commands? I think we should probably skip the sorting there too. -- hundred-and-one symptoms of being an internet addict: 64. The remote to the T.V. is missing...and you don't even care. /// 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: [vim 70d] switching tab pages
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. > 2. In Visual mode Ctrl-O is not needed, but text is unselected (can > restore visual selection with gv) Visual mode is stopped when switching to another tab page. I don't see how it would work otherwise. > 3. When within search prompt started with "/" or ex prompt started with ":", > I could not find any way to switch tab pages. If this is intentional, > It should perhaps also be documented. You can't document all things that don't work. When editing the command line you can't change to another window. Has always been like that. > 4. Selecting font with Edit/Select Font changes font for all tab pages. > I think it would be very useful to have also an option to have > different fonts (or at least different font sizes) in tab pages. That is not possible, the font is used for everything, also the command line. The Vim window resizes too. > 5. When several files with long file names are opened, not all tabs > fit into GUI tab line; > I could find no way to swich tab pages that did not fit on tabline > with mouse - tabs are not scrollable; popup menu activated with Right > Click on tabline does not offer an option to swich tabs; and there is > no free space to click. Depends on the GUI. My opinion is that the tabs should fit, otherwise the whole purpose of using tabs (accessing them with a single click) is defeated. If really needed, there could be a menu to show the tabs that don't fit. Scrolling the tabs is a really bad solution (Motif does it anyway...). > 6. It would be useful if switch to previous tab could be activated > with mouse, perhaps Middle button-Click of Shift+left button click? What is the previous tab? > Also, next/previous tab in tabline popup menu would be convenient. That is more work than clicking in the tab, doesn't make sense. For some GUIs and with the console a click right of the tab labels cycles through them. -- hundred-and-one symptoms of being an internet addict: 69. Yahoo welcomes you with your own start page /// 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: Omni completion file naming
On 4/13/06, Doug Kearns <[EMAIL PROTECTED]> wrote: > They're currently in $VIMRUNTIME/autoload. I agree that it would be > better, since the autoload mechanism allows for subdirectory use, if > they were all added to autoload/complete. > > setlocal omnifunc=complete#python#Complete Yes, that sounds like a decent scheme. nikolai
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. --
Re: List behavior
Srinath Avadhanula wrote: > I am wondering if its just me who feels that the restrictions placed on > some of the List functions are not such a great idea. > > 1. a[:5] in python returns the first five elements of a if len(a) > 5 or > all elements if len(a) < 5. In VimL, a[:4] is an error if len(a) < 5. Right > now, we have to do something like: a[:(min(5,len(a))-1)] to get the same > behavior. It seems to be a common enough behavior to want to get the first > so many elements (or less) of a list that I have found myself doing this at > least 5-6 times already... Python seems to have gotten this right IMHO. I suppose this means that when the second index is higher than the length of the list it's set to the length of the list. It also means that you will never get an error message when the list is shorter as you expected. What do others think? > 2. In VimL, a[N:M] is an error if M In Python, this is just an empty list. This too has to be accounted for > using verbose min() statements. What is the motivation for this > restriction? Is it an implementation issue? If you have M smaller then N minus one you have probably done something wrong. > In fact, why not model VimL's lists on Python's lists? In Python many errors go unnoticed. I learned that the hard way. This is a balance between having the language warn you about errors, or letting it up to the user to discover why something doesn't work. For Python they might have a different idea about the right way, but they can't change it without breaking existing scripts. -- "Thou shalt not follow the Null Pointer, for at its end Chaos and Madness lie." /// 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 ///
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.
Fwd: Bug#292397: vim freezes on swap file prompt
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 !
Cheers,
-- Message transmis --
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]
package vim
tag 292397 + upstream
tag 292397 + patch
thansk
Hi!
I've done some more debugging on this problem, and it seems only a few
of the vim variants are affected. Specifically, I can reprocude the
problem using vim.gnome, vim.python and vim.perl, but vim.basic,
vim.gtk, vim.tiny, vim.lesstif, vim.ruby, vi.tcl and vim.full work
fine.
Also, I've build a version of vim.perl with -ggdb3, and can reproduce
the problem there. GDB gives the following backtrace after the freeze:
| (gdb) bt
| #0 0xe410 in __kernel_vsyscall ()
| #1 0xb77fed6d in ___newselect_nocancel () from
| /lib/tls/i686/cmov/libc.so.6 #2 0x0815887b in RealWaitForChar
| (fd=0, msec=100, check_for_gpm=0xbfcd399c) at os_unix.c:4743 #3
| 0x081585c1 in WaitForChar (msec=100) at os_unix.c:4445
| #4 0x08154b75 in mch_inchar (buf=0xbfcd3a4a "", maxlen=46,
| wtime=100, tb_change_cnt=0) at os_unix.c:328 #5 0x081b950f in
| ui_inchar (buf=0xbfcd3a4a "", maxlen=46, wtime=100, tb_change_cnt=0)
| at ui.c:189 #6 0x081185dd in get_keystroke () at misc1.c:3025
| #7 0x08111f63 in do_dialog (type=2, title=0x81fb014 "VIM -
| ATTENTION", message=0x82fa060 "Swap file \"/tmp//%tmp%test.swp\"
| already exists!", buttons=0x81faf88 "&Open Read-Only\n&Edit
| anyway\n&Recover\n&Quit\n&Abort", dfltbutton=1, textfield=0x0) at
| message.c:3298 #8 0x0810971d in findswapname (buf=0x8234428,
| dirp=0xbfcd404c, old_fname=0x0) at memline.c:4107 #9 0x081039a2 in
| ml_open_file (buf=0x8234428) at memline.c:552 #10 0x08103ac4 in
| check_need_swap (newfile=1) at memline.c:604 #11 0x080d27d0 in
| readfile (fname=0x8235848 "/tmp/test", sfname=0x8235848 "/tmp/test",
| from=0, lines_to_skip=0, lines_to_read=2147483647, eap=0x0, flags=1)
| at fileio.c:642 #12 0x0806c4a2 in open_buffer (read_stdin=0,
| eap=0x0) at buffer.c:130 #13 0x080f770a in create_windows
| (parmp=0xbfcd43f0) at main.c:2378 #14 0x080f5589 in main (argc=2,
| argv=0xbfcd4534) at main.c:794
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 n<0, 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 */
Happy Vimming!
Bas.
PS: this was all tested using the 6.4+7.0c05-1 versions from
experimental.
--
Kind regards,
++
| Bas Zoetekouw | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 |
++
---
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
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: :!gvim does not work
> -Original Message- > From: Benji Fisher [mailto:[EMAIL PROTECTED] > Sent: 13 April 2006 16:44 > To: vim-dev@vim.org > Subject: :!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. Not happening on RH Enterprise Server 4.0. I tried :!gvim recursively from every new gvim spawn (7 levels), no problem. Using 7.0aa, probably the last before the the first alpha, lat which could be gotten from anonymous CVS before CVS problems started. ---Zdenek
Re: has anybody done syntax highlighting for linux Kconfig files ?
On 4/13/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > 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).
Hm, forgot to add syncing to the light version. I added the following:
syn syncmatch kconfigSyncHelp grouphere kconfigHelpText
'help\|---help---'
I hope that's how you use the 'syn sync ... grouphere' syntax...
It seems to work anyway.
Peace.
nikolai
" Vim syntax file
" Maintainer: Nikolai Weibull <[EMAIL PROTECTED]>
" Latest Revision: 2006-04-13
if exists("b:current_syntax")
finish
endif
let s:cpo_save = &cpo
set cpo&vim
if exists("g:kconfig_syntax_heavy")
syn match kconfigBegin '^' nextgroup=kconfigKeyword
\ skipwhite
syn keyword kconfigTodo contained TODO FIXME XXX NOTE
syn match kconfigCommentdisplay '#.*$' contains=kconfigTodo
syn keyword kconfigKeywordconfig nextgroup=kconfigSymbol
\ skipwhite
syn keyword kconfigKeywordmenuconfig nextgroup=kconfigSymbol
\ skipwhite
syn keyword kconfigKeywordcomment menu mainmenu
\ nextgroup=kconfigKeywordPrompt
\ skipwhite
syn keyword kconfigKeywordchoice
\ [EMAIL PROTECTED]
\ skipwhite skipnl
syn keyword kconfigKeywordendmenu endchoice
syn keyword kconfigPreProcsource
\ nextgroup=kconfigPath
\ skipwhite
" TODO: This is a hack. The who .*Expr stuff should really be generated so
" that we can reuse it for various nextgroups.
syn keyword kconfigConditionalif endif
\ [EMAIL PROTECTED]
\ skipwhite
syn match kconfigKeywordPrompt '"[^"\\]*\%(\\.[^"\\]*\)*"'
\ contained
\ [EMAIL PROTECTED]
\ skipwhite skipnl
syn match kconfigPath '"[^"\\]*\%(\\.[^"\\]*\)*"\|\S\+'
\ contained
syn match kconfigSymbol '\<\k\+\>'
\ contained
\ [EMAIL PROTECTED]
\ skipwhite skipnl
" FIXME: There is â probably â no reason to cluster these instead of just
" defining them in the same group.
syn cluster kconfigConfigOptions contains=kconfigTypeDefinition,
\kconfigInputPrompt,
\kconfigDefaultValue,
\kconfigDependencies,
\kconfigReverseDependencies,
\kconfigNumericalRanges,
\kconfigHelpText,
\kconfigDefBool,
\kconfigOptional
syn keyword kconfigTypeDefinition bool boolean tristate string hex int
\ contained
\ nextgroup=kconfigTypeDefPrompt,
\ @kconfigConfigOptions
\ skipwhite skipnl
syn match kconfigTypeDefPrompt '"[^"\\]*\%(\\.[^"\\]*\)*"'
\ contained
\ nextgroup=kconfigConfigOptionIf,
\ @kconfigConfigOptions
\ skipwhite skipnl
syn match kconfigTypeDefPrompt "'[^'\\]*\%(\\.[^'\\]*\)*'"
\ contained
\ nextgroup=kconfigConfigOptionIf,
\ @kconfigConfigOptions
\ skipwhite skipnl
syn keyword kconfigInputPromptprompt
\ contained
\ nextgroup=kconfigPromptPrompt
\ skipwhite
syn match kconfigPromptPrompt '"[^"\\]*\%(\\.[^"\\]*\)*"'
\ contained
\ nextgroup=kconfigConfigOptionIf,
\ @kconfigConfigOptions
\ skipwhit
Re: Vim 7.0d02
Salman Halim wrote: > 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). The default for 'sessionoptions' contains "tabpage" instead of "tabpages". You can fix that in option.c. -- hundred-and-one symptoms of being an internet addict: 76. Your ISP regards you as a business partner rather than as a customer. /// 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: 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 n<0, 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
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. -- Q: How many legs does a giraffe have? A: Eight: two in front, two behind, two on the left and two on the right /// 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
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
odd completion (mis)behavior
I am a few days behind: vim 7.0d (Linux). I have the text "Mary Ellen" and "May 2" in my buffer. I want to type "Mary Ellen" again, so (not noticing the "May 2") I do Ma but that gives me May 2 Oops! So I type a few times (three, to be exact). Much to my surprise, I get May x�> Ma (In case it gets garbled in translation, that looks like May x<99>> ^PMa to me.) When I repeat the experiment, I get different garbage, so I am guessing that there is an uninitialized variable here. BTW, can someone point me to where it explains what characters get me out of completion mode and which do not? I expected to do it. --Benji Fisher
Re: netrw 'filetype'
On Thu, 13 Apr 2006 at 9:48am, Charles E Campbell Jr wrote: > 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. I didn't see a filetype set at all. See below... > > >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). It is not a big deal, especially if you have a reason. > > 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. 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)? -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
invisible bar in help tags
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 ':help'). They are not visible (but the tag jumping still works). Moreover: on a black gnome-terminal the cursor becomes completely invisible when moving on them, while using a gui-enabled vim when the cursor is on them they're visible in reversed colors (but still not visible when the cursor is elsewhere). I tried several colorschemes, they seem not to affect the bug. 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: :!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: Omni completion file naming
On 4/13/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote: > On 4/13/06, Doug Kearns <[EMAIL PROTECTED]> wrote: > > > They're currently in $VIMRUNTIME/autoload. I agree that it would be > > better, since the autoload mechanism allows for subdirectory use, if > > they were all added to autoload/complete. > > > > setlocal omnifunc=complete#python#Complete > > Yes, that sounds like a decent scheme. Sounds reasonable - Bram, what do you think? Would you like me to rename the 'pycomplete' functionality as specified above, or as pythoncomplete#Complete ?
Re: Vim 70 and multibyte printing
Hello, On 4/13/06, Valery Kondakoff <[EMAIL PROTECTED]> wrote: > Hello, vim-developers! > > Please, bring some lite on this topic: is this true, that it is > still impossible to print mutibyte textes using (g)Vim 7.0 when you > set 'encoding' to 'utf-8'? > > At least all my experiments were unsuccsessfull. I'm using gVim 7.0d > under WinXP SP2. > > > As far as I understand the Vim 7.0d beta available from ftp.vim.org > is compiled without postscript support. Is this the reason why > multibyte printing is impossible? > > I just can't believe such an advanced editor like (g)Vim just > can not provide such an obvious feature like multibyte printing - so > you should reopen the textes in Notepad just to print them! > According to version7.txt, multi-byte printing is now supported: Printing multi-byte text*new-print-multi-byte* -- The |:hardcopy| command now supports printing multi-byte characters. The 'printmbcharset' and 'printmbfont' options are used for this. Also see |postscript-cjk-printing|. (Mike Williams) - Yegappan
Re: :!gvim does not work
Dnia czwartek, 13 kwietnia 2006 17:19, Bram Moolenaar napisał: > 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. Confirming for vim7.0d on Linux Mandriva 2006.0 . $PATH is the same in terminal and inside vim. Problem is in script-space. when both calls are with -u/U NONE I can play with any level. Seem that Benji and me have the same plugins :) m.
Re: invisible bar in help tags
On Thu, Apr 13, 2006 at 02:25:40PM -0400, Stefano Zacchiroli wrote: > 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 ':help'). > > They are not visible (but the tag jumping still works). Moreover: on a > black gnome-terminal the cursor becomes completely invisible when moving > on them, while using a gui-enabled vim when the cursor is on them > they're visible in reversed colors (but still not visible when the > cursor is elsewhere). > > I tried several colorschemes, they seem not to affect the bug. This seems to mainly affect things when bg=dark. With the various colorschemes I tried, the bars were either very hard to see or impossible to see without placing the cursor on them. With bg=light, I'm generally able to see the bars. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: invisible bar in help tags
On Thu, Apr 13, 2006 at 03:08:14PM -0400, James Vega wrote: > This seems to mainly affect things when bg=dark. With the various > colorschemes I tried, the bars were either very hard to see or > impossible to see without placing the cursor on them. With bg=light, > I'm generally able to see the bars. That's indeed true for the console version of vim. But with gvim I'm unable to see the bars no matter how I set 'bg'. -- 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: 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 ':help'). 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: console menus priority
--- Bram Moolenaar wrote: > > Xavier de Gaye wrote: > > > When running Vim 7.0d on FC3 as: > > > > $ gvim -u cfg.vim > > > > with cgf.vim as: > > > > "= > > " some sample menus with priorities > > an 01.100 To.up R > > an 01.200 To.down r > > > > an 02.100 Session.getsession:source ~/.vim/wk/ > > an 02.200 Session.mksession :mksession! ~/.vim/wk/ > > > > " setup for console menus > > set guioptions=acgirLtMe > > set wildmenu > > set cpo-=< > > set wcm= > > map :emenu > > "= > > > > The console menus (displayed after hitting ), are ordered using > > alphabetical order instead of the configured priorities. This is a > > different behavior from the behavior in vim6.4. > > > > After setting 'set guioptions+=m', one can see that the GUI menus > > priorities are set correctly with the configured priorities, though. > > The generic completion function is now sorting the matches. I can see > you don't want this for ":emenu". How about the other ":*menu" > commands? I think we should probably skip the sorting there too. > Yes. I prefer using completion on the ':emenu' command (console menus) instead of the GUI menus, because I try to avoid using the mouse. And it saves one screen line. And you can still use those same menus on a console, for example on cygwin. So it would be nice if the most often used menus and submenus can be set in the first positions to avoid cycling through the whole menu list. Xavier -- http://clewn.sourceforge.net gdb support in Vim
Re: invisible bar in help tags
On Thu, Apr 13, 2006 at 10:01:32PM +0200, Georg Dahn wrote: > 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. I see ... It is debatable whether it's a feature or not: what if I would like to copy text from the help somewhere else? I can end up in pasting '|' which I was not expecting. No matter how you see it, you're still hiding to the user information which is there. Is this good? My answer is "no". That said, it is still a bug in console version of vim when bg='dark'. In that scenario the cursor disappear when it is on the '|' and the user is completely lost. 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. -!-
Vim 70 and multibyte printing
Hello, Yegappan! Thursday, April 13, 2006, 10:42:31 PM, you wrote: >> At least all my experiments were unsuccsessfull. I'm using gVim 7.0d >> under WinXP SP2. YL> According to version7.txt, multi-byte printing is now supported: YL> Printing multi-byte text *new-print-multi-byte* YL> -- YL> The |:hardcopy| command now supports printing multi-byte characters. YL> The 'printmbcharset' and 'printmbfont' options are used for this. YL> Also see |postscript-cjk-printing|. (Mike Williams) As you can see in my initial message I was trying to play with the new 'printmbcharset' and 'printmbfont' options, but I was unable to force gVim to print the file in correct encoding. So I was asking for some help: if there is some happy gVim 7.0 user, who set 'encoding' to 'utf-8' and still was able to print multibyte text? Can you, please, share your encoding-related settings? Thanks! -- Best regards, Valery Kondakoffmailto:[EMAIL PROTECTED] PGP key: mailto:[EMAIL PROTECTED]@nncron.ru
Re: invisible bar in help tags
Stefano Zacchiroli wrote: On Thu, Apr 13, 2006 at 10:01:32PM +0200, Georg Dahn wrote: 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. I see ... It is debatable whether it's a feature or not: what if I would like to copy text from the help somewhere else? I can end up in pasting '|' which I was not expecting. No matter how you see it, you're still hiding to the user information which is there. Is this good? My answer is "no". Guess I rather like it, myself. That said, it is still a bug in console version of vim when bg='dark'. In that scenario the cursor disappear when it is on the '|' and the user is completely lost. Huh? Why is the "user completely lost"? There's no help missing. Again, it depends on the colorscheme. I use astronaut.vim, and I can make out the bars (because my background is navyblue but the bar is black); and that's with the console version, too. Personally, I like Vince Negri's conceal method even better -- the bars could be completely suppressed, *except* for the line where the cursor is. Better readability, plus no editing surprises. Sad to say, conceal isn't in 7.0. Easy to toggle on and off. Regards, Chip Campbell
Re: invisible bar in help tags
It is debatable whether it's a feature or not: what if I would like to copy text from the help somewhere else? I can end up in pasting '|' which I was not expecting. No matter how you see it, you're still hiding to the user information which is there. Is this good? My answer is "no". This is nothing new, the highlight 'Ignore' has been there since I started using Vim. If you don't like some characters to be hidden in the help files, feel free to change the highlight, e.g: hi Ignore guifg=Gray or whatever color you like. There is no information being hidden to the user. This is a highlight for characters needed to highlight something correctly which cannot be done without any tricks. These characters are dummy characters only, which the user does not need to and usually does not want to see. If a user still wants to see these dummy characters, he can do that by changing the highlight. But this makes as much sense as complaining, that Firefox hides the HTML-tags to the user. Best wishes, Georg ___ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
Re: invisible bar in help tags
> Personally, I like Vince Negri's conceal method even better -- the > bars could be completely suppressed, *except* for the line where the > cursor is. Better readability, plus no editing surprises. Sad to > say, conceal isn't in 7.0. Easy to toggle on and off. Well, I don't know Vince Negri's conceal method, but using the cursorline does the job, too. Mapping 'set invcursorline' to a function key allows an easy turning on and off of the cursorline. 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
On Thu, Apr 13, 2006 at 04:34:44PM -0400, Charles E Campbell Jr wrote: > Guess I rather like it, myself. Ok, I drop the argument of whether is good or not to hide the bars. I don't like hiding them, but as has been pointed out I can change that behaviour. Fair enough. Still I believe there's a bug, read on ... > >That said, it is still a bug in console version of vim when bg='dark'. > >In that scenario the cursor disappear when it is on the '|' and the user > >is completely lost. > Huh? Why is the "user completely lost"? There's no help missing. Because he is no longer able to see the cursor: he has no idea about where it is located on the screen. I don't have astronaut.vim, but I tried a lot of other colorschemes and with bg='dark' on a black terminal (a fairly common scenario I believe) the cursor vanish when going on such a bar. Wouldn't this be an issue for many users? 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: invisible bar in help tags
Georg Dahn wrote: It is debatable whether it's a feature or not: what if I would like to copy text from the help somewhere else? I can end up in pasting '|' which I was not expecting. No matter how you see it, you're still hiding to the user information which is there. Is this good? My answer is "no". This is nothing new, the highlight 'Ignore' has been there since I started using Vim. If you don't like some characters to be hidden in the help files, feel free to change the highlight, e.g: hi Ignore guifg=Gray or whatever color you like. There is no information being hidden to the user. This is a highlight for characters needed to highlight something correctly which cannot be done without any tricks. These characters are dummy characters only, which the user does not need to and usually does not want to see. If a user still wants to see these dummy characters, he can do that by changing the highlight. But this makes as much sense as complaining, that Firefox hides the HTML-tags to the user. And there are even more "dummy characters" that have been hidden from the "completely lost" users. Did you know that a ">" at the end-of-line will cause subsequent indented text get highlighted as "helpExample -> Comment", but the ">" itself is "Ignore"d? Wait, there's another: a "<" at the start-of-line will turn the helpExample off. It, too, is "Ignore"d. Check out the effect of a "~" at the end-of-line, too (:he pattern-overview). Regards, Chip Campbell
Re: invisible bar in help tags
On Thu, Apr 13, 2006 at 04:52:58PM -0400, Charles E Campbell Jr wrote: > And there are even more "dummy characters" that have been hidden from > the "completely lost" users. Please ... "completely lost" was referred to users who don't know where their cursor is, not to users who have hidden characters. -- 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: invisible bar in help tags
Because he is no longer able to see the cursor: he has > no idea about where it is located on the screen. 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. BTW, I have tried several color schemes in my console Vim (dark and light ones) and I could always see the cursor being located at a bar (I am using Windows XP). It may depend on the type of the console. Best wishes, Georg ___ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
Re: invisible bar in help tags
Stefano Zacchiroli wrote: On Thu, Apr 13, 2006 at 04:34:44PM -0400, Charles E Campbell Jr wrote: Huh? Why is the "user completely lost"? There's no help missing. Because he is no longer able to see the cursor: he has no idea about where it is located on the screen. I don't have astronaut.vim, but I tried a lot of other colorschemes and with bg='dark' on a black terminal (a fairly common scenario I believe) the cursor vanish when going on such a bar. Wouldn't this be an issue for many users? Sorry -- I missed the part about the cursor being atop the "|". I'm afraid that my cursor doesn't disappear at all when atop "Ignore"d characters, either in console vim or in the gui. I've been using if v:version >= 700 let &t_SI="\]12;blue\x7" let &t_EI="\]12;yellow\x7" endif lately with console vim. Shows up differently when its in normal vs insert mode on an xterm. If you tried setting Cursor to use reverse, it should show up. So, the problem you're having is with any and all Ignore characters, with the Cursor as your colorscheme has it. Regards, Chip Campbell
Re: invisible bar in help tags
On Thu, Apr 13, 2006 at 11:01:09PM +0200, Georg Dahn wrote: > 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. It's my belief that the cursor should always be visible on the screen. -- 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: invisible bar in help tags
On Thu, Apr 13, 2006 at 05:02:00PM -0400, Charles E Campbell Jr wrote: > Sorry -- I missed the part about the cursor being atop the "|". No problem. > So, the problem you're having is with any and all Ignore characters, > with the Cursor as your colorscheme has it. Indeed it is, do you consider as possible/useful to hack vim help highlighting and/or default configuration so that the problem does not show up in the help windows? 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: 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: netrw 'filetype'
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 -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: netrw 'filetype'
On 2006-04-13, Gary Johnson <[EMAIL PROTECTED]> wrote: > 7.x plugins, for those of use who will be using both versions for s/use/us/ I'm not from Chicago, really; I just can't type. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
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: [vim 70d] switching tab pages
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. > > > 2. In Visual mode Ctrl-O is not needed, but text is unselected (can > > restore visual selection with gv) > Visual mode is stopped when switching to another tab page. I don't see > how it would work otherwise. > > > 3. When within search prompt started with "/" or ex prompt started with ":", > > I could not find any way to switch tab pages. If this is intentional, > > It should perhaps also be documented. > > You can't document all things that don't work. When editing the command > line you can't change to another window. Has always been like that. I misunderstood vim here; I thought command line is local to tab; You can have different command line area height in different tabs, so indeed there is some kind of 'localness'. > > > 4. Selecting font with Edit/Select Font changes font for all tab pages. > > I think it would be very useful to have also an option to have > > different fonts (or at least different font sizes) in tab pages. > > That is not possible, the font is used for everything, also the command > line. The Vim window resizes too. > OK. Maybe I am spoilt by kde 3.5 konsole, where font and font size is local to tab. > > 5. When several files with long file names are opened, not all tabs > > fit into GUI tab line; > > I could find no way to swich tab pages that did not fit on tabline > > with mouse - tabs are not scrollable; popup menu activated with Right > > Click on tabline does not offer an option to swich tabs; and there is > > no free space to click. > > Depends on the GUI. My opinion is that the tabs should fit, otherwise > the whole purpose of using tabs (accessing them with a single click) is > defeated. If really needed, there could be a menu to show the tabs that > don't fit. Scrolling the tabs is a really bad solution (Motif does it > anyway...). I can agree with that. However, current behaviour with gvim7.0d and GTK2 is also not good; if file names are too long so that some tabs do not fit on tabline, the active tabpage label is not necessarily displayed, switching tabs to those with invisible labels is possible only from keyboard. In other software I can see that Firefox shorten labels; when mouse pointer is placed on such shorten label, full tab title is displayed in termporary yellow box (just like description of icons in GTK2 gvim) In OpenOffice calc tab labels can be scrolled; In kde 3.5 konsole tab labels can also be scrolled. I do not have strong opinion whether shortening names should be preferred to scrolling. > > > 6. It would be useful if switch to previous tab could be activated > > with mouse, perhaps Middle button-Click of Shift+left button click? > > What is the previous tab? I meant tab page with number less by one (modulo number of tab pages). I just like symmetry (maybe too much ...) > > > Also, next/previous tab in tabline popup menu would be convenient. > > That is more work than clicking in the tab, doesn't make sense. For > some GUIs and with the console a click right of the tab labels cycles > through them. Sure. My comment was pehaps motivated by the test with long file names, where some tab labels were invisible (and there was no 'right of the tab labels' place on tabline) I must say I personally like tabs feature very much. I just thought about people new to vim and their possible problems. Best regards, Wojtek
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: [vim 70d] switching tab pages
On Thu, Apr 13, 2006 at 08:34:48PM -0400, James Vega wrote: > 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. I agree that "it" is not documented, where "it" means the fact that the help for Ctrl-Pgup does not mention that this works only in Normal mode. It is "implicitly documented" in the sense that there is no tag for i_CTRL-, and it is not mentioned under ins-special-special , but that only helps if you already know vim (and its docs) pretty well. If you want vim to behave that way, then :inoremap :inoremap ought to do it. Similarly, you can switch windows (with the mouse, for example) while in Insert mode. If you care to search the archives (back a few years, perhaps) you will find that I gave advice on how to do this, mapping and using window-local variables. :help design-flexible HTH --Benji Fisher
Re: invisible bar in help tags
> Let's distinguish: are you nitpicking about my word choice or actually > stating that there's no problem at all? In the first part of your first mail, where you state, that information is hidden to the user, I don't see any problem at all. That the cursor is invisible sometimes, is a problem to be solved, but it is not such a huge problem that one is totally lost. > If looking at a screen I could not discover where my cursor is, then I > feel lost. It's an annoying absence of feedback. I want to see the cursor all the time, too. > 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. If the cursor is sometimes invisible in the default configuration, then this is indeed a problem which has to be solved. Since I don't have Debian, I cannot try to locate the problem myself. Does this problem occur in the latest gnome-terminal only? Has it worked with the previous version? Is there a change which could affect this? Best wishes, Georg ___ Introducing the new Yahoo! Answers Beta A new place to get answers to your questions Try it http://uk.answers.yahoo.com
