Re: Improved integration between Vim and its environment (full-screen, open URL, background execute())
> > Which executable do you intend to execute in a cross-plattform
> > portable way?
>
> (c)make/(b)jam/aap, gcc, doxygen, ctags, latex, ...
In my experience the major problem with running external apps like
those listed above is filenames -- e.g. when I use cygwin tools from
windows gvim or when I want to use the same code to run an executable
on linux and windows etc. I don't consider the cmd window a major
problem since it's often minimized anyway.
IMHO a "portable way" would have to include a way to filter filenames
(e.g. when using cygwin, I'd like to pass them to cygpath -u before
running the command). Such a function call could then look like:
call foo#fexecute('%x -9 %f', 'gzip', expand('%')), where %f expands
to a filename,
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [patch] redraw bug with 'foldcolumn' and 'conceallevel'
Dominique Pellé wrote: > Vince Negri wrote: > > > From: Dominique Pellé [mailto:dominique.pe...@gmail.com] > > > >> Thinking about it further, this second attached patch > >> also fixes the fold column redraw bug with less redraws > >> than patch in previous email. > > > >> However, unlike previous patch, it does not fix the > >> redraw glitches with moving commands ) ]] CTRL-F (etc) > >> so they require specific fixes. > > > > I think this patch is the right way to go about it, as we shouldn't > > be redrawing unnecessarily (esp since Vim is often run over remote > > connections.) > > > > That does mean that explicit fixes need to be added for a number of movement > > commands, but I'd rather sort them out as they are discovered. > > > > Dominque, you so far have a list of these movement commands needing > > treatment: > > > > ) > > ]] > > > > > > CTRL-F > > CTRL-B > > CTRL-U > > CTRL-E (when cursor is on the top line, causing scrolling) > > CTRL-Y (when cursor is on the bottom line, causing scrolling) > > CTRL-O > > CTRL-I > > [count]go > > [count]g; > > > > :[range] > > :go [count] > > > > > > ..have you found any others since? It would be good if I could try to sort > > them all > > out "in one go" > > Searching further, I find several other motion commands which > do not unconceal the current line and conceal the old line: > > gd > gD > [* > [# > > Undo commands: > g- > g+ > u > CTRL-R > :earlier > :later > :undo > :redo > > ctag and cscope commands: > g] > CTRL-] > :ts > :tj > :pop > :[count]tag > :cs find ... > > (CTRL-L to redraw works around it in all cases). I think it's time to look into a more generic solution. Can we store the old line number in the main loop, and only update there? Search for last_cursormoved, that should give some hints. Note that updates won't happen on typeahead. Is that good or not? -- hundred-and-one symptoms of being an internet addict: 209. Your house stinks because you haven't cleaned it in a week. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] redraw bug with 'foldcolumn' and 'conceallevel'
Vince Negri wrote: > From: Dominique Pellé [mailto:dominique.pe...@gmail.com] > >> Thinking about it further, this second attached patch >> also fixes the fold column redraw bug with less redraws >> than patch in previous email. > >> However, unlike previous patch, it does not fix the >> redraw glitches with moving commands ) ]] CTRL-F (etc) >> so they require specific fixes. > > I think this patch is the right way to go about it, as we shouldn't > be redrawing unnecessarily (esp since Vim is often run over remote > connections.) > > That does mean that explicit fixes need to be added for a number of movement > commands, but I'd rather sort them out as they are discovered. > > Dominque, you so far have a list of these movement commands needing treatment: > > ) > ]] > > > CTRL-F > CTRL-B > CTRL-U > CTRL-E (when cursor is on the top line, causing scrolling) > CTRL-Y (when cursor is on the bottom line, causing scrolling) > CTRL-O > CTRL-I > [count]go > [count]g; > > :[range] > :go [count] > > > ..have you found any others since? It would be good if I could try to sort > them all > out "in one go" Searching further, I find several other motion commands which do not unconceal the current line and conceal the old line: gd gD [* [# Undo commands: g- g+ u CTRL-R :earlier :later :undo :redo ctag and cscope commands: g] CTRL-] :ts :tj :pop :[count]tag :cs find ... (CTRL-L to redraw works around it in all cases). -- Dominique -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] redraw bug with 'foldcolumn' and 'conceallevel'
On Tue, Jun 15, 2010 at 9:08 AM, Vince Negri wrote: > From: Dominique Pellé [mailto:dominique.pe...@gmail.com] > >> Thinking about it further, this second attached patch >> also fixes the fold column redraw bug with less redraws >> than patch in previous email. > >> However, unlike previous patch, it does not fix the >> redraw glitches with moving commands ) ]] CTRL-F (etc) >> so they require specific fixes. > > I think this patch is the right way to go about it, as we shouldn't > be redrawing unnecessarily (esp since Vim is often run over remote > connections.) > > That does mean that explicit fixes need to be added for a number of movement > commands, but I'd rather sort them out as they are discovered. > > Dominque, you so far have a list of these movement commands needing treatment: > > ) > ]] > > > CTRL-F > CTRL-B > CTRL-U > CTRL-E (when cursor is on the top line, causing scrolling) > CTRL-Y (when cursor is on the bottom line, causing scrolling) > CTRL-O > CTRL-I > [count]go > [count]g; > > :[range] > :go [count] I haven't tested the patch, but I'd bet that [count]z- [count]z+ [count]z [count]zt etc will need fixups, and might be easy to miss since their no-count behavior doesn't move the cursor. ~Matt -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Anyone want to implement vi keys in OpenOffice
I second that. ViEmu for MS Office is so damn great, I really wonder why no-one has (apparently) done that for OO.org yet. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Improved integration between Vim and its environment (full-screen, open URL, background execute())
On 6/14/2010 10:24 PM, Peter Odding wrote: Ernie Rael wrote: I wonder what the chances are of getting a new command in vim that does what you want (or perhaps some options for no-window and no-wait). Then the DLL on windows would not be needed. [...]on UNIX it's dead easy to make system() calls asynchronous, circumventing the "cooked" mode: you can just wrap the external command in ( ... ) & [...] Though it is possible, if the behavior could be abstracted into vim options/commands (rather than OS specific code in scripts) then there could be general benefit. It looks like the ":!start" is only available on windows. -ernie -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.426
On Tue, Jun 15, 2010 at 5:55 PM, James Vega wrote:
> That is, if you simply do ":set langmap=a\," then after the command-line
> is parsed you get ":set langmap=a,". The comma isn't escaped. When you
> do ":set langmap=a\\,", then the backslash still exists after the
> command-line is parsed and then when the option parsing takes place it
> will see ":set langmap=a\," and you have an escaped comma.
OK, thank you for explanation, have changed my langmap like this:
set
langmap=ёйцукенгшщзхъфывапролджэячсмитьбюЙЦУКЕHГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮ;`qwertyuiop[]asdfghjkl\\;'zxcvbnm\\,.QWERTYUIOP{}ASDFGHJKL:\\"ZXCVBNM<>
--
Best regards,
Valery Kondakoff
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.426
On Tue, Jun 15, 2010 at 8:20 AM, Valery Kondakoff wrote: > On Tue, Jun 15, 2010 at 4:01 PM, Andy Wokula wrote: >> Am 15.06.2010 13:53, schrieb Valery Kondakoff: I'm receiving an error E357 'Matching character missing for a' if I execute ':set langmap=a\,' form command line. >>> Seems to work well like this: :set langmap=a\\,'. Is this a bug? >> >> No. >> :h option-backslash > > I understand, that if I want to enter a backslash in settings it > should be escaped by another backslash. But currently I'm using > backslash to escape the comma. Why should I enter two backslashes? Right, and in order for that backslash to be part of the option string so that parsing of the option will see the backslash, you need to escape it. It's not a matter of escaping the comma on the command-line (since that doesn't matter). It's a matter of having a backslash in the resulting string that's used for the option so that the option itself has a backslash before the comma. That is, if you simply do ":set langmap=a\," then after the command-line is parsed you get ":set langmap=a,". The comma isn't escaped. When you do ":set langmap=a\\,", then the backslash still exists after the command-line is parsed and then when the option parsing takes place it will see ":set langmap=a\," and you have an escaped comma. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: [patch] redraw bug with 'foldcolumn' and 'conceallevel'
From: Dominique Pellé [mailto:dominique.pe...@gmail.com] > Thinking about it further, this second attached patch > also fixes the fold column redraw bug with less redraws > than patch in previous email. > However, unlike previous patch, it does not fix the > redraw glitches with moving commands ) ]] CTRL-F (etc) > so they require specific fixes. I think this patch is the right way to go about it, as we shouldn't be redrawing unnecessarily (esp since Vim is often run over remote connections.) That does mean that explicit fixes need to be added for a number of movement commands, but I'd rather sort them out as they are discovered. Dominque, you so far have a list of these movement commands needing treatment: ) ]] CTRL-F CTRL-B CTRL-U CTRL-E (when cursor is on the top line, causing scrolling) CTRL-Y (when cursor is on the bottom line, causing scrolling) CTRL-O CTRL-I [count]go [count]g; :[range] :go [count] ..have you found any others since? It would be good if I could try to sort them all out "in one go" Vince -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Improved integration between Vim and its environment (full-screen, open URL, background execute())
Hello, "Tom Link" wrote : > Which executable do you intend to execute in a cross-plattform > portable way? (c)make/(b)jam/aap, gcc, doxygen, ctags, latex, ... As far as I'm concerned, the need exists. I'd rather not require an external executable/DLL though. -- Luc Hermitte http://lh-vim.googlecode.com/ http://hermitte.free.fr/vim/ -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.426
On Tue, Jun 15, 2010 at 4:01 PM, Andy Wokula wrote:
> Am 15.06.2010 13:53, schrieb Valery Kondakoff:
>>> I'm receiving an error E357 'Matching character missing for a' if I
>>> execute ':set langmap=a\,' form command line.
>> Seems to work well like this: :set langmap=a\\,'. Is this a bug?
>
> No.
> :h option-backslash
I understand, that if I want to enter a backslash in settings it
should be escaped by another backslash. But currently I'm using
backslash to escape the comma. Why should I enter two backslashes?
:help 'langmap'
"Special characters need to be preceded with a backslash. These are
";", ',' and backslash itself.".
At least, escaping of ";" works well without double backslashes (like
this: '\;').
BTW: gVim 7.2.441 complains about not escaping the double quotes (")
as well. Should this be added to the langmap docs?
--
Best regards,
Valery Kondakoff
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.426
Am 15.06.2010 13:53, schrieb Valery Kondakoff: On Tue, Jun 15, 2010 at 3:47 PM, Valery Kondakoff wrote: Patch 7.2.426 Problem:Commas in 'langmap' are not always handled correctly. Solution: Require commas to be backslash escaped. (James Vega) Files: src/option.c I'm receiving an error E357 'Matching character missing for a' if I execute ':set langmap=a\,' form command line. Seems to work well like this: :set langmap=a\\,'. Is this a bug? No. :h option-backslash -- Andy -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.426
On Tue, Jun 15, 2010 at 3:47 PM, Valery Kondakoff wrote: >> Patch 7.2.426 >> Problem: Commas in 'langmap' are not always handled correctly. >> Solution: Require commas to be backslash escaped. (James Vega) >> Files: src/option.c > I'm receiving an error E357 'Matching character missing for a' if I > execute ':set langmap=a\,' form command line. Seems to work well like this: :set langmap=a\\,'. Is this a bug? -- Best regards, Valery Kondakoff -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.426
On Fri, May 14, 2010 at 7:33 PM, Bram Moolenaar wrote: > Patch 7.2.426 > Problem: Commas in 'langmap' are not always handled correctly. > Solution: Require commas to be backslash escaped. (James Vega) > Files: src/option.c Hmm... Something wrong here. Now, if I'm adding this: 'set langmap=a\,' to my _vimrc I'm receiving an error: 'Error detected while processing d:\tools\vim_vimrc: line 16: E357: 'langmap': Matching character missing for <0431>'. I'm receiving an error E357 'Matching character missing for a' if I execute ':set langmap=a\,' form command line. The same langmap and command were working well in gVim 7.2.267. Now there is an error in gVim 7.2.441 (Win7). -- Best regards, Valery Kondakoff -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: Improved integration between Vim and its environment (full-screen, open URL, background execute())
Peter Odding wrote: > I've asked myself why Vim's system() function on Windows uses > vimrun.exe and shows a command prompt window. The only reason > I can think of is so that the user has a chance to quit the > external command using Ctrl-C. Sorry if the following is not relevant (I have not followed this thread). If you do not have to use system() to get results, you can use :!start which is different from :! on Windows. I believe that :!start does not use vimrun.exe. There is some info in the following: http://vim.wikia.com/wiki/Execute_external_programs_asynchronously_under_Windows John -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Anyone want to implement vi keys in OpenOffice
I just got the message that vi keys are welcome in OpenOffice, but as an addon, please see http://www.openoffice.org/issues/show_bug.cgi?id=89663 Perhaps there is someone on the vim lists interested in implementing this? Kind regards, L -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Fixed issue with langmap
2010/6/15 Vladimir A. Pavlov :
> But when I try pressing ^[ to exit insert mode (or ^O to exit it
> temporarily) in russian xkb layout I got `х' (the russian character
> placed at the same key as `[') inserted instead of exiting.
> All the keybindings with Ctrl key don't work, such as completion
> (^n, ^p, ...), editing (^w, ^u).
It seems the Windows gVim build (7.2.267) is not affected of this
issue. All the examples above works well with this langmap:
set
langmap=ёйцукенгшщзхъфывапролджэячсмитьбюЙЦУКЕHГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮ;`qwertyuiop[]asdfghjkl;'zxcvbnm,.QWERTYUIOP{}ASDFGHJKL:\"ZXCVBNM<>
--
Best regards,
Valery Kondakoff
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
