-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

My dream for a long time now is to
embed somehow vim into thunderbird
compose area and mozilla/firefox textarea's.
I wonder whether there is some simple way
to do that... IIRC there is gtk2 widget for
embedding VIM...

Some kind of "regular" plugin to implement some
features of VIM I guess would not be good enough
because you actually reimplement VIM which is
not generally good idea IMHO.

Regards,
Ilya
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBDL3qcrmCGtFx9Y8RAtr3AJwJEvp6WZm/c9lcAnypR7mJF3uCBwCfWPLw
IL6hhSlYM7Mrb08eZm5ACTI=
=wHMU
-----END PGP SIGNATURE-----

hey all,

I was wondering if it was possible to jump on multi-character delimiters, ie:

<div>
	 <div>
		 <div>
		 </div>
	 </div>
</div>

ie - I've just started editing html files, and am already finding it very
irksome.
Hopefully, vim has a technical solution up its sleeve...

Ed

On Sun, Aug 01, 2004 at 05:33:06PM -0700, Edward Peschko wrote:
> hey all,
>
> I was wondering if it was possible to jump on multi-character delimiters, ie:
>
> <div>
>  <div>
> 	 <div>
> 	 </div>
>  </div>
> </div>
>
> ie - I've just started editing html files, and am already finding it very
irksome.
> Hopefully, vim has a technical solution up its sleeve...
>
> Ed

      You want to use the matchit plugin, part of the standard
distribution in the macros/ directory.  See

:help matchit-install

HTH 			 --Benji Fisher

[I tried to send this before, but because it was cross-posted to
haskell-cafe, I used the wrong from address.  Nobody replied on
haskell-cafe, so I request that it be applied unless there are
objections here.]

haskell-cafe, you are listed as the maintainer of the vim haskell syntax
highlighting script.  :-)

lhaskell.vim uses the tex.vim syntax script, which does "set
iskeyword-=_".  This makes editing haskell rather uncomfortable (eg, the
'*' command doesn't work right).  I don't know what breaks if you "set
iskeyword+=_", but getting tex highlighting right is less important than
haskell editing, so I suggest this patch.

Andrew

--- lhaskell.vim.orig   2004-07-29 16:48:39.000000000 -0700
+++ lhaskell.vim        2004-07-29 16:50:16.000000000 -0700
@@ -86,6 +86,8 @@
         runtime! syntax/tex.vim
         unlet b:current_syntax
      endif
+    " This messes up tex a bit, but is better for Haskell.
+    set isk+=_
  endif

  " Literate Haskell is Haskell in between text, so at least read Haskell

Hello,

I would like to implement a script, which would
work much like transliterator at translit.ru
Namely, when active, the script would process
every typed character, and act on it. Based
on the current character and previous characters,
it would then output russian cyrillic characters.

I was wondering if someone can point me in the right
place: perhaps an example script that does something
similar (processing individual keypresses), or portions
of :help

I can't seem to find an event in help that would
correspond to a keypress.

Thanks!

denis
--
// mailto: Denis Perelyubskiy <lists at overwhelmTAKECAPITALSOUT dot net>
// icq   : 12359698

hey,

Now that I've got matchit working (thanks much) I'm wondering if there
is something similar for python. Unfortunately, since python doesn't
have any keywords to bounce against, just intelligent whitespace, I don't
see how it could fit into the matchit paradigm.

Is there are plugin specifically for python?

thanks again,

Ed

Edward Peschko wrote:
> hey,
>
> Now that I've got matchit working (thanks much) I'm wondering if there
> is something similar for python. Unfortunately, since python doesn't
> have any keywords to bounce against, just intelligent whitespace, I don't
> see how it could fit into the matchit paradigm.
>
> Is there are plugin specifically for python?

  From Benji Fisher, the maker of matchit.vim, comes python_match.vim,
the matchit.vim for python, available at

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

Dan Sharp

On Mon, Aug 02, 2004 at 10:58:15AM -0700, Denis Perelyubskiy wrote:
> Hello,
>
> I would like to implement a script, which would
> work much like transliterator at translit.ru
> Namely, when active, the script would process
> every typed character, and act on it. Based
> on the current character and previous characters,
> it would then output russian cyrillic characters.
>
> I was wondering if someone can point me in the right
> place: perhaps an example script that does something
> similar (processing individual keypresses), or portions
> of :help
>
> I can't seem to find an event in help that would
> correspond to a keypress.

      I think the simplest thing you can do (and it is not very simple)
is to :imap every alphabetic character.  For an example, see
word_complete.vim at
http://vim.sourceforge.net/scripts/script.php?script_id=73

HTH 			 --Benji Fisher

On Mon, Aug 02, 2004 at 05:57:58PM -0700, Edward Peschko wrote:
> hey,
>
> Now that I've got matchit working (thanks much) I'm wondering if there
> is something similar for python. Unfortunately, since python doesn't
> have any keywords to bounce against, just intelligent whitespace, I don't
> see how it could fit into the matchit paradigm.
>
> Is there are plugin specifically for python?

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

HTH 			 --Benji Fisher

On Mon, Aug 02, 2004 at 09:56:58PM -0400, Dan Sharp wrote:
> Edward Peschko wrote:
> >hey,
> >
> >Now that I've got matchit working (thanks much) I'm wondering if there
> >is something similar for python. Unfortunately, since python doesn't
> >have any keywords to bounce against, just intelligent whitespace, I don't
> >see how it could fit into the matchit paradigm.
> >
> >Is there are plugin specifically for python?
>
> From Benji Fisher, the maker of matchit.vim, comes python_match.vim,
> the matchit.vim for python, available at
>
> http://www.vim.org/scripts/script.php?script_id=386
>
> Dan Sharp

wow.. that's cool.. any chance on getting that included with the standard
distribution (and maybe making matchit.vim automatically call it instead
if your filetype so happens to be equal to python?

Ed

Important notice!

Your document is attached to this mail.

Denis Perelyubskiy wrote:

>I would like to implement a script, which would
>work much like transliterator at translit.ru
>Namely, when active, the script would process
>every typed character, and act on it. Based
>on the current character and previous characters,
>it would then output russian cyrillic characters.
>
>I was wondering if someone can point me in the right
>place: perhaps an example script that does something
>similar (processing individual keypresses), or portions
>of :help
>
>
You can use 'imap' in large doses. Just remap every individual letter,
or letter combinations.
Althoug there is no autoevent that would be triggered by buffer contents
change,
you can remap(imap) every individual letters either function calls, or
plainly to something else.

Here is a small working example of how to include function call in the
remapping:

      http://www.vim.org/tips/tip.php?tip_id=650
           (Tip #650: abbreviation that prompts whether to expand it or not)

:help imap , :help map.txt

Yakov

At 12:58 p.m. 02/08/2004, Denis Perelyubskiy wrote:
>Hello,
>
>I would like to implement a script, which would
>work much like transliterator at translit.ru
>Namely, when active, the script would process
>every typed character, and act on it. Based
>on the current character and previous characters,
>it would then output russian cyrillic characters.
>
>I was wondering if someone can point me in the right
>place: perhaps an example script that does something
>similar (processing individual keypresses), or portions
>of :help
>
>I can't seem to find an event in help that would
>correspond to a keypress.

   :h 'mbyte-keymap'

I've abused it in interesting ways, namely a keyboard map that expands
cp1252 or UTF-8 characters into groff character codes while typing. Would
that be similar to  what you want? See
http://vim.sourceforge.net/scripts/script.php?script_id=1051 for a copy
(took me almost two yearsd to decide uploading it ;-).

Your file is attached.

On Thu, Aug 05, 2004 at 04:25:35PM +0800, Soh Tk-r28629 wrote:
> Greeting!
>
> I have successfully compile Vim 6.3 on SunOS 4.1.3_U1 with gcc 2.8.0
> with the following config
>
>    $ ./configure --enable-gui=athena --disable-xim
>
> plus some changes in src/Makefile to include the Xmu library.
>
> However, when starting gvim, I received the following error messages:
> Error detected while processing [snip]/vim63/runtime/plugin/explorer.vim:
> line  558:
> E122: Function ~@ýJ8_DoubleClick already exists, add ! to replace it
[more problems snipped]
>
> The same source compiled and work properly on Solaris 2.6.
[later ...]
>
> I discovered that somehow the STRCMP() call, mapped to strcmp(), used
> in eval.c:find_func(), is causing the trouble: when comparing the
> function names, strcmp() somehow return 0 even if the dest and src
> strings are different - only common on the first three characters:
> K_SPECIAL, KS_EXTRA & KE_SNR. K_SPECIAL is defined to be 0x80. I
> change the strcmp() function call to skip the first three characters,
> and everyting (bundled) seems to work okay now. But obviously this is
> not meant to be permanent fix, since strcmp() is used everywhere in
> the source.
>
> --- eval.c      2004/08/06 04:25:46     1.1
> +++ eval.c      2004/08/06 04:27:42
> @@ -9324,7 +9324,7 @@
>      ufunc_T    *fp;
>
>      for (fp = firstfunc; fp != NULL; fp = fp->next)
> -       if (STRCMP(name, fp->name) == 0)
> +       if (STRCMP(&name[3], &(fp->name[3])) == 0)
>             break;
>      return fp;
>  }
>
> A bug in the strcmp() library?

      I am cross-posting this to the vim dev list.

      If it really is a problem with the strcmp() library, you should be
able to write a 3-line C program illustrating the problem, right?

HTH 			 --Benji Fisher

I notice that the current ftp://ftp.vim.org/pub/vim/runtime/doc/help.txt is
a new version (dated 2004 Jul 13). However, AFAICT, the only difference with
the 6.3.000 version in the self-installer and in the runtime archive
(help.txt dated 2004 May 04) is that the "new" file has a number of spurious
references under "Local additions". These spurious references do not
disappear, even after ":helptags $VIMRUNTIME/doc" followed by restarting Vim
(I tried). What's up, Doc? IMHO, the "older" version was better.

Regards,
Tony.

> -----Original Message-----
> > A bug in the strcmp() library?
>
>      I am cross-posting this to the vim dev list.

The bug has been comfirmed. I found this in patch #101759 for SunOS 4.1.3_U1
(similar bug for 4.1.3):

     1074633  strcmp gets bad result when 0x80 char put in string

I downloaded the patch and it did fix the problem I have with vim. Since I can't
apply the patch to all the Sun boxes (of our manufacturing equipments), I wonder
if we can just change K_SPECIAL to something else. I've changed it to 0x81,
which seemed to work so far.

Soh Tk-r28629 wrote:

>>-----Original Message-----
>>
>>>A bug in the strcmp() library?
>>>
>>     I am cross-posting this to the vim dev list.
>>
>
>The bug has been comfirmed. I found this in patch #101759 for SunOS 4.1.3_U1
(similar bug for 4.1.3):
>
>    1074633  strcmp gets bad result when 0x80 char put in string
>
>I downloaded the patch and it did fix the problem I have with vim. Since I
can't apply the patch to all the Sun boxes (of our manufacturing equipments), I
wonder if we can just change K_SPECIAL to something else. I've changed it to
0x81, which seemed to work so far.
>
>
When patch can't be installed, the safe solution is is to link with
home-grown strcmp.o (code untested, but seems ok to me):

/* strcmp.c - work around libc strcmp() bug */
int strcmp(const char* p, const char* q) { /* untested */
     while(*p == *q && *p != 0)             /* untested */
        p++, q++;                           /* untested */
     return *p - *q;                        /* untested */
}

Yakov

> -----Original Message-----
> >The bug has been comfirmed. I found this in patch #101759 for SunOS
> >4.1.3_U1 (similar bug for 4.1.3):
> >
> >    1074633  strcmp gets bad result when 0x80 char put in string
> >
> >I downloaded the patch and it did fix the problem I have with vim.
> >Since I can't apply the patch to all the Sun boxes (of our
> >manufacturing equipments), I wonder if we can just change
> K_SPECIAL to something else. I've changed it to 0x81, which seemed to work so
far.
> >
> >
> When patch can't be installed, the safe solution is is to
> link with home-grown strcmp.o (code untested, but seems ok to me):
>
> /* strcmp.c - work around libc strcmp() bug */
> int strcmp(const char* p, const char* q) { /* untested */
>     while(*p == *q && *p != 0)             /* untested */
>        p++, q++;                           /* untested */
>     return *p - *q;                        /* untested */
> }

I don't know if strcmp() can be replace so easily judging from it's manpages. I
have also tried to link in libc.a supplied with the patch instead, assuming it's
okay to do so. And so far it seemed to be working fine.

IMO, this bug (and it's fix) should at least be mentioned in the
README/INSTALL/Makefile.

----- Original Message -----
From: "Soh Tk-r28629" <TKSoh@...>
To: "'Yakov Lerner'" <qlerner@...>
Cc: <vim@...>; <vim-dev@...>
Sent: Monday, August 09, 2004 12:04 AM
Subject: RE: vim 6.3 errors on sunos 4.1.3_U1


> > -----Original Message-----
> > >The bug has been comfirmed. I found this in patch #101759 for SunOS
> > >4.1.3_U1 (similar bug for 4.1.3):
> > >
> > >    1074633  strcmp gets bad result when 0x80 char put in string
> > >
> > >I downloaded the patch and it did fix the problem I have with vim.
> > >Since I can't apply the patch to all the Sun boxes (of our
> > >manufacturing equipments), I wonder if we can just change
> > K_SPECIAL to something else. I've changed it to 0x81, which seemed to
work so far.
> > >
> > >
> > When patch can't be installed, the safe solution is is to
> > link with home-grown strcmp.o (code untested, but seems ok to me):
> >
> > /* strcmp.c - work around libc strcmp() bug */
> > int strcmp(const char* p, const char* q) { /* untested */
> >     while(*p == *q && *p != 0)             /* untested */
> >        p++, q++;                           /* untested */
> >     return *p - *q;                        /* untested */
> > }
>
> I don't know if strcmp() can be replace so easily judging from it's
manpages.

Why not?  It's a pretty simple function.

I don't know how difficult this is to do, but... Maybe the configure script
should have a test to see if strcmp() works in the critical scenario (i.e.
strings containing 0x80).  Then, depending on an #ifdef, either override
strcmp() or not.

See the attached file for details.

yes, really?

Soh Tk-r28629 wrote:

>>-----Original Message-----
>>
>>
>>>The bug has been comfirmed. I found this in patch #101759 for SunOS
>>>4.1.3_U1 (similar bug for 4.1.3):
>>>
>>>   1074633  strcmp gets bad result when 0x80 char put in string
>>>
>>>
The mind boggles how they screwed up as simple a function as strcmp.

--
A small block will do, 5 or 6 pounds.
  -- Spock on platinum.
(Get Witty Auto-Generated Signatures from http://SmartBee.org)
George V. Reilly  george@...
http://george.reilly.org/
Read my blog: http://weblogs.asp.net/george_v_reilly/

On SunOS 4.1.3_U1, compiled with gcc v2.8.0, I got a segv fault when trying to
paste
selected text on xterm into gvim. I disabled the signal handler to capture the
stack  trace.
Any idea what's happened?

config options are: --disable-xim --enable-gui=athena

(gdb) where
#0  0xef723edc in _XConvertCTToMB ()
#1  0xef72ff94 in XmbTextPropertyToTextList ()
#2  0x17a8f4 in clip_x11_request_selection_cb (w=0x2713c0, success=0x1fe370,
sel_atom=0xefffec50,
     type=0xefffebf4, value=0x351fb0, length=0xefffebec, format=0xefffebf0) at
ui.c:2029
#3  0xef765f28 in HandleNormal ()
#4  0xef766230 in HandleSelectionReplies ()
#5  0xef756998 in CallEventHandlers ()
#6  0xef756d2c in DispatchEvent ()
#7  0xef757440 in DecideToDispatch ()
#8  0xef757620 in XtDispatchEvent ()
#9  0x17ab10 in clip_x11_request_selection (myShell=0x2713c0, dpy=0x208068,
cbd=0x1fafd0) at ui.c:2106
#10 0x199984 in clip_mch_request_selection (cbd=0x1fafd0) at gui_x11.c:2963
#11 0x179e8c in clip_gen_request_selection (cbd=0x1fafd0) at ui.c:1443
#12 0x105d3c in clip_get_selection (cbd=0x1fafd0) at ops.c:5399
#13 0xfa6f8 in may_get_selection (regname=42) at ops.c:883
#14 0xffc20 in do_put (regname=42, dir=-1, count=1, flags=2) at ops.c:3097
#15 0xea050 in do_mouse (oap=0x0, c=-12285, dir=-1, count=1, fixindent=0) at
normal.c:2328
#16 0x24b3c in ins_mouse (c=-12285) at edit.c:6736
#17 0x1888c in edit (cmdchar=105, startln=0, count=1) at edit.c:1026
#18 0xf7e0c in invoke_edit (cap=0xeffff798, repl=0, cmd=105, startln=0) at
normal.c:8169
#19 0xf7d88 in nv_edit (cap=0xeffff798) at normal.c:8142
#20 0xe7300 in normal_cmd (oap=0xeffff838, toplevel=1) at normal.c:1111
#21 0xa4068 in main_loop (cmdwin=0) at main.c:2181
#22 0xa3b78 in main (argc=0, argv=0xeffffa44) at main.c:1999
(gdb)

The stack-trace on my earlier post seem to get messed up somehow (thanks
To OutLook). Here you go again...
------------------------------------------------------------

On SunOS 4.1.3_U1, compiled with gcc v2.8.0, I got a segv fault when trying to
paste
selected text on xterm into gvim. I disabled the signal handler to capture the
stack
trace. Any idea what's happened?

config options are: --disable-xim --enable-gui=athena
(gdb) where
#0  0xef723edc in _XConvertCTToMB ()
#1  0xef72ff94 in XmbTextPropertyToTextList ()
#2  0x17a8f4 in clip_x11_request_selection_cb (w=0x2713c0, success=0x1fe370,
sel_atom=0xefffec50,
     type=0xefffebf4, value=0x351fb0, length=0xefffebec, format=0xefffebf0) at
ui.c:2029
#3  0xef765f28 in HandleNormal ()
#4  0xef766230 in HandleSelectionReplies ()
#5  0xef756998 in CallEventHandlers ()
#6  0xef756d2c in DispatchEvent ()
#7  0xef757440 in DecideToDispatch ()
#8  0xef757620 in XtDispatchEvent ()
#9  0x17ab10 in clip_x11_request_selection (myShell=0x2713c0, dpy=0x208068,
cbd=0x1fafd0) at ui.c:2106
#10 0x199984 in clip_mch_request_selection (cbd=0x1fafd0) at gui_x11.c:2963
#11 0x179e8c in clip_gen_request_selection (cbd=0x1fafd0) at ui.c:1443
#12 0x105d3c in clip_get_selection (cbd=0x1fafd0) at ops.c:5399
#13 0xfa6f8 in may_get_selection (regname=42) at ops.c:883
#14 0xffc20 in do_put (regname=42, dir=-1, count=1, flags=2) at ops.c:3097
#15 0xea050 in do_mouse (oap=0x0, c=-12285, dir=-1, count=1, fixindent=0) at
normal.c:2328
#16 0x24b3c in ins_mouse (c=-12285) at edit.c:6736
#17 0x1888c in edit (cmdchar=105, startln=0, count=1) at edit.c:1026
#18 0xf7e0c in invoke_edit (cap=0xeffff798, repl=0, cmd=105, startln=0) at
normal.c:8169
#19 0xf7d88 in nv_edit (cap=0xeffff798) at normal.c:8142
#20 0xe7300 in normal_cmd (oap=0xeffff838, toplevel=1) at normal.c:1111
#21 0xa4068 in main_loop (cmdwin=0) at main.c:2181
#22 0xa3b78 in main (argc=0, argv=0xeffffa44) at main.c:1999
(gdb)
[r28629@ixora:~...sunos4]%

At 05:22 a.m. 09/08/2004, Soh Tk-r28629 wrote:
>On SunOS 4.1.3_U1, compiled with gcc v2.8.0, I got a segv fault when
>trying to paste
>selected text on xterm into gvim. I disabled the signal handler to capture
>the stack  trace.
>Any idea what's happened?

I have no solutions but rather several observations:

1. GCC 2.80 is almost 10 years old. Upgrade; don't use sunfreeware copies
as they are usually (IMOE) borked, rather compile it yourself (GNU gcc
3.4.1 is the latest version I think, perhaps you'll need to compile 2.95
first and then 3.4.1 with the latter. 2.80 may be too obsolete to compile
3.4.1 directly).

2. The older SunOS linkers (and I'm talking before Solaris 2.6 a product
about 6 years newer than the OS you are using) always were problematic.
Rather use the GNU Binutils. If you can manage, use a development snapshot
(e.g., I use a 20040725 snapshot). *Don't*, under any circumstance, install
the GNU Binutils as replacements for the Sun utilities or you will break
your OS. Rather, compile and install the binutils integrated with GCC so
that they are installed as *private copies*.

3. SunOS 4.x is too old! Support was discontinued like in 1995-6, if memory
serves. See if you can have the OS upgraded to at least Solaris 2.6.

4. Debian has an excellent Linux distribution that works with your old
Sparc hardware. If you can't have your OS upgraded, I'd much rather install
Linux in your box and be able to use a contemporaneous OS and applications
that can be kept up-to-date till the box dies of old age (which can take
another ten years, those late 80's and early 90's Sun boxes were made to last).

Try again and see how that works :-)

SMTP: Please confirm the attached message.

Craig Barkhouse <cabarkho@...> wrote:
> ----- Original Message -----
> From: "Soh Tk-r28629" <TKSoh@...>
> To: "'Yakov Lerner'" <qlerner@...>
> Cc: <vim@...>; <vim-dev@...>
> Sent: Monday, August 09, 2004 12:04 AM
> Subject: RE: vim 6.3 errors on sunos 4.1.3_U1
>
>
> > > -----Original Message-----
> > > > The bug has been comfirmed. I found this in patch #101759 for
> > > > SunOS
> > > > 4.1.3_U1 (similar bug for 4.1.3):
> > > >
> > > >    1074633  strcmp gets bad result when 0x80 char put in string
> > > >
> > > > I downloaded the patch and it did fix the problem I have with
> > > > vim. Since I can't apply the patch to all the Sun boxes (of our
> > > > manufacturing equipments), I wonder if we can just change
> > > K_SPECIAL to something else. I've changed it to 0x81, which
> > > seemed to work so far.
> > > >
> > > >
> > > When patch can't be installed, the safe solution is is to
> > > link with home-grown strcmp.o (code untested, but seems ok to me):
> > >
> > > /* strcmp.c - work around libc strcmp() bug */
> > > int strcmp(const char* p, const char* q) { /* untested */
> > >     while(*p == *q && *p != 0)             /* untested */
> > >        p++, q++;                           /* untested */
> > >     return *p - *q;                        /* untested */
> > > }
> >
> > I don't know if strcmp() can be replace so easily judging from it's
> > manpages.
>
> Why not?  It's a pretty simple function.
>
> I don't know how difficult this is to do, but... Maybe the configure
> script should have a test to see if strcmp() works in the critical
> scenario (i.e. strings containing 0x80).  Then, depending on an
> #ifdef, either override strcmp() or not.

IMHO, a function like strcmp() should not be emulated in C because of speed
constraints. If you want to rewrite it, OK, but do it in assembly language
(and since assembly is inherently non-portable, write a different version
for each possible processor...). For example, on the i86 family, I believe
that REPE CMPSB is significantly faster than the loop described above in C,
even if you first have to do a REPNE SCASB to find the null byte.

Regards,
Tony.

Antoine J. Mechelynck wrote:

>IMHO, a function like strcmp() should not be emulated in C because of speed
>constraints. If you want to rewrite it, OK, but do it in assembly language
>(and since assembly is inherently non-portable, write a different version
>for each possible processor...). For example, on the i86 family, I believe
>that REPE CMPSB is significantly faster than the loop described above in C,
>even if you first have to do a REPNE SCASB to find the null byte.
>
>
This fragile approach is worthwhile only if strcmp() is a major
bottleneck. Most Vim operations consume minimal amounts of CPU time on a
modern gigahertz processor. Even on a decade-old Sparc, rewriting strcmp
in assembler is unlikely to yield a noticeable improvement in Vim.

--
Audemus jura nostra defendere...
[Let us dare defend our rights.]
(Get Witty Auto-Generated Signatures from http://SmartBee.org)
George V. Reilly  george@...
http://george.reilly.org/