Ending up in insert mode

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Ending up in insert mode

Antun Karlovac
I'm writing an autocmd, and I want to end up in insert mode, but it
always ends up in regular mode:

     autocmd FileType lzx iabbr attrs <attribute name="" type="string"
bbbbhh<C-R>=Eatchar('\s')<CR>i

I think some of the special characters got lost, but the idea is to put
my cursor between the quotes of 'name=""'. I would have thought the "i"
at the end would put me in insert mode, but it does not.

-Antun
Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

A.J.Mechelynck
Antun Karlovac wrote:

> I'm writing an autocmd, and I want to end up in insert mode, but it
> always ends up in regular mode:
>
>     autocmd FileType lzx iabbr attrs <attribute name="" type="string"
> bbbbhh<C-R>=Eatchar('\s')<CR>i
>
> I think some of the special characters got lost, but the idea is to put
> my cursor between the quotes of 'name=""'. I would have thought the "i"
> at the end would put me in insert mode, but it does not.
>
> -Antun
>
>
>
What does your function "Eatchar()" do? Could it be that it "eats" the
character "i" from the mapping?

Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

Gary Johnson
In reply to this post by Antun Karlovac
On 2005-10-11, Antun Karlovac <[hidden email]> wrote:
> I'm writing an autocmd, and I want to end up in insert mode, but it
> always ends up in regular mode:
>
>     autocmd FileType lzx iabbr attrs <attribute name="" type="string"
> bbbbhh<C-R>=Eatchar('\s')<CR>i
>
> I think some of the special characters got lost, but the idea is to put
> my cursor between the quotes of 'name=""'. I would have thought the "i"
> at the end would put me in insert mode, but it does not.

I think you may have to use :startinsert to do this.

    :help :startinsert

HTH,
Gary

--
Gary Johnson                 | Agilent Technologies
[hidden email]     | Wireless Division
                             | Spokane, Washington, USA
Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

Antun Karlovac
In reply to this post by A.J.Mechelynck
Maybe - I thought it was a standard function but then realized that it
was a user-defined one:

func! Eatchar(pat)
     let c = nr2char(getchar())
     return (c =~ a:pat) ? '' : c
endfunc

Does that look like it's eating the i?


-Antun

A. J. Mechelynck wrote:
>
> What does your function "Eatchar()" do? Could it be that it "eats" the
> character "i" from the mapping?
>
> Best regards,
> Tony.
>
Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

A.J.Mechelynck
Antun Karlovac wrote:

> Maybe - I thought it was a standard function but then realized that it
> was a user-defined one:
>
> func! Eatchar(pat)
>     let c = nr2char(getchar())
>     return (c =~ a:pat) ? '' : c
> endfunc
>
> Does that look like it's eating the i?
>
>
> -Antun


Could be (in the call to "getchar()"). I guess that Eatchar() call
should come at the end of the autocommand. Let's have a try (untested,
to be entered all on one line):

:autocmd FileType lzx iabbr attrs <lt>attribute name="" type="string">
<C-O>16h<C-R>=Eatchar('\s')<CR>

See ":help i_CTRL-O"

Notes:
1. Are you sure you want to "eat" the first character typed after
"attrs" if it isn't a backslash or an s? (But if it's an s, the
abbreviation likely won't be expanded and you'll just see "attrss",
unless you type "attrs^]s" where ^] means "hit Ctrl-RightBracket to
expand the abbreviation".)
2. Functions predefined in Vim have names in lowercase. Global functions
defined in scripts have names starting with an uppercase letter.



HTH,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

Jürgen Krämer

Hi,

A. J. Mechelynck schrieb:

> Antun Karlovac wrote:
>
> > Maybe - I thought it was a standard function but then realized that it
> > was a user-defined one:
> >
> > func! Eatchar(pat)
> >     let c = nr2char(getchar())
> >     return (c =~ a:pat) ? '' : c
> > endfunc
> >
> > Does that look like it's eating the i?

no. It eats at most one whitespace character.

> Could be (in the call to "getchar()"). I guess that Eatchar() call
> should come at the end of the autocommand. Let's have a try (untested,
> to be entered all on one line):
>
> :autocmd FileType lzx iabbr attrs <lt>attribute name="" type="string">
> <C-O>16h<C-R>=Eatchar('\s')<CR>
>
> See ":help i_CTRL-O"
>
> Notes:
> 1. Are you sure you want to "eat" the first character typed after
> "attrs" if it isn't a backslash or an s? (But if it's an s, the
> abbreviation likely won't be expanded and you'll just see "attrss",
> unless you type "attrs^]s" where ^] means "hit Ctrl-RightBracket to
> expand the abbreviation".)

"Eatchar()" is described in the Vim documentation as a helper function
to consume the character that triggered an abbreviation. It wants an
regular expression as argument, so '\s' consumes one whitespace
character.

Regards,
J?rgen

--
J?rgen Kr?mer                              Softwareentwicklung
HABEL GmbH & Co. KG                        mailto:[hidden email]
Hinteres ?schle 2                          Tel: +49 / 74 61 / 93 53 - 15
78604 Rietheim-Weilheim                    Fax: +49 / 74 61 / 93 53 - 99
Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

A.J.Mechelynck
J?rgen Kr?mer wrote:

> Hi,
>
> A. J. Mechelynck schrieb:
>> Antun Karlovac wrote:
>>
>>> Maybe - I thought it was a standard function but then realized that it
>>> was a user-defined one:
>>>
>>> func! Eatchar(pat)
>>>     let c = nr2char(getchar())
>>>     return (c =~ a:pat) ? '' : c
>>> endfunc
>>>
>>> Does that look like it's eating the i?
>
> no. It eats at most one whitespace character.
>
>> Could be (in the call to "getchar()"). I guess that Eatchar() call
>> should come at the end of the autocommand. Let's have a try (untested,
>> to be entered all on one line):
>>
>> :autocmd FileType lzx iabbr attrs <lt>attribute name="" type="string">
>> <C-O>16h<C-R>=Eatchar('\s')<CR>
>>
>> See ":help i_CTRL-O"
>>
>> Notes:
>> 1. Are you sure you want to "eat" the first character typed after
>> "attrs" if it isn't a backslash or an s? (But if it's an s, the
>> abbreviation likely won't be expanded and you'll just see "attrss",
>> unless you type "attrs^]s" where ^] means "hit Ctrl-RightBracket to
>> expand the abbreviation".)
>
> "Eatchar()" is described in the Vim documentation as a helper function
> to consume the character that triggered an abbreviation. It wants an
> regular expression as argument, so '\s' consumes one whitespace
> character.
>
> Regards,
> J?rgen

Ah, I see.

Well, the autocommand I gave above uses Ctrl-O to execute a single
Normal-mode command from Insert mode rather than switching modes with
Esc and i, so it might be worth trying anyway. If it has bugs, I believe
they will be easy to iron out.


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

Antun Karlovac
In reply to this post by A.J.Mechelynck
Hey Tony

That worked perfectly - thanks!

What is it that made your command work? Was it the <C-O>?

-Antun



A. J. Mechelynck wrote:

> Antun Karlovac wrote:
>
>
>
>
> Could be (in the call to "getchar()"). I guess that Eatchar() call
> should come at the end of the autocommand. Let's have a try (untested,
> to be entered all on one line):
>
> :autocmd FileType lzx iabbr attrs <lt>attribute name="" type="string">
> <C-O>16h<C-R>=Eatchar('\s')<CR>
>
> See ":help i_CTRL-O"
>
> Notes:
> 1. Are you sure you want to "eat" the first character typed after
> "attrs" if it isn't a backslash or an s? (But if it's an s, the
> abbreviation likely won't be expanded and you'll just see "attrss",
> unless you type "attrs^]s" where ^] means "hit Ctrl-RightBracket to
> expand the abbreviation".)
> 2. Functions predefined in Vim have names in lowercase. Global functions
> defined in scripts have names starting with an uppercase letter.
>
>
>
> HTH,
> Tony.
>
Reply | Threaded
Open this post in threaded view
|

Re: Ending up in insert mode

A.J.Mechelynck
Antun Karlovac wrote:
> Hey Tony
>
> That worked perfectly - thanks!
>
> What is it that made your command work? Was it the <C-O>?
>
> -Antun

I'm not sure. Ctrl-O (in Insert mode, execute a single Normal-mode
command then return to Insert mode) allows doing away with the "Esc [do
domething] i" rigmarole. Placing the <C-R>= _after_ returning to Insert
mode makes sure that it is correctly interpreted as "insert the value of
the following expression". Using [count]h rather than a string of b's
and h's allows it to be counted as a single Normal-mode command (thus
requiring only a single Ctrl-O).


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Things don't work like they should

Jack Donohue
In reply to this post by Jürgen Krämer
I've found the functionality of matchit.vim extremely useful.  Matching  < >
in html tags, matching opening and closing tags, etc.  Unfortunately, it
doesn't seem to be working any more.  Every once in a while on one of my
computers if the phase of the moon is right, it works, and life is good.
But this seems to happen with decreasing frequency.  I've got the same vim
setup on all of my computers, and am using matchit:
Version:     1.7, for Vim 6.1

I tried removing all other copies of this from everywhere but the
vimfiles\plugin directory and verified that this was in fact being loaded,
but it still doesn't seem to work.

Any ideas?

Thanks,


Jack

PS: Another problem I have is that I installed a plugin that does html tag
completion but it seems to interfere with some of my own macros and I would
like to remove it, but can't remember which on it is.  Anyone know?

Reply | Threaded
Open this post in threaded view
|

Re: Things don't work like they should

A.J.Mechelynck
Jack Donohue wrote:

> I've found the functionality of matchit.vim extremely useful.  Matching
> < > in html tags, matching opening and closing tags, etc.
> Unfortunately, it doesn't seem to be working any more.  Every once in a
> while on one of my computers if the phase of the moon is right, it
> works, and life is good. But this seems to happen with decreasing
> frequency.  I've got the same vim setup on all of my computers, and am
> using matchit:
> Version:     1.7, for Vim 6.1
>
> I tried removing all other copies of this from everywhere but the
> vimfiles\plugin directory and verified that this was in fact being
> loaded, but it still doesn't seem to work.
>
> Any ideas?
>
> Thanks,

Does matchit appear in the output of ":scriptnames"? If it doesn't, you
might want to remove it even from the plugin directory, keep it under
macros/ where the distribution put it, and add the following one-liner
as $VIM/vimfiles/plugin/matchit.vim (for all platforms including Windows
and Unix) or $HOME/vimfiles/plugin/matchit.vim (for Windows) or
$HOME/.vim/plugin/matchit.vim

        runtime macros/matchit.vim

(Use the $VIM location for system-wide use, or the $HOME location if you
want it to be user-specific.) Does it change anything?

>
>
> Jack
>
> PS: Another problem I have is that I installed a plugin that does html
> tag completion but it seems to interfere with some of my own macros and
> I would like to remove it, but can't remember which on it is.  Anyone know?

The full path names of all plugins are shown in the output of the
":scriptnames" command. A great help to memory in cases like yours.


Best regards,
Tony.