How to remember end of line when quitting/reopening in insert mode
Jean Johner
Please launch gvim easy (using vimrc_example.vim as .vimrc)
gvim -y file1
Put the cursor (|) at the end of line 10
Quit
Reopen by gvim -y file1
Result: The cursor is not at the end of line 10.
Is there a solution?
Best regards
Jean Johner
Tony Mechelynck
Either source the vimrc_example.vim, for instance by adding
runtime vimrc_example.vim
near the top of your vimrc, or at least add the following (from lines 80
or thereabouts in the example vimrc):
if has('autocmd')
augroup vimrcEx
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event
" handler (happens when dropping a file on gvim).
" Also don't do it when the mark is in the first line, that is
" the default position when opening a file.
autocmd BufReadPost *
\ if line("'\"") > 1 && line("'\"") <= line("$") |
\ exe "normal! g`\"" |
\ endif
augroup END
endif
This will remember your cursor location for each file, even across
sessions if your 'viminfo' setting is nonempty (see the ' [apostrophe]
paragrapĥ under :help 'viminfo'). I _think_ that the 'insertmode'
setting (characteristic of evim or [g]vim -y) is irrelevant for
autocommands.
Use of continuation lines assumes that you're in 'nocompatible' mode
(which is the default if your vimrc is named $HOME/.vimrc or $HOME/_vimrc).
If you _don't_ have +autocmd compiled-in, then sorry, you gotta get a
more powerful version.
Best regards,
Tony.
--
"Calvin Coolidge looks as if he had been weaned on a pickle."
-- Alice Roosevelt Longworth
Jean Johner
wrote:
> Either source the vimrc_example.vim, for instance by adding ...
Hi Tony,
Perhaps I was not clear enough.
As told in the first message, vimrc_example.vim is used as .vimrc, so
that the BufReadPost `" autocmd you described is activated.
Indeed, the cursor column is remembered except when the cursor is at
the end of a line in insert mode, in which case the last but one
column is remembered (this pb does not occur in normal mode since the
column corresponding to end of line in insert mode is not reachable).
Of course, it is a detail, but a solution would participate to vim
"perfectness".
I think it should be possible to solve this pb since situations exist
where the end of line is remembered in insert mode.
For example, create a fold, go to insert mode, open the fold, put the
cursor at the end of a line inside the fold, close the fold, reopen
it. You see that the cursor is well at the end of the line.
Best regards
Jean Johner
Tony Mechelynck
Ah, well, I'm not sure how you could do it... wait...
maybe
:set virtualedit=onemore
but I'm not sure of the results, and it could have some side-effects.
Other than that, no idea.
Best regards,
Tony.
--
There are very few personal problems that cannot be solved through a
suitable application of high explosives.
Brian L. Matthews
> if has('autocmd')
> augroup vimrcEx
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event
> " handler (happens when dropping a file on gvim).
> " Also don't do it when the mark is in the first line, that is
> " the default position when opening a file.
> autocmd BufReadPost *
> \ if line("'\"") > 1 && line("'\"") <= line("$") |
> \ exe "normal! g`\"" |
> \ endif
> augroup END
> endif
Shouldn't the line("'\"") > 1 be > 0? Otherwise if the cursor is
positioned on line 1, it won't move it to the correct column (the
example in :help last-position-jump uses exe "normal! g'\"" so it
already isn't using the column, so in that case > 1 is fine as there's
no need to move the cursor from line 1 to line 1).
Brian
Jean Johner
....
It seems that my point was definitely not clear. I state it again:
Please launch gvim easy (using vimrc_example.vim as .vimrc)
gvim -y file1
Put the cursor (|) at the end of line 10 (after the last letter, say
column 24)
Quit (by using the cross in the right-up corner of the window)
Reopen by gvim -y file1
Result: The cursor is not at line 10, column 24 but at line10, column
23 (before the last letter).
This means that easy gvim does not remember the end of line cursor
position.
I think that this will be perceived as a bug by easy gvim users.
Other insert mode text editors like gnome/gedit do remember the end of
line cursor position properly.
Tony Mechelynck wrote
> :set virtualedit=onemore
You are right, it solves the problem for a pure insert mode use.
The side effect for those that use CTRL-L to access normal mode is
that the x command (del) no longer goes back when reaching the end of
a line. Annoying in my opinion.
Best regards
Jean Johner
Gary Johnson
> On Mar 22, 9:11�pm, "Brian L. Matthews" <blmatth...@gmail.com> wrote:
>
> ....
>
> It seems that my point was definitely not clear. I state it again:
>
> Please launch gvim easy (using vimrc_example.vim as .vimrc)
> gvim -y file1
> Put the cursor (|) at the end of line 10 (after the last letter, say
> column 24)
> Quit (by using the cross in the right-up corner of the window)
> Reopen by gvim -y file1
>
> Result: The cursor is not at line 10, column 24 but at line10, column
> 23 (before the last letter).
>
> This means that easy gvim does not remember the end of line cursor
> position.
> I think that this will be perceived as a bug by easy gvim users.
> Other insert mode text editors like gnome/gedit do remember the end of
> line cursor position properly.
The problem you're encountering, as I understand it, arises because
Vim's cursor does not lie between character positions--it lies on
character positions. In the following line, for example,
cat
the cursor can be on the 'c', the 'a' or the 't'. From those three
positions, you can insert text (i) on the left or append text (a) on
the right. There are four locations in which you may want to put
text or to position an insertion cursor. There are only three
locations, however, at which you can place Vim's cursor before
entering insert mode.
When in insert mode in that line, the next keystroke could place a
character in one of four locations. That means that Vim is in one
of four possible states. If you were to leave insert mode at that
point, Vim would have only three places at which to put the cursor
and would be in one of three possible states. Vim has lost
information.
I was about to write that where the cursor _was_ is not a property
of the cursor, but that's not true in other situations. For
example, if I move the cursor straight up from this comma, it will
move to the 'F', then to the space between the 'a' and the 'p', then
to the start of the empty line, then to the period following
"information", and then to the 's' in "lost". It remembered that it
started in column 58. It forgets that information, though, upon the
next command other than a vertical motion command.
I suppose, then, that the cursor in normal mode could be made to
remember whether it had been to the right or to the left of the
current position when it was in insert mode.
Hmm. I wonder if there is a way to save, access and make use of
that additional information without messing up the way Vim operates
normally.
Regards,
Gary
Jean Johner
...
Hi Gary,
You are right, there is one column more in insert mode than in normal
mode.
This is clear if you have "set ruler" which indicates column 54 if you
are positionned after the last available column 53 in normal mode.
I guess that is why the option "set virtualedit=onemore" has been
invented.
Indeed setting virtualedit=onemore DOES SOLVE the problem as indicated
previously.
But this solution has unpleasant side-effects in normal mode.
It must be possible to solve the problem differently (by indicating
somehow to .viminfo that the quit has been done with the cursor at the
end of a line in insert mode).
It is the developpers' job to find a solution.
Best regards,
Jean
Gary Johnson
I would say rather that it is the developer's job to determine the
feasibility of a solution. It is not the developer's job to find a
solution to every issue perceived to be a problem by any user.
Nevertheless, I think Vim already contains the components of a
solution to this problem as I will illustrate.
Create a line containing some text like this and leave insert mode.
Mary had a little lamb
Now change that line by appending to the end of it, like this, and
again leave insert mode.
Mary had a little lamb that was white.
Now execute the following command and note the result.
:echo col("'[") col("']") col(".")
27 43 42
The last changed column, 43, is to the right of the current cursor
column, 42. Also, that line has only 42 columns. That indicates
that while Vim was last in insert mode it was appending to the
current line. To restore Vim's state to what it was before leaving
insert mode, the cursor would be moved to column 42 and the 'a'
normal-mode command executed. Alternatively, the :startinsert! ex
command could be executed.
I think someone could use that information to put the appropriate
logic into an appropriate autocommand, perhaps in evim.vim, and get
the behavior you want.
Regards,
Gary
Tony Mechelynck
I agree with the above, and to "the developers' job", I'll add that
"the" developer, Bram Moolenaar, has a full-time job which leaves him
little time to fix outright bugs in Vim, let alone add enhancements. We
are all lucky enough that he places such a fine (and oh, how well
documented! :-) ) editor at our disposition, at no cost to us (and yes,
we are encouraged to contribute to Bram's favourite charity, but if any
of us doesn't, his copy of Vim won't stop functioning just as well as it
does for those who do contribute).
The source code of Vim is all available, anyone has access to it; see
for instance by following the two last links of the summary of my Vim
page http://users.skynet.be/antoine.mechelynck/vim/ how I used to
compile Vim when I was on Windows and how I still do now that I'm on
Linux. No-one prevents you (Jean), or anyone else for that matter, from
altering the code to add any feature that suits your whim; once it works
to your satisfaction you can even publish your changes and ask to have
them added to the list of "unofficial patches" at
http://groups.google.com/group/vim_dev/web/vim-patches so that anyone
may profit by it. (Having your changes made part of "official" mainline
Vim requires, among others, convincing Bram that the change is a
valuable addition, that it doesn't beak backwards compatibility, that it
is free of obvious bugs, and that it obeys "Vim coding style". It's not
just any patch that can pass his judgment.)
Best regards,
Tony.
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
Jean Johner
wrote:
...
Sorry. I did not want to be offending or authoritary.
I just wanted to outline that the fact that easy gvim (with the
present vimrc_example.vim) does not remember end of lines is an
obvious imperfection which gives a bad image of the code, especially
to beginners. Let me recall again that gnome/gedit does it perfectly.
set virtualedit=onemore works but has unpleasant side-effects in
normal mode.
Finding another solution appears to be an interesting programming
problem (see Gary's mail)
Not being myself a vim expert nor a C programmer (I am in fact a
physicist), I encourage the vim community to eliminate this "bug".
Best regards
Jean
Andy Wokula
It's a bit tricky, but you can try the following code:
augroup LastPos
au! BufReadPost * call s:LastPos(&insertmode)
augroup END
func! s:LastPos(mode)
if a:mode == 2
au! LastPos InsertEnter
call feedkeys("\<C-R>=''[setpos('.',getpos(\"'\\\"\"))]\r", "n")
elseif line("'\"") >= 1 && line("'\"") <= line("$")
if a:mode == 1
au LastPos InsertEnter * call s:LastPos(2)
else
exe "normal! g`\""
endif
endif
endfunc
--
Andy
Andy Wokula
> Am 24.03.2010 16:03, schrieb Jean Johner:
>> On Mar 24, 3:33 pm, Tony Mechelynck<antoine.mechely...@gmail.com>
>> wrote:
>> ...
>>
>> Sorry. I did not want to be offending or authoritary.
>>
>> I just wanted to outline that the fact that easy gvim (with the
>> present vimrc_example.vim) does not remember end of lines is an
>> obvious imperfection which gives a bad image of the code, especially
>> to beginners. Let me recall again that gnome/gedit does it perfectly.
>>
>> set virtualedit=onemore works but has unpleasant side-effects in
>> normal mode.
>>
>> Finding another solution appears to be an interesting programming
>> problem (see Gary's mail)
>>
>> Not being myself a vim expert nor a C programmer (I am in fact a
>> physicist), I encourage the vim community to eliminate this "bug".
>>
>> Best regards
>> Jean
This one is slightly more robust:
" TODO
" + how can we be sure that <C-R>=... will be executed in Insert mode?
" ! use intermediate <Plug>LastPos
map <Plug>LastPos <Nop>
cmap <Plug>LastPos <Nop>
ino <silent> <Plug>LastPos <C-R>=''[setpos('.',getpos("'\""))]<CR>
augroup LastPos
au! BufReadPost * call s:LastPos(&insertmode)
augroup END
func! s:LastPos(mode)
if a:mode == 2
au! LastPos InsertEnter
call feedkeys("\<Plug>LastPos")
Jean Johner
> This one is slightly more robust:
> ...
It seems to work very nicely. Congratulations Andy!
Perhaps it could be worth suggesting Bram to incorporate that code in
his vimrc_example.vim (after addind the necessary tests that gvim is
called with -y or evim is used).
Best regards.
Jean
Jean Johner
(after addind the necessary tests that gvim is
> called with -y or evim is used).
Tests are not even necessary, it works equally well with gvim alone.
Miraculous!
Best regards.
Jean
Andy Wokula
> On Mar 24, 6:29 pm, Andy Wokula<anw...@yahoo.de> wrote:
>
>> This one is slightly more robust:
>> ...
>
> It seems to work very nicely. Congratulations Andy!
Ok, good to hear.
> Perhaps it could be worth suggesting Bram to incorporate that code in
> his vimrc_example.vim (after addind the necessary tests that gvim is
> called with -y or evim is used).
I think an example vimrc should be simple rather than 100% correct.
Maybe the code is worth a tip on vim.wikia.com, and the example vimrc
could then refer to it.
--
Andy
Jean Johner
Please test the 2 following situations
1)
gvim -y file1
put the cursor on line 10, end of line (column 24)
Quit with the cross top-right of windows
gvim -y file1 (to reopen)
Result: the cursor is at end of line 10 (OK)
2)
gvim -y file1
put the cursor on line 10, end of line (column 24)
Quit with Menu|Exit (or CTRL-O :q)
gvim -y file1 (to reopen)
Result: the cursor is on line 10, column 23
This does not occur with set virtualedit=onemore and the standard
autocmd.
Best regards
Jean Johner
Christian Brabandt
> A little problem however
> Please test the 2 following situations
>
> 1)
> gvim -y file1
> put the cursor on line 10, end of line (column 24)
> Quit with the cross top-right of windows
> gvim -y file1 (to reopen)
> Result: the cursor is at end of line 10 (OK)
>
> 2)
> gvim -y file1
> put the cursor on line 10, end of line (column 24)
> Quit with Menu|Exit (or CTRL-O :q)
> gvim -y file1 (to reopen)
> Result: the cursor is on line 10, column 23
This happens, because ctrl-o moves the cursor when leaving insert mode.
You can prevent this by using <c-\><c-o>
The same is true for using the menu. The help menu is created using the
:amenu command, which prepends each command with <c-o> in insert mode.
For insert mode, this should probably be <c-\><c-o>. But I am not sure,
if you can change this. May be, this needs another patch.
regards,
Christian
Christian Brabandt
BTW: I noticed some unpleasant side effects when playing around with
Andy's solution. The plugin seems to interfer with jumping to the
correct help section. Using :h topic this put me somewhere near the topic,
but not at the right position. This does not happen everytime and I assume
this only happens, when a help page is opened for the first(?) time.
regards,
Christian
Andy Wokula
Maybe this has to do with updating the LOCAL ADDITIONS section in the
main help page.
--
Andy
Christian Brabandt
I am sorry, but I don't understand.
regards,
Christian
Andy Wokula
The main help page ('helpfile')
:h
has a section
:h local-additions
which collects the headlines of plugin docs (~/.vim/doc/*.txt, ...).
Vim has to update it frequently, as $VIMRUNTIME/doc/help.txt is not changed.
Maybe this process has influence on the cursor position.
--
Andy
Christian Brabandt
I don't think, this was the problem.
regards,
Christian
Tony Mechelynck
[...]
> I think an example vimrc should be simple rather than 100% correct.
> Maybe the code is worth a tip on vim.wikia.com, and the example vimrc
> could then refer to it.
>
I think the vimrc_example.vim should set an example, and as such it
cannot afford to be sloppy. Anything in it which doesn't work as
intended should be corrected, if possible: that's why I recommend to
implement it by sourcing it from the user's vimrc (so the most recent
version is always used) rather than by copying it (which "freezes" the
version used) then more or less misguidedly adding the user's settings
in the same file. (I know Bram disagrees about this source-vs.-copyedit
preference, and I don't completely fathom his reasons for it.)
Best regards,
Tony.
--
default, n.:
[Possibly from Black English "De fault wid dis system is you,
mon."] The vain attempt to avoid errors by inactivity. "Nothing will
come of nothing: speak again." -- King Lear.
-- Stan Kelly-Bootle, "The Devil's DP Dictionary"
Tony Mechelynck
This ought not to influence other helpfiles, and even in help.txt the
tags file for help contains search commands, not line numbers (see :help
help-tags; the single exception is the entry for help-tags itself, which
sends you to line 1 of the tags file), so I don't believe it would be
relevant either.
As for updating it "frequently", does Vim update it more often than (1)
at startup and (2) when :helptags is run? That should be enough,
shouldn't it?
OTOH, all helpfiles have 'nomodifiable' set, and IIRC you're setting the
cursor location at an InsertEnter autocommand, which ought not to be
triggered for a 'nomodifiable' file, so Christian's observations leave
me baffled.
Best regards,
Tony.
--
If anything can go wrong, it will.
Jean Johner
wrote:
>so Christian's observations leave
> me baffled.
Please find below a reproduceable situation where help side-effects of
Andy's code appear:
Use vimrc_example.vim completed with Andy's code as .vimrc
Go to home directory
rm .viminfo (DON'T FORGET)
gvim file1
:set insertmode
CTRL-O :h zR
Result: the help window opens at the beginning of fold.txt (not the
correct place)
If :set insertmode is not typed, the problem does not occur.
Do you reproduce that?
Best regards
Jean Johner
Andy Wokula
Yes. Vim first jumps to the tag, then lastpos jumps to `" which is
initialized with (line 1, col 1).
I added more guards.
Installation (suggestion only):
- disable existing last-position-jump code in the vimrc
- put the attached file in the plugin folder
--
Andy
Jean Johner
> - disable existing last-position-jump code in the vimrc
> - put the attached file in the plugin folder
It seems to work very nicely. Thanks.
NB: Your code works when "set insertmode" is present in .vimrc (as a
special case gvim -y).
It does not work when "startinsert" is used instead (which has the
advantage of keeping the Esc key).
Could you cure that?
Best regards
Jean Johner
Jean Johner
One (last?) suggestion to improve lastpos.vim
1) Consider a .vimrc containing the following 2 lines:
set insertmode
imap <F8> <C-\><C-O>:bprevious<CR>
Please do the following:
gvim file1
CTRL-O :e file2
put the cursor at the end of line 10
<F8>
put the cursor at the end of line 10 (in file1)
Use <F8> several times
You see that the end of lines are remembered (Good)
2) Just add "set hidden" in the .vimrc
set insertmode
set hidden
imap <F8> <C-\><C-O>:bprevious<CR>
Please do the following:
gvim file1
CTRL-O :e file2
put the cursor at the end of line 10
<F8>
put the cursor at the end of line 10 (in file1)
Use <F8> several times
You see that only line numbers are remembered. The cursor is always on
column 1.
Can you improve that?
Hint: Using vimrc_example.vim as .vimrc (without lastpos.vim), the
same problem occurs in normal mode. The solution is to replace
BufReadPost with BufWinEnter in vimrc_example.vim.
Best regards
Jean Johner
Jean Johner
>> NB: Your code works when "set insertmode" is present in .vimrc (as a
>> special case gvim -y).
>> It does not work when "startinsert" is used instead (which has the
>> advantage of keeping the Esc key).
>>
>> Could you cure that?
> Easily, but you need to set a variable.
> " in the vimrc:
> let g:lastpos_startinsert = 1
> startinsert
Hi Andy,
I did that and installed your new plugin (private attachment). It
works perfectly. Thanks.
May be you could send the new plugin to vim_use.
Best regards
Jean
Jean Johner
>> Can you improve that?
> IIRC, you already mentioned this on the list?
> I think it's not related to the last-position-jump problem -- so, mission accomplished for now ;-) Maybe I'll spend some
> time on it after the holidays.
>> Hint: Using vimrc_example.vim as .vimrc (without lastpos.vim), the
>> same problem occurs in normal mode. The solution is to replace
>> BufReadPost with BufWinEnter in vimrc_example.vim.
> Even better, if you know the solution then please try it yourself ;-).
Hi Andy,
Finally, just replacing "BufReadPost" with "BufWinEnter" in the latest
version of your plugin and suppressing the original BufReadPost
autocmd of vimrc_example.vim (if any) does the job.
With this plugin+replacement of <C-O> with <C-\><C-O>+ Christian's
patch for the menus (not yet tested by myself), one can consider that
the proposed problem is completely solved.
Bram does not seem enthusiastic to take all that into account
officially. Perhaps we could reiterate our proposition after intense
use has shown no side-effects.
Have nice holidays!
Regards,
Jean Johner
Jean Johner
>> Hi Andy,
>>
>> Finally, just replacing "BufReadPost" with "BufWinEnter" in the latest
>> version of your plugin and suppressing the original BufReadPost
>> autocmd of vimrc_example.vim (if any) does the job.
>Ok.
>> With this plugin+replacement of<C-O> with<C-\><C-O>+ Christian's
>> patch for the menus (not yet tested by myself), one can consider that
>> the proposed problem is completely solved.
>I also looked into it again ...
>I suppose you exclusively switched buffers this way (using the menus, while staying in Insert mode)?
>It's a little bit funny, but it only works because of a bug (that is:
>the variable g:lastpos_startinsert is not removed after "usage", the script expects Insert mode to be started all the time, >which is true for your use case).
>But once you press Escape and continue with Normal mode, it will no longer work.
>The fix: remove the variable after usage.
>But this doesn't work as well: In the above use case (Insert mode on all the time (basically)), the BufWinEnter event >needs announcement of the Insert-mode-is-about-to-start-soon situation.
>I think the only way to solve this is to detect that we are in the Normal-mode-only-for-one-command mode (when >BufWinEnter fires). But such a check is not available yet (AFAIK). And I don't want to suggest this -- it would actually >make the Vimscript-approach superfluous.
>> Bram does not seem enthusiastic to take all that into account
>> officially.
>Once more it turns out that Bram is right. He seems to have some magical feeling what can be done at what not.
>> Perhaps we could reiterate our proposition after intense use has shown
>> no side-effects.
>Sorry, problems found ...
>> Have nice holidays!
>Thanks, Easter holidays.
Hi Andy,
Your script with "BufWinEnter" replacing "BufReadPost" works in insert
mode when switching between buffers is done using <C-\><C-O>:bp<CR>.
It does not work using the menus (without Christian's patch).
If CTRL-L is used to quit insert mode, it no longer works at all,
cursor on column 1 (you are right).
So, 2 solutions:
1) Keep your (bugged) script and work in insert mode only
2) Keep the original vimrc_example.vim with "BufReadPost" replaced
with "BufWinEnter". It works in normal mode and almost works in insert
mode. I still have to understand why the vimrc_example's BufWinEnter
autocmd works in normal mode when switching between buffers when the
similar in your script does not.
Best regards
Jean Johner
Jean Johner
In the case of your script with "BufWinEnter" replacing "BufReadPost"
and supposing "set insertmode" in the .vimrc, we have seen that
escaping insert mode with CRTL-L results in no column remembering when
switching between buffers.
This can be worked around in the following way:
Quit insert mode using <Esc> with "imap <Esc> <C-O>:set
noinsertmode<CR>"
Reenter insert mode using "i" with "map i :set insertmode<CR>"
Best regards
Jean Johner
Andy Wokula
Might work, but it's only a workaround ...
There are more commands that enter Insert mode:
a o O I A gI maybe others
and there are more commands that stop Insert mode:
CTRL-C, CTRL-\_CTRL-N, ...
User may have mappings using these commands in non-remappable mode
(bypassing the above mappings).
--
Andy
Jean Johner
> Might work, but it's only a workaround ...
>
> There are more commands that enter Insert mode:
> a o O I A gI maybe others
>
> and there are more commands that stop Insert mode:
> CTRL-C, CTRL-\_CTRL-N, ...
>
> User may have mappings using these commands in non-remappable mode
> (bypassing the above mappings).
You are right. For the script to work in all cases, each incursion in
insert mode should be complemented with a "set insertmode". Each
return to normal mode by a "set noinsertmode". Perhaps this can be
done automatically.
For insert mode lovers, most of the mapping use <C-O> which is not
really leaving insert mode.
For some long tasks where normal mode is more convenient (e.g.
folding), the above workaround is useful. When it is finished, the
user definitely goes back to insert mode with "i".
Best regards
Jean Johner
--
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
Subscription settings: http://groups.google.com/group/vim_use/subscribe?hl=en
JOHNER Jean 066030
> See attachment for a new approach (lastpos v0.6).
> (doesn't need announcement for Insert mode)
Please find attached Andy's new miracle plugin.
Works with either "set insertmode" or "startinsert" in .vimrc.
Works when switching between buffers (with <C-\><C-O>:bp<CR>).
Works when leaving insert mode.
No workarounds required.
A must!
Best regards
Jean Johner