headers
Vigil | 1 Jul 2005 01:58
Favicon

Re: editing long string literals in languages without multi-line strings

I don't know a general solution, but SQLUtilities is good for formatting SQL 
statements.

http://www.vim.org/script.php?script_id=492

--

-- 

.
Permalink | Reply | 0 comments |
headers
adah | 1 Jul 2005 04:23

Re: Woe with MBCS File Names in UTF-8 Mode on Windows

Do you have `set encoding=UTF-8' in your _vimrc or somewhere? If not, you 
will have no problems at all. If yes, please tell me your exact version 
and patch number as reported by `:version'.

Best regards,

Yongwei





Strange <strangemk2 <at> citiz.net>
2005-07-01 01:24

 
        To:     vim <at> vim.org
        CC: 
        Subject:        Re: Woe with MBCS File Names in UTF-8 Mode on Windows

I've a try with my gvim, it seems I can't find any problem about
the 测试件.txt with 测试 in it, encoded as UTF-8, Both in command prompt
or :e!.
I'm using a chinese version of windows2000 sp4.

Best regards,

Strange

On Thu, Jun 30, 2005 at 11:42:27AM +0800, adah <at> netstd.com wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
adah | 1 Jul 2005 07:26

Re: Woe with MBCS File Names in UTF-8 Mode on Windows

> > BTW, the strange problem seems in the three Chinese characters.  `:e
> > 测试.txt' and `:e 试件.txt' both are OK.  However, some other
> > characters in the file name can become corrupt when saving the file,
> > e.g., 炜 (e7829c in UTF-8, ecbf in GBK) will become ç? (c3a7 c282 in
> > UTF-8).  I have no clue how it comes.
> 
> I'm afraid I also don't know.  Perhaps there is some problem with
> conversion from Unicode to your current codepage.  This uses the
> MS-Windows library functions, thus it's not something I can fix.

I did a trace into Vim, and I found that it was because the `9c' of
e7829c (炜) had been lost before mch_open is called.  Could this give
you a clue?  Or give me a guidance where I should investigate further?

Best regards,

Yongwei
Permalink | Reply | 1 comment |
headers
adah | 1 Jul 2005 07:41

u_int not defined in nbdebug.h of vim 6.3 src

I found this when building a debug version of Vim 6.3.078 with

  nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes GIME=yes MBYTE=yes 
DEBUG=yes

Adding a `typedef unsigned int u_int;' works for me, but I think there 
should be better ways.

Best regards,

Yongwei
Permalink | Reply | 1 comment |
headers
Steven Weng | 1 Jul 2005 07:58
Picon

Can Ctags find the all the caller of a function?

Hi all,

Ctags can find the function definition easily. Also I can use the find and grep
to  find the all the function in a project.

My question is "can Ctags find the all the caller of a function?"

Thanks
Steven
Permalink | Reply | 1 comment |
headers
Thomas Geulig | 1 Jul 2005 08:43
Picon

Re: Can Ctags find the all the caller of a function?

> My question is "can Ctags find the all the caller of a function?"

ctags can't, but you can try cscope (http://cscope.sourceforge.net/).

Thomas
Permalink | Reply | 0 comments |
headers
Antony Scriven | 1 Jul 2005 11:35

Re: Mapping the > character

On Jun 30, David Fishburn wrote:

 > Vim 6.3.75 WinXP SP2
 > 
 > Standard usage:
 > :map <C-F1> :do something<CR>
 > 
 > But what if you want to use the "<" and ">" keys in your map?
 > 
 > Really I wanted CTRL->, but I do not believe we can use
 > that key since if I type:
 > :<C-V><C->>  (^V, followed by ^>)
 > I do not get any output, so I assume this means I cannot
 > map that key.
 > 
 > So I tried ALT->, using ^V I can see this has a value.
 > So I can map it using ^V and then the character.
 > However, I do not like doing this since it is not
 > particularily self documenting.  Is there anyway to map
 > these characters while escaping them (or something).

Try typing a ^V M-> in a buffer and then use ga to see what
it is. Just a quick check: you are typing M-> and not M-.
right? In gvim on W32 I find mapping <M-.> and <M->> works
fine.

Antony
Permalink | Reply | 1 comment |
headers
Bram Moolenaar | 1 Jul 2005 11:41
Picon

Re: u_int not defined in nbdebug.h of vim 6.3 src


Yongwei wrote:

> I found this when building a debug version of Vim 6.3.078 with
> 
>   nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes GIME=yes MBYTE=yes 
> DEBUG=yes
> 
> Adding a `typedef unsigned int u_int;' works for me, but I think there 
> should be better ways.

Disable the NBDEBUG code.  I don't know how it got enabled, it's not
useful for Vim debugging.

--

-- 
hundred-and-one symptoms of being an internet addict:
196. Your computer costs more than your car.

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Permalink | Reply | 0 comments |
headers
Bram Moolenaar | 1 Jul 2005 11:41
Picon

Re: Woe with MBCS File Names in UTF-8 Mode on Windows


Yongwei wrote:

> > > BTW, the strange problem seems in the three Chinese characters.
> > > `:e 测试.txt' and `:e 试件.txt' both are OK.
> > > However, some other characters in the file name can become corrupt
> > > when saving the file, e.g., 炜 (e7829c in UTF-8, ecbf in
> > > GBK) will become ç? (c3a7 c282 in UTF-8).  I have no clue how it
> > > comes.
> > 
> > I'm afraid I also don't know.  Perhaps there is some problem with
> > conversion from Unicode to your current codepage.  This uses the
> > MS-Windows library functions, thus it's not something I can fix.
> 
> I did a trace into Vim, and I found that it was because the `9c' of
> e7829c (炜) had been lost before mch_open is called.  Could
> this give you a clue?  Or give me a guidance where I should
> investigate further?

I would guess that somewhere in the code the DBCS codepage is used to
locate the character, instead of using it as UTF-8.  Since I don't have
a DBCS system, I can't try this.

If you are able to see what happens in a debugger then you should be
able to follow the route from typing the command to the mch_open() call.

--

-- 
Some of the well know MS-Windows errors:
	ETIME		Wrong time, wait a little while
	ECRASH		Try again...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bram Moolenaar | 1 Jul 2005 11:41
Picon

Re: Crash with 'substitute' in gvim (win32)?


Pero Brbora wrote:

> > If you run the same example with a debug build of gvim
> > (gvimd.exe) ... does it give some more human-readable fault-
> > logging information?
> 
> Nothing except info from "fault log" (see bellow).
> 
> I tried to provide you with a lot of info (not too much I hope).
> I must say that I wasn't alvays able to reproduce it (!?), but I
> managed to get some info from gdb.
> 
> See bellow for:
> --gdb log
> --fault log
> --gvimd version
> --bugreport script (gvim)
> 
> It would be nice if someone also could reproduce it, although crash
> reproduction is about 90% here.
> Also I found that "#" in 1st and 2nd line are significant, without
> them - no crash. And if you write right before issuing command
> history - sometimes no crash. So please use "example file" bellow
> and follow "crash scenario".

It appears that the crash happens in the syntax highlighting code.  But
when you edit a file like you describe syntax highlighting will not be
used.  Your bugreport also shows that the 'syntax' option is empty.
I'm guessing you have at least done ":syntax on".  Then perhaps it's the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane