Re: Getting a more readable font

[Tony Mechelynck]

On Tuesday, April 18, 2023 at 5:58:25 PM UTC+2 Yee Cheng Chin wrote:

No, please *don't* set fileencoding, encoding, or fileformats in your vimrc 
at all. That's not where those settings should go and in fact you should 
rarely need to set these settings. The default works just fine. I recommend 
reading the documentation on what each one does. Online snippets like 
StackOverflow and great for addressing specific needs but they are not good 
for setting up a vimrc cohesively.

Setting 'encoding' etc. in the vimrc _may_ be a good idea if they aren't 
yet set to utf-8 (this usually means on Windows but it might happen on any 
weirdly set system). The snippet below, somewhere near the top of your 
vimrc, will make sure that Vim, on any system, uses utf-8 internally, which 
will allow it to process files in any encoding (for some unusual ones you 
may have to tell it what to use in the :new or :edit command for the file, 
see ":help ++enc"). This snippet is written using non-vim9 syntax; I've 
liberally added comments (take them or leave them, they make of course no 
difference to the snippet's working) to make it easier to understand.

" save the keyboard locale if defaulted to the same as 'encoding'
if  == ""
let  = 
endif
" if 'encoding' is not already some Unicode Transfer Format,
" use UTF-8
if  !~? '^u'
set enc=utf-8
endif
" The following ('fencs' with a final s) defines the heuristic to use
" when reading a file, to determine its encoding.
" It is a comma-separated list with no intervening spaces.
" It may be varied as follows:
" * ucs-bom should come first; it will recognize Unicode files having
" a BOM (byte-order mark ; "encoding mark" would be a better
" designation) i.e. a U+FEFF codepoint as the very first character.
" * utf-8 should come next ; it will recognize files encoded in UTF-8
" even without BOM.
" * default will use (if possible) the system default locale
" ($LC_CTYPE or equivalent) as set on your computer. If it is an 8-bit
" encoding it will always be accepted.
" * latin1 (or some other predefined 8-bit encoding) should come last,
" especially if the default encoding is not before it or is not 8-bit. It 
will
" catch whatever has not yet been caught by whatever is to its left.
set fencs=ucs-bom,utf-8,default,latin1
" The following ('fenc' without the final s, defined globally) defines
" what to use when creating a new file from scratch.
" One advantage of UTF-8 is that files containing only characters
" in the range 0x00 to 0x7F are represented identically in UTF-8
" and in (7-bit) us-ascii. You might prefer some other default: YMMV.
setg fenc=utf-8

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/28aa43dd-9c8f-4e93-9d02-4e5f2dd69594n%40googlegroups.com.

Re: Vim9 import [was Vim9 script feature-complete]

[Tony Mechelynck]

On Tuesday, January 4, 2022 at 6:26:07 PM UTC+1 Bram Moolenaar wrote:

>
> Marvin Renich wrote: 
>
> > * Bram Moolenaar  [220103 12:33]: 
> > > > On 2022-01-03, Marvin Renich  wrote: 
> > > > > Don't bother with the 
> > > > 
> > > > > import MyClass from "myclass.vim" 
> > > > > import {someValue, MyClass} from "thatscript.vim" 
> > > > > 
> > > > > syntax, and only provide 
> > > > > 
> > > > > import "myclass.vim" 
> > > > > import "myclass.vim" as Other 
> > > > > 
> > > > > and require use of the namespace prefix: 
> > > > > 
> > > > > Other.MyClass 
> > > > > 
> > > > > The first case, without the "as" would default to the file name, 
> with 
> > > > > leading directories and trailing ".vim" removed 
> > > > 
> > > > I do not think that using a filename as an identifier is a good 
> idea. 
> > > > For instance, calling a script 1.vim would automatically make it 
> > > > non-importable (without "as"). 
> > 
> > I agree that using the (cleansed) file name is suboptimal, but it was 
> > the simplest choice. There are a couple other possibilities. One is to 
> > require the "as" clause. 
> > 
> > Another is to do something similar to Go (a language I like, if you 
> > couldn't tell :-) ). Every Go source file has a package statement, 
> > «package frob», and when importing, this package identifier, «frob», is 
> > used as the prefix (if not overridden in the import statement). 
> > 
> > Every vim9 script file already has a vim9script statement. You could 
> > say that in order for the script to be imported the vim9script statement 
> > must be of the form «vim9script ScriptId» where ScriptID must be a 
> > capitalized identifier. If you import two different scripts with the 
> > same script ID, you must use the "as" clause for at least one of them. 
> > 
> > Alternatively, you could require either the script ID on the vim9script 
> > statement or the "as" clause on the import statement. 
>
> Adding a script ID adds another mechanism and I don't see enough 
> advantage in it. It raises questions, such as what happens if two 
> completely unrelated plugins use the same ID? 
>

I see an important disadvantage: with this system, if in the importing 
script you don't explicitly rename the namespace, then when reading the 
source it isn't possible to know that after

import foobar.vim
   call ScriptID.Function()

the ScriptID is defined by a statement in foobar.vim. If the "implicit 
namespace" were easily deductible from the script name (as it already is in 
the autoload mechanism) then you would have, maybe,

import foobar.vim
call foobar.Function()

or something similar, which is much more transparent.

>
> Since the import can use a relative file name, a short file name can 
> work. It's only when using a file name in 'runtimepath' that we can 
> expect the name to be longer. Thus requiring the use of "as" up front 
> does not seem necessary. 
>
> > > Since a script needs to use "export" to be able to be imported, having 
> > > to use a nice name for the script is clearly needed. The only thing is 
> > > that it may be a long name to avoid name collisions, but then the "as 
> > > {name}" form can be used to shorten the name. 
> > > 
> > > > I personally find that using an imported name without a prefix (as 
> it is 
> > > > currently possible) makes my code terse, and I think that in the 
> limited 
> > > > scope a plugin that works well. 
> > 
> > My opinion is the opposite, here. Even in small, simple scripts, the 
> > prefix makes the code more readable; there is no question from where the 
> > identifier came. 
>
> Right. Somehow code writers can be very lazy typing things, and then 
> spend lots of time (possibly much later) figuring out what the code is 
> doing. Unfortunately I'm not aware of any studies being done on this 
> (it's more computer art than computer science). 
>
> > > > But I understand that Vim9 scripts might 
> > > > have a broader use, such as generic libraries of functions that can 
> be 
> > > > used by many scripts. In that context, stricter scoping rules, such 
> as 
> > > > in Go, are likely a cleaner approach. 
> > > > 
> > > > How about always requiring a prefix, but allowing explicit namespace 
> > > > pollution? As in 
> > > > 
> > > > import "myclass.vim" as Other 
> > > > use Other # Makes Other.F() available as just F() 
> > 
> > I like this very much; it works regardless of how the prefix gets 
> > defined ("as" clause, vim9script statement, or cleansed filename). 
> > 
> > I think if I had to pick, I would require the "as" clause. It is 
> > simple, and doesn't depend on the script author keeping the same script 
> > ID with newer versions of the script. The author of the script doing 
> > the importing is required to be in control. 
> > 
> > > Throwing everything from "Other" into the current namespace is going 
> to 
> > > cause trouble, because someone may add an item to myclass.vim that 
> > > conflicts with what is in your script. 

Re: Cols and number

[Tony Mechelynck]

On Wednesday, November 17, 2021 at 4:01:00 PM UTC+1 fel...@felipegasper.com 
wrote:

> Hello, 
>
> When I set `cols=80` and enable line numbering (`number`), I lose the last 
> few columns for code because MacVim uses them for the line numbers. 
>
> Is it possible to make the `cols` setting account for line numbering, so 
> that I get 80 columns for editing code, regardless of whether line 
> numbering is on (and how many columns the line numbers themselves need)? 
>
> Thank you! 
>
> Cheers, 
> -Felipe Gasper
>

Vim's 'columns' setting includes the line number (if any), whose width 
varies according to how many lines are in the file and on the 'numberwidth' 
setting. No matter which options you set, if you are running Vim in an 
80-column-wide terminal, you won't be able to get 80 columns for the text 
plus some additional columns for the line number. Otherwise, if your screen 
is wide enough, and your Vim is compiled with +float, you can get the width 
of the linenumber as (untested)
:nu?(max([:numberwidth,floor(log10(line('$')))+2])):0
floor(log10(n)) should be one less than the number of decimal digits needed 
to write the number n, and +2 because we add back not only that "one less" 
but also the single empty column between the line number and the text.

Add the value of the above expression to the desired textwidth (here 80), 
set 'columns' to the sum of both, then check if you got what you wanted 
(because setting 'columns' is limited by the actual available width: if I 
try to set it to 999 it will actually be set to only the number of 
characters that can be displayed onscreen).

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/baa69f20-e47d-4c1f-a210-25fc959abccan%40googlegroups.com.

Re: Meta on Mac

[Tony Mechelynck]

On Sunday, March 7, 2021 at 2:25:56 AM UTC+1 duhd...@gmail.com wrote:

> Hi All,
> I'm wondering if there is a way to enable meta key for vim on mac. I'm 
> using it from terminal. I read an earlier post in the mail list about 
> MavVim.app GUI. But I want to stick to the stock Vim. What I have found out 
> working:
>
> 1. NeoVim works with  out of the box. Of course you need to turn on 
> Meta emulation of your terminal.
> 2. Vim works with -->˜ kind of mapping when turning meta emulation 
> off.
> 3. Vim works with n kind of mapping when turning meta emulation on.
>
> So far, my best option seems to use n types of mapping. But not sure 
> if this kind of mapping works with linux or not. Also for plugins using 
> Meta, I have to remap manually. I hope there are better options to have 
> Meta natively on Mac.
>
> Regards,
> Haodong Du
>

I suggest a two-step solution:

map x   " IMPORTANT: do not use :noremap here
map  whatever

This way, for all the mappings thus defined, Esc and Meta will  be 
interpreted the same way. You may also want to set timeouts as follows:
'timeout'   (boolean) on
'timeoutlen' (milliseconds) slower than your slowest typing speed for the 
{lhs} of a single mapping
'ttimeoutlen' (milliseconds) faster than your fastest typing speed but 
slower than the interval between successive bytes sent by the system for a 
single keypress.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/e62a398b-d8d9-41df-883b-c491661d1347n%40googlegroups.com.

Re: resizing the macvim window

[Tony Mechelynck]

All Vim GUIs describe their screen sizes in terms of character cells. Some 
of them (including IIRC GTK2 and GTK3; I'm not sure about Windows and I 
don't know about MacVim) fill up the whole display when you click the 
"Maximize" button in one of the top corners, but in any case this only adds 
a few unused pixels along the borders, because Vim basically works with 
fixed-size character cells, using one cell for most characters, two cells 
for "wide CJK" characters, and between one and 'tabstop' cells for a hard 
tab, but never a noninteger number of cells. Even GTK2/GTK3 gvim, which can 
use any font, look ugly when using a proportional font, because the 
character cells are still of fixed size, which means that "wider" 
characters like m look cramped while "narrower" characters like i and l 
(small I and small L) seem to be surrounded by too much empty space. This 
property of using character cells of fixed size (a size which, in GUI Vim 
like gvim and MacVim, can only be changed by changing the 'guifont' 
setting) is so basic a property of Vim (and of Legacy vi before it IIUC) 
that I expect it never to change for as long as Vim will exist.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/e550d6e1-eaba-415c-9cc8-44134eaacd42n%40googlegroups.com.

Re: resizing the macvim window

[Tony Mechelynck]

P.S. The size of the Firefox window is measured in pixels. The size of the 
MacVim screen (not including the window decorations, whose width is 
constant) is measured in characters. This comes from the different 
philosophy of these applications and is expected.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/68d756b9-6899-43ee-9825-c970cee9574fn%40googlegroups.com.

Re: Character bracketing

[Tony Mechelynck]

On Sunday, October 18, 2020 at 9:51:26 PM UTC+2, Fameli, Nicola wrote:
>
>
>
>
> --
> *From:* vim_mac@googlegroups.com  on behalf of 
> Tony Mechelynck 
> *Sent:* 18 October 2020 8:46
> *To:* vim_mac
> *Subject:* Re: Character bracketing 
>  
> [*CAUTION:* Non-UBC Email] 
> On Saturday, October 17, 2020 at 11:49:25 AM UTC+2, Fameli, Nicola wrote: 
>>
>> Hi there,
>>
>>
>> something's up with my vi(m) editor in my mac pro Terminal app (Mac OS 
>> Catalina) and it's driving me insane.
>>
>>
>> It happens when I make a new file, say a python function in which I might 
>> write from the command line:
>>
>> $vim function.py
>>
>> def function(variable):
>>
>>pass
>>
>> then I type :wq to save it and exit.
>>
>> Next time I open it I'll see each letter bracketed by ^@, as in:
>>
>> ^@d^@^@e^@^@f^@ ^@f^@^@u^@^@n... you get the idea.
>>
>>
>> Interestingly, if I add text to an existing file, save it and close it, 
>> the issue isn't there next time I open it. It seems to happen only when I 
>> make a fresh file and with vim 8.1.2292 as well as 8.2.1719.
>>
>>
>> Any help to solve this would be much appreciated.
>>
>>
>> Keep up the great work,
>>
>> Nicola
>>
>
> Open a non-existing filename in Vim and then type:
>
>:verbose set term? termencoding? encoding? fileencoding? 
> fileencodings?
>:language ctype
>
> with of course  at the end of each line. What are the answers?
>
> Best regards,
> Tony.
> -- 
> -- 
>
> Hi Tony,
>
> thanks for the instructions. Here are the responses to those commands:
>
> :verbose set term? termencoding? encoding? fileencoding? fileencodings?
> term=xterm-256color
>   termencoding=
>   encoding=utf-16
> Last set from ~/.vimrc line 3
>   fileencoding=
>   fileencodings=ucs-bom,utf-8,default,latin1
> Last set from ~/.vimrc line 3
>
> :language ctype
> Current ctype language: "en_CA.UTF-8"
>
> Best regards,
> Nicola
>
> The problem is at line 3 of your vimrc, which sets 'encoding' to utf-16 
where utf-8 would be better. You might also want to set a default for 
'fileencoding' by means of
:setglobal fileencoding=utf8

Using :setglobal means that it will be used _only_ for new files, because 
for existing files the 'fileencodings' (plural) heuristics will try to 
determine the current encoding. If you want to create a UTF-16 file anyway, 
then ":setlocal fenc=utf-16 bomb" (without the quotes) will create it with 
a BOM so that when reopening it it will be detected as UTF-16 and not as 
Latin1 with about every other character being a NULL (Ctrl-@)

See at https://vim.fandom.com/wiki/Working_with_Unicode the recommended 
vimrc code and where to find details in the Vim help about the several 
options set by that code.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/723643dd-7bea-4bad-9764-ccb4e6f9b51co%40googlegroups.com.

Re: Character bracketing

[Tony Mechelynck]

On Saturday, October 17, 2020 at 11:49:25 AM UTC+2, Fameli, Nicola wrote:
>
> Hi there,
>
>
> something's up with my vi(m) editor in my mac pro Terminal app (Mac OS 
> Catalina) and it's driving me insane.
>
>
> It happens when I make a new file, say a python function in which I might 
> write from the command line:
>
> $vim function.py
>
> def function(variable):
>
>pass
>
> then I type :wq to save it and exit.
>
> Next time I open it I'll see each letter bracketed by ^@, as in:
>
> ^@d^@^@e^@^@f^@ ^@f^@^@u^@^@n... you get the idea.
>
>
> Interestingly, if I add text to an existing file, save it and close it, 
> the issue isn't there next time I open it. It seems to happen only when I 
> make a fresh file and with vim 8.1.2292 as well as 8.2.1719.
>
>
> Any help to solve this would be much appreciated.
>
>
> Keep up the great work,
>
> Nicola
>

Open a non-existing filename in Vim and then type:

   :verbose set term? termencoding? encoding? fileencoding? 
fileencodings?
   :language ctype

with of course  at the end of each line. What are the answers?

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/7d6b918d-3266-406e-9571-264c8a97a1f9o%40googlegroups.com.

Re: Folding in markdown files

[Tony Mechelynck]

On Saturday, January 11, 2020 at 2:41:06 AM UTC+1, Maral Watanabe wrote:
>
> Hi,
>
> I store all my notes in a vimwiki with markdown syntax. 
> These are the relevant settings from my .vimrc:
>
> let g:vimwiki_table_mappings=0
> let g:vimwiki_table_auto_fmt=0
> let g:vimwiki_folding='expr'
>
> let g:vimwiki_ext2syntax = {'.md': 'markdown', '.markdown': 'markdown', 
> '.mdown': 'markdown'}
> let g:vimwiki_list = [{'path': '~/Documents/vimwiki/', 'syntax': 
> 'markdown', 'ext': '.md'}, ... ]
>
>
> When I try to fold sections in a note I encounter a very strange behavior.
>
> Suppose this is the note document and the cursor is located at  
> and I am in normal mode (Screen_1):
>
> Title: Some Titel
>
> # Header
>
> some line
>
> ## Section
>
> section line
>
>
> When I press *zc* to close the folding I receive this error: *E490: No 
> Fold found.*
>
> Then I cycle through the opened tabs by typing *gt* until I am back in 
> the tab of the above note. Now the folding of the *Header* is closed, 
> i.e. the content of the tab is like this (Screen_2):
>
> Title: Some Titel
>
> # Header [7] 
> --
> ~
> ~
>
>
> Now I can open the folding of the *Header* with *zo* and close it with 
> *zc*. 
> But when I wait a few seconds without hitting any key while the buffer is 
> shown like in *Screen_2* 
> MacVim opens the entire folding of *Header,* i.e. it automatically 
> switches the buffer back to *Screen_1*.
> After that automatic expansion of the folding of *Header* MacVim forgets 
> the folding it has used before.
> Now, when I try to close the folding with *zo* I again receive the error  
> *E490: 
> No Fold found.*
>
> Is this a known issue of MacVim? Does anyone have an idea why this 
> behaviour occurs?
>
> By the way: At work I use gVim (with almost the same settings in my vimrc) 
> under Windows 10 and Ubuntu 16.04.
> In gVim I encounter no such issues when I use fold commanads like *zc* 
> and *zo*.
>
> My MacVim version is: *Custom Version 8.1.2234 (161)*
>
> Ciao
>
> Maral
>

I don't see these two plugins (filetype-pligins?) on my system. I hope 
someone else can help you.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/b8e4c728-b187-4f7f-b1c5-4efa8be69c30%40googlegroups.com.

Re: Folding in markdown files

[Tony Mechelynck]

On Saturday, January 11, 2020 at 2:41:06 AM UTC+1, Maral Watanabe wrote:
>
> Hi,
>
> I store all my notes in a vimwiki with markdown syntax. 
> These are the relevant settings from my .vimrc:
>
> let g:vimwiki_table_mappings=0
> let g:vimwiki_table_auto_fmt=0
> let g:vimwiki_folding='expr'
>
> let g:vimwiki_ext2syntax = {'.md': 'markdown', '.markdown': 'markdown', 
> '.mdown': 'markdown'}
> let g:vimwiki_list = [{'path': '~/Documents/vimwiki/', 'syntax': 
> 'markdown', 'ext': '.md'}, ... ]
>
>
> When I try to fold sections in a note I encounter a very strange behavior.
>
> Suppose this is the note document and the cursor is located at  
> and I am in normal mode (Screen_1):
>
> Title: Some Titel
>
> # Header
>
> some line
>
> ## Section
>
> section line
>
>
> When I press *zc* to close the folding I receive this error: *E490: No 
> Fold found.*
>
> Then I cycle through the opened tabs by typing *gt* until I am back in 
> the tab of the above note. Now the folding of the *Header* is closed, 
> i.e. the content of the tab is like this (Screen_2):
>
> Title: Some Titel
>
> # Header [7] 
> --
> ~
> ~
>
>
> Now I can open the folding of the *Header* with *zo* and close it with 
> *zc*. 
> But when I wait a few seconds without hitting any key while the buffer is 
> shown like in *Screen_2* 
> MacVim opens the entire folding of *Header,* i.e. it automatically 
> switches the buffer back to *Screen_1*.
> After that automatic expansion of the folding of *Header* MacVim forgets 
> the folding it has used before.
> Now, when I try to close the folding with *zo* I again receive the error  
> *E490: 
> No Fold found.*
>
> Is this a known issue of MacVim? Does anyone have an idea why this 
> behaviour occurs?
>
> By the way: At work I use gVim (with almost the same settings in my vimrc) 
> under Windows 10 and Ubuntu 16.04.
> In gVim I encounter no such issues when I use fold commanads like *zc* 
> and *zo*.
>
> My MacVim version is: *Custom Version 8.1.2234 (161)*
>
> Ciao
>
> Maral
>

I don't think this issue is peculiar to MacVim (though I could be 
mistaken); but it could be a bug in Vim 8.1.2234. Which version of gvim are 
you using at work? It can be seen from the top part of the output of the 
:version command, once you are running that gvim version. You can capture 
that output, for instance in the clipboard (see :help :redir — and the 
clipboard is register +). You don't need to answer with the full output of 
:version, the interesting part is the top part, up to and including the 
line which ends with "Features included (+) or not (-)", you can remove the 
part after that, after pasting and before sending.

If your gvim version is not 8.1.2234, you can see a one-line description of 
each Vim patch, for version 8.1 at http://ftp.vim.org/pub/vim/patches/8.1/ 
and for 8.2 at http://ftp.vim.org/pub/vim/patches/8.2/ ; I don't think the 
difference between the last patchlevel of 8.1 and version 8.2.0 is related 
to folding so if there is something relevant to your problem it should be 
listed on one of these two pages.

The latest Vim source as of this writing is 8.2.110; if your gmail version 
at work is later than your MacVim version, then maybe you can try and find 
a later MacVim?

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/40d35257-fe22-4e8b-857b-f33ce6e81a5d%40googlegroups.com.

Re: system copy with command-C without moving cursor

[Tony Mechelynck]

On Friday, November 8, 2019 at 5:51:31 PM UTC+1, Steve Molin wrote:
>
> Thank you for your reply, Tony. I didn't mean to imply that the mouse 
> doesn't work beautifully, it does and I'm constantly amazed by the power of 
> Vim.
>
> Having tinkered with this for a couple hours, and read what I can find in 
> the manual, I think the problem is that when 'set mouse=' there are two 
> different things that can be called the "selection": you can select using 
> the Vim commands (eg vw) or using the mouse (eg double-left-click). When 
> you hit command-C MacVim will copy the Vim-command-selection to the system 
> clipboard but not the mouse-selection (presumably the same with gvim and 
> control-C in Windows and X)
>
> I tried unmapping command-C, hoping that would let the system process it, 
> but MacVim still processes it (eg in insert, control-v command-c then 
> results in the text "")
>
> p.s. For completeness, I tested with no .vimrc with the same results.
>

Hm, it seems I'm out of my depth here, you'll probably need some Mac user 
to help you (I'm on Linux).

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/c0b497cb-8083-4afa-8fbe-149a9c324e91%40googlegroups.com.

Re: system copy with command-C without moving cursor

[Tony Mechelynck]

On Wednesday, November 6, 2019 at 11:32:09 PM UTC+1, Steve Molin wrote:
>
> I would like to use double-click to select a word and command-C to copy to 
> the system cut buffer (terminology?), which works fine as long as "set 
> mouse=a"
>
> But that has the side effect of moving the insert cursor position, which I 
> disable with "set mouse="
>
> Can I have both behaviors? Ie, double-click to select a work, command-C to 
> copy selection, without moving the cursor?
>
> I've ready extensively in the FAQ and other docs and I can't figure it out.
>
> Thanks!
>

The canonical way to put stuff into the clipboard or the cut-buffer in Vim 
is to "yank" (or "delete") into either register + or register *. Under X11 
(Unix, Linux, BeOS, etc.) these two registers are different, under Windows 
they are the same, under OSX I'm not sure. Register + (the "clipboard") is 
used in all GUIs (including gvim) for Edit→Copy, Edit→Paste and Edit→Cut. 
Register * (the "selection") is pasted by the middle mouse button.

The mouse works beautifully in gvim (or, I suppose, in the macvim GUI); 
when running Vim in a terminal it depends on the terminal. If the mouse 
doesn't do what you want you can always use the keyboard: for instance, to 
yank the current word into the clipboard from Insert mode it's Ctrl-O (or 
maybe Cmd-O on OSX, I'm not sure but I don't think so) followed by "+yaw 
(Ctrl-O for "do one Normal-mode command", quote-plus for "into the 
clipboard" and yaw for "yank a word). Once you get the hang of it you'll 
find out that the mouse is ideal to move the cursor to a random point in 
the text and that the keyboard is more efficient for almost everything else.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_mac/c8bceed2-ae21-42a7-b6ee-5a946f8fdca1%40googlegroups.com.

Re: Problem with the 'r' replace command and the US-Extended keyboard

[Tony Mechelynck]

P.S. Combining characters and precomposed characters can even be used together, 
as in the first syllable of the dactylic hexameter scansion of

Dǣdălŭs īntĕrĕā Krētēn lōngūmquĕ pĕrōsus
Ēxsĭlĭō tāctūsquĕ lŏcī nātālĭs ămōre…

where AFAIK there is no precomposed æ with caron.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with the 'r' replace command and the US-Extended keyboard

[Tony Mechelynck]

On Saturday, November 27, 2010 at 12:48:47 PM UTC+1, Andrew Gollan wrote:
> I had a quick look here to see if this was already discussed, but
> couldn't see anything.
> 
> I am using MacVim 7.3-53 (the stable release as best I can tell). I
> also use the US-Extended keyboard to enter a lot of vowels with
> macrons (opt-a + vowel). I also convert a lot of texts without the
> macrons to have them. (I am a Latin teacher).
> 
> When I use replace mode (the 'r' command) and then type the 'opt-a'
> all looks good, I get the free-floating macron, but then vim ignores
> the next letter completely: e.g. opt-a+i gives me just the macron not
> the 'i' with a macron. If I hit another 'i' then it goes into insert
> as you would expect.
> 
> This works properly in the vim 7.2 shipped by apple in /usr/bin, and I
> would have sworn that it worked in previous MacVim versions, but I
> can't be sure.
> 
> Can anyone point me at either what I doing wrong, or where I should
> report this as a bug?
> 
> Andrew Gollan
> quī loquitur Latīnē et linguam quoque docet.

I'm not on a Mac so I'm answering in general "Vim" terms. I see two ways to add 
a macron (or a breve) on a vowel with no special OS-related settings; this 
assumes that your 'encoding' is set to utf-8 and that 'fileencoding' (singular) 
for the file in question is either empty or some Unicode charset.

Method 1: Add a combining macron or breve.

This method does not remove the existing vowel but adds an additional accent 
which is displayed at the same place in the text. This "composing character" 
must be placed immediately after the "spacing character" for the vowel (place 
your cursor on the vowel in Normal mode, then hit a). In Insert mode, Ctrl-V u 
0304 (with no spaces in between) adds a combining macron to the letter 
immediately before the cursor, and Ctrl-V u 0306 adds a combining breve.

Method 2: Replace the vowel by a precomposed vowel-with-macron or 
vowel-with-breve

Method 2a: by making a keymap (Requires a Vim compiled with +keymap, se the 
output of ":version"). For such a low number of characters I don't recommend 
making a keymap but I have written a HowTo about keymaps at 
https://vim.wikia.com/wiki/How_to_make_a_keymap

Method 2b: By using digraphs (requires a Vim compiled with +digraphs, see the 
output of ":version").
The digraphs for precomposed vowel+macron and vowel+breve are already defined. 
(I think, however, that y-breve doesn't exist; but y is only used in Latin for 
transliteration of Greek names so maybe you can do without it). Use the 
following (with no spaces) when Vim expects you to type a character into the 
editfile:
Ctrl-K a - (the last of these is a minus sign) gives a+macron
Ctrl-K e - gives e+macron
etc.
Ctrl-K a ( gives a+breve
Ctrl-K e ( gives e+breve
etc.
Vim regards each of these Ctrl-Kxx combinations as one letter for e.g. the 
operand of the Normal-mode r command. They also work in Insert or Replace, and 
even Command-line, modes.

HTH,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is there an easy to remap alt key which is consistent with gvim on Windows and Linux?

[Tony Mechelynck]

On Friday, December 21, 2018 at 12:52:16 AM UTC+1, Kevin Gao wrote:
> Hello folks,
> 
> I would like to know: Is there an easy to remap alt key which is consistent 
> with gvim on Windows and Linux?
> 
> On Windows/Linux, 
> inoremap  :echo "??? "
> works.
> 
> But on MacVim, it does not work.
> 
> I check online: some one suggested this solution: 
> https://stackoverflow.com/questions/7501092/can-i-map-alt-key-in-vim (1st 
> solution).
> 
> The 1st solution is very bad to me, because it means I've to remap all alt 
> keys, only for MacVim, which is very tedious.
> 
> So is there an easy to remap alt key which is consistent with gvim on Windows 
> and Linux?
> 
> Thanks for your reply.

Some keys and key combinations are seen or not seen, or seen as different or as 
identical, different ways on different operating systems, indeed sometimes 
between gvim and Vim-in-Console on a single operating system.

The only way that I know of to use mappings consistently over all OSes, 
terminals and GUIs is to only use keys and key combinations which are seen, and 
seen as different, in all environments. This may require some trial and error 
but over the time I have come upon some rules of thumb:

- Printing keys are usually seen, and seen as different, everywhere, but most 
of those corresponding to an ASCII character, i.e. to something not higher than 
0x7F, are already in use by Vim and should not be remapped. If your keyboard 
(and keyboard driver) can consistently produce printing keys above 0x7F (mine 
has §éèçಳù£µ plus quite a number of AltGr combinations) then those keys are 
candidates for remapping in Normal mode but maybe not in Insert mode.
- F keys are usually seen. Shift-F keys are usually seen in gvim but might be 
confused with the corresponding unshifted F keys when running in a terminal. Of 
these, F1 is usually reserved for Help and F10 is often reserved for Menu. 
Ctrl-F keys are usually preempted on Linux by the X11 window manager and thus 
usually won't reach Vim or gvim on Linux, so they should be avoided if 
compatibility with Linux is important to you.
- Cursor keys are usually seen, but they have so useful default bindings that 
IMHO they should not be remapped.
- Alt+printable keys are often seen as no different than the same key with no 
Alt but with the keycode ORed with 0x80. Alt+non-printable keys may or may not 
be seen, and if seen they might be seen as the same combo with fewer modifiers.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Uganda visit report

[Tony Mechelynck]

On Fri, Aug 10, 2018 at 4:45 PM, Bram Moolenaar  wrote:
>
> Hello Vimmers,
>
> I have visited Vim's charity project in June. I finally had time to
> finish writing my report and organise the pictures.  You can find it
> here: http://www.iccf.nl/news.html
>
> It has links to the photo album and a short video.

Good news, on the average, though "not everyone can afford to boil
water" and "the solar [electricity] system is too expensive to fix"
distress me a little. I hope access to cooking heat will improve once
the new electric installation is approved and electricity from outside
(less expensive than running a generator) can be brought even to the
existing generator shed.

Two thousand pupils in one high school is quite a lot: I'm told the
one where I went in Brussels in 1961-1967 had (at the time) something
like one thousand, and it was not a small one; though I'm told
attendance has increased now that it is coeducational (in my time it
was a "boys only" school, except at both ends of the curriculum: in
kindergarten and in the "special math" class for students having
completed Latin-Greek humanities who wanted –or whose parents wanted
them– to enter some "scientific" university faculty) (The Head was at
that time a hellenist, which explains why Latin-Greek was regarded as
tops).

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RTL with combining characters... any progress?

[Tony Mechelynck]

On Friday, May 18, 2018 at 2:02:31 AM UTC+2, Ron Aaron wrote:
> Let me say up-front, I use MacVim all the time, and I really like it.  I love 
> it.  Until I have to write Hebrew.  Then I don't like it... and if I have to 
> edit Hebrew with combining characters (diacritics and cantillation marks) -- 
> I start to tear out my remaining strands of hair.
> 
> I see that I posted about this in 2009, so I was wondering if any progress 
> has been made since then?  Perhaps there are some options I should set, but I 
> tried the ones in the mac help file and there was nothing which changed the 
> experience for the better.
> 
> Thanks for any help...
> Ron

I think this question belongs in the vim_use group but the Google Groups web 
interface won't let me crosspost. Please send further inquiries there, unless 
they concern Mac-specific questions which do not apply to Vim for Windows or 
Linux.

I don't know Hebrew, but occationally I write short texts in vocalised Arabic 
(another RTL language with combining characters) and the result is not so 
bad... for a text editor with no knowledge of bidi text, and where every 
character has a fixed width.

Display using Vim in console mode in the mlterm terminal allows for bidi text, 
since in that case bidirectionality is handled by the terminal, not by Vim.

Under the 'maxcombine' option (q.v.), I see that "the default value, 2, should 
work with most languages, but Hebrew might require 4." Have you tried that? The 
maximum setting is 6. Also, that option is only used when 'encoding' is utf-8, 
see http://vim.wikia.com/wiki/Working_with_Unicode about how to set that 
without garbling your text. This is one case where UTF-8 is probably better 
than some national encoding such as ISO_8859-8.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding settings to .vimrc doesn't work

[Tony Mechelynck]

 On Thu, May 4, 2017 at 6:41 AM, Alla <vitale.a...@gmail.com> wrote:
>
>
> On 5/3/17 21:12, Tony Mechelynck wrote:
>>
>> On Wednesday, May 3, 2017 at 7:54:10 AM UTC+2, Yongwei Wu wrote:
>>>
>>> On 3 May 2017 at 13:11, Alla <vitale.a...@gmail.com> wrote:
>>>
>
> 
>>
>> Nowadays most teachers let lefties write with their right hand, they think
>> they have better things to learn than which hand to put the pen in. By
>> forcing yourself to use always hjkl and never ←↓↑→ you are figuratively (and
>> voluntarily) putting yourself into the position of one of these "forced
>> lefties" of 85 years ago. Good luck!
>
>
> I don't agree that this is a good comparison: being a left-handed person is
> a natural feature, while anything one does in Vim is a matter of acquiring a
> certain skill - mental and physical.

Well, in one case you acquire certain mental and physical skills with
Vim, in other cases you acquire mental and physical skills with a pen.
The only difference I see is that being left-handed is congenital,
possibly even innate, while preferring to use ←↓↑→ over hjkl is
acquired — you probably hadn't even met hjkl before you started using
Vim.

I still think — together with Yongwei Wu, another old-timer — that one
should not artificially restrict oneself not to use some particular
abilities of Vim. But, well, you want to learn to "write" with the
"hand" you don't feel most at ease with, it's your problem, go ahead.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding settings to .vimrc doesn't work

[Tony Mechelynck]

On Wednesday, May 3, 2017 at 8:12:40 PM UTC+2, Tony Mechelynck wrote:
> On Wednesday, May 3, 2017 at 7:54:10 AM UTC+2, Yongwei Wu wrote:
> > On 3 May 2017 at 13:11, Alla <vitale.a...@gmail.com> wrote:
> > > I see your point, and thank you for explaining this. As a beginner in
> > > programming
> > > I still can't decipher a good advice from a bad one. That one sounded
> > > reasonable for those who are just starting using Vim, and this could help
> > > them
> > > to develop a physical habit of avoiding "easy" conventional tools, which 
> > > are
> > > redundant and not useful in Vim.
> > 
> > Let me be more specific in this case. The arrow keys are designed to
> > help you navigate. No matter what Vim enthusiasts say, I do not
> > consider using arrow keys is a problem. You have to use arrow keys in
> > other application, so using them is not a bad habit. It is especially
> > the case in Insert Mode, as there are no alternatives.
> > 
> > > And no, I didn't start the new instance of Vim. I just did, and, yes, it
> > > works.
> > >
> > > Could you, please, share what types of changes/settings are reasonable
> > > to add to vimrc?
> > 
> > There are simply too many settings in Vim. I believe you can find a
> > lot of tutorials. It is process of continuous learning. And people
> > normally also have a lot of plugins, which may or may not be reflected
> > in their .vimrc files.
> > 
> > I have an old Linux .vimrc already on the web. Although it is a bit
> > outdated, my current .vimrc on Mac is evolved from that one. Maybe you
> > can consult that one first:
> > 
> > http://wyw.dcweb.cn/vim/.vimrc.html
> > 
> > It is commented, and you can do ":help keyword" for features you are
> > not familiar with.
> > 
> > A few more additions:
> > 
> > " The plugin package bundled with Vim 8 is useful, when you
> > " accidentally opening a file a second time.
> > if v:version >= 800
> >   packadd! editexisting
> > endif
> > 
> > " Vim 7+ has spelling check
> > if has('syntax')
> >   nmap:setlocal spell!
> >   imap   :setlocal spell!
> > endif
> > 
> > " Make syntax highlighting more accurate by synchronizing more lines
> > au BufReadPost *  syn sync minlines=1000
> > 
> > -- 
> > Yongwei Wu
> > URL: http://wyw.dcweb.cn/
> 
> I agree. In many cases there are several different ways to get a certain 
> result in Vim, and IMHO this is an advantage, not an inconvenient. Some Vim 
> users pefer to move with hjkl. Others prefer to use arrow keys. Still others 
> prefer to click the mouse where they want to go. Others use one or the other 
> of these different methods depending on circumstances. So what? If it works 
> for you, use it.
> 
> Let me take a comparison from a different field of experience: Most people 
> feel more at ease when writing with the right hand, but a significant 
> minority prefers to use the left hand, and a small minority can start with 
> the chalk in the left hand on the left side of the blackboard and end the 
> same line with the chalk in the right hand on the right side of the same 
> blackboard (or vice-versa if using RTL script like among others Hebrew or 
> Arabic. When my mother was in grade school (in the 1930s) all lefties were 
> forced to write with the right hand: so my mother ended up writing with the 
> right hand (because she was forced) and sewing with the left (because she 
> wasn't). When playing tennis some 50 years ago, she used to pass the racket 
> from one hand to the other, which upset her friends playing with her.
> 
> Nowadays most teachers let lefties write with their right hand, they think 
> they have better things to learn than which hand to put the pen in. By 
> forcing yourself to use always hjkl and never ←↓↑→ you are figuratively (and 
> voluntarily) putting yourself into the position of one of these "forced 
> lefties" of 85 years ago. Good luck!
> 
> Best regards,
> Tony.

Oops! Nowadays they let lefties write with their _left_ hand of course.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting Started

[Tony Mechelynck]

On Wednesday, March 22, 2017 at 1:54:56 AM UTC+1, Tony Mechelynck wrote:
> On Wednesday, March 22, 2017 at 1:49:16 AM UTC+1, Robert Koehler wrote:
> > Please assume there is an Idiots Guide for VIM. What would it filled with? 
> > I am completely new. All I know is how to access VIM through the terminal.
> 
> Simple: Install Vim on your system, then run the vimtutor program. It will 
> present you with a series of lessons (extremely well-written IMHO) about how 
> to use Vim.

P.S. There is also a gvimtutor but I don't know whether it can be used with 
macvim. (I think ir does, but I cannot check it because I'm not on a Mac.) If 
it can't, it shouls work with gvim for X11 but on a Mac this is much less 
practical.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting Started

[Tony Mechelynck]

On Wednesday, March 22, 2017 at 1:49:16 AM UTC+1, Robert Koehler wrote:
> Please assume there is an Idiots Guide for VIM. What would it filled with? I 
> am completely new. All I know is how to access VIM through the terminal.

Simple: Install Vim on your system, then run the vimtutor program. It will 
present you with a series of lessons (extremely well-written IMHO) about how to 
use Vim.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting started with vim: is MacVim == Gvim?

[Tony Mechelynck]

On Monday, March 13, 2017 at 7:01:05 AM UTC+1, vitale.a...@gmail.com wrote:
> Hello!
> 
> I am new to Vim (and only learning programming), and will be grateful
> for your help.
>  I am on Mac OS El Capitan 10.11.6. 
> Recently I have been advised to start using Gvim, but upon
> visiting vim.org and trying to decipher information published
> there in Download tab, I deduced the Gvim is used only for 
> Windows, while Macs can use only MacVim. 
> 
> Questions:
> (1) is it correct that Gvim is used only for Windows, and 
> on Mac I can use only MacVim?
> 
> (2) is MacVim the same as Gvim, i.e. does it have same 
> features?
> 
> (3) I have checked my version of Vim installed on my 
> computer (I wonder if it came with El Capitan, looks like
> it, because I don't recall installing it myself), and if I understood
> correctly it doesn't have GUI features. I assume Gvim is the 
> same as Vim but with GUI, correct? 
> If yes, how can I add GUI, or shall I install MacVim from scratch?
> 
> Here is what I see in my Terminal:
> 
> vim --version
> VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 14 2016 16:06:49)
> Compiled by r...@apple.com
> Normal version without GUI.  Features included (+) or not (-):
> -arabic +autocmd -balloon_eval -browse +builtin_terms +byte_offset +cindent 
> -clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
> -conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs 
> -dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path 
> +find_in_path +float +folding -footer +fork() -gettext -hangul_input +iconv 
> +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent 
> +listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape 
> -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse 
> +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype 
> +path_extra -perl +persistent_undo +postscript +printer -profile +python/dyn 
> -python3 +quickfix +reltime -rightleft +ruby/dyn +scrollbind +signs 
> +smartindent -sniff +startuptime +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
>  -xterm_clipboard -xterm_save 
>system vimrc file: "$VIM/vimrc"
>  user vimrc file: "$HOME/.vimrc"
>   user exrc file: "$HOME/.exrc"
>   fall-back for $VIM: "/usr/share/vim"
> Compilation: gcc -c -I. -D_FORTIFY_SOURCE=0 -Iproto -DHAVE_CONFIG_H -arch 
> i386 -arch x86_64 -g -Os -pipe
> Linking: gcc -arch i386 -arch x86_64 -o vim -lncurses
> 
> Thank you!

It is in part a question of point of view. One might say that MacVim is a "gvim 
flavour" for the MacOSX Cocoa GUI. When someone says "Try using gvim rather 
than Console Vim" he usually means "the Vim GUI rather than Vim running in a 
terminal", and in that sense, "gvim" includes MacVim.

OTOH, with only Bram's official sources and not the additional MacVim modules, 
it is possible to compile a gvim which will run on a Mac, but only in the X11 
GUI. This is for instance what is meant if someone says "On the Mac, you will 
probably use MacVim in preference to gvim" (i.e. to gvim for X11).

What you see in your terminal is a console-only Vim, which is neither MacVim 
nor gvim for X11, and can only run within a terminal. This is what is meant by 
"without GUI" in "Normal version without GUI" near the top.

Oh, and about your first question, Gvim is not "only for Windows". On Windows, 
gvim and Console Vim must be different executables, but on Linux it is possible 
to compile a single "GUI-enabled" executable which will run as a GUI when 
invoked as gvim, and in a terminal when invoked as vim. On the Mac, as I said 
before, MacVim can be regarded as a "gvim for Cocoa" and when helpfiles or list 
posts targeting any OS and not specifically the Mac talk of gvim, MacVim is 
usually included.


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim 8 pre-announcement

[Tony Mechelynck]

On Tue, Aug 16, 2016 at 6:43 PM, Bram Moolenaar  wrote:
>
> Hello Vim users,
>
> Work on Vim 8.0 is coming close to an end.  I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible.  Once 8.0 is out we can't make changes that would
> break plugins.
>
> An overview of new features can be found in:
> https://github.com/vim/vim/blob/master/runtime/doc/version8.txt

IIUC, ":help version8.txt" in the latest (today's) runtime files gives
the same as the above, with the usual Vim hotlinks: double-click a
help tag, or put the cursor on it and hit Ctrl-]

The current version8.txt is dated 2016 Aug 16 at the end of its first line.

> A version with links (but a day older):
> http://vimhelp.appspot.com/version8.txt.html
>
> Please review the new features, try them out and report what should be
> changed on the vim-dev maillist.  Of course you should also report bugs
> you find.
>
> Happy Vimming!
>
>
> PS. If you are interested in meeting Vim users: Vimfest is happening in
> Berlin Sept. 16-18.  http://vimfest.org
>
>
> --
> How To Keep A Healthy Level Of Insanity:
> 9. As often as possible, skip rather than walk.
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org///
>
Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: gvim and ASCII glyphs

[Tony Mechelynck]

On Thu, Aug 11, 2016 at 1:39 AM, manuelschiller.pimail via vim_dev
<vim_...@googlegroups.com> wrote:
> On Wednesday, 10 August 2016 02:35:04 UTC+2, Tony Mechelynck  wrote:
>> Manuel:
>>
>> In the past there have been "unofficial" features published as patches
>> which remained outside of the "official" Vim repositories but publicly
>> available, sometimes for years, before Bram finally decided to take
>> them in. The +conceal and +float features, now part of mainstream Vim,
>> are two examples of such which I've seen remain "unofficial
>> third-party patches" while several successive minor versions of Vim
>> came and went.
>>
>> Maybe you could publish your patch (as a patch that could be applied
>> by running "patch -p1 ligatures.diff", or something like that, at the
>> top level of a Vim repository clone), upload it somewhere on github or
>> vim.org or wherever, and let anyone use it who wants. Then after
>> letting it bake there for some time, we'll know better how popular it
>> is. Assuming that the new version currently being made ready will be
>> called Vim 8.0 and be released before the end of 2016, we might then
>> have a poll about your patch when getting ready for 8.1 or 8.2, and
>> let's hope that that will arrive long before 8.0 is at patchlevel
>> 8.0.2200 — Vim 7.4, whose original release was almost exactly three
>> years ago, seems to have been quite successful in its own way.
>>
>> If you choose to go this way, please set it up so that it could be
>> disabled at compile-time (I mean, place the changes  behind #ifdef
>> FEAT_LIGATURES or something equally distinctive), it will help it
>> being accepted into the main code, since anyone not wanting it would
>> be able to disable it at compile-time — and similarly, an option (to
>> enable or disable it at runtime if present at compile-time, let's say
>> in the vimrc or gvimrc before starting the GUI) would IMHO be equally
>> welcome.
>>
>>
>> Best regards,
>> Tony.
>
> Hi Tony,
>
> you (and others) are making very good points here, and I appreciate the
> feedback.
>
> Following your suggestion, I have created a vim fork with a branch for
> this kind of development:
>
> https://github.com/manuelschiller/vim/tree/glyphs
>
> Currently, it contains two patches:
>
> - gui_gtk_x11: force shaping one character at a time for ASCII glyph cache
>
>   This one does what it says. It'll get fonts like PragmataPro or Hasklig
>   working in gvim without ligatures, and without the drawing caveats we
>   discussed earlier. I imagine that this patch might make inclusion in vim
>   quite a bit earlier (I'd hope soonish, but that may be wishful thinking)
>   than the next item, because I do not think it does anything controversial.
>   If you'd like to see style improvements etc., please let me know, I'm
>   happy to accomodate you. :)
>
> - gui_gtk_x11: enable poor man's ligatures
>
>   This one is the bit that enables ligatures, and will require a couple of
>   iterations on my side before it's ready to be considered for inclusion.
>   (For example, I'd like to make the set of characters that disable the
>   ASCII glyph cache user-configurable, and I have to find out how C code
>   gets access to variables inside vimscript...) For the curious, this is
>   something they might want to try out, and give feedback...
>
> I would again like to thank you all for the friendly and constructive
> atmosphere. And let me know if you have suggestions, please!
>
> Manuel

Hm. gui_gtk_x11.c is of course only for gvim with GTK GUI running on
Linux-X11. GTK2, and now even GTK3 ("new in 8.0"), are of course the
preferred GUIs for Vim on Linux these days, and for X11 in general
(though a few older ones are still supported IIUC); however, what
about other flavors of gvim? Such as gvim for Windows, and, maybe
worse, MacVim (gvim for Mac-Cocoa IIUC), of which I think, but am not
sure, that all its sources are included in the current "official" Vim
sources. Do Windows and/or Mac have similar fonts? Won't they feel
left out? The mechanisms to implement the corresponding Poor Man's
Ligatures will of necessity be different because we're at too low a
level for cross-platform programming to be possible all the way. Maybe
you don't have the necessary OSes to build and test the corresponding
gvim versions (neither do I) so it might perhaps be useful if some
Windows Vim developer(s) and some Mac Vim developer(s) joined you on
this project.

I'm cross-posting on the vim_mac group because Mac people might (or
might not) be interested; but this thread was started on vim_dev. Mac
developers: please refer to vim_dev f

Re: Combining accents in MacVim

[Tony Mechelynck]

On Tuesday, August 9, 2016 at 6:50:52 PM UTC+2, Nicola wrote:
> On 2016-08-06 11:10:38 +0000, Tony Mechelynck said:
> 
> > On Monday, June 27, 2016 at 9:37:42 AM UTC+2, Nicola wrote:
> >> Hi,
> >> sorry if this has been reported already (I could not find any information).
> >> 
> >> Combining accents are not rendered correctly in MacVim, no matter
> >> whether "Draw marked text inline" is checked or not. Try, for example,
> >> ė̃ (U+0303 with U+0117). Such combinations are displayed correctly in
> >> terminal Vim (both in Terminal.app and iTerm2) using the same fonts (I
> >> have tried with Menlo, Consolas, and SF Mono).
> >> 
> >> Using MacVim 7.4 (104), patch 1-1941, compiled by Homebrew.
> >> 
> >> Nicola
> > 
> > No reply, it seems.
> > 
> > On Linux, I have noticed that some fonts place combining characters 
> > correctly while others don't. For instance in FreeMono (and FreeSans 
> > and FreeSerif in the browser) the combining accents are correctly 
> > placed. In some other fonts (I forget which) they aren't.
> 
> I do not think that it is a font problem. I have tried with lots of 
> fonts (including FreeMono) and the behaviour is the same: using Core 
> Text Renderer, the height of diacritical marks does not adapt to the 
> height of the associated glyph.
> 
> Btw, is this the right place to report issues or should I use GitHub?
> 
> Nicola

If this is a mac-only issue, as it seems to be, this is the proper place.

For issues concerning all versions of Vim whether or not running on a Mac, 
there are also the vim_use Google group for questions about general use, for 
instance "How do I get syntax highlighting even on very long lines" or "what is 
the difference between vimrc and gvimrc? (both of these are answered in the 
help), and the vim_dev Google Group for "development" issues including bug 
reports, crash reports, requests for enhancements, etc.

GitHub issues are reflected on the vim_dev group.


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Combining accents in MacVim

[Tony Mechelynck]

On Monday, June 27, 2016 at 9:37:42 AM UTC+2, Nicola wrote:
> Hi,
> sorry if this has been reported already (I could not find any information).
> 
> Combining accents are not rendered correctly in MacVim, no matter 
> whether "Draw marked text inline" is checked or not. Try, for example, 
> ė̃ (U+0303 with U+0117). Such combinations are displayed correctly in 
> terminal Vim (both in Terminal.app and iTerm2) using the same fonts (I 
> have tried with Menlo, Consolas, and SF Mono).
> 
> Using MacVim 7.4 (104), patch 1-1941, compiled by Homebrew.
> 
> Nicola

No reply, it seems.

On Linux, I have noticed that some fonts place combining characters correctly 
while others don't. For instance in FreeMono (and FreeSans and FreeSerif in the 
browser) the combining accents are correctly placed. In some other fonts (I 
forget which) they aren't.


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: colorschemes are all slightly off

[Tony Mechelynck]

On Friday, February 12, 2016 at 3:09:37 AM UTC+1, kevin olson wrote:
> I have done a ton of research on making my .vimrc perfect and I am still 
> getting slightly off-color differences, here is an example of the gruvbox 
> colorscheme in MacVim compared to VIM in iterm2:
> 
> 
> Above is VIM using the proper blue () where as MacVim does not inherit that 
> color

The Vim GUI (gvim or MacVim) and Console Vim normally don't inherit colors from 
each other (but see the wiki page linked below). Colors for the GUI are set in 
the range from #00 (black) to #FF (white) as RRGGBB settings for a 
total of 2^24 different shades; this uses the guifg= and guibg= settings in the 
:hi ex-command. Colors for Console Vim are set in the range from 0 to (_Co - 
1), usually 0 to 7 or 0 to 15, by the ctermfg= and ctermbg= arguments.

"VIM using the proper blue () where as MacVim does not inherit that color", you 
say. Or is it the opposite? Most terminal emulators can't display more than 256 
different colors, which means that unless you're using a "safe" #RRGGBB color 
the result will be slightly off. Safe colors are defined as colors where the 
red, green and blue values are each a multiple of 0x33, plus a number of shades 
of grey about which I don't know the details (multiples of 0x33 means hex 00, 
33, 66, 99, CC and FF, or six values; 6x6x6 for the three components makes 216, 
plus 16 for the "conventional" 16-color palette leaves room for 24 additional 
shades of grey).

See http://vim.wikia.com/wiki/Using_GUI_color_settings_in_a_terminal for 
details.


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How do I: Open file in same window (new tab) and GOTO line?

[Tony Mechelynck]

I assume that by “window” you mean “Vim instance”, since in Vim parlance there 
may be one or more (plit) windows within a tab but not the opposite. There are 
also one or more tabs (or tab pages) in one “Vim screen” (or Vim instance) but 
not the opposite.

I don't run a Mac, but in general to start Vim with three tab pages, one file 
in each, you would invoke it as

vim -p file1.ext file2.ext file3.ext

This should work with any "vim flavour" such as vim, gvim, MacVim, etc. You may 
want to vary it according to the peculiarities of MacOsX.

See ":help -p"

To open the file at a specific line, I expect that prefixing the filename with 
+123 (for line 123), followed by a space, should work, but I haven't yet tested 
it: so to open several files, each in its tab, and each at a specific line, you 
could do

vim -p +123 file1.ext +456 file2.txt +789 file3.txt

but I haven't tested it.

See ":help +cmd"

In general, if you set the 'viminfo' option correctly, Vim will remember where 
the cursor was in a given file when it was last used, and with the proper 
autocommand (as in $VIMRUNTIME/vimrc.example.vim lines 73-79, so if you source 
that from your vimrc you've got it) the file will be reopened at that same 
position (or at line 1 if no position was remembered for the file).

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: supplementary character rendering problem, gvim with MacVim 7.4(87)

[Tony Mechelynck]

On Friday, December 25, 2015 at 8:34:20 AM UTC+1, Kenneth R. Beesley wrote:
[...]
> I don’t think that the “temporay Deseret Range” is relevant here.  My glyphs 
> are in the official Deseret Range, 
> and always have been, in a
> monospace font that used to work, but now the glyphs get rendered as if they 
> had a space after them.  (There
> is no space in the buffer, unless you actually enter a space.  It just 
> appears to be a rendering problem for any
> glyph with a supplementary code point value.)  And it’s not just Deseret 
> characters; I see the same broken 
> behavior for rendering Shavian characters, which are also in the 
> supplementary area.
> 
>  
> 
> > 
> > I still use the Bitstream Vera Sand Mono font and I have no problems with 
> > it; however I don't use it for Deseret, only Latin, Cyrillic, and more 
> > rarely Greek and Arabic. I tried switching to FreeMono but strangely enough 
> > Vim is the only application which misplaces that font's composing 
> > characters so I've come back.
> 
> The issue seems to be tied to the rendering of characters from the 
> supplementary area.  So you won’t see it with Latin,
> Cyrillic, Greek or Arabic characters, which are all in the BMP.  Using 
> something like Fontforge, try copying a glyph to the supplementary
> area of your font of choice (at some code point value ) and then 
> entering it in a gvim buffer using Ctrl-V U
> See how it’s rendered.

Rather than construct a character of my own, I entered existing characters from 
the "Deseret" range (10400-1044F) and from the "Coptic Epact Numbers" range 
(102E0-102FF). Most of these codepoints have no glyph in my Bistream Vera Sans 
Mono font, so I get a "fallback glyph" whic is just the codepoint number in 
octal, and seems to cover to screen cells, but here the cursor moves onkly by 
one cell per character. In particular, the glyph for U+10400 DESERET CAPITAL 
LETTER LONG I is defined, and when I put it between two dashes it has no empty 
call on either side.

However I am on Linux, so I suppose that your problem lies with the rendering 
engin used on the Mac rather than with Vim's mostly cross-platform logic.

(Even though I'm on Linux, I still occasionally watch the vim_mac group, in 
order (among others) to catch (or even detect) problems which might be 
cross-platform and redirect them to the vim_use and vim_mac groups. In this 
case you seem to have found a genuinely "Mac-only" problem so I don't think 
I'll say much more on this thread.


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: supplementary character rendering problem, gvim with MacVim 7.4(87)

[Tony Mechelynck]

On Monday, December 21, 2015 at 2:50:01 AM UTC+1, Kenneth R. Beesley wrote:
> Problem:  supplementary character rendering problem, MacVim 7.4(87)
> 
> MacVim is running for me (gvim flavor), but supplementary characters look 
> like they are displayed double-width.
> These same supplementary characters, from the same (mono) font, used to work. 
>  Something has changed,
> and I haven’t quite tracked it down.  Any help would be much appreciated.
> 
> Background:   Running OS X Yosemite 10.10.5
>   MacVim 7.4(87) installed in /Applications/MacVim.app
> 
>   Running gvim
>   ‘which gvim’ returns ~/bin/gvim
>   which is just a pointer to ~/bin/mvim, which 
> was supplied along with MacVim.app
> 
>   Invoking ‘gvim’ from the command line does indeed 
> launch MacVim Custom Version 7.4(87)
> 
>   My ~/.gvimrc file does get run, and includes the command
>   set anti guifont=BrighamVu\ Sans\ Mono:h12
> 
>   This font does get selected (I checked with ‘:set 
> guifont’  inside MacVim)
>   Normal editing using 16-bit characters from the Basic 
> Multilingual Plane works as expected.
> 
> The BrighamVuSansMono.ttf font resides in my ~/Library/Fonts/.  It is the 
> DejaVu_Sans_Mono.ttf
> font that I augmented with Deseret Alphabet glyphs from the range U+10400 — 
> U+1044F.
> I.e. I added new glyphs in the supplementary area.
> 
> This font has worked for me for a long time.  But now something has changed.  
> Perhaps my fault, but I’m stumped.
> 
> Behavior:
> Now when I enter a character from the Deseret Alphabet range, it gets 
> rendered on the gvim page as if it were double width.
> I.e. the Deseret glyphs from the modified font get rendered on the screen, 
> but it _looks_ like there is a space between the characters.
> But there is no space (unless a space is actually typed).  Advancing the 
> pointer, using the usual l (l.c. L) command in command
> mode progresses from one Deseret character to the next, and the correct 
> supplementary code point value is displayed on the bottom
> line for each character.
> 
> It’s just the _display_ of the supplementary characters that is the problem.  
> Each Deseret (supplementary) character glyph
> looks like it has a space after it.
> 
> A similar problem occurred when I first upgraded from 7.3 to 7.4, and it was 
> solved by opening
> MacVim > Preferences > Advanced 
> and UNticking “Use Core Text renderer” (Thanks Bjorn)
> 
> This option is still unticked.  (Ticking it doesn’t help.)
> 
> I’m stuck.  Any help would be appreciated.
> 
> Thanks,
> 
> Ken

If this means version 7.4.087 of the underlying Vim code, then it is just over 
a year old (11/11/2013) and in that time many water has gone under the bridge: 
the current patchlevel is 7.4.979. You can check it by running ":version" 
(without the quotes of course), mone says:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 19 2015 17:08:28)
Included patches: 1-979

as its first two lines. ("Included patches: 1-979" means it's 979 patchlevels 
"higher" than the first "stable" 7.4 release.) So the first action I would 
recommend would be to install the most recent MacVim you can find.

This said, the ranf U+10400-U+1044F is the official Deseret range (see 
http://www.unicode.org/Public/8.0.0/ucd/Blocks.txt and search for what to Vim 
would be the pattern /^10400\./), but before it was adopted there used to be a 
"temporary Deseret range" in one of the UserCode Areas.
See also http://www.unicode.org/charts/PDF/U10400.pdf for a look at what these 
characters look lite.

I still use the Bitstream Vera Sand Mono font and I have no problems with it; 
however I don't use it for Deseret, only Latin, Cyrillic, and more rarely Greek 
and Arabic. I tried switching to FreeMono but strangely enough Vim is the only 
application which misplaces that font's composing characters so I've come back.

The Unicode ranges are periodically updated, but only by addition and IIUC the 
Vim code is periodically updated so it can use the proper values for 
singlewidth/doublewidth, for what is the canonical case conjugate of what, what 
is a printing character and what is as yet unassigned, etc.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim] Include a .desktop file (#454)

[Tony Mechelynck]

Note: My HD crashed this summer, so I lost my address book. I added Steve
Hall's address from memory but I'm not sure it is his current address. If
he has a newer address, please let him and me know.

On Sun, Oct 18, 2015 at 5:25 PM, Thomas G. 
wrote:

> Hey,
>
> Is it possible to add to the repository a .desktop file for vim and gvim
> similar to the gvim.desktop
> 
> file packaged by archlinux. For the vim.desktop one would obviously have
> to set Terminal=true.
>
> I can open a pull request if this makes it any easier.
>
> Best regards,
> Thomas
>
You mean, a desktop icon to launch Console Vim and one to launch gvim? IIUC
that should be done at install time (by "make install" on Linux), and on
Windows the different desktop icon used by Windows should be installed. I
don't know if the current Windows installers (Steve Hall's and Bram's)
already do this but I do know that on Windows the desktop launch icons are
not called *.desktop

On the Mac I don't know what is used, or if MacVim already does it.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Mapping alt+arrow keys?

[Tony Mechelynck]

I'm redirecting this conversation to vim_use which I think is more appropriate 
than vim_mac in this case.

On Wednesday, October 7, 2015 at 2:02:30 AM UTC+2, Shaun Friedle wrote:
> Hi,
> 
> I'm having difficultly mapping alt + the arrow keys at startup in MacVim.
> 
> So, I have this in my .vimrc in order to move between windows:
> 
> map  :wincmd k
> map  :wincmd j
> map  :wincmd h
> map  :wincmd l
> 
> But this doesn't work in MacVim at startup, alt+left/right navigate to 
> previous/next word and alt+up/down seem to navigate to previous/next 
> paragraph. It does work if I do:
> 
> :source ~/.vimrc
> 
> So somehow if my execute my vimrc after MacVim has started then the mapping 
> works correctly. Everything else in my vimrc works normally without having to 
> manually source it including other key mappings. I've also tried deleting 
> everything else in my vimrc except those 4 lines and it still doesn't work. 
> If I change the maps to:
> 
> map  :wincmd k
> map  :wincmd j
> map  :wincmd h
> map  :wincmd l
> 
> Then it works correctly at MacVim startup, but I don't want to have to hold 
> both ctrl+alt. Only keybindings with alt alone don't work.
> 
> I've tried playing with the macmeta setting, it doesn't make any difference. 
> I shouldn't need macmeta anyway according to the help page:
> 
>   Note: Some keys (e.g. , , , ) can be
>   bound with the Meta flag even when this option is disabled, but this
>   is not the case for the majority of keys (e.g. , ).
> 
> I'm kind of stumped at this point. Any help is appreciated.
> 
> Thanks,
> Shaun

If you don't want to hold both Ctrl and Alt, well, choose some other {lhs}. 
Here is an example, but it is thertainly not the only possibility:

:map  h
:map  j
:map  k
:map  l

Or if Ctrl-W is easy for you to type, just use it instead of :wincmd, that's a 
built-in key binding (in Vim compiled with +windows, of course), no mapping 
needed.

See :help :wincmd

What I use is, navigate to the next or previous window rather than 
geographically, as follows:
" move to next window with F11, previous window with Shift-F11
" These will accept a count (in Normal mode at least)
" to go to Nth window from top, not Nth previous or next window
:map  w
:map  W
:map!  w
:map!  W


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_mac" 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Speeding up cold startup

[Tony Mechelynck]

On Wednesday, December 11, 2013 7:42:43 AM UTC+1, Kevin Burke wrote:
 So I used binary search to track down the issue and narrowed it to this line 
 in my vimrc:
 
 
 
 set rtp+=$GOROOT/misc/vim
 
 
 
 If $GOROOT is not set, vim gets very slow (for me 'Starting GUI' takes about 
 5.5 seconds). Otherwise macvim boots in about half a second, which isn't 
 great, but is fast enough for me.
 
 
 
 I can produce more info if it'll be useful for debugging but you'll have to 
 show me how.

Try

if $GOROOT != 
set rtp+=$GOROOT/misc/vim
endif

Or else, use the standard directories ($HOME/.vim and $HOME/.vim/after for 
user-private scripts, $VIM/vimfiles and $VIM/vimfiles/after for system-wide 
scripts not distributed with Vim, and $VIMRUNTIME — at the moment, normally 
$VIM/vim74 — for ONLY the files that come with Vim). These are the 
'runtimepath' default. On Unix-like OSes, $VIM is usually /usr/local/share/vim 
but it may vary a little from one installation to the next; one factor may be 
whether you compiled Vim yourself or got it from the same source as your OS.

One way to have it both ways if you don't need _different_ scripts in 
$GOROOT/misc/vim and $HOME/.vim is to symlink the latter to the former on 
installations where $GOROOT is defined.

Best regards,
Tony.
-- 
The devout are always urged to seek the absolute
 truth with their hearts and not their minds.
  [Eric Hoffer, The True Believer]

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how to copy into system clipboard

[Tony Mechelynck]

On Wednesday, November 20, 2013 6:44:11 PM UTC+1, Bee wrote:
 On Wednesday, November 20, 2013 12:43:22 AM UTC-8, LittleQ wrote:
 
  it should be ‘single quote’, so it’s  ‘, ‘ not  `, `
 
 
 
 I know ' works for lines, but my attempt to use ` is to select a character 
 range.
 
 
 
 :help `
 
 ' `  To the first line or character of the last selected Visual area in the 
 current buffer.
 
 
 
 Is there a way to write the CHARACTER selection to stdout? for use by pbcopy
 
 
 
 Bill

Ex-commands always act linewise on the range of lines you type between the : 
and the command name (or before the command name in a script).

To act on a visual selection you could type +y in Visual mode, but using 
:normal would defeat this because hitting : in Visual mode goes out of Visual 
and places you in command-line mode with :',' before the cursor, so that the 
ex-command you're about to type will act linewise on the just unselected Visual 
selection. You can act characterwise on an object or a motion by including the 
object or motion command after +y in the operand of :normal, e.g.:

:normal +yW

will yank to the clipboard (i.e. copy) the WORD at the cursor with no 
surrounding space. (Similarly, just :normal yW would yank it to the unnamed 
register.) Then you would have to find out how to put that out to your pbcopy 
command. One possibility (in a script) would be

normal yW
$put
$,$w !pbcopy
$del

remembering that the $put command will add the register linewise after the last 
line (thus creating a new line) so the $ line number in the last two commands 
above will be one more than in the $put command. I haven't checked where the 
cursor ends up at the end of this snippet.

The above snippet is valid because a WORD will never span more than one line. 
How to make it work for a multi-line characterwise yank is left as an exercise 
to the reader. (Hint: see help line() and :help :execute)

Best regards,
Tony.
-- 
As a general rule of thumb, never trust anybody who's been in therapy
for more than 15 percent of their life span.  The words I am sorry and I
am wrong will have totally disappeared from their vocabulary.  They will stab
you, shoot you, break things in your apartment, say horrible things to your
friends and family, and then justify this abhorrent behavior by saying:
Sure, I put your dog in the microwave.  But I feel *better* for doing it.
-- Bruce Feirstein, Nice Guys Sleep Alone

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Utf-8 in terminal.app

[Tony Mechelynck]

On Wednesday, November 13, 2013 9:15:33 AM UTC+1, LuKreme wrote:
 I use vim in terminal.app all the time, but I cannot seem to get the right 
 combination of settings to be able to enter UTF-8 text. If I am trying to 
 enter “ I will get a å93 or something. Similar to that instead.
 
 
 
 Terminal.app can display UTF-8 just fine, so I don't think it is terminal.app 
 language setting that is the issue.
 
 
 
 (This is not using vim via the GUI)
 
 
 
 -- 
 
 Sign sign sign, everywhere a sign

http://vim.wikia.com/wiki/Working_with_Unicode might help you.

Best regards,
Tony.
-- 
We don't do a new version to fix bugs. - Bill Gates
The new version - it's not there to fix bugs. - Bill Gates
-- Retranslated from Focus 43/1995, pp. 206-212

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: make URLs clickable

[Tony Mechelynck]

On Friday, November 1, 2013 9:29:03 PM UTC+1, Albert Zeyer wrote:
 Hi,
 
 I want to be able to click on URLs I see in MacVim so that it opens the URL 
 with the responsible application (e.g. a http link with my default browser). 
 How can I do that? Is that possible?
 
 Regards,
 Albert

A valid URL cannot include spaces (they must be replaced by %20), so if it is 
itself between spaces, +yiW (with the cursor anywhere on it) will yank it to 
the clipboard. Similarly +yi or +yi if it is between , etc., see :help 
object-motions. Then you can paste it into your favourite browser's URL bar.

This question (or at least this answer) applies to vim (compiled with 
+clipboard, of course) on any platform, not just on the Mac, so it should have 
been asked on the vim_use group.

Best regards,
Tony.
-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Gandhi

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: wildignore and opening files

[Tony Mechelynck]

On Saturday, October 26, 2013 12:15:46 PM UTC+2, Martin Finke wrote:
 Setting wildignore seems to make it impossible to open ignored files at 
 all...for example, let's say we're ignoring the pattern: *.min.js because 
 we don't want minified files to turn up in searches and when using :e. With 
 this pattern ignored, it's not possible to open a file like jquery.min.js, 
 even when double-clicking in Finder or dragging the file onto the MacVim 
 window. It will just show an error E479: No match.
 Is there a way to solve this?

'wildignore' ignores files matching the pattern when using |wildcards| in 
Ex-commands that take a filename, or in expand(), glob() and globpath(). You 
can always open the file by typing its full name without wildcards, e.g.

:e jquery.min.js

or by clicking it (or hitting o) in a netrw window (after editing a 
directory).


Best regards,
Tony.
-- 
signal(i, SIG_DFL); /* crunch, crunch, crunch */
-- Larry Wall in doarg.c from the perl source code

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Mac resume feature

[Tony Mechelynck]

On Friday, October 25, 2013 8:39:40 PM UTC+2, björn wrote:
 On Thu, Oct 24, 2013 at 5:35 PM,  wrote:
 
  On Wed, Oct 23, 2013 at 08:49:03AM -0700, Penn Su wrote:
 
  In Mac since Lion I believe, they introduced the resume feature that would 
  let apps to resume the windows, and the unsaved documents state before 
  quitting. I wish macvim could also implement this feature so that whatever 
  windows or buffers, tabs that I have opened in macvim could be resume if I 
  accidentally quit the app.
 
 
 
  This has been requested before.  That functionality can be mimicked from 
  within vim by using various options and perhaps autocommands for some 
  special occasions.  Start by looking at :help autowriteall, which should 
  do what you want for the case of accidental closure.  For automatic 
  reopening of windows, look at :h sessions, which would almost certainly 
  work much better wrt to Vim than Apple's version anyway.
 
 
 
  I sure hope the Apple implementation of this doesn't get put into MacVim.
 
 
 
 Yeah, I think the consensus was that Apple's implementation is
 
 inferior in the case of Vim.
 
 
 
 That being said.  Configuring Vim to autosave documents probably
 
 requires a PhD in Vim script, whereas the resume feature in other apps
 
 is automatic.  It would be nice to have something in MacVim that was
 
 as easy to use.
 
 
 
 Björn

You could use

:au VimLeave mks!

then create a desktop shortcut to start Vim with the -S switch, which hardly 
requires a PhD in Vim scripting. It does assume that your Vim executable has 
been compiled with +autocmd and +mksession. The only problem AFAIK would be 
which value to set for 'sessionoptions' (q.v.) to get all you need and avoid 
unneeded duplication of code with, for instance, your vimrc.

Or if (like me) you want to start Vim almost every time with the same files in 
the same windows and tabs, you could write a session script manually, with 
whatever ex-commands you would like to see Vim run after sourcing your vimrc, 
in order to load your usual session, bypassing :mksession entirely. The 
reason you might want to keep these commands out of your vimrc would ve so that 
you could run Vim from time to time with no saved session.

See
:help :version
:help VimLeave
:help :mksession
:help -S
:help 21.4
:help views-sessions
:help 'sessionoptions'

Best regards,
Tony.
-- 
With a gentleman I try to be a gentleman and a half, and with a fraud I
try to be a fraud and a half.
-- Otto von Bismark

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How do I full maximise the window (not in full mode) ?

[Tony Mechelynck]

On Tuesday, September 24, 2013 6:18:42 PM UTC+2, jonas_jonas wrote:
 Hi,
 
 
 
  The screenshot is here:
 
  http://snag.gy/gRu2C.jpg
 
  
 
  We can clearly see that there exists some space between the bottom line of 
  MacVim and the screen.
 
  
 
  How can I eliminate that extra useless space?
 
 
 
 It depends on font-size and line-height.
 
 
 
 If the screen-height minus menu-height minus window-border minus
 
 tabbar-height is not dividable by your line-height, I guess you wont be
 
 able to get rid of this space.
 
 
 
 
 
 Best
 
 
 
 Frank
 
Yes; this is not limited to MacVim: every gvim version (for any OS) does the 
same. The Vim GUI will not allow 'lines' (the number of lines of text 
displayed) or 'columns' (the number of characters per line) (in both cases 
across all split windows) to exceed what can be displayed on your screen. This 
means that there may be a few pixels (a partial line) below the Vim screen and 
a few pixels right of it (a partial column) that gvim (or macvim) won't use.

Best regards,
Tony.
-- 
God made the integers; all else is the work of Man.
-- Kronecker

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how to prevent cmd+Q when multiple splits are open?

[Tony Mechelynck]

On Tuesday, September 10, 2013 3:18:55 PM UTC+2, leob wrote:
 Hello all,
 
 Is there a way of preventing cmd+Q from closing when there are more than one 
 buffer open via splits? Note that i'm not asking about tab's.
 
 Thanks in advance
 
 Leo

I'm not on the Mac so (part of) what I'm saying below might not apply to you.

AFAIK, Ctrl-Q (on Linux and Windows, at least, where ther'e is no Cmd key) 
closes nothing; it is an alternative to Ctrl-V (which, in Normal mode, starts 
block-visual, and, in Insert-mode, start literal character insertion.

The command to close a split-window is normally :q (but it also closes the 
current tab if there is only one window in it, and the whole of Vim -hidden 
unsaved buffers mermitting- if there are no nonhelp windows apart from the 
current one). You could also use :close (q.v.) which will never quit Vim.

Is there a mapping for Cmd-Q on your installation on Vim? Try

:verbose map D-Q
:verbose map! D-Q

(both with and without the exclamation mark).

Or if you are on MacVim there might be something of which I'm totally unaware 
in the MacVim customizations (the sources added to plain-vanilla Vim to give it 
a non-X11 GUI on the Mac).


Best regards,
Tony.
-- 
He keeps differentiating, flying off on a tangent.

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: symlinked mvim script can't find original (with solution)

[Tony Mechelynck]

On Friday, August 23, 2013 9:35:48 PM UTC+2, Lance E Sloan wrote:
 The problem:  If MacVim is not installed in one of the common directories and 
 the mvim script called from the shell prompt is actually a symbolic link 
 (symlink) to the original mvim script, the script will probably fail with the 
 error message:
 
   Sorry, cannot find MacVim.app.  Try setting the VIM_APP_DIR 
   environment variable to the directory containing MacVim.app.
 
 As the error message says, one could set the VIM_APP_DIR environment variable 
 to resolve this, but I've noticed a small change to the mvim script that can 
 eliminate the need for that variable in many cases.
 
 The background:  I don't like to install non-Apple applications in 
 /Applications if I can avoid it.  I like to install them in 
 /Local/Applications instead.  When I installed MacVim, I did that.   The app 
 and the mvim script are in a MacVim folder, so that their full paths are:
 
   /Local/Applications/MacVim/MacVim.app
   /Local/Applications/MacVim/mvim
 
 I have a bin directory in my home directory and $HOME/bin is in my path.  
 To add the mvim script to my path, I created a symlink to the mvim script in 
 its installation directory.  That is:
 
   $HOME/bin/mvim - /Local/Applications/MacVim/mvim
 
 When I call the mvim script, I get the error mentioned above because the 
 correct directory is not returned from this link of the mvim script:
 
   myDir=`dirname $0`
 
 myDir ends up with the value of $HOME/bin, which is not where MacVim.app is 
 installed.  A possible solution would be to also add a symlink to MacVim.app 
 in $HOME/bin, but that doesn't feel right.
 
 My solution:  Replace the setting of myDir in the mvim script with this:
 
   myDir=$(dirname $(readlink $0))
   if [ -z $myDir ]
   then
 myDir=`dirname $0`
   fi
 
 This uses the readlink utility to try to read the original file to which 
 the current script name links.  If the result is an empty string (probably 
 because the script name probably wasn't a symlink), fall back to using the 
 current script name, as before
 
 This is a good solution, because if these additional lines were added to the 
 distributed mvim script, it would eliminate the need for more users to edit 
 the script or set the VIM_APP_DIR environment variable.
 
 I thought of posting this as a bug to the MacVim issue tracker, but since it 
 feels more like an enhancement or feature request, I followed the 
 instructions to post about it here first.

Instead of a softlink ~/mvim - /Local/Applications/MacVim/mvim, try adding 
/Local/Applications/MacVim itself to your $PATH (at the end, and with a colon 
separator, I suppose). The shell will then find the original mvim script at its 
actual location without the need for a symlink.


Best regards,
Tony.
-- 
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, The Ultimate Computer, stardate 4731.3

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Change python version/path

[Tony Mechelynck]

On Saturday, August 24, 2013 11:52:42 PM UTC+2, L8D wrote:
 I need to change the python path to use the python 2.7.5 I installed with 
 homebrew. How do I do that?

Normally configure should find the right version (at least when compiling a 
Console version of Vim, or gvim for X11). For MacVim I'm less sure but I hope 
the same applies. In all cases, to use a different Python version you must 
recompile from source.

If configure doesn't find the correct version, I think there is some argument 
to tell it where to look but I'm not sure of the details. Check the 
src/Makefile and/or the src/auto/configure.

Best regards,
Tony.
-- 
A Riverside, California, health ordinance states that two persons may
not kiss each other without first wiping their lips with carbolized rosewater.

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: guifont setting not permanent?

[Tony Mechelynck]

On Sunday, August 11, 2013 3:32:16 PM UTC+2, Dan Fabrizio wrote:
 Hi All,
 
 
 In my vimrc file,  I have 
 set guifont=Monaco:h16
 
 Vim starts with font size 12.   If I source .vimrc,   the fonts size changes 
 to 16 while the current vim session is running.   The next time I start vim,  
 its back to font size 12
 
 Thanks, Dan

Normally, setting guifont in the vimrc is remembered until the GUI starts.

Try
:verbose set gfn?
to see where it was last set.

Best regards,
Tony.
-- 
I never failed to convince an audience that the best thing they
could do was to go away.

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: compiling huge + lua but no lua...

[Tony Mechelynck]

On Monday, June 24, 2013 9:00:17 PM UTC+2, Chris Lott wrote:
 I'm trying to compile MacVim with Lua support on OS X 10.8.4 -- I have
 
 grabbed the latest code from: https://github.com/b4winckler/macvim
 
 
 
 Lua and Cscope are installed, which I understand are necessary
 
 
 
 But when I compile using the configure:
 
 
 
 ./configure --with-features=huge --with-lua-prefix=/usr/local/bin/lua
 
 --enable-luainterp=dynamic
 
 
 
 Everything compiles fine, but :version still shows -lua
 
 
 
 Suggestions?
 
 
 
 c
 
 --
 
 Chris Lott ch...@chrislott.org

Dynamic interpreter interfaces are mostly for Windows. For Unix-like 
platforms (including Linux and, I suppose, Mac OS X) the static interfaces 
are used. I set the following environment variables when compiling Vim on Linux:

#!/bin/bash
export CONF_OPT_GUI='--enable-gnome-check'
export CONF_OPT_LUA='--enable-luainterp'
export CONF_OPT_PERL='--enable-perlinterp'
export CONF_OPT_PYTHON='--enable-pythoninterp'
export CONF_OPT_TCL='--enable-tclinterp'
export CONF_OPT_RUBY='--enable-rubyinterp'
export CONF_OPT_MZSCHEME='--disable-mzschemeinterp'
export CONF_OPT_CSCOPE='--enable-cscope'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='--with-compiledby=antoine.mechely...@gmail.com'

Beware that the above file must be sourced, not run, so these environment 
settings persist when the next bash command (e.g. make) is run. And of course 
you will want to change at least the last line (and possibly some other ones 
too, depending on the compile-time options you prefer).

See also:
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm

Best regards,
Tony.
-- 
LARGE MAN:   Who's that then?
CART DRIVER: (Grudgingly) I dunno, Must be a king.
LARGE MAN:   Why?
CART DRIVER: He hasn't got shit all over him.
 Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: using % inside quotes ( ) - e.g. ':call ScreenShellSend(echo %:p)'

[Tony Mechelynck]

On May 19, 3:49 pm, peiman khosravi peimankhosr...@gmail.com wrote:
 Dear all,

 I am trying to run this command:

 :call ScreenShellSend(echo %:p)

 Where %:p should be replaced by the current file path. For obvious reasons
 this doesn't work so I get 'echo %:p' in the terminal instead. Is there a
 workaround for this?

 Many thanks in advance
 Peiman
In addition to what you found, the following (without backticks) will
also work:

:call ScreenShellSend('echo ' . expand('%:p'))


Best regards,
Tony.
--
I've seen, I SAY, I've seen better heads on a mug of beer
-- Senator Claghorn

-- 
-- 
You received this message from the vim_mac 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

--- 
You received this message because you are subscribed to the Google Groups 
vim_mac group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_mac+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: winpos works if I source .vimrc but not on startup

[Tony Mechelynck]

On Nov 27, 8:24 am, Chris Lott ch...@chrislott.org wrote:
 I have the following in my .vimrc:
 :winpos 30 30

 However, when I start MacVim, the window position doesn't get set
 properly. But if I source my .vimrc with a window open, the position
 is set correctly (the window jumps to the proper position).

 How can I get the window to the right position upon startup?

 c
 --
 Chris Lott ch...@chrislott.org

:winpos {xvalue} {yvalue} is one of the few settings which is supposed
to be remembered until GUI startup if you use it before the GUI has
started. I don't know what the differences are in this respect between
MacVim and the other flavours of gvim, but if you suspect that the
command is issued too early, you can move it into an autocommand for
the GUIEnter event, which is triggered immediately after successfully
starting the GUI and opening the GUI window, before the VimEnter event
for GUI Vim.

see

-- 
You received this message from the vim_mac 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: winpos works if I source .vimrc but not on startup

[Tony Mechelynck]

On Nov 27, 11:36 am, Tony Mechelynck antoine.mechely...@gmail.com
wrote:
 On Nov 27, 8:24 am, Chris Lott ch...@chrislott.org wrote:

  I have the following in my .vimrc:
  :winpos 30 30

  However, when I start MacVim, the window position doesn't get set
  properly. But if I source my .vimrc with a window open, the position
  is set correctly (the window jumps to the proper position).

  How can I get the window to the right position upon startup?

  c
  --
  Chris Lott ch...@chrislott.org

 :winpos {xvalue} {yvalue} is one of the few settings which is supposed
 to be remembered until GUI startup if you use it before the GUI has
 started. I don't know what the differences are in this respect between
 MacVim and the other flavours of gvim, but if you suspect that the
 command is issued too early, you can move it into an autocommand for
 the GUIEnter event, which is triggered immediately after successfully
 starting the GUI and opening the GUI window, before the VimEnter event
 for GUI Vim.

oops, hit Send too fast
 see
:help GUIEnter
:help autocmd.txt

Best regards,
Tony.
--
BROTHER MAYNARD: Armaments Chapter Two Verses Nine to Twenty One.
ANOTHER MONK:And St.  Attila raised his hand grenade up on high
saying O
 Lord bless this thy hand grenade that with it thou
mayest
 blow thine enemies to tiny bits, in thy mercy. and
the Lord
 did grin and people did feast upon the lambs and
sloths and
 carp and anchovies and orang-utans and breakfast
cereals and
 fruit bats and...
BROTHER MAYNARD: Skip a bit brother ...
 Monty Python and the Holy Grail PYTHON (MONTY)
PICTURES LTD

-- 
You received this message from the vim_mac 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: disable ESC key?

[Tony Mechelynck]

On Nov 6, 11:46 pm, Derek Ashley Thomas derekatho...@gmail.com
wrote:
 [...] Who needs a caps-lock anyway? http://www.apple.com/jp/keyboard/

Me for one. For titles or for text in all caps such as Unicode
codepoint names or Bugzilla statuses and resolutions.

I suppose though, that if I were writing mostly in CJK scripts (kanji/
hanzi/hanja - hiragana - katakana - hangeul) I would have much less
use of it.


Best regards,
Tony.
--
Money is the root of all evil, and man needs roots

-- 
You received this message from the vim_mac 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: disable ESC key?

[Tony Mechelynck]

On Nov 4, 9:14 pm, Chris Lott ch...@chrislott.org wrote:
 I'd like to disable the ESC key in interactive mode (I only want to do
 so in gui), but the following, which seems like it should work,
 doesn't seem to do anything:

 :inoremap esc nop

 ideas?

 c
 --
 Chris Lott ch...@chrislott.org

And how would you go back to Normal mode?

Or do you want to never use Normal mode and always remain in Insert
mode, changing Vim to a sort of Notepad clone? See :help -y

Best regards,
Tony.
--
If you don't care where you are, then you ain't lost.

-- 
You received this message from the vim_mac 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: MacVim and App Store

[Tony Mechelynck]

On Sep 8, 9:30 pm, Carl Jacobsen li...@carlrj.com wrote:
[...]
 Are you on this list for any reason other than to make yourself feel
 smug?

Believe it or not, yes I am. I occasionally answer posts which were
made on vim_mac but actually belong on vim_use, and I also help ban
the spammers and allow the legitimete new subscribers.


 I've used a considerable number of Unix variants and Unix-alikes
 (Linux included) starting with the then-new 4.2BSD on a Vax in 1983,
 eight years before the earliest version of Linux existed. I choose to
 use Mac OS X because I prefer it to all other available choices,
 *including Linux*, for a wide variety of reasons (and looking cool in
 coffee shops is *not* on that list). Linux is a nice Unix-alike, but
 has always been missing a *really* good, thorough, *consistent*, GUI.
 Mac OS X is a good BSD-variant Unix, with an absolutely fantastic GUI.
 To me, and to many others, it's worth jumping through a few hoops
 (like buying [fantastic-but-spendy] Mac hardware) to be able to use
 Mac OS X. We probably won't be able to sufficiently educate you about
 what you're missing out on to change your mind, but, by the same
 token, you aren't going to be able to convince us that Linux is
 superior to Mac OS X. So please don't try.

I suppose we just don't have the same preferences. I don't blame you
for preferring the luxury of a Rolls-Royce (and paying for it), please
son't snub my VW Beetle.


 And back on topic, count me in on being willing to contribute (each
 year) towards a membership for Björn in the Mac Developer Program,
 should he elect to start signing MacVim (I think it would involve
 jumping through some hoops in Xcode initially, but could then be
 automated to a simple call to /usr/bin/codesign in the Makefile).

 My apologies for feeding the troll,
 Carl

Oh, and BTW I don't know what privileges registered developers
enjoy, maybe that's one of the reasons why it seemed unduly expensive
to me to pay USD 99 just for being one.

Usually I'm the one recommending not to feed the animals :-P Can't you
take humor? Not when it means someone doesn't assume costlier is
better, apparently. Oh, well, maybe I'm the one feeding the troll now.
I'll shut up.


Best regards,
Tony.
--
 Eat drink and be merry, for tomorrow they may make it illegal.

-- 
You received this message from the vim_mac 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: 64 bit macVim for mountain lion

[Tony Mechelynck]

On Aug 15, 2:23 pm, Andre aip.schae...@googlemail.com wrote:
 Am Montag, 6. August 2012 00:31:50 UTC+2 schrieb Chen Huang:

  The latest snapshot seems to use 32 bit rather than 64 bit. Can you post a 
  64 bit binary?

 Building MacVim via MacPorts does build a very stable 64Bit version. May be 
 that does help you?

 Just Follow the instructions onhttp://www.macports.org,
 * install MacPorts for mountain lion
 * Install the latest XCode and the optional command line utilities
 * Open Terminal
 * Issue 'sudo port install MacVim'

 If all works cleanly, You'll have a 64 bit version in /Applications/MacPorts/ 
 on your machine.

 Hope that helps,
 André

The port (listed as vim some three-fourths down the page of
http://www.macports.org/ports.php?by=categorysubstr=editorspage=2pagesize=50
) is currently version 7.3.615 which is reasonably recent (published
by Bram on 25 July).

-- 
You received this message from the vim_mac 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: Unicode matchpairs not possible?

[Tony Mechelynck]

On Jul 3, 6:14 pm, Axel Kielhorn v...@axelkielhorn.de wrote:
 Am 03.07.2012 um 14:17 schrieb Tony Mechelynck:

  It is documented under :help 'matchpairs':

  Currently only single byte character pairs are allowed, and they must
  be different.

 Thanks, I somehow missed that.

 Maybe I should transform » and « to  and  while editing and convert it 
 back when writing the file. It's easier to type that way, which is another 
 bonus.

 Axel

Maybe you could, but in that case beware that having unpaired less-
than and greater-than signs (as in mathematics) will confuse Vim when
trying to find the mate of a  or  marker. And of course you won't
be able to use  for much less than and  for much greater than
or similar.

Best regards,
Tony.

--

Whom computers would destroy, they must first drive mad.

-- 
You received this message from the vim_mac 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: Unicode matchpairs not possible?

[Tony Mechelynck]

On Jul 1, 7:27 pm, Axel Kielhorn v...@axelkielhorn.de wrote:
 Hi!

 I'm using:

 VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun  4 2012 19:19:42)
 MacOS X (unix) version
 Included patches: 1-531

 The default matchpairs are:
 matchpair(:),{:},[:]

 I can
 :set mps+=:

 to add a new matchpair, but I can't

 :set mps+=«:»
 or
 :set mps+=‹:›

 I get
 E474: Invalid argument: mps+=‹:›

 Shouldn't Vim accept any unicode character?

 Axel

It is documented under :help 'matchpairs':

Currently only single byte character pairs are allowed, and they must
be different.

What is or isn't a single-byte character depends on how characters are
represented in memory (i.e. the global 'encoding' option), not on disk
(the buffer-local 'fileencoding'). If 'encoding' is set to utf-8,
only the 128 lowest codepoints are single-byte, so you can add :
(0x3C 0x3E) but not «:» (0xAB 0xBB) and not ‹:› (U+2039 U+203A). If
'encoding' is set to Latin1, only the lowest 256 Unicode codepoints
can be represented in memory, each as a single byte, so in that case
you can add «:» but you cannot even represent ‹:› in memory (in any
buffer, since 'encoding' is a global option).

Best regards,
Tony.

--

Economists state their GNP growth projections to the nearest tenth of
a
percentage point to prove they have a sense of humor.
-- Edgar R. Fiedler

-- 
You received this message from the vim_mac 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: Ctrl-w not working with Dvorak-Qwerty layout

[Tony Mechelynck]

On Feb 11, 11:18 am, Jason Garber j...@jasongarber.com wrote:
 Hi everyone. I need your help figuring out a key mapping issue. I use
 the Dvorak-Qwerty (Dvorak for typing and Ctrl/Shift/Alt, but Cmd
 shortcuts are QWERTY) layout in OS X and have used regular vim in the
 terminal for years. I don't use a keymap or anything; hjkl are spread
 out over the keyboard. All this works fine in MacVim as it did in vim:
 Ctrl-f, Ctrl-b, Ctrl-u, and Ctrl-d take me forward, back, up
 and down.

 Ctrl-w and Ctrl-v don't work though. In MacVim they are located
 where you would find them on QWERTY. In the terminal (mvim -v) they
 work fine, like I'm used to. Also, when I switch OS X to the Dvorak
 layout, they work fine in MacVim.

 Anyone have some insight into this? I suppose for the time being I'll
 just need to figure out which ones are broken and remap them, like map
 C-w C-,

This would require you to hit whatever makes your keyboard generate
Ctrl-W in order to get Ctrl-, (which, BTW, is not defined) so there
are two reasons why it wouldn't work.

I suggest that you choose some F key (these, IIUC, are in the same
location on Dvorak and QWERTY keyboards) and map it to the Ctrl-W key,
as follows:

:map  F9 C-W
:map! F9 C-W

I used a similar mapping when I didn't know what key combination would
generate Ctrl-] on my keyboard (and now that I do know, I've kept the
mapping because that “native” key combo is difficult to produce).

-- 
You received this message from the vim_mac 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: How to get updated winwidth() after :set guifont ?

[Tony Mechelynck]

I'm redirecting this thread to the vim_mac group and adding Björn to the CC.

On 02/01/12 03:33, Zhao Cai wrote:

On 01/01/12 16:37, Zhao Cai wrote:

Problem: Right after `set guifont=…`, `winwidth()` returns the old win width 
instead of the new width which would be changed by new guifont size.

I tried to call `redraw` between but it does not work.

Any suggestion? Thanks.

- Zhao



Experiments here show the following (while typing ex-commands manually in gvim 
7.3.390 with GTK2/Gnome2 GUI):

If the GUI is maximized (truly maximized, not just with :set lines=999 
columns= but by clicking the Maximize menu or widget), it is anchored to 
the screen borders; in that case setting a smaller font will increase 'lines', 
'columns' and also winwidth(0)

If the GUI is not truly maximized, then setting a smaller font will keep 
'lines' and 'columns' unchanged and reduce the pixel size of the GUI. In that 
case winwidth(0) is also kept unchanged.

Trying to set 'lines' or 'columns' to a value bigger than the available screen 
space (also by increasing the 'guifont' size) will cause Vim to reduce 'lines' 
and 'columns' to something no bigger than what is now available onscreen. In 
this case winwidth(0) may also get reduced.

With no vertical splits present, I always see winwidth(0) ==columns


Thanks for your answer!


If you see something else, please answer the following:

- Which GUI flavour? (macvim, GTK2, Motif, Windows, …)

MacVim

- Which Vim version and patch level?

7.3 (2010 Aug 15, compiled Nov 10 2011 17:45:40)

- Compiled by yourself (from which sources) or downloaded precompiled (from 
where)?

Precompiled newest snapshot

- Exact steps to reproduce; actual results; expected results


I just retested a few more times. The problem happens only when I use mac 
lion's native full screen. For normal full screen, the winwidth function works 
just fine.

Command I use: `letguifont = 'Bitstream Vera Sans Mono:h18' | echomsg 
winwidth(0)`



Detailed version info
```
:version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Nov 10 2011 17:45:40)
MacOS X (unix) version
Included patches: 1-353


7.3.353


Compiled by Bjorn Wincklerbjorn.winck...@gmail.com
Huge version with MacVim GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent 
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind
+cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval 
+ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding 
-footer +fork() +fullscreen -gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall 
+linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname 
+mouse +mouseshape +mouse_dec -mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +mouse_urxvt 
+multi_byte +multi_lang -mzscheme +netbeans_intg +odbeditor +path_extra +perl 
+persistent_undo +postscript +printer +profile
+python -python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs 
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl +terminfo
+termresponse +textobjects +title +toolbar +transparency +user_commands 
+vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore 
+wildmenu +windows +writebackup -X11 -xfontset +xim
  -xsmp -xterm_clipboard -xterm_save
system vimrc file: $VIM/vimrc
  user vimrc file: $HOME/.vimrc
   user exrc file: $HOME/.exrc
   system gvimrc file: $VIM/gvimrc
 user gvimrc file: $HOME/.gvimrc
 system menu file: $VIMRUNTIME/menu.vim
   fall-back for $VIM: /Applications/MacVim.app/Contents/Resources/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall 
-Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp  -g -O2 -arch i386 
-D_FORTIFY_SOURCE=1
Linking: gcc   -L.-L. -arch i386 -L/usr/local/lib -o Vim -framework 
Cocoa -framework Carbon  -lncurses  -liconv -framework Cocoa
-fstack-protector -L/usr/local/lib  -L/System/Librar
y/Perl/5.12/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -framework 
Python   -framework Ruby
```


Best regards,
Tony.
--
The devil finds work for idle circuits to do.

--
You received this message from the vim_use 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




--
You received this message from the vim_mac 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: Mapping the arrow keys in insert mode?

[Tony Mechelynck]

On Dec 24, 4:00 pm, Pedro Henrique Guedes Souto
pedro.h.so...@gmail.com wrote:
 On 24/12/2011, at 12:38, Tony Mechelynck wrote:

  Maybe Vim diesn't see them as these keys? In Insert mode, does macvim
  print anything (and what) if you type these keys preceded each time by
  Ctrl-V (or by Ctrl-Q if your Ctrl-V is remapped to the paste
  operation)? Then same question, but preceded by Ctrl-K instead?

 Yes, it prints Right, Left, Up and Down.

 I changed the mappings to this:
 inoremap Up    nop
 inoremap Down  nop
 inoremap Left  nop
 inoremap Right nop

 And still not working...
 Is that a Bug, maybe?

Try Nop instead of nop. If that doesn't work, then I don't know.




  Best regards,
  Tony.

 Thanks for you answer, have a nice Xmas.

Thank you, I did. Hope you did too.


 --Pedro Henrique Souto

Best regards,
Tony.
--
On Monday mornings I am dedicated to the proposition that all men are
created jerks.
-- Avery

-- 
You received this message from the vim_mac 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: Mapping the arrow keys in insert mode?

[Tony Mechelynck]

On Dec 23, 12:34 pm, Pedro Henrique Guedes Souto
pedro.h.so...@gmail.com wrote:
 Hey folks,

 I have this section in my .vimrc file:

      Don't. Use. The. Arrow. Keys.
     nnoremap up    nop
     nnoremap down  nop
     nnoremap left  nop
     nnoremap right nop
     inoremap up    nop
     inoremap down  nop
     inoremap left  nop
     inoremap right nop

 But, the arrow keys still work in insert mode. How can I fix that? Or it's 
 impossible to do it?

 My Macvim version is: Vim version 7.3.  Last change: 2010 Jul 20
 And I'm in MacOS X Lion.

 Thanks in advance!

 --Pedro Henrique Souto

Maybe Vim diesn't see them as these keys? In Insert mode, does macvim
print anything (and what) if you type these keys preceded each time by
Ctrl-V (or by Ctrl-Q if your Ctrl-V is remapped to the paste
operation)? Then same question, but preceded by Ctrl-K instead?

Best regards,
Tony.
--
A girl and a boy bump into each other -- surely an accident.
A girl and a boy bump and her handkerchief drops -- surely another
accident.
But when a girl gives a boy a dead squid -- *that had to mean
something*.
-- S. Morganstern, The Silent Gondoliers

-- 
You received this message from the vim_mac 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: Can you stop netrw or NERDTree from appearing when opening a directory with MacVim?

[Tony Mechelynck]

On Dec 21, 7:53 pm, Wes Baker w...@wesbaker.com wrote:
 Just like the subject says, I typically open directories using MacVim
 and either netrw (I think) or NERDTree shows up every time. I'd rather
 it didn't and only showed a blank buffer. Can I do that?

 Thanks,
 Wes

I don't know about NERDtree; but if you disable netrw, Vim will give
you an error instead when you try to open a directory: the main
purpose of the netrw plugin is to allow Vim to display the contents of
a directory when you edit it.

Now if you just want to open an empty window with the _local
directory_ set to a certain directory, that's a different (and easy)
question:

:new | lcd /foo/bar/baz

or, to save some keystrokes, put

:cabbrev expr CD ((getcmdtype() == ':'  getcmdpos() = 3)? 'new
Bar lcd' : 'CD')

in your vimrc then use :CD /foo/bar/baz

to open an empty window and make /foo/bar/baz the current directory.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
250. You've given up the search for the perfect woman and instead,
 sit in front of the PC until you're just too tired to care.

-- 
You received this message from the vim_mac 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: UTF-8 puzzle

[Tony Mechelynck]

On Dec 19, 3:31 pm, Gabriel snoopy.6...@googlemail.com wrote:
 I am using MacVim 7.3 under Lion.

 Now here is something that puzzles me with UTF8 files.

 I write a small text file in MacVim, saved it with utf-8 file
 encoding, opened it in TextEdit, and I get all these funny square-root
 characters instead of umlauts.

 And vice versa, I wrote simple text file in TextEdit, set the
 preferences of TextEdit such that it saves files always as UTF-8,
 saved the file, opened it in MacVim -- and I get all these funny 9c
 characters instead of umlauts.

 I also experimented a little with the extended attribute
 com.apple.TextEncoding, to no avail.

 Can anybody tell me, which is the correct way to write/save UTF-8
 files?

 Best regards,
 Gabriel.

If the program which will read the text can handle a BOM, use it, even
with UTF-8. In Vim, this is done with :setlocal bomb. It is usable
for HTML, CSS, and some others. It is not usable for anything where
the first line must start with #! (Unix shell scripts, Perl, ...). I
think it doesn't work with C/C++ either but I could be wrong.

For XML and HTML files the charset can also be declared in the file,
as follows:

?xml version=1.0 encoding=UTF-8?
or
meta http-equiv=Content-Type content=text/html; charset=utf-8 /

but (unlike the BOM) these are not recognised by Vim's fileencoding
detection heuristics

Now the umlauts:
Character - Latin1 hex - UTF-8 hex - UTF-8 mistranslated as Latin1
ä   E4   C3 A4   ä
Ä   C4   C3 84   Ã 
ë   EB   C3 AB   Ã
Ë   CB   C3 8B   Ã 
etc. (Latin 1 hex is also Unicode ordinal, i.e. ä - U+00E4 etc.)

See also
  :help ga
  :help g8
about how I found the above, and
  :help 'isprint'
  :help 'isfname'
about how to tell vim which characters are printable.

-- 
You received this message from the vim_mac 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: Manipulate selected text

[Tony Mechelynck]

On Sep 30, 7:13 pm, Kyle Lippincott spect...@gmail.com wrote:
 It probably depends on selectmode then.. I think by default on Marin
 behavior it's only set to 'mouse', but I set it to all three
 (including 'cmd') before writing that.  Even more reason for me to
 dislike the feature - too hard to tell what's going to happen ;)

I have 'selectmode' set to key,mouse, meaning that it will be
started by a mouse drag, by a shift-click or by a shift-arrow key, but
not by hitting v V or Ctrl-V

I see that 'selectmode' is set by the :behave command; I use
neither :behave mswin nor :behave xterm but some intermediate values,
as follows:
set selectmode=mouse,key
set mousemodel=popup
set keymodel=startsel
set selection=inclusive

Best regards,
Tony.
--
Reader, suppose you were an idiot.  And suppose you were a member of
Congress.  But I repeat myself.
-- Mark Twain

-- 
You received this message from the vim_mac 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: Manipulate selected text

[Tony Mechelynck]

On Sep 29, 6:26 pm, Kyle Lippincott spect...@pewpew.net wrote:
 This sounds an awful lot like select mode to me.  Verify before you hit :
 that you're in 'VISIUAL' not 'SELECT' mode.  Investigate the 'selectmode'
 option and 'behave' command to see why this might be getting turned on.
  It's meant to mimic Microsoft Windows selection model behavior, but I find
 it very confusing..

 If you *want* to use select mode but switch to visual for something, ctrl-o
 will switch to visual for one command, ctrl-g will straight up switch.  If
 you accidentally erase something in select mode when you meant to hit
 ctrl-[og] to get to visual first, you can undo it by hitting 'u', then 'gv'
 to regain the previous selection (but you'll still be in select mode, so
 don't forget the ctrl-o or ctrl-g this time ;)).

gv will put you back in Visual mode, even if you were in Select mode
before. At least that's how it happens on GTK2 gvim, and I can't see
why MacVim would do it differently. Not knowing about Ctrl-G, I've
often used Escgv to go from Select to Visual.

-- 
You received this message from the vim_mac 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: Color scheme options getting reset

[Tony Mechelynck]

On Sep 29, 11:28 pm, toki reddog...@gmail.com wrote:
 Hi Tony,

 That seems to have worked.  Not sure why this didn't take effect when I
 added the lines into the default color profile in the MacVim package.  I
 actually did try making a colorscheme inside the .app package, as well, but
 it didn't work.  I wonder why having it in a local .vim/ directory makes a
 difference.

 Anyhow... thanks.  I have never encountered this problem until using vim on
 Mac OS, probably because I'm not too familiar with how the program operates
 on this platform yet.  Always a few kinks to work out.

 -t

Neither have I. What I explained in my previous post is what I would
have done (and actually did, though with different custom colors) on
Windows and on GTK2. I'm happy it worked for you too.

-- 
You received this message from the vim_mac 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: Color scheme options getting reset

[Tony Mechelynck]

On Sep 29, 5:14 am, toki reddog...@gmail.com wrote:
 I have used vim / gvim on windows and Linux for many years, and have
 recently started using mvim.  The color scheme I use is the default VIM
 colors, except with a few changes, which I put into my ~/.gvimrc file:

 hi Normal guibg=black guifg=grey90
 hi Cursor guibg=red guifg=NONE
 hi NonText guibg=grey15
 hi Constant gui=NONE guibg=grey15
 hi Special gui=NONE guibg=grey15

 I also edited the default gvimrc file in the .app package to take out line
 that loads the macvim scheme by default.  After making these changes,
 though, mvim seems to ignore the guibg parameters for Constant and Special,
 and puts them back to black.  I tried just about everything from editing the
 default color scheme file, to adding the lines into vimrc, gvimrc, etc., but
 nothing seems to work aside from manually sourcing my .gvimrc file after
 startup.

 I know that mvim is reading my ~/.gvimrc file as there are other parameters
 I have in there (lines, columns, etc.).  It just seems that it's ignoring
 the guibg tags for Constant and Special highlights, or the variables are
 getting overwritten after this point.

 Are there any configuration files that are loaded after this point that
 could be overwriting these options?  I'm getting tired of having to type
 :.source ~/.gvimrc every time I load up the app.

 Environment is Mac OS Lion 10.7.1, MacVIM snapshot 62, zsh shell.

 Any help is appreciated.

 -toki

Try creating a new colorscheme with your changes. Start by moving the
default colorscheme to $HOME/.vim/colors under a different name
(create any missing directories as you go along), change the :let
colors_name line to reflect the new name, add your lines in it, and
add a :colorscheme line for it in your vimrc (see :help :colorscheme).

Any highlight group which you don't set will be set to its default
colors.

Best regards,
Tony.
--
Gee, Mudhead, everyone at More Science High has an
extracurricular activity except you.
Well, gee, doesn't Louise count?
Only to ten, Mudhead.

-- Firesign Theater

-- 
You received this message from the vim_mac 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: How to change font with a space in the font?

[Tony Mechelynck]

On Sep 10, 10:19 pm, Israel Chauca F. israelvar...@fastmail.fm
wrote:
 On Sep 10, 2011, at 12:39 PM, Blueplastic wrote:

  Hi guys,

  I want to change my default font to one with a space in the middle.
  How do I do this? what is the correct syntax for the .gvimrc file?

  set guifont=Anonymous Pro:h12

  or

  set guifont=Anonymous Pro:h12

 Escape the space:

 set guifont=Anonymous\ Pro:h12

 Israel

yes, in general any space, double quote, vertical bar or backslash in
the arguments of the :set, :setlocal and :setglobal statements must be
backslash-escaped. But for backslashes Vim tries to determine if a
Windows file path was meant and adds some black magic.

See :help option-backslash


About how to set the 'guifont' option portably (so that it will
continue to work on other platforms and with other Vim versions), see
http://vim.wikia.com/wiki/Setting_the_font_in_the_GUI (which includes
several examples of font names with spaces in them).


Best regards,
Tony.
--
There are also a lot of nice buildings in Haiphong.  What their
contributions are to the war effort I don't know, but the desire to
bomb a virgin building is terrific.
-- Commander Henry Urban Jr.

-- 
You received this message from the vim_mac 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: Changing elements of a color scheme

[Tony Mechelynck]

On 07/07/11 16:26, Eric Weir wrote:


I've discovered a color scheme that I like better than the one I've been using 
since starting with Vim/MacVim a few months ago. However, there's one element 
that clashes for me -- the color of the cursor. I know what color I'd like it 
to be, i.e., the color that CameCase words get in a plugin I use using this 
scheme.

How do I change the color of the cursor? How do I identify and specify the 
color I want?

Thanks,
--
Eric Weir
Decatur, GA  USA
eew...@bellsouth.net






1) If the colorscheme you've come to love is one distributed with Vim 
(and found in $VIMRUNTIME/colors/) then don't modify it in-place. The 
way to modify such a scheme for your own youse is to:


a) Make sure that directory $HOME/.vim/colors exists, and if necessary, 
create it, with its parent if that doesn't yet exist either
b) Copy the colorscheme you want to edit into that new directory, and 
give it a new name that doesn't clash with the name of any existing 
colorscheme

c) THEN you may modify that new colorscheme without fear.

(Anything in the directory tree starting at $VIMRUNTIME may be silently 
modified whenever you upgrade Vim.)


2) See
:help 'guicursor'
:help lCursor
:help hl-Cursor
:help hl-CursorIM
:help CursorIM
for the names of the cursor colors used in the gvim or MacVim GUI. In 
short, they are:

- Cursor the cursor color for everything except what is said below
- lCursorwhen a keymap (or language-mappings) are in effect
- CursorIM   when an Input Method (XIM or Windows IME) is in effect

See also:
	- about one page below :help xfree-xterm how to set the cursor color 
in an xterm

- :help xterm-blink to make the cursor blink in an xterm
	- the full :help xterm-color section about how to nudge some 
particular terminals to get color in them
	- :help termcap-cursor-color about how to change cursor color in some 
terminals when going into or out of Insert mode.



Best regards,
Tony.
--
Physicists do it with charm

--
You received this message from the vim_mac 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: Changing font for highlighted groups

[Tony Mechelynck]

On Jul 2, 7:31 pm, Spiff spiffis...@gmail.com wrote:
 Hi. Are there any plans to implement font selection in highlights, as
 in gvim/GTK2?

 e.g. hi! Conceal font=STIXRegular:h14

IIUC what is said under :help highlight-font you can use this in any
GUI vim (including MacVim), not only in gvim with GTK2 GUI, *BUT* for
any highlight group other than Menu and Tooltip:
- the font chosen should be a monospace font, and in gvim flavours
other than GTK2 it MUST be so
- the font chosen must have exactly the same pixel dimensions as the
default font, and this means the following:
  - exactly the same pixel width
  - exactly the same pixel height
  - exactly the same pixel distance between the bottom of the cell and
the bottom pixels of lovercase x
  - exactly the same pixel distance between the top of the cell and
the top pixels of lowercase x
  - exactly the same pixel distance (a signed integer, which may be
zero but doesn't have to) between the top of uppercase I and of
lowercase l

Because of these constraints, you will in general be better off
leaving the font unchanged (in MacVim, and in GTK2 gvim too) and
setting the other attributes (bold, italic, bg color, fg color, wavy
underlining color…)


Best regards,
Tony.
--
As long as I am mayor of this city [Jersey City, New Jersey] the great
industries are secure.  We hear about constitutional rights, free
speech and the free press.  Every time I hear these words I say to
myself, That man is a Red, that man is a Communist.  You never hear
a
real American talk like that.
-- Frank Hague (1896-1956)

-- 
You received this message from the vim_mac 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: syntastic with pathogen

[Tony Mechelynck]

On May 19, 10:14 am, Adimir Colen adimirco...@gmail.com wrote:
 Hi all,

 I'm using pathogen with the following script,

 https://gist.github.com/980381

 when I open a file, the following error:
 E117: Unknown function: SyntasticStatuslineFlag
 E15: Invalid expression: SyntasticStatuslineFlag ()

 Can someone help me?

 Tks!

Maybe that's an error in pathogen, a third-party script? Try searching
it for that function name.

Best regards,
Tony.
--
Scott's first Law:
No matter what goes wrong, it will probably look right.

-- 
You received this message from the vim_mac 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: Creating a new file saves with ^@

[Tony Mechelynck]

On May 14, 10:01 pm, Mellified Man adr...@luff.me wrote:
 On May 13, 5:38 pm, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote:

  So I would investigate the 'fenc' and 'fencs' options, and perhaps even
  'enc'. If you mess with them in your .vimrc, you may well have made a
  mistake. It sounds to me like 'fenc' is being given a default that
  'fencs' doesn't recognise upon reopening or something like that.

  Comparing the value of 'fenc' when the file is originally being created
  and looks right with that when it is reloaded and looks wrong could
  help, too. Use

  :verbose set fenc?

 I had set encoding=unicode in my .vimrc. Disabling this fixed the
 issue. Both fenc and fencs were unset. I don't recall why I thought I
 needed to change encoding in the first place.

 Thanks!

Since Unicode is not an encoding known to Vim, it will translate to
and from it using iconv, without realizing that Unicode often means
UTF-16 or UTF-16le, which Vim knows and handles in a special way,
because many characters, including all Latin-1 characters, have in
these encodings a representation which includes a null byte (and null
bytes have a special function in C strings). Therefore if you set
'encoding' to UTF-16 (with or without le or be) Vim will use UTF-8
internally, an encoding which can represent the same Unicode
codepoints as any endianness variant of UTF-16 or UTF-32, but whose
only use for a null byte is as the representation of the codepoint U
+ control = NULL.

See also http://vim.wikia.com/wiki/Working_with_Unicode

-- 
You received this message from the vim_mac 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: /ftplugin vs /plugin [was: Re: MacVim handling csv]

[Tony Mechelynck]

On Aug 19, 9:59 am, Etienne Benoît Roesch etienne.roe...@gmail.com
wrote:
 Le 19 août 2010 à 08:11, John Beckett a écrit :
  Etienne Benoît Roesch wrote:
  Initially, I put it in ~/.vim/ftplugin/ as instructed, but it
  did not load (did not show up with :scriptnames). Then I
  moved it to ~/.vim/plugin/ instead. The command :scriptnames
  does show ~/.vim/plugin/csv.vim now, but loading a .csv file
  does not trigger the plugin, nor does creating a file from
  scratch with fields between commas and :set ft=csv

  As indicated in the Usage section at:
 http://vim.wikia.com/wiki/Working_with_CSV_files

  you have to put csv.vim in the *ftplugin* directory (not
  plugin), *and* you have to put a .csv rule in filetype.vim.

  I suggest you move csv.vim from plugin to ftplugin, and double
  check the .csv rule, then close Vim and start it again.

  To be sure you have the .csv rule, enter the following in Vim:
     :au BufNewFile *.csv
     :au BufRead *.csv

  They should both show something like:
  filetypedetect  BufRead
     *.csv     setf csv

  John

 Hi John,

 I know how to read instructions, thank you :) but I must have failed to 
 mention that I did add a .csv rule in filetype.vim. I have been using vim for 
 years now, and adding that rule is the first thing I did! -- although I have 
 to admit I had to create filetype.vim, as I was usually handling autocmds in 
 .vimrc. Those bad old habits!
 Both :au BufNewFile *.csv and :au BufRead *.csv do show:  *csv  set csv

 When I said Initially, I put it in ~/.vim/ftplugin/ as instructed, but it 
 did not load (did not show up with :scriptnames) .. I should have added:
 - Opening test.csv (content below) did not activate column hightlightning 
 *and* using H J K L 0 $ produced some weird behaviour (H goes up the file, 
 and J does nothing...) *and* the :Sort command yields an error E492: Not an 
 editor command: Sort

 this,is,a
 dummy,file,foo

 - Nor did typing the content of test.csv in a buffer, and entering :set 
 ft=csv (I can verify the ft update in my statusline)
 - or replacing commas with tabs

 Hence my initial post. From your first response, I got to try :scriptnames, 
 which I didn't know before and showed no script in /ftplugin whatsoever. As 
 the plugin readcsv.vim I was previously using resided in /plugin and not 
 /ftplugin, I decided to try putting csv.vim in /plugin. It did show up in 
 :scriptnames, but still did not produce the expected behaviour.

 From reading this list of symptoms, I can only conclude that MacVim does not 
 check into /ftplugin. How can I solve this?

 Again, John, thank you very much for your help! I am *really* looking forward 
 to using your plugin :)

 Best regards,

 Etienne

Étienne-Benoît, it sounds like you did not enable filetype-plugins in
your vimrc. Make sure that it contains one (and one only) of the lines

filetype plugin on
filetype plugin indent on
runtime vimrc_example.vim
source $VIMRUNTIME/vimrc_example.vim


Best regards,
Tony.
--
If a jury in a criminal trial stays out for more than twenty-four
hours, it is certain to vote acquittal, save in those instances where
it votes guilty.
-- Joseph C. Goulden

-- 
You received this message from the vim_mac 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: MacVim Script Load Order

[Tony Mechelynck]

On Jul 18, 12:49 am, Dan dan.r.a...@gmail.com wrote:
 Hello,

 I have recently set up MacVim 7.2 snapshot 52 as an external editor
 with Xcode and I have installed cocoa.vim script from vim.org into my
 home .vim directory.  Now using vim from the terminal, cocoa.vim works
 fine and I receive all the cocoa objective-C syntax enhancements when
 working with objc files.  However, MacVim fails to do the same.

 After a little a investigation with using the ':scriptnames' command I
 found the that MacVim would load the following syntax files in this
 exact order:

  30: /Users/Dan/.vim/after/syntax/objc_enhanced.vim
  31: /Users/Dan/.vim/after/syntax/cocoa_keywords.vim
  32: /Applications/MacVim-snapshot-52/MacVim.app/Contents/Resources/
 vim/runtime/syntax/objc.vim
  33: /Applications/MacVim-snapshot-52/MacVim.app/Contents/Resources/
 vim/runtime/syntax/c.vim

 So it appeared that MacVim's internal objc.vim file would clobber the
 loaded enhancements from objc_enhanced.vim.  Shouldn't MacVim load
 the $HOME/.vim/after/syntax directory after it loads its own
 internal syntax files?  I'm not sure if this is an issue worthy to be
 reported as a bug.

 As a quick and dirty fix I copied objc_enchance.vim and
 cocoa_keywords.vim to MacVim's runtime/syntax directory and added
 ru syntax/objc_enhanced.vim to the bottom of the syntax/objc.vim
 file.  I realize that this is probably not the best way to get around
 the issue but it worked for me.

 - Dan

Each script is listed only once by :scriptnames, in the order they
were _first_ sourced; but each syntax script is sourced again for each
edit file of that syntax. From what you say, I can only conclude that
the first objc-enhanced file was sourced before the first objc
file — or else, the file was detected as one syntax, and the script
for that syntax invoked the script for another syntax: for instance,
at line 21 of $VIMRUNTIME/syntax/objc.vim I see runtime! syntax/
c.vim which will, at that point, source the syntax/c.vim script from
all 'runtimepath' trees in sequence. At that point, objc.vim had not
yet finished running, but it is listed before c.vim because it
_started_ before it.

Best regards,
Tony.
--
Higgeldy Piggeldy,
Hamlet of Elsinore
Ruffled the critics by
Dropping this bomb:
Phooey on Freud and his
Psychoanalysis --
Oedipus, Shmoedipus,
I just love Mom.

-- 
You received this message from the vim_mac 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: MacVim 7.3a BETA - Intel/10.6+

[Tony Mechelynck]

I forgot:
* Added
  - 'conceal' / 'ownsyntax' options (V. Negri)

-- 
You received this message from the vim_mac 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: How do I change the line height?

[Tony Mechelynck]

On 27/06/10 15:50, björn wrote:

On 27 June 2010 05:26, Tony Mechelynck wrote:


On Apr 21, 2:07 am, björnbjorn.winck...@gmail.com  wrote:

On 20 April 2010 17:18, Bjorn Tipling wrote:


I would like to increase the spacing between lines for better
readability. Is this possible in MacVim?


You'll want to try

:set linespace=1

and adjust the 1 to your liking.  Unfortunately, 'linespace' only
takes integer values so you may not be able to adjust it as precisely
as you would like.



How precise would you want to be? According to the help, 'linespace'
is measured in pixels, not in text lines.


My point is that 'linespace=1' adds up to quite a lot of extra (total)
space if you have a moderate amount of lines, making the lines seem
quite far apart (at least to my eyes).  On Mac OS X all drawing is
done using floats so fractional line spacing would allow for finer
control.

Björn



Well, my point is that the screen is made of pixels anyway, so that any 
fractional setting here would have to be rendered by spacing the lines 
unequally (e.g. lsp=0.25, if supported, would mean one additional pixel 
every four lines) which wouldn't be nice to look at.



Best regards,
Tony.
--
My theology, briefly, is that the universe was dictated but not
signed.
-- Christopher Morley

--
You received this message from the vim_mac 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: How do I change the line height?

[Tony Mechelynck]

On Apr 21, 2:07 am, björn bjorn.winck...@gmail.com wrote:
 On 20 April 2010 17:18, Bjorn Tipling wrote:

  I would like to increase the spacing between lines for better
  readability. Is this possible in MacVim?

 You'll want to try

 :set linespace=1

 and adjust the 1 to your liking.  Unfortunately, 'linespace' only
 takes integer values so you may not be able to adjust it as precisely
 as you would like.

 Björn

How precise would you want to be? According to the help, 'linespace'
is measured in pixels, not in text lines.


Best regards,
Tony.
--
My love, he's mad, and my love, he's fleet,
And a wild young wood-thing bore him!
The ways are fair to his roaming feet,
And the skies are sunlit for him.
As sharply sweet to my heart he seems
As the fragrance of acacia.
My own dear love, he is all my dreams --
And I wish he were in Asia.
-- Dorothy Parker

-- 
You received this message from the vim_mac 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: FuzzyFinder both works and don't

[Tony Mechelynck]

On Oct 19 2009, 8:24 am, Wraul mathias@gmail.com wrote:
 Hi
 I have a problem that I can't solve and would really appreciate some
 assistance. I'm quite new to vim so maybe it's really simple, but I
 can't figure out were it's going wrong or where I'm doing something
 wrong.

 I have installed the latest version (3.3) of the plugin 
 FuzzyFinderhttp://www.vim.org/scripts/script.php?script_id=1984

 If I use the version of vim that comes with osx the plugin works fine.
 If I uses the script mvim that comes with macvim the plugin works
 fine.
 If I use my alias gvim='/Applications/MacVim.app/Contents/MacOS/Vim -
 g' the plugin works fine.
 If I start MacVim using open /Applications/MacVim.app the plugin works
 fine.

 But if I start macvim from either Spotlight or Finder the plugin gives
 me the following error when for example I try to invoke it
 using :FufFile:
 Error detected while processing function fuf#onComplete..
 11..25..fuf#filterMatchesAndMapToSetRanks..SNR4_setRanks..SNR4_scoreBoundaryMatching:
 line    4:
 E806: using Float as a String

 I'm running snapshot 50 of MacVim on SnowLeopard.
 I have tried to move both .vimrc, .gvimrc and .vim/ and then
 reinstalling the plugin.
 I have also tired with the setting Launch Vim processes in a login
 shell both on and off.

 Thanks
 Wraul

I don't use FunnyFinder myself, but that message means (IIUC) that at
line 4 of function SIDscroreBoundaryMatching (or
s:scoreBoundaryMatching) in the script listed as #4 in the output of
the :scriptnames command, a variable which has already been assigned a
floating-point value is being reused as a String. (Note that, now that
Vim supports floating-point numbers, 4.5 is the floating-point value
four and a half while 4 . 5 (with intervening spaces) is the String
value '45'.)

Opening that script in Vim ought to let you see which variable that
is. Where it got that floating-point value is a different matter.


Best regards,
Tony.
--
When are you BUTTHEADS gonna learn that you can't oppose Gestapo
tactics *with* Gestapo tactics?
-- Reuben Flagg

-- 
You received this message from the vim_mac 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: Planning Vim 7.3

[Tony Mechelynck]

On 11/04/10 22:16, Bram Moolenaar wrote:


Christian Brabandt wrote:


Are you considering any patches from
http://groups.google.com/group/vim_dev/web/vim-patches
for inclusion?


Yes, but many of these patches are not mature.  E.g., first one,
Improved regular expression engine, is still lacking the tests to
verify that it doesn't break anything.  That's a pity, because it can
make syntax highlighting much faster.

I want to avoid that I include something that triggers a long sequence
of bug fixes.  Works fine for me is not always a good indication.
7.3 is going to be a stable release, thus I don't want to take too much
risc.  Part of my work will be to estimate the risc, which involves
carefully looking through the code changes.



It is true that they are in different stages of development. Here are my 
top five; not in preference order.


#14 (Vince Negri's conceal/ownsyntax/cursorbind) already has a long 
track record. I first heard about it when I first learned about Steve 
Hall's Vim for Windows, that must have been in Vim 6.2 or 6.3 time, and 
it was not new even then. Has documentation. Maybe too controversial 
(not enough mainline-like) to be included by default? OTOH it has been 
victim of bit-rotting in the past (i.e. conflict with mainline 
patches) and of course bringing it in would eliminate that problem 
forever. A compile-time option maybe (or two, or three)? You're the boss.


#13 (Access W32 clipboard from Cygwin Unix Vim) is interesting but 
still in beta. IIUC ifdeffed by whatever FEAT_* corresponds to 
has('win32unix'). Bring 'em in or let it bake some more?


#10 (Variable tabstops) sounds interesting. I haven't tested it. 
Reportedly still in alpha. Probably wait some more (Vim 8.0 ?) but keep 
an eye on it.


#9 (Relative line numbers) sounds interesting. I haven't tested it. Its 
authors say it works. I don't feel competent to evaluate it by 
eyeballing the code.


#7 (Bill McCarthy's additional float functions). This one I've taken up 
in my Huge Vim. Not a single problem AFAICT. Code examination shows 
that it is done cleanly and simply, within #ifdef FEAT_FLOAT, and does 
not interfere with other stuff outside the call function - return 
value codepath. IMHO this one is the most worthy of including into 
mainline Vim (and perhaps the least risky). Maybe a one-time check in a 
build with FEAT_EVAL on and FEAT_FLOAT off to make sure no #ifdef was 
forgotten. (I already compile a Tiny build without +eval in addition to 
my Huge build, from the same source, and no problems there either.) 
Documentation exists and is well-written, as a separate helpfile to 
avoid problems with rsync; probably merge that into eval.txt.



Best regards,
Tony.
--
   n = ((n   1)  0x) | ((n   1)  0x);
   n = ((n   2)  0x) | ((n   2)  0x);
   n = ((n   4)  0x0f0f0f0f) | ((n   4)  0xf0f0f0f0);
   n = ((n   8)  0x00ff00ff) | ((n   8)  0xff00ff00);
   n = ((n  16)  0x) | ((n  16)  0x);

-- C code which reverses the bits in a word.

--
You received this message from the vim_mac 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: Planning Vim 7.3

[Tony Mechelynck]

On 11/04/10 16:33, Bram Moolenaar wrote:
[...]

It would also be nice if we can update the spell files.  Volunteers
wanted!  See $VIMRUNTIME/spell/README.txt, the MAINTAINING A LANGUAGE
section.



IIUC, Mozilla uses the same spellfile format as Vim? If that's the case, 
and if the Mozilla license (which, BTW, is undergoing revision, see 
among others 
http://blog.lizardwrangler.com/2010/03/10/updating-the-mozilla-public-license/ 
), or whatever other license some of these dictionaries may be using, is 
found to be compatible with the Vim license, then maybe we could just 
borrow the desired files from the dictionaries at 
https://addons.mozilla.org/en-US/thunderbird/browse/type:3 ? (Note: an 
.xpi is just a .zip under another name.)



Best regards,
Tony.
--
Heavy, adj.:
Seduced by the chocolate side of the force.

--
You received this message from the vim_mac 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: Remote commands?

[Tony Mechelynck]

On Feb 16, 2:05 am, Sean DeNigris truste...@clipperadams.com wrote:
  Sorry for taking so long to reply to your posts.  I think what you are
  looking for is the remote functions, see :h remote.txt|/FUNCTIONS.

 I've been using remote, and thought there might be a better way, but
 after posting on vim_use, it seems the two options for remote commands
 are:
 1. sending keys
 2. wrapping exe in a function and calling it with remote-expr

 Thanks!

Ben Fritz gave you the following solution on vim_use:

--remote-send ':ruby delete_line(1)CR'

which I think is as economical (as elegant as a math teacher would
say) as you could get. I might add that you would maybe want to test
for Ruby support -- something like (untested):

--remote-send ':if has(ruby) | exe ruby_delete_line(1) | else |
echoerr Sorry, no ruby | endifCR'

(all on one line, and with single quotes around the whole to force the
Unix-like shell to pass the | as part of the parameter). I wrap the
ruby statement in an exe so that Vim versions without ruby support
would not try to parse it.

However you could delete the first line more easily without calling
ruby:

--remote-send ':1dCR'

(which is still an ex-command) or

--remote-send ggdd

In the latter case I think the quotes can be omitted since there are
no embedded spaces and no risk of interpretation by the shell.


Best regards,
Tony.
--
Hey!  Who took the cork off my lunch??!
-- W. C. Fields

-- 
You received this message from the vim_mac 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: Trailing ^M characters in .vimrc?

[Tony Mechelynck]

On Feb 27, 9:39 am, Jonathan jonathan.w...@gmail.com wrote:
 Apologies if this is an obvious problem, but the solutions I've been
 looking at don't seem to work.

 When I load MacVim (via mvim from the terminal), the following error
 messages appear:

 Error detected while processing /Users/jweed/.vimrc:
 line    2:
 E488: Trailing characters: nocompatible^M
 line    5:
 E474: Invalid argument: columns=80^M
 line    6:
 E474: Invalid argument: wrapmargin=8^M
 line    7:
 E492: Not an editor command: ^M

 Based on information I've found online, this seems to be a problem
 with line encodings. The only solutions I've found suggest fixing this
 problem by running a substitute command: %s/\r/\r/g. I've tried this
 (from inside MacVim) and it seems to work fine, but when I restart
 mvim the same error occurs and my .vimrc options are not set.

 Any suggestions? For reference, my .vimrc appears below, as it appears
 when I open it in macvim.

 Thanks, Jonathan


See :help :source-crnl

If you want to use a single vimrc on Unix-like Vim (which can only
handle LF-only ends-of-lines) and on Mac-Classic-like Vim (which can
handle either LF-only or CR-only but only if 'fileformats' [plural] is
not empty) you may have to (1) make sure that your vimrc was written
with 'fileformat' (singular) set to unix (use :setlocal ff=unix just
before writing it) and (2) invoke Vim with --cmd set ffs=mac,unix on
the command-line.

See also
:help 'fileformat'
:help 'fileformats'
:help --cmd


Best regards,
Tony.
--
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no
matter
what it does.
-- Will Rogers

-- 
You received this message from the vim_mac 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: mac-like arrow key navigation?

[Tony Mechelynck]

On Nov 27, 11:31 pm, dc dc.pik...@gmail.com wrote:
 hi -

 enjoying macvim, and its great for block editing.
 but does anyone have a mapping file for normal mac-like motion in
 insert mode?

 eg
 opt-left = move a word to left
 shift-opt-left = select a word to left
 cmd-opt-left = go to beginning of line
 opt-delete = delete a word

 etc.

 flipping to command-mode for each word motion is kinda tediious
 i tried like:
  imap M-Left Escbi

 without luck.

 btw these start/end of line emacs style keys are indispensable, it
 would just be great if they worked on the vi command mode as well as
 in the editor. hitting :e and editing a path, theres no easy way to
 just edit the command
  imap C-a Esc0i
  imap C-e Esc$a

Even if you have no Home or Ctrl key on your keyboard, I believe
you can still use these keys in the {rhe} of mappings, like this:

noremap!M-Left

-- 
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php

Re: mac-like arrow key navigation?

[Tony Mechelynck]

On Nov 27, 11:31 pm, dc dc.pik...@gmail.com wrote:
 hi -

 enjoying macvim, and its great for block editing.
 but does anyone have a mapping file for normal mac-like motion in
 insert mode?

 eg
 opt-left = move a word to left
 shift-opt-left = select a word to left
 cmd-opt-left = go to beginning of line
 opt-delete = delete a word

 etc.

 flipping to command-mode for each word motion is kinda tediious
 i tried like:
  imap M-Left Escbi

 without luck.

 btw these start/end of line emacs style keys are indispensable, it
 would just be great if they worked on the vi command mode as well as
 in the editor. hitting :e and editing a path, theres no easy way to
 just edit the command
  imap C-a Esc0i
  imap C-e Esc$a

Even if you don't have a Ctrl or Home key, I believe they can
still be used in the {rhs} of mappings, as follows:

noremap!M-LeftC-Left
noremap!S-M-Left  S-C-Left
noremap!D-M-Left  Home
noremap!D-M-Right End
noremap!D-Del C-W

etc. But I'm not on a Mac so I can't test it. They should work at
least in Console Vim (I suppose); for MacVim I'm not sure how much it
differs from mainline gvim. Note that I'm intentionally using
noremap! rather than inoremap, in order to get the same result in
both Insert and Command-line modes.

See
:help ins-special-special
and for the latter mapping (of course)
:help i_CTRL-W

Best regards,
Tony.
--
I'd love to go out with you, but I did my own thing and now I've got
to undo it.

-- 
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php

Re: Obviousmode. Highlight issue.

[Tony Mechelynck]

On Oct 30, 10:08 am, björn bjorn.winck...@gmail.com wrote:
[...]
 MacVim changes the colorscheme in its system gvimrc file, but only if
 you have not set another colorscheme manually.  However, the heuristic
 to check if the colorscheme has changed will fail if you only modify
 individual highlight entries which is why you are seeing this problem.
  Moving the highlight entries into your gvimrc will fix the problem.

 I never realized this problem was there.  Would you say that this
 urgently require a fix?  (It should work if I source the MacVim
 colorscheme in the system vimrc instead.  Will this cause other
 problems?)

 Björn

Why not leave the Vim colors at the compiled-in defaults? The MacVim
help (or something) could always mention that, _for those who like
it_, there is a macvim colorscheme available which is supposed to
blend better with the Mac look-and-feel.

Best regards,
Tony.
--
Arbitrary systems, pl.n.:
Systems about which nothing general can be said, save nothing
general can be said.

-- 
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php

Re: issue with textwidth and wrap

[Tony Mechelynck]

On Oct 19, 4:20 pm, Srinath srinath.vadlam...@gmail.com wrote:
 I want to use the line wrap mechanism usually done by :
 :set wrap
 :set textwidth=20
 This would normally allow for one to type upto 20 characters on one
 line and then have it continue on the next.

 I removed all of my user setting files and directories to make sure a
 plugin was not interfering.

 This seems to not happen with snapshot 50.   I invoke the 2 commands
 above and type characters and they continue for ever on one line.

 Is there a way in MacVim and vim to see what are all the global
 settings loaded?

 Thank you,
 Srinath

To see which settings are not at their defaults, use

:set

wih no arguments. To see all settings _including_ those still at their
defaults, use

:set all

However, 'wrap' and 'textwidth' have nothing to do with each other.
'wrap' will wrap your lines (without breaking them) at the window
margin, onto several screen lines per file line if necessary,
possibly in the middle of a word, and with absolutely no regard for
the value of 'textwidth'. 'textwidth' defines where Vim will _break_
lines (but usually only comment lines, not code lines) when you type
them. Where 'textwidth' will exert its influence is further defined by
the 'formatoptions' setting (see :help fo-table).

Note that the help says 'formatoptions' defaults to tcq if
'nocompatible', vt if 'compatible', however there are filetype-
plugins for various 'filetype's which set (locally, on files of that
filetype) a different value.


Best regards,
Tony.
--
If life is a stage, I want some better lighting.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: ^W+movement key - strange behaviour on Snow Leopard

[Tony Mechelynck]

On Oct 10, 9:45 am, Shirk sh...@bitspin.org wrote:
 OK,

 got it resolved.. it's not the fault of MacVim but of my keyboard
 layout.
 I'm using the dvorak layout provided here:http://halibrand.de/dvorak/
 (german) - this used to work fine with Tiger and Leopard
 but now it seem ^W doesn't send the right modifiers anymore..

 Thank you anyway!

 P.S. - I'm working on the transparency issues on SL, if all turns out
 well I'll submit a patch.

If you don't know which (if any) key combo will produce 0x17 (ASCII
Ctrl-W) on your keyboard, you can always use the :winc[md] ex-
command instead — see :help :wincmd.

P.S. Pleast bottom-post on the Vim lists (it's possible: you don't
have to keep the insert cursor above the quote the way the Google
Groups web interface sets it), see 
http://groups.google.com/group/vim_use/web/vim-information


Best regards,
Tony.
--
If God had intended Man to Watch TV, He would have given him Rabbit
Ears.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Simple Environment Questions

[Tony Mechelynck]

On Oct 9, 5:26 pm, Tyson Roberts nallo...@gmail.com wrote:
 Thanks Bjorn, that's exactly what I needed!

 (Was trying to detect both if and what gui vim was running in so that I
 could do some custom things on each platform/environment.)

 - Tyson

 On Sat, Oct 10, 2009 at 12:02 AM, björn bjorn.winck...@gmail.com wrote:

  2009/10/9 Tyson Roberts:
   How does one go about detecting whether vim was executed from within
   MacVim/gvim/in a command terminal?

   I'm trying to come up with a robust, relocatable vimrc framework at this
   point, now that I'm working on windows/mac/linux simultaneously.

   Also, anyone know a simple test to see if a g:fred variable has been
  defined
   or not?  I'm having trouble with that one (and kind of embarrassed I
  haven't
   found the answer after all these years). -_-

  Hi Tyson,

  I'm not sure this is what you are looking for, but have you tried

  if has(gui_macvim)
   ...

  The help on :h feature-list and :h has() may be of help.

  Björn

Yes: I'm not sure about MacVim but I know that the various flavours of
X11 Vim can run either in GUI mode or in Console mode with a single
executable, and that in that case the :gui command allows to go from
Console to GUI at any time after startup. So you may have to note the
differences between

has('gui')
compiled with GUI support
has('gui_gtk2')
has('gui_macvim')
has('gui_mac')
has('gui_proton')
has('gui_motif'')
has('gui_win32')
etc.: compiled with a certain GUI flavour (see them all under 
:help
feature-list)
has('gui_running')
either running in GUI mode, or (during startup) about to start 
the
GUI

I'm not sure whether has('gui_mac') is TRUE or FALSE in MacVim, nor
exactly to which Macintosh OSes it corresponds (GUI for any MacOS? for
MacOS9 or lower? other?). It is possible for more than one of the
gui_* features to be satisfied in a single executable: for instance
mine (Linux GUI for GTK2/Gnome2) answers 1 to all three of has
('gui_gtk'), has('gui_gtk2') and has('gui_gnome').

Also, when the GUI is started (be it during startup or, in the case of
a GUI executable with Console-mode support, possibly later in response
to the :gui command), it sources the system gvimrc (if found),
your .gvimrc or _gvimrc (on Unix-like systems, .gvimrc is tried first,
then _gvimrc if not found; on Dos-like systems it's the opposite), and
runs the autocommands for the GUIEnter event (provided, of course,
that it is compiled with the +autocmd feature, which, for a GUI-
enabled Vim, is usually the case).

The locations where Vim looks for the system gvimrc and for the user
[._]gvimrc are mentioned near the middle of the output of the
:version command. These locations may be modified at compile-time;
if they aren't, the system gvimrc is $VIM/gvimrc (with no dot or
underscore) and the user .gvimrc is $HOME/.gvimrc (and Vim tries an
underscore if it doesn't find it with a dot, or vice-versa on Dos/
Windows). To know what these environment variables mean to Vim, type
:echo $VIM or :echo $HOME (without the double quotes in both
cases, of course) in a running Vim.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
180. You maintain more than six e-mail addresses.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: encoding

[Tony Mechelynck]

On 30/09/09 17:07, Doris Wagner wrote:

 hi list,

 I am using vim from the terminal (mac os 10.5); I often use german
 umlauts;

 now, when I write the umlaut ö with another editor, in my case with
 texshop, and open the file with vim, there ist no ö displayed, but
 9a;
 apparently, something with the encoding is wrong;

 my .vimrc-settings are as in

 http://hoepfl.de/articles/2007/01/vimderbar.html

 recommended, that is:

 set encoding=utf-8
 set fileencoding=
 setglobal fileencoding=utf-8
 set fileencodings=ucs-bom,utf-8,latin1 set termencoding=latin1


 so can anyone help me?

 tia
 doris

Ox9A is not an o-umlaut in Latin1 or UTF-8: in Latin1 it is the control 
character SCI (Single Character Introducer), and in UTF-8, the 
_codepoint_ U+009A (encoded on disk as 0xC2 0x9A) is the same control 
character, while the _byte_ 0x9A can only be the second or further byte 
of a multibyte sequence.

I suspect that Texshop is using macroman as its encoding, but only you 
can ascertain that, by trial and error, as follows (in Vim):

(in the vimrc)
...
if has('multi_byte')
if enc !~? '^u'
if tenc == 
let tenc = enc
endif
set enc=utf-8
endif
if 0
 the following is optional
 (check the help before uncommenting)
set fencs=ucs-bom,utf-8,latin1
setg bomb fenc=latin1
endif
endif
...

(at the keyboard)
:e ++enc=macroman filename.enc

replacing filename.enc by the filename, of course. (You may want to 
have pre-recorded, using Texshop, a test file containing as many 
non-ASCII different characters as you can dream of.)

If it still isn't that, you'll have to try other charsets (Windows-1252, 
maybe?) as the argument of the ++enc modifier.

See :help ++opt


Best regards,
Tony.
-- 
Rule of the Great:
When people you greatly admire appear to be thinking deep
thoughts, they probably are thinking about lunch.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Bracket autocomletion

[Tony Mechelynck]

On Sep 15, 10:57 pm, Robert H sigz...@gmail.com wrote:
 On 9/14/09 9:30 PM, David Turetsky wrote:

  Of course, you could also be going crazy!

 I agree with that one.

 I had an inoremap in an old .vimrc that did autocomplete from { ( [
 brackets.

 Robert

Maybe something like

inoremap{   {CRCR}Up
inoremap[   []Left
inoremap(   ()Left

? (The special treatment for braces is because of the assumption that,
in C code (or similar), you want { and } at the end and start of a
line respectively, with the bracketed code on the intervening lines).


Best regards,
Tony.
--
So as your consumer electronics adviser, I am advising you to donate
your current VCR to a grate resident, who will laugh sardonically and
hurl it into a dumpster.  Then I want you to go out and purchase a
vast
array of 8-millimeter video equipment.

... OK!  Got everything?  Well, *too bad, sucker*, because while you
were gone the electronics industry came up with an even newer format
that makes your 8-millimeter VCR look as technologically advanced as
toenail dirt.  This format is called 3.5 hectare and it will not be
made available until it is outmoded, sometime early next week, by a
format called Elroy, so *order yours now*.
-- Dave Barry, No Surrender in the Electronics
   Revolution

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Option key mapped to meta AND getting the characters behind option?

[Tony Mechelynck]

On Sep 18, 6:54 pm, björn bjorn.winck...@gmail.com wrote:
 2009/9/17 krisse:



  I'm a macvim and latex-suite user. I'd like to utilize the alt-key
  macros provided by the latter, and found this [1] thread after some
  googling. Now, it does work and I get the alt-key macros all right,
  but I also need (quick) access to the characters normally found behind
  the option key.

  Tried searching for different (i)mapping stuff around the web, but
  can't figure out a) quite how to do it -- as I've never really dabbled
  with mappings before -- nor b) how best it might be done. One idea
  would be to use some other key as alt for the macros, like maybe
  caps lock, which I never use. But how would I go about doing it?

 Hi Krisse,

 I can't think of any way to accomplish what you are asking for.  Either:

 1) find another way of accessing the characters that need Alt (set up
 new bindings, use abbreviations :h abbreviations, use a keymap :h
 mbyte-keymap), or

 2) change the mappings in the vim-latex scripts to use another
 modifier instead of Alt (i.e. open up the vim-latex scripts and modify
 them directly)

 Unless you use a lot of the vim-latex bindings I guess the latter may
 be the simpler solution.

 Björn

However, the advantage of using a keymap (or making your own, see
http://vim.wikia.com/wiki/How_to_make_a_keymap ) is that you can
switch between the two sets of keybindings (those from the keymap and
the other ones) at the touch of a key (normally Ctrl-^ but you can of
course remap it if that key is not easily accessible, or not available
at all, on the keyboard layout you use).


Best regards,
Tony.
--
Fortune's Fictitious Country Song Title of the Week:
How Can I Miss You if You Won't Go Away?

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Replying to messages

[Tony Mechelynck]

On Sep 3, 2:42 pm, John Beckett johnb.beck...@gmail.com wrote:
[...]
 There is one page on the vim_use group that has general stuff,
 and I will take this opportunity to post my standard message:

 Reminder to everyone: Please bottom post on this list. Quote a
 small (relevant) part of the message you are replying to, and
 put your text underneath.

 See the list 
 guidelines:http://groups.google.com/group/vim_use/web/vim-information

 John

I know the general lines, but I just went there to read it again
attentively. (People, it's worth it.)

The last line made me LOL:

«If your expensive gadget can't bottom post, wait until you can find
a computer.»

though I would maybe not have gone that far. For short posts (about as
long as an SMS), including thank-you notes (whose utility is dubious
anyway) top- vs. bottom-posting doesn't matter much to me. The longer
the quote or the longer the reply, the more trimming and ordering
(question _then_ answer, or question then answer then reply to the
answer, etc.) are important I'd say.

Hm, thinking of it (and of how I'm replying in vim_mac, to which I'm
subscribed in digest mode, unlike vim_use, vim_dev and vim_multibyte
which are sent in full to my inbox), maybe I would have said:

«If your expensive gadget can't bottom post in email, have it (or
find something that can) browse the Google Groups and their web
interface.»

I've heard that some handheld devices include true browsers nowadays,
so why not use that, if you have to reply to the vim-list while
waiting for the bus to arrive? ;-)


Best regards,
Tony.
--
Abandon the search for Truth; settle for a good fantasy.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: About Animals

[Tony Mechelynck]

On Sep 2, 12:54 pm, John Beckett johnb.beck...@gmail.com wrote:
 I have no idea how this spam appeared on vim_mac. I am a manager
 for the Vim groups (actually, the only manager for vim_mac,
 apart from Bram who naturally does not get involved in
 moderating messages).

 Google Groups has had a dramatic increase in spam in the last
 few days, with over 40 spam attempts to the Vim groups in the
 last three days (a spammer creates an account then sends a
 message to a group; that message appears in a moderation queue
 for a manager to approve or reject).

 Anyway, I am certain that I clicked the Spam button in the
 management interface for this particular message, yet it was
 sent to the group (I have deleted it from the Google Groups
 archive). The gmail servers have been experiencing problems
 lately; perhaps some overload condition caused the Google Groups
 system to malfunction.

 I'm telling you all this to work off some steam: I am beginning
 to think that Google Groups is a bit of a disaster because it is
 too attractive and easy a target for spammers.

 John

Steam locomotives (when they existed, and wherever they still exist)
always have a safety valve, and it's for a reason. Let steam build up
too much pressure, and you burst.

Spam is a nuisance, and I think it is more obvious every day that,
like some diseases (AIDS, epilepsy, malignant cancerous tumors,
multiple sclerosis, ...), you can treat it some, but you can't win it
over. John, if it weren't for you, I don't know in what shape the Vim
groups would be. I also know that nobody's perfect: not me, not you,
not the Google people, nobody. Let's just each fill up our own tasks
as best we can, and hope for the better.


Best regards,
Tony.
--
Do you realize how many holes there could be if people would just take
the time to take the dirt out of them?

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: stop new windo from tiling?

[Tony Mechelynck]

On Aug 17, 9:23 pm, pixelterra r...@pixelearth.net wrote:
 When I hit cmd+n I get a new window. However they always tile, so that
 after 3 new windows, the window is partially off the screen. And I
 have to use my mouse (ewe) to move it back to visible.

 Any way to change this behavior. This doens't happen in Firefox...

In addition to all that has already been suggested, another
possibility would be to change _your_ behaviour, and use :new or
:sview (or :tabedit or :tab sview) to open a new window (or a new
tab) in the existing gvim, rather than a new gvim screen using Cmd-n


Best regards,
Tony.
--
On his first day as a bus driver, Maxey Eckstein handed in
receipts of $65.  The next day his take was $67.  The third day's
income was $62.  But on the fourth day, Eckstein emptied no less than
$283 on the desk before the cashier.
Eckstein! exclaimed the cashier.  This is fantastic.  That
route never brought in money like this!  What happened?
Well, after three days on that cockamamie route, I figured
business would never improve, so I drove over to Fourteenth Street and
worked there.  I tell you, that street is a gold mine!

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: modify TIS handling for cooperation with iminsert/imsearch

[Tony Mechelynck]

On Aug 28, 2:02 pm, björn bjorn.winck...@gmail.com wrote:
[...]
 I guess it sets it to Sweden because my time zone is set to Stockholm,
 Sweden...but it is a bit weird since my default language is English
 and my OS X version is English as well.

You might try using

language ctype en_US

or

language ctype C

(untested) near the top of your vimrc. I haven't tested it (I don't
use an IM).

See
:help :language


 Actually, it is pretty neat that it automatically switches to the
 current locale (i.e. Swedish in my case) since this is most likely the
 expected behaviour when 'imd' is set.  Your tip of setting imi=0 and
 ims=0 reverts the behaviour back to what I first envisioned...so this
 is definitely an improvement!  I've got set imd imi=0 ims=0 in my
 gvimrc as well now.
[...]

Setting 'ims' to -1 (meaning use 'imi') could be useful: it means
changing 'imi' applies automagically to the / and ? search commands,
in addition to Insert mode, Ex-commands, and some Normal mode command
operands such as r f t etc. (all of which, IIUC, always use 'imi').

I don't know where (if anywhere) the Ctrl-^ key is on my keyboard, so
I use the following keymap-related commands in my vimrc:
set imi=0 ims=-1
noremap F8:let l:imi = !l:imi
inoremapF8C-O:let l:imi = !l:imi
cnoremapF8C-^

For IM, you would of course multiply the right-side operand of the
:let statements by 2, making it  2*(!l:imi). (Ctrl-^ has a
different meaning in Normal mode; the above allows F8 to toggle
keymaps [or, with the indicated change, IM] in any mode.)


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
114. You are counting items, you go 0,1,2,3,4,5,6,7,8,9,A,B,C,D

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Horizontal scrolling on the trackpad

[Tony Mechelynck]

On Jul 15, 5:59 pm, Tiago Taveira tiagotave...@gmail.com wrote:
 Hi,

 I use a Powerbook G4 which has the two-finger vertical and horizontal
 scrolling through the trackpad. However, I can only use the vertical
 one with MacVim, horizontally it doesn't work (I also have the
 scrollbar active with 'set guioptions+=b' if that's relevant).

 Should it work somehow, or it isn't implemented?

 Thanks,
 Tiago

Does it make a difference if you move the mouse pointer onto the
horizontal scrollbar and _then_ start scrolling? With my wheelmouse it
does (on gvim with GTK2/Gnome2 GUI on Linux).

Best regards,
Tony.
--
Quick, sing me the BUDAPEST NATIONAL ANTHEM!!

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Feature request: fuenter/fuleave autocommands

[Tony Mechelynck]

On Jun 25, 9:41 pm, alexanderkahn alexanderk...@gmail.com wrote:
 In :help 'fullscreen' there is this note:

         XXX: Add fuenter/fuleave autocommands? You might want to display
         a NERDTree or a Tlist only in fullscreen for example. Then again,
 this
         could probably be in a sizechanged autocommand that triggers if the
         size is above a certain threshold.

 I think that would be an *awesome* feature. I have two widescreen
 displays, so my use case would be to set 'columns' to be very wide
 when using fullscreen mode, but set it back to being normal width when
 leaving fullscreen. Then I could have two vsplits side by side. I
 could also set up this vsplit to be automatically set up based on
 whatever the the buffer being edited in the next tab.

 Sorry that I'm just asking for a feature and don't have the capacity
 to actually write the code myself, but I thought I would just chime in
 and say that thees autocommand hooks would be very useful!

 Cheers,
 Alex

There already is a VimResized autocommand. You could use it to call a
function which would check lines and/or columns against your
threshold, then open or close your vertical split-window (your
sidebar, maybe) accordingly.

But your speaking of changing 'columns' when entering or leaving
fullscreen mode makes me doubt. If you mean that Vim should react on
maximizing or un-maximizing the Vim screen by hand, which
automagically changes the 'columns' setting (it does, just try it)
then the above paragraph applies. If you want to have Vim resize
itself when the pixel width of your monitor changes, then I believe
there is no portable Vim way to do that. (As shown in Nico's post,
there is a Mac-specific way. Beware that 'fuopts' doesn't exist on
standard Vim so you shouldn't expect to see it work if you use Vim
on Unix, Linux, Windows, etc. in addition to the Mac.)

BTW, VimResized (like all autocommands) applies to all versions of
Vim, not only the Mac version; people on the vim_use group could have
told you about it. (How to make the OS resize Vim when the screen
pixel size changes _is_ Mac-specific all right.)


Best regards,
Tony.
--
Never worry about theory as long as the machinery does what it's
supposed to do.
-- R. A. Heinlein

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Naming window tabs

[Tony Mechelynck]

On Jul 9, 12:11 pm, Mariusz Nowak marius...@gmail.com wrote:
 It'll be nice to be able to give custom names to window tabs. Has
 anybody thought of such option ?

 In each tab I have few files open. Each tab is for different task
 really, then when there are many tabs open it's difficult to find tab
 for specific task. They're named after files currently focused in them
 which in many cases is not very informative.

You can create custom tabs with any text you like, using the
'guitablabel' option for GUI-like tabs, or the 'tabline' option for
text-like tabs, even in the GUI if you remove the e flag from
'guioptions'. (The advantage of using text-like tabs in the GUI is
that you can have identical tabs in gvim and Console Vim, and set them
at a single place in your vimrc.)

See
:help 'guitablabel'
:help 'tabline'
:help 'guioptions'
:help 'go-e'
:help 'showtabline'

Best regards,
Tony.
--
Only adults have difficulty with childproof caps.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Zoom window horizontally too?

[Tony Mechelynck]

On Jul 8, 6:14 am, David M. Wilson d...@botanicus.net wrote:
 Hi there,

 I've been digging through the docs with no luck. Basically, I have a
 global accelerator assigned to any menu option labelled Zoom. This
 has the effect in Terminal of expanding the focused window to full
 vertical/horizontal dimensions.

 Can this be done with MacVim? I noticed the old Carbon port also only
 maximized vertically, so I thought perhaps there is a generic Gvim-
 related option for it.

 (I'm aware of full screen mode - awesome! but not quite what I want)

 Thanks,

 David
 PS: this thing rocks

In addition to what Björn said, you should be able to use

:set lines=9 columns=9

in your gvimrc, or in a :if has('gui_running') wrapper in your
vimrc, to always maximize the Vim GUI (gvim or, I suppose, MacVim).

You can also zoom the split-windows inside Vim:

- to do it always, put this in your vimrc:

if has('windows')
set winminwidth=0 winwidth=9 winminheight=0 winheight=9
endif

I use it only for the height, since when running vimdiff I prefer to
have vertically split windows of equal width.

- to do it once (from the keyboard, in Normal mode):
- horizontally: Ctrl-W |
- vertically: Ctrl-W _

see
:help 'lines'
:help 'columns'
:help 'winheight'
:help 'winminheight'
:help 'winwidth'
:help 'winminwidth'
:help CTRL-W__
:help CTRL-W_bar


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
67. Your hard drive crashes. You haven't logged in for two hours.  You
start
to twitch. You pick up the phone and manually dial your ISP's
access
number. You try to hum to communicate with the modem.  You
succeed.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Failed to dragdrop-open a file with wide-chars in its filename

[Tony Mechelynck]

On 24/06/09 14:00, björn wrote:

 Hi Eljay,

 2009/6/23 John (Eljay) Love-Jensen:

 As far as I can tell (from searching around) HFS+ always uses
 normalization form D (NFD) for filenames.

 HFS+ uses a variant of NFD for filenames.  (The HFS+ variant predates
 standardizatoin of NFD.)  This requirement is enforced by the OS.

 http://developer.apple.com/technotes/tn/tn1150.html
 http://developer.apple.com/technotes/tn/tn1150table.html
 http://developer.apple.com/qa/qa2001/qa1235.html
 http://www.unicode.org/reports/tr15/

 Thanks for clarifying that (and for the links!).

 Windows uses NFC for filenames.  I'm not sure if the Linux world settled on
 NFC or NFK.

 I read that Windows uses NFKC.  Have you got a reference for the claim
 that NFC is used?

 So as a workaround for the issue the OP had I now normalize filenames
 to compatibility form C (NFKC) before passing the filename on to Vim
 and this takes care of the OP's problem.

 NFC or NFKC?  Those are different normalizations.

 Windows NTFS file system uses NFC.  But it isn't enforced by the OS, yet.

 I did mean the compatibility form NFKC since I read somewhere that
 NTFS uses NFKC, but I did not research that very carefully.


 However, as I see it this really is a legitimate issue in Vim itself
 in that it does not handle NFD properly (the example above should
 always render as one glyph, not three as it does now if NFD is used).
 Either Vim should ensure that all buffers are normalized to composed
 form NFC/NFKC or it needs to be made NFD aware.

 I agree with your assessment.

 Does anybody on the vim_multibyte list (this mail goes to vim_mac as
 well) have any comments on this?

 The relevant Mac OS X routine APIs are:

 CFURLRef url =
 CFURLCreateWithFileSystemPath(
   kCFAllocatorDefault,
   cfstringFullPath,
   kCFURLPOSIXPathStyle,
   false));

 char bufferUTF8[32768*4]; // Worst case scenario.
 // As per Apple documentation, paths can be up to 30,000 UTF-16
 // encoding units long, with each component being up to 255 UTF-16
 // encoding units long.  Too bad there isn't an API to specify the
 // exact buffer size /a priori/.

 Boolean success =
 CFURLGetFileSystemRepresentation(
   url,
   true,
   bufferUTF8[0],
   sizeof bufferUTF8);

 Thanks.  NSString has a method called fileSystemRepresentation which
 I'm guessing does the same thing(?).  I used the NSString method
 precomposedStringWithCompatibilityMapping to convert to NFKC.

 Björn

Hm, NFKC and NFKD sometimes fuse slightly different glyphs into a single 
normalized form. For instance, NFKC(²) = 2, though both are 
(different) Latin1 characters (0xB2 and 0x32). IIRC, DOS would have kept 
them distinct.

Best regards,
Tony.
-- 
hundred-and-one symptoms of being an internet addict:
56. You leave the modem speaker on after connecting because you think it
 sounds like the ocean wind...the perfect soundtrack for surfing 
the net.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Failed to dragdrop-open a file with wide-chars in its filename

[Tony Mechelynck]

On 20/06/09 19:58, björn wrote:

 2009/6/20 Tony Mechelynck:

 On Jun 19, 11:22 pm, björnbjorn.winck...@gmail.com  wrote:
 [...]
 I'm afraid I know way too little about text rendering to fix this, so
 until somebody else fixes it in core Vim the problem will remain.  I
 would highly suggest that you take up the rendering problem on the
 vim_dev mailing list (just send a text file with 한 as the content and
 ask why it renders as three glyphs).

 Sorry,
 Björn

 The OP's problem was about a file with 한 as (part of) the filename,
 not as the content.

 Tony,

 I appreciate that you reply to my post, but there really is no need in
 stating the painfully obvious.  The problem appears when the filename
 is displayed in the command line (as a result of opening the file) and
 as such you run into the same problem if you have that character as
 part of the contents of a file.

 I'm on Linux, so what I see may be different from what you see on
 MacVim; but in gvim I see 한 (when in the content of a file) as one
 glyph (U+D55C, corresponding to three bytes, hex ED 95 9C). Are you
 sure you have 'encoding' correctly set? (I use utf-8).

 I tried it myself on Linux and had the same problem and realized that
 the problem has to do with how you represent 한.  If done as you
 suggest with U+D55C it works (both Linux and MacVim), but if
 represented by U+1112, U+1161, U+11AB then Vim will render it as three
 glyphs but here the Cocoa text system combines these into one glyph
 and that is where the problem in MacVim appears.  (By the way: MacVim
 defaults to use utf-8 for 'encoding'.)

Ah, I see. I entered it in Vim by copy-paste from your previous post in 
the vim_mac Google Group page in my browser.

Vim is obviously unaware of hangul jamo decomposition / recomposition 
and IIUC will render each of them as one glyph. I'm not sure how to have 
them be treated as one spacing + (in this case) 2 composing characters 
though IIUC it would be the right way to do it.


 So in a way the problem is related to having 한 in a filename since Mac
 OS X apparently represents it as U+1112, U+1161, U+11AB instead of as
 U+D55C.  Still, if one were to enter those three characters separately
 in a buffer the same problem would arise.  As far as I see it this
 only means that the Cocoa text system is not suitable for this purpose
 which only means that we will have to migrate to the ATSUI or CoreText
 renderers sometime in the future.

 To conclude: it seems that this is a problem with the Cocoa text
 system and not that something in Vim has to be fixed as I stated in
 my previous post (unless Vim should do the same as Cocoa and
 automatically render ᄒ,ᅡ,ᆫ as 한).

 Björn

Well, sorry I can't help you.


Best regards,
Tony.
-- 
Really heard in court in the U.S.A.:
Q.: Doctor, before you started the autopsy, did you check the pulse?
A.: No, I didn't.
Q.: Did you test the blood pressure?
A.: No, I didn't.
Q.: Did you check the breathing?
A.: No, I didn't.
Q.: Then there is a possibility that you autopsied a living person?
A.: No, there isn't.
Q.: How can you be so sure, Doctor?
A.: Because his brain was in a jar on my desk.
Q.: I see. But couldn't the patient be still alive nevertheless?
A.: Hm, yes, he could still be alive, practicing as a lawyer.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Compiling vim on OSX Leopard

[Tony Mechelynck]

On 07/05/09 00:09, R. Hicks wrote:

 I just tried with the following configure (after getting the latest from
 svn):

 ./configure --enable-cscope --enable-multibyte --with-features=huge

 I get a whole bunch of gui_mac warnings and errors and at the end it
 reports:

 make[1]: *** [objects/gui_mac.o] Error 1
 make: *** [install] Error 2


 Is this a known problem?

 Robert

This is not the right group for such a specific question.

This group is about problems related with _using_ already compiled 
versions of Vim.

Problems related with _compiling_ Vim in general should go to the 
vim_dev group, and specific problems about Vim on the Mac (including 
compiling Macvim) should go to the vim_mac group, so I'm trying to 
redirect the replies to this email. Please subscribe to those two groups 
if you haven't yet.

In general, you should make sure to have the include files for every 
software that you want to compile into Vim. This usually means 
installing the corresponding development packages. You should go 
through all those configure errors one by one and see if there are 
installable modules, possibly development packages, that you could 
install to make them disappear.

For the MacVim build, I don't know the details, but I think that an 
unofficial patch is necessary. I could, however, quite easily be wrong 
in that respect since I am on Linux myself and previously I've been on 
Windows but never on a Mac.

In general, I believe that my HowTo page 
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm might still 
be helpful to you (since OS X is a Unix-like OS), but I also believe 
that on the Mac it is not the full story.


Best regards,
Tony.
-- 
The Schizophrenic: An Unauthorized Autobiography

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: MacVim looks different when invoked as gvim

[Tony Mechelynck]

On Apr 17, 9:01 pm, dwhit dwhitma...@gmail.com wrote:
 I'm running 'MacVim 7.2 stable 1.2/33.3' and using the mvim shell
 script provided with it. I have it in ~/bin/ with symlinks to it from
 view, vim, gview, and gvim. $ gvimenter gets me a new MacVim window
 with a black bg and white text. Cmd-N on a running MacVim gets me a
 new MacVim window with a white bg and black text. Why the difference
 and where can I change it to act the same?

 Thanks,
 David

Try
:set bg=light
:hi Normal guibg=white guifg=black
:syntax enable

in your gvimrc or in an autocommand for the GUIEnter event. Beware: I
cannot try it myself, because I'm not on a
--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: DejaVu Sans Mono, MacVim, Combining Diacritics

[Tony Mechelynck]

On 16/04/09 01:57, Kenneth Reid Beesley wrote:
 Problem with rendering Combining Diacritics, using DejaVuSansMono in
 MacVim/gvim


 I use MacVim/gvim with either

   1.  DejaVuSansMono.ttf , currently 2.29, or
   2.  BrighamVuSansMono.ttf (my modification of DejaVuSansMono.ttf
 2.22 that I augmented, using FontForge, with Deseret Alphabet glyphs)

 With input sequences involving combining diacritics, and having
 nothing to do with the added Deseret Alphabet glyphs, I somehow have
 better results with BrighamVuSansMono.ttf (based on DejaVuSansMono.ttf
 2.22) than with DejaVuSansMono.ttf 2.29.

 For example, if, using DejaVuSansMono.ttf 2.29, I enter (in MacVim/
 gvim) the sequence

 0 0061LATIN SMALL LETTER A
 1 0328COMBINING OGONEK
 2 0301COMBINING ACUTE ACCENT
 3 0020SPACE
 4 0061LATIN SMALL LETTER A
 5 0301COMBINING ACUTE ACCENT
 6 0328COMBINING OGONEK
 7 0020SPACE
 8 000a

 the gvim rendering is garbled.  (I should see two instances of 'a'
 with ogonek below and an acute accent above.)
 The 'a's are not displayed, and there are some floating accents.
 Here's a picture of the result in my gvim window:
[...]

You're spurring me to run some more tests on my version of gvim.

I'm on Linux with GTK2 gvim, and I don't have BrighamVu Sans Mono 
installed, but I have DejaVu Sans Mono and I normally use Bitstream Vera 
Sans Mono (another avatar of DejaVu, I think). I tried your examples 
with a very large font size (20) to avoid any possible errors due to 
incorrectly seeing what was displayed. Also, I added several spaces 
before, between and after the two complex characters so as not to miss 
badly located combiners. I'm not sure which versions of the fonts are 
installed, but gvim is 7.2.148 and GTK2 is 2.14.4.

Bitstream Vera Sans Mono 20: for both examples the first combining char. 
is correctly located but the second one is one character cell to the 
right of where it ought to be; when moving the block cursor over it by 
one cell at a time, I see the following: with the cursor on the a, the 
ill-placed combiner blinks in opposite phase with it; if I move the 
cursor right from there, that ill-placed combiner disappears, but Ctrl-L 
or focus off-on makes it reappear. Moving the cursor left from the a 
makes the ill-placed combiner stay visible.

DejaVu Sans Mono 20: the first example is displayed correctly (with 
acute above and ogonek below). The second one has its ogonek correctly 
placed, but the acute is now one cell left of where it ought to be, and 
the visual weirdness described above is reversed: displayed in opposite 
phase when the block cursor blinks atop the a (but this time barely 
visible against the background during the blinking cursor's on phase), 
disappears if I move the cursor left from there, reappears by Ctrl-L or 
focus off-on, remains shown if I move the cursor right from there.

Let's try another font: Courier New 20. Here the second example is 
displayed correctly, the first one has its acute one cell right of where 
it ought to be, same weird interaction with the blinking block cursor as 
the BitStream Vera ogonek.

And another: Lucida Typewriter 20. Same results as with Bitstream Vera.

And another: FZFangSong 20 (a Chinese font). Same results again (yes, 
even ogoneks exist in this Chinese font).


I wonder what makes one character display correctly (for me) in DejaVu, 
the other one in Courier, and neither in the other fonts. I don't think 
it is Vim (though I might be wrong), but is it something in the font, or 
something in the GUI interface (GTK2 in my case)? I don't know.


Best regards,
Tony.
-- 
Any fool can paint a picture, but it takes a wise person to be able to
sell it.

--~--~-~--~~~---~--~~
You received this message from the vim_mac maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---