[patch] Add Error autocmd event

205 views
Skip to first unread message

Anton Lindqvist

unread,
Feb 8, 2016, 2:23:49 PM2/8/16
to vim...@vim.org
Hi,
This is a result of a previous discussion[1] which concluded that a more general
Error autocmd event would be a better addition than the proposed TagNotFound
event.

Questions and comments regarding the patch in no particular order:

- Is the addition to the main_loop function at a suitable location?

- The error code (emsg_code) is the actual code including the 'E' prefix.
Another solution is to use the numerical representation of the error code.

- The get_error_pat function is used to translate error codes into something
more descriptive. As of writing this only one such mapping is present. We
could either ensure that all possible error codes has a mapping or add them on
demand. The function is doing a linear search of error_pats. If the error code
is represented as an int this could be replaced with a constant lookup if the
array index is equal to the error code:

static const char *error_pat[] = {
[426] = "tagnotfound",
}

If mappings of all possible error codes is present the array won't end up
being that sparse.

The existing solution (representing error codes as string) could also be
improved by replacing the linear search with a binary search.

- If no mapping of the error code to pattern is found the actual error code is
used as the amatch argument when triggering the Error event.

[1] https://groups.google.com/d/msg/vim_dev/XzhNNjbtfow/u6BWsne4CwAJ
add-error-autocmd-event.patch

Bram Moolenaar

unread,
Feb 8, 2016, 4:57:52 PM2/8/16
to Anton Lindqvist, vim...@vim.org
I am wondering if this is really a useful solution.

At least in scripts one can already use try/catch to deal with errors.
Thus this patch is mainly for when typing commands.

The original reason was to handle an error for a tag lookup. With the
solution the tag lookup will still fail. It can trigger rebuilding the
tags file, but for most users it will be quite unexpected that trying to
jump to the same tag suddenly works a bit later.

Can you think of a command or situation where this patch provides a
nice, useful solution?


--
I'm in shape. Round IS a shape.

/// Bram Moolenaar -- Br...@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 ///

Christian Brabandt

unread,
Feb 9, 2016, 3:01:43 AM2/9/16
to vim...@vim.org
Hi Bram!
But only, if the user did setup the Error autocommand. So he should
expect that, right?

> Can you think of a command or situation where this patch provides a
> nice, useful solution?

I think, it has come up in the past before:
- Catching E482/E484/E485 because /tmp got cleaned out would be
possible.
https://groups.google.com/d/msg/vim_use/qgRob9SWDv8/FAOFVVcDTv0J
- https://groups.google.com/d/msg/vim_dev/EbTWqBl2rdw/vT4fTaGFnMoJ
- and possibly others, which I don't remember currently.

Best,
Christian
--
Treffen sich Kinkel und Hinze im Magen von Kohl.
Sagt Kinkel: "Ich glaube, der Kohl hat mich gefressen."
Darauf Hinze: "Kann ich nichts zu sagen, ich kam von der anderen
Seite rein."

Ben Fritz

unread,
Feb 9, 2016, 10:59:05 AM2/9/16
to vim_dev, vim...@vim.org
On Tuesday, February 9, 2016 at 2:01:43 AM UTC-6, Christian Brabandt wrote:
> > Can you think of a command or situation where this patch provides a
> > nice, useful solution?
>
> I think, it has come up in the past before:
> - Catching E482/E484/E485 because /tmp got cleaned out would be
> possible.
> https://groups.google.com/d/msg/vim_use/qgRob9SWDv8/FAOFVVcDTv0J
> - https://groups.google.com/d/msg/vim_dev/EbTWqBl2rdw/vT4fTaGFnMoJ
> - and possibly others, which I don't remember currently.
>

A couple more interesting ideas:

Set 'nowrapscan' in the .vimrc, but catch an E385 (search hit bottom without match) and offer to wrap to the beginning (temporarily set wrapscan).

Or, similar to the initial use of rebuilding tags if a tag is not found, modify 'path' if a file is not found for gf and friends.

Does the autocmd work to catch things thrown by :throw? If so there could be all kinds of uses for that.

Writes failing for files being readonly could prompt to retry with the sudo + tee trick.

I'm sure clever plugin authors will find plenty more.

Anton Lindqvist

unread,
Feb 9, 2016, 2:48:26 PM2/9/16
to vim...@vim.org, Bram Moolenaar
Bram,
The creation of the tags file when missing was just an example of a use-case of
my own and is of course a opt-in usage of the new event.

> Can you think of a command or situation where this patch provides a
> nice, useful solution?

Other than the examples already provided, here's a couple of ideas:

- Opening a new file in a non existing directory and then write triggers a E212
which could be caught and then before writing again try to create the
directory (%:h) of the file.

- The SpellFileMissing autocmd event could probably be implemented using the
Error event instead. However this might not a suitable idea since it would
require keeping the old event for backwards compability.

--
:wq

Andy Wokula

unread,
Feb 9, 2016, 3:08:43 PM2/9/16
to vim...@googlegroups.com
Am 09.02.2016 um 20:48 schrieb Anton Lindqvist:
>> Can you think of a command or situation where this patch provides a
>> nice, useful solution?
>
> Other than the examples already provided, here's a couple of ideas:
>
> - Opening a new file in a non existing directory and then write triggers a E212
> which could be caught and then before writing again try to create the
> directory (%:h) of the file.

You can already do something like (quoted from somewhere ...):

:au BufWrite * if v:cmdbang && !isdirectory(expand('%:h')) | cal mkdir(expand('%:h'), 'p')| endif

--
Andy

Anton Lindqvist

unread,
Feb 14, 2016, 5:50:29 AM2/14/16
to vim...@vim.org
Here's a revised patch including a more rigorous way of parsing the error code
from a error message.

Another use-case I've been trying recently: if wrapscan is initially disabled,
enable it when the search hits top/bottom. This way one is notified that the
search reached the end but pressing n/N again will temporary enable wrapscan in
order to redo the search from the opposite end.

set nowrapscan
let s:wrapscan = 0

func! s:ToggleWrapScan(rhs) abort
if s:wrapscan
set wrapscan
let s:wrapscan = 0
else
set nowrapscan
endif
return a:rhs
endfunc
nnoremap <expr> n <SID>ToggleWrapScan('n')
nnoremap <expr> N <SID>ToggleWrapScan('N')

augroup error
au! Error E38[45] let s:wrapscan = 1
augroup END

--
:wq
add-error-autocmd-event.patch

Anton Lindqvist

unread,
Feb 17, 2016, 11:19:48 AM2/17/16
to vim...@vim.org
Updated patch attached which adds a missing autocmd feature check.

--
:wq
add-error-autocmd-event.patch

Anton Lindqvist

unread,
Feb 22, 2016, 10:20:39 AM2/22/16
to vim...@vim.org
Realized I was using my personal preference for cinoptions. Here's a
revised patch with correct indentation.

--
:wq
add-error-autocmd-event.patch

Anton Lindqvist

unread,
Feb 25, 2016, 11:08:40 AM2/25/16
to vim...@vim.org, Bram Moolenaar
Bram,
I noticed your comment in todo.txt about the fact that the current
solution only remembers the code of last error that occurred. Here's a
first attempt address this issue by using an growarray. Caution: I don't
know if it's wise to clear the array in the main loop.

--
:wq
add-error-autocmd-event.patch

Bram Moolenaar

unread,
Feb 25, 2016, 4:17:58 PM2/25/16
to Anton Lindqvist, vim...@vim.org
Thanks. However, I still have doubts about how useful this is.
Autocommands are tricky as they are, and this one is more tricky then
others.

It's not that I don't like your work, I just don't want to make a
promise to users, which means once this is in we'll have to keep it
around forever. Even when we find a better solution eventually.


--
ARTHUR: No, hang on! Just answer the five questions ...
GALAHAD: Three questions ...
ARTHUR: Three questions ... And we shall watch ... and pray.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

Anton Lindqvist

unread,
Feb 27, 2016, 5:05:23 AM2/27/16
to vim...@vim.org, Bram Moolenaar
On Thu, Feb 25, 2016 at 10:17:34PM +0100, Bram Moolenaar wrote:
>
> Anton Lindqvist wrote:
>
> > Bram,
> > I noticed your comment in todo.txt about the fact that the current
> > solution only remembers the code of last error that occurred. Here's a
> > first attempt address this issue by using an growarray. Caution: I don't
> > know if it's wise to clear the array in the main loop.
>
> Thanks. However, I still have doubts about how useful this is.
> Autocommands are tricky as they are, and this one is more tricky then
> others.
>
> It's not that I don't like your work, I just don't want to make a
> promise to users, which means once this is in we'll have to keep it
> around forever. Even when we find a better solution eventually.

Sounds reasonable and I respect your judgment.

--
:wq

mattn

unread,
Mar 19, 2016, 10:47:15 AM3/19/16
to vim_dev, vim...@vim.org, Br...@moolenaar.net
BTW, if incldue this patch, vim will allow to create any commands.

function! s:OverrideCmd(msg)
if a:msg =~ "^E492: Not an editor command: "
" something
endif
endfunction
au! Error E492 call s:OverrideCmd(v:errmsg)

For example, create command name leading lower letter, multibyte string, or etc.
I'm not strong opinion about this patch, but we need to consider for effect to others.

- mattn

Reply all
Reply to author
Forward
0 new messages