Re: add mapping for buftype=nofile?

2016-01-20 14:38 GMT+03:00 赵启明赵 <chemzqm@gmail.com>:

Need to be clarified,  BufReadCmd  should be used for plugin which set options for the buffer they created, so that user could use BufReadPost autocmd to check the options safely, is that what you means?

​BufReadCmd should be used for creating plugin-specific special buffers. For *all* plugin-specific special buffers, this is what this option is for.​ By "special" I mean buffers that show some plugin-specific contents like given directory (in plugins like netrw or NERDTree), VCS log (in plugins like aurum, fugitive and vcscommand) or remote resource (e.g. like netrw that is able to open http:// links) and unpacked file contents (like gzip, but that unfortunately uses BufReadPost): opposed to "regular" buffers which show contents of an existing file as-is (and which may also be opened by a plugin).

This is not taking into account whether after opening buffer plugin is setting any options. Main reasoning behind this is sessions support; also this is what BufReadCmd was designed for.

 

在 2016年1月20日星期三 UTC+8下午12:08:43，ZyX写道：

> 2016-01-20 5:08 GMT+03:00 Josef Fortier <josef....@gmail.com>:
> I'd like to map q to bwipe for all bt == nofile, but I'm having trouble finding the autocmd to make it work (assuming that this is the way to go)?
>
>
>
> I've tried (transcribed from memory)
>
>
>
> autocmd bufreadpost *
>
> \ if buftype == 'nofile' |
>
> \    nnoremap <buffer> q :bwipe<qr> |
>
>
>
>
> ​You have added trailing space here and additionally use `<CR>`​ and not `<qr>`.
>
>  
> \ endif
>
>
>
> with various types of events, but I do not seem to be choosing the right events, or am missing something else.
>
>
>
>
> ​This highly depends on what plugin used to set buftype. E.g. if it was something like
>
>
>     edit plugin://some-name
>     setlocal buftype=nofile
>
>
> then *any* event will be too early because *all* are run when `:edit` is.
>
>
> You may need `FileType` event with plugin-specific filetypes. It may appear that *no* events are applicable if plugin used
>
>
>     noautocmd edit plugin://some-name
>
>
> , temporal `set eventignore=…` with your event or if plugin opened its buffer on another event and that another event does not have `nested` modifier (I have no idea why this is not the default).
>
>
> ---
>
>
> Actually the only correct way to open plugin-specific buffers is using
>
>
>     edit plugin://data
>
>
> and make plugin define BufReadCmd, but guess how many plugins actually do use this variant? I can say that
>
>
> 1. Many of them think that BufReadPost is the way to go. E.g. built-in plugins for viewing compressed files.
> 2. Many other think that it is OK to open plugin-specific buffers using "make user run some API call (command, function, mapping) and make API call handler open buffer with random name and then do what is necessary". No events are involved in process at all.
>
>
> ---
>
>
> Thus the best variant is using
>
>
>     autocmd OptionSet buftype :if v:option_new is# 'nofile' | nnoremap …| endif
>
>  
>
>
> Secondary question, can anyone see any issues with this?
>
>
>
> FWIW, I'm trying to make the "q" -> quit convention universal across older plugins (it seems to be a pretty common convention with newer plugins)
>
>
>
> ​I think that macros may be needed not only while editing. E.g. in my aurum I mostly take only normal-mode commands that will definitely not be needed: I mean editing commands (except for buffers which are supposed to be edited, of course).
>
>    
>
>
> Any collective wisdom?
>
>
>
> --
>
> --
>
> 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
>
>
>
> ---
>
> You received this message because you are subscribed to the Google Groups "vim_use" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
--
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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
--
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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.