Re: BUG: wrong recognition of words in Vim7.1b on Windows
Dnia poniedziałek 21 maj 2007, Bram Moolenaar napisał: > That "@" means that Vim uses the library function isalpha(). Apparently > your environment is not setup properly for isalpha() to work with your > encoding cp1250. Thus that is a problem with your > library/system/environment. Well, I installed Vim on three MS-Windows XP machines coming from different vendors and everywhere was that bug. Looks like classic example of: 1. MS-Windows is always right 2. If MS-Windows is wrong see 1. m. -- The world really isn't any worse. It's just that the news coverage is so much better.
Re: Google Summer of Code 2007 : Improve regexp performance
Dnia piątek 16 marzec 2007, Asiri Rathnayake napisał: > > A multithreaded matcher might be useful to vim but do we have a need for > fuzzy matching ? > For main regexp engine I think not. But it could be useful for command line completions (think zsh). m.
Re: google summer of code
Dnia czwartek 15 marzec 2007, Josh napisał: > I am interested in creating a kde or other window manager interface > for vim, While I'd like to see kvim resurrection with complete KDE integration it is pointless at the moment: KDE3 is near its end, KDE4 isn't ready yet for serious coding. However: Qt4 GUI interface with the same GUI code for all major platforms (Linux, Windows, MOX, and several others), would be great thing. m.
Re: .xht and .xhtml file extensions for xhtml filetype detection
Dnia poniedziałek 26 luty 2007, Bram Moolenaar napisał: > Apparently nobody noticed them. Are *.xht and *.xhtml widely used for > XHTML? Spotted .xhtml several times, never saw .xht . m.
Re: Vim crashing while starting nibbles game
Dnia czwartek 15 luty 2007, Hari Krishna Dara napisał: > After I updated the nibbles game, a user reported that his gvim crashes Cannot start Nibble at all: Error in function 29_Nibble..nibble#Nibble: line 50: E416: cleared latest genutils and nibble. m.
Re: Vim and OS versions
Dnia niedziela 11 luty 2007, A.J.Mechelynck napisał: > Upgraded from novell-SUSE Linux 9.3 to openSUSE 10.2 > My Vim compiled under 9.3 refuses to load: "perl.so not found". > Recompiled (with make reconfig, same feature set). Different versions of Perl I suppose. > The new executable runs (with -ruby but I'll try to see about that). > The display (with the same 'guifont') is *much* more good-looking > (crisper). I don't know why. Different antialias settings maybe. Newer GTK. m.
Re: Vim 7 performance notes
Dnia środa 07 luty 2007, Alexei Alexandrov napisał: > Hi Mikolaj Machowski, you wrote: > > Nice work. Could you send or place somewhere patches? I'd like to test > > them on more complex regexps. > > Here it is. Note that the biggest speed-up is observed when regexp is > matched a lot of times. The regexp mechanism itself is not affected at > all here - so if you have one regexp which runs very long you won't > probably notice any major difference. When testing it with VST it gave 3.4% speed improvements (the same metodology - 3 tests before and after, choose the best results). m.
Re: Vim 7 performance notes
Hello, Nice work. Could you send or place somewhere patches? I'd like to test them on more complex regexps. TIA m.
Re: Konsole: lost focus of window or tab
Dnia piątek 19 styczeń 2007, Matthew Woehlke napisał: > So, just to make sure I am following, Vim does or does not currently > understand any escape sequences for focus events? It sounds like "no", > but then what about A.J.'s comment about reacting to "[focus] events for > 'the GUI and a few console versions where this can be detected'"? > From placement of focus related functions in Vim source looks like currently such events are supported only in GUI and Win32 console. There is no general code. m.
Re: Konsole: lost focus of window or tab
Dnia czwartek 18 styczeń 2007, Bram Moolenaar napisał: > Note that we also need one to enable/disable getting these events. A > program should only get the events when asked for. Are you talking here about Vim part or Konsole part? m.
Re: Konsole: lost focus of window or tab
Dnia czwartek 18 styczeń 2007, Matthew Woehlke napisał: > ...I am not a Vim hacker, but if you can rig Vim to handle some escape > sequence, I may be able to help make Konsole understand/send them. A > start might be to write a simple application that sends the sequence to > turn on the function and then listens for them and takes some action > (like beeping and/or printing a message with a time stamp) when it > receives a notification. You could use that to test Konsole. (Read: if > you write that, it will make me much more motivated to help you with > hacking on Konsole :-).) I am not Vim hacker, not even programmer. The only I am able to do is simple shell thingy: #!/bin/bash read key if [ `echo $key | grep '24' ` ]; then echo -e 'you got it' fi 24 should be replaced by escape code, if code is coming from terminal maybe it should be ``read -e``, not just ``read``. In addition you have to manually press enter to go further :( Works with codes of function keys. m.
Re: Konsole: lost focus of window or tab
Dnia środa 17 styczeń 2007, Matthew Woehlke napisał: > > I'm willing to (try to, at least) help get this working in 3.5.x if you > can dig up what the needed escapes are (it sounds like there are already > existing examples?)... it probably won't be accepted but you could use > it locally, and of course submit it for porting to KDE4. On kde-devel R. Knight said he can accept it to 3.5.7 release and later maintain it for KDE 4. Now, some start. I don't know much about term internals. I read something yesterday and today so forgive me if I wrote something stupid. Just seed for further discussion: Base info according to man terminfo: Variable String: focus_lost Cap name:flo TCapcode:fL Description: terminal lost focus Escape sequence: \E[1fl Variable String: focus_gained Cap name:fga TCapcode:fG Description: terminal gained focus Escape sequence: \E[1fg These sequences and names don't conflict with any other entry defined in my /etc/termcap or /usr/share/terminfo/** . m.
Re: Konsole: lost focus of window or tab
Dnia środa 17 styczeń 2007, Matthew Woehlke napisał: > Matthew Woehlke wrote: > > Mikolaj Machowski wrote: > >> Is it possible to recognize if window or tab of Konsole lost focus > >> through termcap/terminfo sequence? > >> > >> Or is it at least possible with dcop or any other way? > >> > >> I am investigating ways to support Vim FocusGain/FocusLost > >> autoevents. > > > > [snip long answer] > > [...and short answer, too] > > Robert Knight says we should be able to add escape sequences to Konsole > to support this. I might be able to help with the patching (although it > is KDE4 that will really get the fix, anything for KDE3 does not seem > likely to be accepted, so you would be patching your own local version), I was waiting 2 years for Lists in VimL so I can wait several months for KDE 4 ;) > but someone Vim-side needs to tell us what Konsole needs to provide... Looks like it should be similar communication like with mouse events. Proper escape codes - I suppose there is no standard at the moment. If Konsole would be first to do it there is chance that will become standard. > Does Vim already support notifications for some terminal emulators? If > so, how do we go about adding Konsole to that list? Comment in :ui.c:3010: says: /* * Called when focus changed. Used for the GUI or for systems where this can * be done in the console (Win32). */ m.
FocusLost and terminal functionality
Hello, What functionality is required from terminal to support FocusLost/FocusGain autoevent? I'd like to file a wish against Konsole (KDE terminal emulator) but don't know what ask for :) m.
Re: [PATCH] count for CR in quickfix window
Dnia pon sty 1 2007, AOYAMA Shotaro napisał: > Hi, > > Here is a small patch for specifying a window in which vim opens > an error when you hit ENTER in a quickfix window. > With this patch, you may hit "3" in the quickfix window, > then the selected error is displayed in the window #3. > > Often I face a situation that I want to display an error, > but don't want to hide a buffer in the above window > or open a new window and break window layout. > I think this feature would be helpful in such time. > > What do you people think about this? Feature is definitely useful, I was very often missing such functionality. But way to open it... "3" usually means "go 3 lines down" - even when it doesn't work in quickfix window. IMO better way would be to make to accept count, eg.: 3 Note: decision belongs to Bram who is on his usual December/January holidays/visit to Uganda. m.
Re: correction in user manual (21.6 Modelines)
Dnia nie lis 26 2006, [EMAIL PROTECTED] napisał: > I'm confused, because this is the latest version in SVN. See: > > https://svn.sourceforge.net/svnroot/vim/vim7/runtime/doc/usr_21.txt > > Doesn't HEAD in svn contain the latest version? > CVS/SVN don't have runtime updates :( m.
Re: FW: elastic tabstops and gvim's GTK text widget
Dnia wto paź 31 2006, Nick Gravgaard napisał: > BTW, does anyone know if it's possible to implement elastic tabstops > as a vim script? It would need to be called whenever a character is > inserted or deleted and would then modify the size of the tabstops. > The tabstops would need to have different widths on different lines. > Is this possible? Rather not. Each letter is kept in its cell. It was specially visible in early stages of GTK2 porting where use of proportional fonts was allowed. Even if you could unblock this possibility they would be treated as monospaced. m.
Re: escape() and '
Dnia wtorek, 24 października 2006 11:10, Nikolai Weibull napisał: > Oh, I see. You're thinking of creating a string for passing to > substitute() inside an :execute, or something like that. Ah, true, > then you'd need to escape the single-quotes for the string, and, e.g., > "." with "\.". Escaping is a lot more difficult than one often > thinks, I suppose. Plus eg. matching string with string()'ed list. m.
Re: escape() and '
Dnia poniedziałek, 23 października 2006 16:25, Nikolai Weibull napisał:
> On 10/23/06, Mikolaj Machowski <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I understand that escape() was primarily designed to escape strings
> > when passing to system functions, but personally I never used that and
> > in didn't noticed such use in various scripts but very often it is
> > used to escape various charaters in Vim's own regexp matching or
> > passing one string to some other Vim command.
> >
> > Hence is the problem: when escaping ' with escape(), character is
> > prepended with \ which doesn't make sense when passing it to other Vim
> > command because proper way to escape it in Vim is doubling it with
> >
> > another '. Example::
> > :echo escape('as''df', '''')
>
> There should really be a third, optional, parameter to escape() where
> you can specify what character to use for escaping.
That wouldn't be real solution because to escape ' you still (in most
situations) would need two escape() calls. One for escape ' with ' and
second for rest of characters with \. The best solution is providing
info about context.
Yakov: why so much contexts? for single and double quotes there is only
difference in number of backslashes. Escaping in command line is rather
problem of which character should be escaped (most notably space), not
system of escaping.
I'd like to see only one flag additional and one default:
s - [default - for backward compatibility] "system" escaping with \
v - Vim escaping, ' for ' and possibly some other (future?) differences
m.
escape() and '
Hello,
I understand that escape() was primarily designed to escape strings when
passing to system functions, but personally I never used that and in
didn't noticed such use in various scripts but very often it is used to
escape various charaters in Vim's own regexp matching or passing one
string to some other Vim command.
Hence is the problem: when escaping ' with escape(), character is
prepended with \ which doesn't make sense when passing it to other Vim
command because proper way to escape it in Vim is doubling it with
another '. Example::
:echo escape('as''df', )
m.
Re: Patch 7.0.134
Dnia niedziela, 15 października 2006 15:10, Bram Moolenaar napisał: > Patch 7.0.134 > Problem:Crash when comparing a recursively looped List or > Dictionary. Solution: Limit recursiveness for comparing to 1000. Is hardcoding any value like that good thing? It could use 'maxfuncdepth' - default value is "only" 100 but user can always adjust it to his liking. m.
Re: Why not commit runtime files?
> I don't know exactly; but I think the various repositories (rsync, FTP, > CVS, SVN) are not maintained by the same people. I think CVS and SVN use > the FTP site as a "master" with automated updates (but not every day), > so that the FTP updates "trickle down" to the CVS/SVN repositories after > a delay of a few days or weeks. Only source files and some runtime files maintained directly by Bram. Updates send by other authors are rarely or never committed to CVS. SVN is synchronised only with CVS. Yes, it is a pity runtime files are not updated in CVS :( Theoretically I (and probably other people) could rsync directory according to your tip but it would wreak havoc in CVS structure... m.
Re: Vim 7.0 (1-109 patches) completion bug.
Dnia poniedziałek, 9 października 2006 12:38, Igor Prischepoff napisał: > Thank you, Bill. > I can confirm same behaviour as you described with my vim. > Now it is up to Bram to decide if this is wrong or right. IMO it is bug because it prevents chained completion. m.
Re: Vim 7.0 (1-109 patches) completion bug.
Dnia czwartek, 5 października 2006 05:16, Igor Prischepoff napisał: > Hi, i think i have found a bug in vim 7.0 > Patch level 1-109. > Windows version +perl +python (i don't think this matters in this case) > > here is how to reproduce: > gvim -u NONE -U NONE > > :set complete-=t " don't want complete from tags file - it's not > > important, just to switch off message > > :set complete+=longest " that's important > > i "now we in insert mode > > one two > o:t"now trying to complete second time - no completion, > nothing" i.e. i've got resulting text in buffer like this: > > one two > one:t > > and no 'two' on second C-N when trying to complete 'two' and message > "Back at original" > > (First completion works as expected, but second didn't shown and not > complete at all) > if remove 'longest' from 'complete' then everything works as expected. > > Can you reproduce that bug? Confirming it for 7.0.110 (Linux, GTK2). > Or it's intended behaviour? I don't think so. Note, when you press space and later return to the end of "one:t" it works. m.
Re: compilation of regular expressions/ enhancement?
Dnia wtorek, 3 października 2006 12:34, Marc Weber napisał: > If this is an issue, there might be the solution introducing a compiled > regular expression as used in python additional to Number, String, > Funcref, List, Dictionary > > What do you think? Would this be an enhancement? IMO compilation of only regexps isn't worth of time. Compilation of whole scripts, THAT would be difference. m.
bugs in vim scripting highlighting
Hello, Noticed two bugs in vim script highlighting: 1. xnoremap and snoremap are not fully recognized. Compare highlighting of those three lines: inoremap CtrlC() xnoremap CtrlC() snoremap CtrlC() Arguments of xnoremap and snoremap aren't highlighted 2. Function element addButton is highlighted as error: function! forms#form.addButton(fname, flabel, fvalue, hotkey, listener) But it works (as in forms.vim). the same apply to call call. syntax/vim.vim version: " Last Change: May 02, 2006 " Version: 7.0-50 m.
Re: Python/Ruby completion requires language interface ?
Dnia środa, 27 września 2006 14:27, Stefan Walk napisał:
> The script terminates, not vim...
>
> if !has('python')
> echo "Error: Required vim compiled with +python"
> finish
> endif
>
> is right at the start.
It could at least degrade to syntax highlighting completion.
m.
Re: Python/Ruby completion requires language interface ?
Dnia środa, 27 września 2006 11:35, A.J.Mechelynck napisał: > I notice that the scripts autoload/pythoncomplete.vim and > autoload/rubycomplete.vim terminate early and with error if the > corresponding interface is not compiled-in. Is that intentional? I would > expect to be able to _edit_ (for instance) a python script even on a Vim > version which cannot _run_ python commands. I don't agree with that. If interface is required for good completion it should be done using that interface. But even in such situation good degrading of script behaviour is required. Crashing IMO is unacceptable. m.
Re: Convert to HTML patch. Opinions / Testing.
Dnia sobota, 9 września 2006 20:03, Edd Barrett napisał: > > - I removed 's because you cannot contain a in a according > to w3. An unstyled would make no difference in this case anyway. While I agree with most of your changes *where* cannot be inside of ? m.
Re: No way to color-region(s) of text -- highlighter mode.
Dnia poniedziałek, 7 sierpnia 2006 15:46, Charles E Campbell Jr napisał:
> Mikolaj Machowski wrote:
> >Full collapsing was discussed some time ago and dismissed because
> >there is no good way to show theirs existence when collapsed.
>
> Hmm -- Vince Negri's "conceal" patch demonstrates, not postulates,
> that this statement is incorrect. Its quite simple: the current line
> is shown without concealing anything in it. Only non-current lines
> may contain concealed text. One place this sort of thing would come
> in handy, for example, is editing LaTeX. With suitable concealment of
> escape sequences, italicized text, for example, could be shown
> italicized but the \textit{ and closing } would be concealed. Unless,
> of course, one was editing the line containing such.
This works only on character wise collapsing and also isn't perfect.
When doing line wise concealing you will never now (with exception of
:se number) if there are hidden lines. Character wise concealment also
has its problems because some lines will be unnaturally short due to
concealing and without possibility to effectively gqap. Of course - in
case of LaTeX conceal patch is better than nothing (hiding \index{},
\footnote{}, maybe substitute math characters) would greatly clarify
text.
m.
ps. I am leaving tomorrow for three weeks, good bye.
Re: Vim-Runtime
Dnia sobota, 5 sierpnia 2006 15:03, Martin Krischik napisał: > > - Many runtime files, and in particular most of the help files, have > > been reissued with new or updated contents for version 7.0. You should > > find them, for instance, under vim70/runtime/ in > > http://ftp.vim.org/pub/vim/unix/vim-7.0.tar.bz2 > > Many - but not all. Quite a few maintainers have updated there runtime > after the release of vim 7.0 - The selectbuf/genutils pligin combo comes > to my mind. They even produced errors. They are no part of standard distro. They have no right to be there. > I fear the original maintainers of the **/ada.vim have files moved on - > probably to the GNAT Programming Studio or a different programming > language - who knows... So the question is indeed: how to become a > maintainer? 1. Write directly to former maintainers about their stance. 2. Write publicly on vim-dev and vim lists about your intentions 3. Send improved files to Bram. m.
Re: No way to color-region(s) of text -- highlighter mode.
Dnia piątek, 4 sierpnia 2006 22:39, François Pinard napisał: > [Mikolaj Machowski] > > >[Mohsin]: > >>Vim only has syntax coloring with regexps. Emacs has functions to > >>apply properties to text blocks, and I was hoping vim has something > >>comparable. > > > >Of course it is possible: > >:help /\%l > >:help /\%c > > Humph, not really! OP asked for highlighting. > > Text properties in Emacs span text regions, which move, expand or shrink > while text is being edited outside or within them. Besides > highlighting, text properties may also be used for making regions > invisible (fully collapsed, not using any estate on the display), > intangible (the cursor skips over them as if they were a single > character), and many other things as well. Full collapsing was discussed some time ago and dismissed because there is no good way to show theirs existence when collapsed. m.
Re: No way to color-region(s) of text -- highlighter mode.
Dnia piątek, 4 sierpnia 2006 18:42, Mohsin napisał: > I want to use a highlighter mode on my text file, example: > :color_region bold line1 col1 line2 col2 > :color_region bold 5 5 6 6 > :color_region underline 5 5 6 6 > > I couldn't do this in vim. Vim only has syntax coloring with regexps. > Emacs has functions to apply properties to text blocks, and I was hoping > vim has something comparable. Of course it is possible: :help /\%l :help /\%c m.
Re: findfile() results are inconsistent
Dnia wtorek, 25 lipca 2006 16:50, Eric Van Dewoestine napisał: > > So, the results are still consistent with the documented behavior. But not internally consistent. But OK - it is documented behaviour. > Regarding ';', the docs imply that it forces a search upwards, but > should probably state that explicitly. Maybe link to file-searching? Thanks Yakov. m.
Re: findfile() results are inconsistent
Dnia wtorek, 25 lipca 2006 07:11, A.J.Mechelynck napisał:
>
> I don't see any inconsistency. According to the help, findfile() is
> "Just like |finddir()|, but find a file instead of a directory." and
> finddir() has: "When the found directory is below the current directory
> a relative path is returned. Otherwise a full path is returned." Isn't
> that what you got?
OK. But even when described it is inconsistency.
> Is the semicolon really obligatory?
>
> :lcd $VIMRUNTIME/doc
> :echo findfile("help.txt",".")
>
> (without a colon), returns "help.txt", which is the expected result.
Try it from directory below $VIMRUNTIME/doc. Without ; it doesn't look
up.
m.
Re: findfile() results are inconsistent
Dnia wtorek, 25 lipca 2006 02:14, Eric Van Dewoestine napisał:
> > 1. We are in /home/mikolaj::
> >
> >echo findifile("b", "1;")
> >1/b
>
> You are giving findfile() a relative path to search, so it is
> returning a relative result.
Result is the same regardless to path in second argument.
m.
findfile() results are inconsistent
Hello,
Results of findfile() are inconsistent:
/home/mikolaj/a
/home/mikolaj/1/b
/home/mikolaj/2/c
/home/mikolaj/3/d
/home/mikolaj/3/4/e
1. We are in /home/mikolaj::
echo findifile("b", "1;")
1/b
2. We are in /home/mikolaj/2::
echo findifile("b", "/home/mikolaj/1;")
/home/mikolaj/1/b
3. We are in /home/mikolaj/3/4::
echo findifile("d", "/home/mikolaj/3/4;")
/home/mikolaj/3/d
Why this inconsistence?
Also mention of ; as obligatory element would be good addition to docs.
m.
Re: poll?
Dnia sobota, 22 lipca 2006 00:38, Kyle Wheeler napisał: > Isn?t that the entire purpose of > http://www.vim.org/sponsor/vote_results.php ? This is very fragmented. m.
Re: poll?
Dnia czwartek, 20 lipca 2006 23:55, Bram Moolenaar napisał: > Yakov Lerner wrote: > > Bram, How about posting a poll on www.vim.org site ? > > Two polls ! (1) Do you you vim6 or vim 7 ? > > (2) Do you use console-mode-vim or gvim ? > > What would we do with the outcome? While I don't understood reason for first poll second should give insight what todo items should get bigger priority. Although console/gvim choice mostly depends on system. To get more significant results it should be more like: - console version on MS-Windows - GUI version on MS-Windows - console version on all other systems - GUI version on all other systems m.
Re: Gvim for KDE
Dnia środa, 19 lipca 2006 10:01, Vince Negri napisał: > I recall that the merging of kvim patches into the Vim tree went further > than that - the KDE gui is mentioned in the help files. I even seem > to remember that at one point the gui_kde files appeared in CVS, It was working. I have compiled KDE version of Vim7 in that period. There was discussion few years ago about problems with KDE version. Major problem is incompatibility between glib event loop used by Vim and Qt event loop. But from various reports looks like Qt4.2 will be able to use glib event loop. It should a) remove some major hacks from kvim implementation b) remove unpleasant delay when using kvim. But to really test this we have to wait for official release of Qt4.2 and someone to write that port (I am not programmer) :/ But it would require to write completely new port - qvim because kdelibs won't be ready for third party things until fall (apart from some really adventurous programmers/users). > Another possible approach would be to do a "pure QT" port > rather than a KDE port (much of the old KDE code could be reused) as > then the resulting GUI Vim would be cross-platform (now that QT4 is > dual-licensed for Windows as well as Un*x) Probably good idea. Although KDE offers nice possibilities: kio-slaves, mox style menu bar. m.
Re: Gvim for KDE
Dnia poniedziałek, 17 lipca 2006 17:09, Charles E Campbell Jr napisał: > As I recall, the vim7 kde port was dropped because there was no > maintainer for the port. I'm not a KDE > user myself, so I'm not a candidate, but perhaps if you volunteered to > do KDE port+maintenance, you > might be able to get it back in. I am not programmer but use KDE. IMO come back to KDE should wait until release of Qt4.2 . It should support glib event loop. Conflicts between glib and Qt event loops were major reasons for unresponsiveness of kvim. m.
Re: Gvim for KDE
Dnia środa, 12 lipca 2006 22:23, Stefan Karlsson napisał: > By the way, is there anyone out there that is working on a KDE version? No. m.
Re: minor feature request: let!
Dnia niedziela, 2 lipca 2006 12:06, Nikolai Weibull napisał: > On 7/1/06, justin constantino <[EMAIL PROTECTED]> wrote: > > E706: Variable type mismatch > > > > As a minor improvement, I think it would be nice if you could do: > > > > let foo = "one,two,three" > > let! foo = split(foo, ',') > > I think we should just remove the whole restriction. > Definitely not. I was thinking about suggestion of :let! few times before and each time I was throwing it away. For example :let allows to change settings. Silently dropping changing of option value or setting it to some absurd setting would be Bad Thing(tm). m.
Re: Proposal: New command/feature for quickfix
Dnia środa, 28 czerwca 2006 22:07, Jochen Baier napisał: > i think a command like "cbefore" or "croot" could be > usefull. using this command after a quickfix trip (vimgrep, Doesn't fulfill your request? m.
Matchparen highlight bug?
Hello,
Create empty file, enter {}, :new, cursor is in new window but parens
are still highlighted.
This example isn't extreme but when returning to previous window in many
colorschemes it makes hard to notice where cursor is.
This chunk fixes that:
function RmMH()
if exists('w:paren_hl_on') && w:paren_hl_on
3match none
let w:paren_hl_on = 0
endif
endfunction
au WinLeave * call RmMH()
m.
Re: [BUG] Crash when modifying a:000
Dnia środa, 21 czerwca 2006 11:17, Nikolai Weibull napisał:
> Something I found some time ago but for some reason forgot to report:
>
> function A(...)
> echo remove(a:000, 0)
> endfunction
> call A('a')
Confirming for 7.020
gdb output:
*** glibc detected *** free(): invalid pointer: 0xbfc099e8 ***
Program received signal SIGBART, Aborted.
[Switching to Thread -1219942176 (LWP 21002)]
0xe410 in __kernel_vsyscall ()
m.
writefile() in map-
Hello,
What was the biggest nuisance for me with ctags was operating only on
saved files. It made working on big files and updating them always a bit
tedious. Here is workaround - with possible big side effects:
Quick and dirty version - note expand() should take care about proper
place of saved file.
function! Semicolon()
call writefile(getline(1,'$'), expand('%'))
call system('ctags -R .')
return ';'
endfunction
inoremap ; Semicolon()
m.
Re: chk_menu_tran.pl: Quick and dirty perl utility to check for missing menu translations
Dnia niedziela, 7 maja 2006 00:40, Wojciech Pilorz napisał: > > Also format of messages is strange, info is split in two parts. How to > > write compiler for that? I've wrote that one: > > I tried to keep line length reasonable, and did not think at all about > automatic processing of the output; shame on me! > > I can of course modify the script to use requested message format by > default; Any proposals? The only requirement I can think is that *all* info potentially useful for user would in one chunk. At the moment it in some cases in two parts:: info, info, info, info in filename.vim:32 offending message Fixing this would be useful especially to identify false positives. m.
Re: Where to submit a patch/modification for consideration?
Dnia sobota, 6 maja 2006 00:01, Eric Arnold napisał: > On 5/5/06, Mikolaj Machowski <[EMAIL PROTECTED]> wrote: > > Dnia piątek, 5 maja 2006 14:35, Eric Arnold napisał: > > > I think vim-dev@vim.org is probably a place to start... > > > > > > I've been hacking the statusline for a long time to do various > > > things a keystroke at a time. I've finally got a compiling env, so > > > I decided to take a stab a creating a key-event. > > > > Very, very, very good thing. It makes possible high-level of > > automation for some things - eg. map Space and pry it will not > > interfere with some scripts. > > > > Personally I'd like to see separation for Insert and Normal mode > > (GetChar, GetCharI?). > > I think 'mode()' will probably suffice for this? I've had bad experiences in the past with mode(). But maybe they were only my things - I didn't really have time to test various possibilities of v:getchar. BTW - general rule for v:variables is they are read-only. Would be good thing to keep consistency. I knot it is late but this would be really good addition to Vim7. For example it could automatically open omnicompletion menu after some letters and in desired context - no need to press (or equivalent)! Possibilities are endless. m.
Re: Where to submit a patch/modification for consideration?
Dnia piątek, 5 maja 2006 14:35, Eric Arnold napisał: > I think vim-dev@vim.org is probably a place to start... > > I've been hacking the statusline for a long time to do various things > a keystroke at a time. I've finally got a compiling env, so I decided > to take a stab a creating a key-event. Very, very, very good thing. It makes possible high-level of automation for some things - eg. map Space and pry it will not interfere with some scripts. Personally I'd like to see separation for Insert and Normal mode (GetChar, GetCharI?). Also for practical purposes it would be probably better to return actual letter. warning in gcc 4.0.1 eval.c: In function 'set_getchar_event_vvars': eval.c:21116: warning: pointer targets in assignment differ in signedness eval.c:21118: warning: pointer targets in assignment differ in signedness eval.c:21120: warning: pointer targets in assignment differ in signedness m.
Re: Bug: CursorLine highlighting wrong after search
Dnia czwartek, 4 maja 2006 16:30, Georg Dahn napisał: > > I am running gVim 7.0g02 on Windows XP. Confirming for gtk2 version. Last character is always highlighted and whole line becomes yellow (default color). BTW - also true for console version. VIM - Vi IMproved 7.0g02 BETA (2006 May 3, compiled May 4 2006 20:22:58) Skompilowany przez [EMAIL PROTECTED] Olbrzymia wersja z GTK2 GUI. Opcje włączone (+) lub nie (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile +python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save vimrc systemu: "$VIM/vimrc" vimrc użytkownika: "$HOME/.vimrc" exrc użytkownika: "$HOME/.exrc" gvimrc systemu: "$VIM/gvimrc" gvimrc użytkownika: "$HOME/.gvimrc" systemowy plik menu: "$VIMRUNTIME/menu.vim" odwet dla $VIM-a: "/usr/local/share/vim" Kompilacja: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O -I/usr/X11R6/include -I/usr/include/python2.4 -pthread Konsolidacja: gcc -L/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/local/lib -o vim -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfreetype -lfontconfig -lXrender -lXext -lpng12 -lz -lXt -lncurses -lacl -lgpm-L/usr/lib/python2.4/config -lpython2.4 -lutil -lm -Xlinker -export-dynamic m.
Re: chk_menu_tran.pl: Quick and dirty perl utility to check for missing menu translations
Dnia czwartek, 4 maja 2006 01:16, Wojciech Pilorz napisał:
> I have just finished a perl script to test menu translation
> completeness; It reads menu.vim, attempts to extract menu definitions
> and compare with menu definitions in specified files from runtime/lang.
>
> synmenu.vim is not read, so for the languages for which syntax menu
> entries are translated there will be a lot of false 'Extra
> translation' messages;
>
> Please be aware that the script is a quick hack; it does NOT
> understand vim scripts syntax and semantics; Just a couple of regexes
> and hashed thrown together.
> So treat the messages with a good grain of salt.
> Anyway, I hope translation maintainers might find it useful - it
> detects a number of not translated menu entries, as well as some
> spelling problems
You could rule out false positives as menu -separators-.
Also format of messages is strange, info is split in two parts. How to
write compiler for that? I've wrote that one:
if exists("current_compiler")
finish
endif
let current_compiler = "menutrans"
let s:cpo_save = &cpo
set cpo-=C
setlocal mp=chk_menu_tran.pl\ %
setlocal errorformat=
\%-GINFO%.%#,
\%m\ at\ %f:%l%.%#,
\%m\ in\ file\ %f:%l,
\%m\ in\ %f:%l
let &cpo = s:cpo_save
unlet s:cpo_save
m.
Re: mrxvtrc filetype and syntax files
Dnia czwartek, 27 kwietnia 2006 21:40, Nikolai Weibull napisał: > > Hi Nicolai, > > Hi. I'm curious, why did you spell my name with a 'c'? During the > last couple of days, people have called me Nicholas, Niklas, and twice > Nicolai. I see a conspiracy forming... Hello Mikolaj, It is popular name but in each language is spelled differently :) m.
Re: Bug: closing an inactive gui tab on windows
Dnia czwartek, 27 kwietnia 2006 10:47, Georg Dahn napisał: > Hi! > > There is another strange behavior with gui tabs on Windows. > > I. First test case > > 1. Open gVim (gvim -u NONE) > 2. Assure, that 'guioptions' contain 'e' (gui tab) > 3. Open a new tab with :tabnew and write something > 4. Now the right tab is active > 5. Right click on the left (inactive) tab and close it > > Then nothing seems to happen. Click somewhere in the edit > window and the closed tab disappears. Confirming for Linux vim7.0e01 (gtk2) Also when clicking on first tab - it is brought to foreground but text window is from second tab. I see: first tab is closed only when in second tab Insert mode was ended. m.
Re: RFC: (x)html completion support in Vim7
Dnia poniedziałek, 24 kwietnia 2006 15:00, Benji Fisher napisał: > I have not looked at the structure of the completion scripts, but > isn't there a way for one script to include another? Under > $VIMRUNTIME/ftplugin/ the file tex.vim (for LaTeX) :source's > plaintex.vim , which :source's initex.vim . You should be able to do > something similar with XHTML 1.0 Frameset/Transitional/Strict. Yes it is possible but because data files are generated automatically seeking a way to "compress" them is hard. Also, unification was done on level of engine between XML and HTML. > This strategy no only reduces file size, it also makes maintenance > easier. Actually no. Version with including had to be maintained manually and so far the only (reported) bug in data files was in file created manually. Also similarities between Frameset/Transitional/Strict are misleading and could lead to hard to spot errors. > > Add functions for detection of DOCTYPE to ftplugins for xhtml and > > html. > > > > Still there is usability problem for creation of new files. Maybe some > > general completion for insertion of DOCTYPE and setting appropriately > > completion. > > Right, and allow users to set a variable (g:html_omni_version or > something) that the ftplugins can check to use as a default for new > files. This will be done by insertion of DOCTYPE. m.
Re: omni-completion: info bug
Dnia piątek, 21 kwietnia 2006 00:20, Aaron Griffin napisał: > Ack, sorry - that was supposed to go to the list > > On 4/20/06, Mikolaj Machowski <[EMAIL PROTECTED]> wrote: > > Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał: > > > On a related note, an 'info' dict entry of '' does not change and/or > > > remove the preview information. Using a single space blanks the > > > window, but an empty string does not. > > > > And this is Good Thing :) > > Well here's the way I see it. If I have completions like so (format > word:info): abc : 'this is info for abc' > def : '' > ghi : 'this is info for ghi' > > Starting on 'abc', you move down to 'def', and the info for 'abc' is > left in the window. Fine, that may be intentional. Moving down to > 'ghi' will switch the info, then moving back up to 'def' will give you > the wrong info, assuming the 'correct' info was the entry for 'abc'. Buf if:: def : ' ' Window will be cleared. And that is Good Thing. m.
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 21:59, Aaron Griffin napisał:
> Is there any possiblity to get the preview window to pop up for single
> completions? If not, I can always force a single empty entry like
> {'word':'', 'abbr':'[Cancel]'} or some such oddity...
:help completeopt
menuone flag
m.
RFC: (x)html completion support in Vim7
Hello, I am author of (x)html completion scripts and related (php, css, javascript). I'd like to ask what you think it should like. At the beginning I was pushing for one default: XHTML 1.0 Strict. Bram didn't like it and now there are two: fot &ft='html' HTML 4.01 Transitional and for &ft=='xhtml' XHTML 1.0 Strict (user can still choose another version with b:html_omni_flavor variable - this improvement may be not yet in snapshot/cvs/svn). Bram still doesn't like it. According for him completion should be more flexible and not limited to some standard. For me it defies whole idea of omni-completion - completion suggestions should be precise. Problem with (X)HTML is there are many standards but creation of messy compilation from them has no sense. Vim is superb program and should support writing of good code - according to standards. To make this support full it could look: - provide data files for most of (X)HTML standards: - HTML 3.2 Strict (for legacy pages) - HTML 4.0 Transitional - HTML 4.0 Strict - HTML 4.0 Frameset - HTML 4.01 Transitional - HTML 4.01 Strict - HTML 4.01 Frameset - XHTML 1.0 Transitional - XHTML 1.0 Strict - XHTML 1.0 Frameset - XHTML 1.1 That is 11 data files, ca. 45kB each (5kB packed) - total 500 kB (55kB) Add functions for detection of DOCTYPE to ftplugins for xhtml and html. Still there is usability problem for creation of new files. Maybe some general completion for insertion of DOCTYPE and setting appropriately completion. TIA for comments. m.
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał: > > On a related note, an 'info' dict entry of '' does not change and/or > remove the preview information. Using a single space blanks the > window, but an empty string does not. And this is Good Thing :) m.
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 13:04, Bram Moolenaar napisał: > Aaron Griffin wrote: > > Just a "heads up": > > > > Using an omni-completion dictionary, a single completion entry (for > > which no menu is displayed) does not update the info preview window. > > Yes, filling the preview window is part of the code for the popup menu. > If there is only one alternative you don't really need more info to make > a choice, right? But old 'info' stays which may lead to misunderstandings. m.
vertical splitting of windows
Hello, Reason for option for always splitting window vertical (from Chris Jones on comp.editors): Horizontal split was probably useful ten years ago but at least for those who favour full-screen mode and with displays that have well over a thousand horizontal pixels, nowadays vertical split makes a lot more sense, don't you think? I would add increasing popularity of panoramic screens (16:9) both in notebooks and in desktop machines. Probably too late for vim7 but maybe todo for vim7.1? m.
Re: Open in new tab (context menu or configuration option)
Dnia piątek, 14 kwietnia 2006 15:11, Bram Moolenaar napisał: > > It's probably better to always use a new tab. Or perhaps use a new tab > when the currently edited file was modified. > > The behavior for dropping the files on a running Vim will be the same, > the same Windows message is used. > > Opinions? Make it an option with default to open in new tab. m.
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: Omni completion file naming
Dnia środa, 12 kwietnia 2006 10:43, Doug Kearns napisał: > I assume the omni completion files should follow the same naming > convention as the other runtime files? Eg. Should the current > pycomplete.vim actually be named pythoncomplete.vim? Probably should. There is no 'ft' as "py", only "python". m.
Re: Vim version 7.0d BETA has been released
Dnia wtorek, 11 kwietnia 2006 15:09, Vince Negri napisał: > Is it just me, or are there CVS problems with SF again? Yes :( m.
