Re: Why is there no :foldupdate?

Christian Brabandt wrote:

> > sometimes I am using fold expressions to simply hide away unwanted
> > parts. Usually this boils down to
> > :set fdm=expr fde=getline(v:lnum)!~getreg('/',1)
> > 
> > While this works fine, it is only limited to whatever was in register  <at> /
> > when this setting was entered. Now this leaves an interesting question:
> > When are 'foldexpr' reevaluated (are they at all)? Reading :h fold.txt
> > does not mentioned when the fold expressions are reevaluated and folds
> > are updated (or I might have missed it).
> > 
> > Now the obvious cure to this is to reenter the foldexpression. So if I
> > am searching for a different term, I need to enter
> > :set fde=getline(v:lnum)!~getreg('/',1)
> > and the folds will be updated.
> > 
> > Of course, I could define my own :Foldupdate like this:
> > :com! Foldupdate :exe "set fde=".&fde
> > 
> > But this looks so fundamental, that I am wondering, whether I am the
> > only one who is missing :foldupdate. Does anybody else think so? Or am I
> > missing something obvious?
> > 
> > PS: Looking at the source, it does not seem too hard, to define an extra
> > :foldupdate command. Does that sound like a reasonable idea? I could
> > prepare a patch for this, if there is interest.
> > 
> > regards,

Re: Why is there no :foldupdate?

Hi Bram!

On Do, 01 Apr 2010, Bram Moolenaar wrote:

> One remark: in the help, add a bit more information about when this would
> be needed, why the folds are not updated automatically.

Attached is an updated patch. Is this better?

regards,
Christian

--

-- 
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

To unsubscribe, reply using "remove me" as the subject.

Re: Why is there no :foldupdate?

On 31/03/10 23:27, Christian Brabandt wrote:
> (fullquote, because copying vim_dev)
>
> On Mi, 31 Mär 2010, Christian Brabandt wrote:
>
>> Hi,
>>
>> sometimes I am using fold expressions to simply hide away unwanted
>> parts. Usually this boils down to
>> :set fdm=expr fde=getline(v:lnum)!~getreg('/',1)
>>
>> While this works fine, it is only limited to whatever was in register  <at> /
>> when this setting was entered. Now this leaves an interesting question:
>> When are 'foldexpr' reevaluated (are they at all)? Reading :h fold.txt
>> does not mentioned when the fold expressions are reevaluated and folds
>> are updated (or I might have missed it).
>>
>> Now the obvious cure to this is to reenter the foldexpression. So if I
>> am searching for a different term, I need to enter
>> :set fde=getline(v:lnum)!~getreg('/',1)
>> and the folds will be updated.
>>
>> Of course, I could define my own :Foldupdate like this:
>> :com! Foldupdate :exe "set fde=".&fde
>>
>> But this looks so fundamental, that I am wondering, whether I am the
>> only one who is missing :foldupdate. Does anybody else think so? Or am I
>> missing something obvious?
>>
>> PS: Looking at the source, it does not seem too hard, to define an extra

Re: Why is there no :foldupdate?

Hi Tony!

On Sa, 03 Apr 2010, Tony Mechelynck wrote:

> On 31/03/10 23:27, Christian Brabandt wrote:
>> Note, how the folding will be wrong, after the second search command
>> (and I have found no way to refresh the folding. zx and zX do not work,
>> though its description led me believe it could have. Well actually I
>> found one way: filtering the whole buffer through cat will also update
>> the folding)

> Doesn't this patch duplicate the already existing zx command?

Please read again, what I already wrote ;)

Should zx or zX maybe be changed to update the folds?

regards,
Christian

--

-- 
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

To unsubscribe, reply using "remove me" as the subject.

bug with getpos("'>")[2] with multibyte charactor?

Hi list,

Don't know if it's a bug or feature, but when in visual mode, if I select just
one multibyte charactor, say "我", getpos("'>")[2] will return a value the
same as getpos("'<")[2], but in fact, a multibyte should occupy multi columns
so it should be a value larger than getpos("'<")[2]'s.

-- 
Regards,
Yue Wu

Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China

--

-- 
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

To unsubscribe, reply using "remove me" as the subject.

Re: bug with getpos("'>")[2] with multibyte charactor?

On 03/04/10 16:22, Yue Wu wrote:
> Hi list,
>
> Don't know if it's a bug or feature, but when in visual mode, if I select just
> one multibyte charactor, say "我", getpos("'>")[2] will return a value the
> same as getpos("'<")[2], but in fact, a multibyte should occupy multi columns
> so it should be a value larger than getpos("'<")[2]'s.
>

Unless 'virtualedit' is set, getpos() returns values corresponding to 
the start position of a character. So if only one character was 
highlighted by the latest Visual selection, '< and '> will be the same, 
even if that character occupies more than one screen column.

If you set 'virtualedit' to "all", then the cursor can be positioned in 
the middle of the space occupied by a hard tab, or (presumably) on the 
2nd cell of a CJK fullwidth glyph. In that case you'll see a difference 
in getpos('.')[3] which will be nonzero to tell you you aren't at the 
start of a character. getpos('.')[2] will still be on the start cell of 
the character in question IIUC.

I don't think that marks can be set halfway a character anyway, even 
with 'virtualedit' nonempty. (Or can they?)

Best regards,
Tony.
-- 
Parts that positively cannot be assembled in improper order will be.

--

-- 

Re: bug with getpos("'>")[2] with multibyte charactor?

On 03-Apr-2010 19:04, Tony Mechelynck wrote:
> I don't think that marks can be set halfway a character anyway, even
> with 'virtualedit' nonempty. (Or can they?)

Correct. [At least in GVIM,] the cursor turns into a double-width block when on 
a Kanji character. 'virtualedit' only applies to positioning inside <Tab> 
characters.

Also be aware that the byte-index returned by getpos() is not related to the 
screen width of a character (queried via virtcol()). In UTF-8 encoding, a Kanji 
character is stored in 3 byte, but takes two columns of screen space. There can 
also be multi-column characters that only take up one byte (<Tab> is the most 
prominent one), and multi-byte characters that only take up one column.

-- regards, ingo

--

-- 
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

To unsubscribe, reply using "remove me" as the subject.

Re: Clicking the mouse doesn't change the jump list?

On 08/02/10 09:00, Matt Wozniski wrote:
> Is it intentional that moving the cursor by clicking the mouse doesn't
> modify the jumplist?  It seems strange that you can't jump back to
> where you were before clicking with `` for instance.  You can get
> around it with a mapping like
>
>     noremap<LeftMouse>  m'<LeftMouse>
>
> but that seems like it shouldn't be necessary...
>
> ~Matt
>

I'm surprised that nobody replied to this post in almost two months.

You cannot click the mouse outside the window, so the maximum distance 
between the "old" and "new" cursor positions for that window when you 
jump by clicking the mouse is one window height. I suppose that this 
means clicking the mouse does not qualify as a "long jump".

The list of "jump commands" is a closed set, enumerated under ":help 
jump-motions"; only keyboard actions are included. The inclusion of L M 
H but not <LeftMouse>, all of which are described together at the very 
end of motion.txt, and none of which moves by more than one window 
height, seems illogical to me too.

Best regards,
Tony.
--

-- 
Lockwood's Long Shot:

Re: vim sf wishlist

On 11/02/10 01:23, Marc Weber wrote:
[...]
> Does a simple buildfarm exists which builds Vim in various configuration
> options doing some sanity checks?
>
> Marc Weber
>

It's easy to construct one, but only on Unix-like systems, including 
Unix-like Cygwin and (IIUC) Mac OS X. Not on native-Windows AFAIK, 
because the configure script doesn't run on that platform. I guess you 
(Marc) know the following but I'm spelling it out for anyone interested:

0) Get the source.
1) Make as many "shadow" subdirectories of src/ as you want different 
configurations, using "make shadow" with src/Makefile; after each pass, 
rename src/shadow (or comment away the Makefile line "SHADOWDIR = 
shadow" and define SHADOWDIR differently yourself for each run of "make 
shadow").
2) Construct shell include scripts (let's call them 
src/$SHADOWDIR/config.sh) similar to the one near the top of my howto 
page http://users/.skynet.be/antoine.mechelynck/vim/compunix.htm , one 
per configuration with the desired settings.
-- For some particularly "unusual" configurations, you may have to break 
the softlink for feature.h and comment or uncomment some of its lines 
differently in different shadowdirs.
3) In each shadowdir:
	source config.sh
	make && make test

compiling gvim