Re: breakindent, take 2
On Mon, May 14, 2007 at 07:30:23PM +0200, Václav Šmilauer wrote: > The patch is against current svn (vim7, rev. 288). Any comments are welcome. I know this might not be desired comment, since I didn't even look at the patch but only at the screenshots. I just wanted to say that this feature would really be awesome, as I am doing a lot of LaTeX coding myself, and the default wrapping really doesn't look well. Martin PS: it would be nice if we could have the vim latex-suite autoindent by default in vim without the need to install the latex-suite (which is just overkill in my opinion). http://vim-latex.sourceforge.net
[Off-topic] Vimperator
I am sorry, if this kind of messages are highly despised on this list. But since vim-users are my main target group, I created a new Firefox extension, which makes browsing the web feel like browsing a vim buffer: http://vimperator.mozdev.org Maybe it helps you vim users, that :wq actually works to quit firefox :) -- Martin
Re: infercase for :substitute?
On Fri, Mar 30, 2007 at 09:00:44AM +0200, Ingo Karkat wrote: > There's another script, SmartCase, which only slightly differs from > keepcase.vim in the semantics of its invocation: > http://www.vim.org/scripts/script.php?script_id=1359 I have used that for some time, but was wondering why it has this bad votings, maybe it doesn't work well in last versions? Or only some stupid bot?
Re: infercase for :substitute?
On Thu, Mar 29, 2007 at 04:29:38PM -0700, Joseph Barker wrote: > Say I have the following line: > > foo = getFoo() > > It would be convenient to be able to do a single :s/foo/bar/g that respects > the case of the original input. It would transform the input line into the > following: > > bar = getBar() > > Would it be possible to add this as an option to :substitute somehow? I toyed > with writing a script to do it, but wasn't able to get very far (obviously, I > could do this by setting noignorecase and doing :s/foo/bar/g > and :s/Foo/Bar/g, but it would be more convenient to just use a single > command). > > JKB Have you tried: http://www.vim.org/scripts/script.php?script_id=6 I think it does exactly what you want. -- Martin
Re: Understanding regxp implementation
On Mon, Mar 19, 2007 at 01:49:53PM +0100, Nikolai Weibull wrote: > On 1/1/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > >On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: > >> On 3/19/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > >> > Hi Bram, Nicolai, > >> > >> A 'k' would be greatly appreciated. > > > >I'm really really sorry, won't happen again... > > Hehe, don't take it too hard, it happens to me all the time. If I had > a dime for every misspelling of my name, I'd have...more money than I > do now. Now I know, why Bram said in his Google Talk that he even uses ctrl-n completion for names, as it helps not misspelling names :) -- Martin
Re: Google Summer of Code 2007 : Improve regexp performance
On Thu, Mar 15, 2007 at 11:28:45PM +0530, Asiri Rathnayake wrote: > Hi all, > > I went through the above idea presented for google summer of code 2007 > and found it interesting. In my opinion, incorporating Thompson NFA into > regexp from the ground up is pretty cool. I also went through the > alternate TRE (http://laurikari.net/tre/index.html) but couldn't verify > whether its an implementation of Thompson NFA ( I will have to dig into > it's source and find it out ). I would like to know further details (if > any) regarding this project and the possible mentor(s). Wow, yesterday I read the announcement of vim's suggested SoC ideas, and I thought, it would be that cool, if the regexp thing would be taken, and here you are :) If you are accepted by Bram/Google I really wish you luck, and hope, that this one could really speed up things like syntax highlighting which can be quite slow for special files even on fast PCs. regrads, Martin
Re: Reminder: Vim presentation in Mountain View tomorrow
As announced, Bram gave an interesting talk about vim on the Google campus last week, for those who couldn't be there, there is a well made video of it there: http://video.google.com/videoplay?docid=2538831956647446078 Maybe it should also be linked from the news entry on vim.org? Off-topic, but since google announced it's third season for the Summer Of Code, wouldn't it be interesting to have vim participate in it? Or is the problem, that you, Bram, already have too little time to play mentor, and there aren't other core developers for this task? -- Martin
Re: Vim 7 performance notes
On Thu, Feb 01, 2007 at 11:20:16PM +0300, Alexei Alexandrov wrote: > Hi Bram et al., > > I'm doing some performance investigations of Vim code trying to understand > whether there are any possibilities to improve it. > Currently I've made the following observations (all investigations are done > on Windows): > > Redundant work is done during regexp operations in syntax highlighting. On > some files it is very noticable. The stack of the hotspot is ... > > syn_current_attr > syn_regexec > vim_regexec_multi > vim_regexec_both > > regtry > regmatch > ga_grow > alloc_clear > memset. So alloc_clear spends > quite a few clockticks in lalloc() and memset(). > The reason for this is pessimistically big grow size for regset growing array: > > ga_init2(®stack, 1, 1); > > This is not very good: many regexp operations don't go deep - non-match is > detected very quickly. But even one element on the stack will lead to > allocating at least 1 bytes (which should be fast with good CRT memory > allocator) and (worse) initializing these 1 bytes with zeros (won't be > that fast). I am not sure if this is really relevant to vim, because I don't have a clue which regexp matching algorithm it is using, but you might want to look into this article, when it comes to regexp speed: http://swtch.com/~rsc/regexp/regexp1.html regards, Martin
Re: Vim 8 enhancements
Now that there are many new - good, or not - ideas coming up. I think it would be a great idea, if the voting page on: http://www.vim.org/sponsor/vote_results.php becomes updated with new ideas, and old ones get deleted/changed. Now that we have omnicompletion, 'add intelligent, context-sensitive completion (intellisense)' does not make sense anymore, rather 'add more /better omni completions'. - add tabbed windows (one tab per window, only one is visible) is also useless as we have it now. I don't know if all current points of registered/paying users should be reset, but probably it's best to start over with 0 points when updating the list. -- Martin
Re: Vim8 idea: complete strings
On Tue, Jan 30, 2007 at 02:03:48AM +0100, A.J.Mechelynck wrote:
> Martin Stubenschrott wrote:
> >I often want to complete full strings in quotes ("foo", 'bla',
> >`command bla blub`).
> >
> >But for now, I really need to type all these things again and again. It
> >would be nice, if I could say "f- to complete full strings.
> >Or maybe also for single qouted strings, and for
> >`-quoted strings. Or maybe just one command to complete all strings, and
> >get from context, if we want to complete " ' or ` strings, depending on
> >what character is in front of . "f would complete "
> >quoted strings ' '-quoted and so on.
> >
> >--
> >Martin
> >
>
> Note: It is not always easy to determine (except by relying on syntax
> groups, which can be mis-synchronized, unless we use ":syn sync fromstart"
> which can be unduly slow) whether a given occurrence of " or ' anywhere in
> the text "being copied from" is an opening or closing quote. Even « is an
> opening quote in French, closing in German, and vice-versa for ».
Unfortunatly you seem to be right :( But the idea to complete longer
tokens than words and shorter than full lines was just too exciting :)
Also completing whole parenthesis (foo bla) or [xyz bla] and {ho hu}
would be fine, and probably easier to do.
--
Martin
Re: JavaScript indentation
On Tue, Jan 30, 2007 at 03:13:54AM +0100, Bram Moolenaar wrote: > Which script are you talking about exactly? There are four script > matches for "cppcomplete" on www.vim.org. Sorry, I thought you knew about it, since it has phenomenal ratings: http://www.vim.org/scripts/script.php?script_id=1520 But make sure you build the ctags database with these settings, when testing: ctags -R --c++-kinds=+p --fields=+iaS --extra=+q . It installs also a lengthy help file with :help omnicppcomplete -- Martin
Vim8 idea: complete strings
I often want to complete full strings in quotes ("foo", 'bla',
`command bla blub`).
But for now, I really need to type all these things again and again. It
would be nice, if I could say "f- to complete full strings.
Or maybe also for single qouted strings, and for
`-quoted strings. Or maybe just one command to complete all strings, and
get from context, if we want to complete " ' or ` strings, depending on
what character is in front of . "f would complete "
quoted strings ' '-quoted and so on.
--
Martin
Re: JavaScript indentation
On Sun, Jan 28, 2007 at 01:12:00AM +0100, Bram Moolenaar wrote:
> > Hope that gets added to the default vim 7.1 distribution, because it's
> > quite the best working omni complete script I have seen so far.
>
> Can you mention on what points cppcomplete.vim works better than the
> ccomplete.vim scripts?
>
> If it's overal better I can replace the script.
First, it checks return types of functsion (where possible).
Lets assume this C code:
typedef struct POINT
{
int x;
float y;
} _POINT;
POINT func()
{
// POINT foo = ...
return foo;
}
int main()
{
func().
}
---
cppcomplete lists me:
x and y as members since func() returns a struct of type POINT.
ccomplete does nothing but searching for a long time. I have a 125MB
tags file in /usr/include with --foldcase, but cppcomplete is instant,
and ccomplete takes some seconds, and still doesn't find something.
Second, I am not sure, if ccomplete can follow typedefs, cppcomplete can.
These are my main 2 concerns, and probably a unified codebase for c/c++
completion is easier to maintain. But I have not worked with ccomplete
that much, so please check, if cppcomplete also works for your usage
szenarios when coding C.
--
Martin
Re: JavaScript indentation
On Sat, Jan 27, 2007 at 07:35:16PM +0100, Bram Moolenaar wrote: > Whatever this ends up to be: Please send me the best javascript indent > script, so that I can include it with the runtime files. A "best guess" > is better than nothing. Full ack. BTW: The last time I browsed the updated runtime/ repository, there was no cppcomplete.vim in the autoload/ directory. I really recommend this omnicomplete script from vim.org's script repository for all C++ code editing, I even use it for coding C, because (in my opinion) it works better there than ccomplete.vim. Hope that gets added to the default vim 7.1 distribution, because it's quite the best working omni complete script I have seen so far. -- Martin
Re: BOF Vim 8 - Suggestions
On Sun, Jan 21, 2007 at 10:55:44PM +0100, Nikolai Weibull wrote: > On 1/21/07, Marc Weber <[EMAIL PROTECTED]> wrote: > > >My comments on nohl: > >nnoremap :nohl echo "" > >should clear message line and remove highlighting > > nnoremap :silent! nohighlight Whenever I put any of these 2 commands in my .vimrc, vim beeps on startup, and when I press 'k' it deletes the current and above line. -- Martin
Re: Odp: BOF Vim 8 - Suggestions
On Fri, Jan 19, 2007 at 07:28:51PM +1100, John Beckett wrote: > In the BOF talk, Bram really was asking for ideas on what would make > new users flock to Vim. Biggest changes would really be defaults imho. And that should be done without really compromising compatible mode. First and most important thing would be to enable nocompatible by default when the executable name is (g)vim, compatible should still be on, when the executable name is vi. Enabling/disabling by an (non-)existing .vimrc file is not the right way, because if you make your own .vimrc file, you want to add some usefull behavior and in exchange you get less optimal behavior in many cases, and probably don't know why that is happening, just because you created a .vimrc with some mappings. It's really crazy that you can't even press Tab after :e to complete filenames in compatible mode. Second would be to enable :syntax on by default in nocompatible mode. Every bullshit-editor (sorry for the word), has syntax highlighting now, and even a Pentium 200 should be fast enough to deal with syntax highligthing. Third, I would enable isearch by default, but keep hlsearch off (as it is now). Most other options are right for experts and newbies as well, or at least have another reason for their default setting. -- Martin
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On Mon, Jan 08, 2007 at 05:05:31PM +0100, Trenton Schulz wrote: > >Would you also vote for changing the console style dialogs? I mean, > >console users are normally used to press y or n, when answering these > >kind of questions. > > Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of > the other "dialogs" on the console version don't ask yes/no questions > as far as I have encountered. I think it is a non-issue for the > console version... Well, mostly I use ZZ, but sometimes :q, but have :set confirm on, so when there are unsaved changes, there is no need to press :q!, but just y to save the changes, or n do discard them. -- Martin
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On Mon, Jan 08, 2007 at 12:14:05PM +0100, Trenton Schulz wrote: > >I'll look into this later. Perhaps Save/Discard/Cancel is better for > >all GUIs, since you don't need to read the text to know whether "yes" > >means "save" or "discard". But it will break the translations. > > Just being a lurker here, I would vote for this being in all GUIs > (not that we get votes here). Having the actual save/discard vs. yes/ > no makes it much simpler to look at a message box and know which > button to press (probably why the "File Changed" dialog in Vim is a > bit easier to decide what to do than the "Save Changes" dialog IMO). Would you also vote for changing the console style dialogs? I mean, console users are normally used to press y or n, when answering these kind of questions. -- Martin
Re: [PATCH] zip plugin: support any filename
On Mon, Oct 23, 2006 at 10:02:48PM +0200, [EMAIL PROTECTED] wrote: > I'm using this to edit firefox extensions directly inside their jar > files. I'm also attaching a patch that adds the required associations > (jar and xpi, I'm sure there are more). I exactly wanted to do the same, but it didn't work. Hopefully your patch gets accepted (didn't test it myself yet though). -- Martin
Re: insert-mode :map-alt-keys and 8-bit locales
On Sun, Oct 22, 2006 at 02:46:02PM +0400, Alexey I. Froloff wrote: > Alt+b and b works both the same, if Alt+Key sends Key > sequence. Consider this as a feature. But is there a timeout? because when this feature is set, I don't want breaking things, when I press b to go back a word. b should only be taken as when these 2 keys come within a very short period. -- Martin
Re: insert-mode :map-alt-keys and 8-bit locales
On Sun, Oct 22, 2006 at 01:31:09AM +0400, Alexey I. Froloff wrote:
> > Vim should _support_ Meta-Sends-Escape mode which is A Must Have
> > for non-ascii 8-bit locales
> Patch attached.
>
> New option - 'eightbitmeta' ('em'), default on. If unset, two
> things happen:
I like the idea, but did not test the patch yet. I did not get alt-keys
work properly with the meta8 option in urxvt set.
--
Martin
Re: Calling COM Components from Vim (Win32)
On Sat, Oct 14, 2006 at 03:44:33PM +0200, Eric Smith wrote: > I've scanned the vim-dev archives looking for any suggestions for and/or > attempts at creating a means of calling dual-interface COM objects from > within the Win32 version of Vim, and come up empty. > > IMHO, this would be a useful feature for extending Vim script to do some > very powerful things. For instance, advanced code completion could be > plugged into Omni. Since COM objects are only Win32, I don't think that will help much with omni completion, because at least those omni completion systems shipped with vim by default should be as cross-platform as possible. -- Martin
Re: Keyword completion
On Wed, Sep 20, 2006 at 01:33:54PM -0700, Gautam Iyer wrote: > Maybe this has been discussed already: When pressing Ctrl-P / Ctrl-N, > can we get vim to complete from the list of syntax keywords? You can do that by setting: :set omnifunc=syntaxcomplete#Complete and then use You can also specifiy certain syntax groups too use, but look into the docs/scripts, how to do that. -- Martin
Re: completion question
On Sun, May 14, 2006 at 05:24:35PM -0400, [EMAIL PROTECTED] wrote:
> All,
>
> If I hit on an empty line to do keyword completion ('completeopt'
> is set to "longest,menuone"), and I type a few chars, then hit backspace
> all the way up to the beginning of the line; the popup window at that
> point disappears. The behavior used to be that the popup window would
> stay up. I think it's inappropriate to have the popup window disappear
> just because you arrived at the initial state when the popup window
> appeared. Couldn't the behavior be that the popup window disappears when
> you go yet passed this point?
I also agree with your point.
Often after pressing to do context senstitive completion, I
press one character to narrow things down.
When I then see, that the narrowed matches don't make sense, I want to
press backspace to get all the previous machtes back.
E.g. often I don't know if it's .length() or .size() to get the length
of an array. Then I press array. and a 'l' - if this
doesn't show me a .length() parameter, pressing s to complete
.size() would make sense.
--
Martin
But in Ctrl-N completion
I am using vim7 final, and have this problem: Let's assume this buffer (between the quotes): " this that " Now i start inserting 'th' and press ctrl-n and get a popup menu with two choices 'this' and 'that', while the inserted text still remains 'th' (I am using completeopt=longest,menu,preview). Now I decide to keep on writing since I don't want neither 'this' or 'that', and write let's say 'thus'. After that I press 'esc', and a '.' to repeat the insertion. But now I get 'thusus' instead of just 'thus'. regards, and thanks for the wonderful vim7 release. -- Martin
Re: vim7 possible bug
On Thu, May 11, 2006 at 03:10:40PM +0200, Pierre Habouzit wrote: > Le Jeu 11 Mai 2006 14:57, Pierre Habouzit a écrit : > > > " make work in popup > > inoremap =pumvisible() ? "\C-Y>" : "\cr>" > > > > sadly I can't do the same with to exit the completion, because > > of beeing (and me using vim into non 8-bit capable > > terminals). > > which is a wrong assertion, > > inoremap =pumvisible() ? "\C-E>" : "\esc>" > > just look to work fine. I don't remember which problem I encountered > with that one ... Here it doesn't work (urxvt terminal), after this mapping, I get things like just writing A and B on a new line when I press or after canceling a popup with esc.
Re: 7.0g02 isearch/redir/balloon display glitch [GTK]
On Thu, May 04, 2006 at 03:02:18PM +0100, Neil Bird wrote:
>
> With the noddy plugin ~/.vim/ftplugin/c/balloon.vim:
>
> function! MyBalloonExpr()
> redir => def
> exe 'silent isearch /'.v:beval_text.'/'
> redir END
> return substitute(def,'^\_s*\(.\{-\}\)\_s*$', '\1', '')
> endfunction
> setlocal balloonexpr=MyBalloonExpr()
> setlocal ballooneval
Sorry, not directly connected to your problem, but I just noticed that
the balloon window can _only_ be used with the mouse. Wouldn't it make
sense if 'balloonexpr' is set, that the balloon is also shown when the
cursor pauses over a character for a certain time? (Just like CursorHold
does).
I think, most people using vim will never touch the mouse but the
balloon could give valuable information (like the definition of
variable) also for keyboard-only users.
--
Martin
Re: More about 7.0g
On Tue, May 02, 2006 at 03:36:02PM +1000, Robert Webb wrote: > - I previously said that I was disappointed to see that under > Windows2000 the tab-line was text rather than GUI. I have since > discovered the "e" fplag for 'guioptions'. Since I set 'guioptions' > in my _vimrc, and there was no "e" flag before, I didn't get the GUI > tab line by default. Wouldn't it make more sense to have a special > flag that indicates to NOT use the GUI-version of the tab line? > That is by far the less common setting, and would give users new to > version 7 the behaviour they would expect, ie use the GUI where > possible. That's why you should follow the help text from the *guioptions* help: > To avoid problems with flags that are added in the future, use the > "+=" and "-=" feature of ":set" |add-option-flags|. -- Martin
Re: some problem with vim7f Beta
On Wed, Apr 26, 2006 at 10:35:30AM +0800, Linsong wrote: > My main point is: I don't want to select entry in the completion menu by > pressing CTRL-N or CTRL-P, instead, I want to input enough characters to > make correct entry become the first entry and it is highlighted, then I > can use CTRL-Y(yes, I have mapped to CTRL-Y since I am tempted > to use ) to confirm the completion. Then just :inoremap That should should do what you expect now (untested). I really disliked old behavior, and think the current completion with 'longest' and ctrl-n is what it should behave like since it's more logical as you only need and and not yet another key like .
Re: Code completion and entries with duplicate 'word' attributes.
On Thu, Apr 20, 2006 at 06:52:44PM -0700, Eric Van wrote: > My code completion function returns a list with the following entries: > kind: 'f', word: 'toCharArray', menu: 'toCharArray() char[] - String' > kind: 'f', word: 'toString', menu: 'toString() String - String' > kind: 'f', word: 'toUpperCase', menu: 'toUpperCase() String - String' > kind: 'f', word: 'toUpperCase', menu: 'toUpperCase(Locale locale) > String - String' > kind: 'f', word: 'toLowerCase', menu: 'toLowerCase() String - String' > kind: 'f', word: 'toLowerCase', menu: 'toLowerCase(Locale locale) > String - String' > So I suggest either removing duplicate checking when results are in > the dictionary format, or at the very least, check the 'menu' > attribute along with the 'word' attribute to determine if an entry is > a duplicate, however that may or may not work for everyone. > > Thoughts? Comments? Yes, use the 'info' field for further information on a single 'word'. In your case you should write all different functions signatures in the 'info' field of just one 'word'. kind: 'f', word: 'toString',menu: 'toString() String - String', info: 'String toString()' kind: 'f', word: 'toUpperCase', menu: 'toUpperCase() String - String' info: 'String toUpperCase()\n String toUpperCase(Locale locale)' ... BTW: how complete is your java support? Does it work good enough for a public release, or is it for your own usage only? -- Martin
Re: Code completion suggestions...
> Maybe I didn't explain this correctly... I would expect the flow to be
>
> - User hits
> - vim executes foo#bar#FindCompletionStart instead of
> CompletionFunction(1, '...')
> The starting column of the completion is returned.
> - vim executes foo#bar#FindCompletions('...') instead of
> CompletionFunction(0, '...')
> The FULL list of completions is retuned, but in this case the 'info'
> attribute of the contained dictionaries is empty (since they would
> be lazily retrieved later, only when needed)
> - User stops on a completion for a determined amount of time
> - vim then executes foo#bar#FindCompletionInfo(index), where index
> is the index of completion the user paused on.
> - vim displays the that info in the preview window
I really like the idea, it would enable both types of 'info' items. If
you can generate 'info' items quickly (like for the C-omnifunc), you can
generate them in the FindCompletions function and store them in an array
and just return the index of this array in the FindCompletionInfo
function.
But for languages where this info could take a lot of time to generate
(like extracting info from man pages, perldoc, or manually from doxygen
comments), you have the time to postpone this time consuming task.
But 1.5 seconds is much too long for a default wait time. Half a second
should be enough IMHO.
--
Martin
Re: Code completion suggestions...
On Thu, Apr 20, 2006 at 08:15:01AM -0700, Eric Van wrote: > So, I propose a means to lazily retrieve info for a completion. > Basically it should be like a CursorHold, but in the context of the > completion popup. If the user stops on a completion for some > determined amount of time, vim should then, ideally, spawn off a > thread to retrieve the info for that completion and display it in the > completion preview. I think it is key to do this retrieval in an > asynchronous way so as not to prevent the user from moving to the next > completion or performing some other action. A very good idea, it was on Bram's TODO list at some time, but is not there anymore (I think). Something like really could be usefull not only for your case, but imagine, that the completion plugin could provide info from man pages for C functions, or info from 'ri' for ruby, or from 'perldoc -f' for perl, etc. THAT would really help coding from only within vim without the need for a sepate terminal open just to get help. -- Martin
