add mapping for buftype=nofile?

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

add mapping for buftype=nofile?

Josef Fortier
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> |
\ endif

with various types of events, but I do not seem to be choosing the right events, or am missing something else.

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)

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: add mapping for buftype=nofile?

Nikolay Aleksandrovich Pavlov


2016-01-20 5:08 GMT+03:00 Josef Fortier <[hidden email]>:
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: add mapping for buftype=nofile?

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

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

> 2016-01-20 5:08 GMT+03:00 Josef Fortier <[hidden email]>:
> 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 [hidden email].
>
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: add mapping for buftype=nofile?

Tim Chase
In reply to this post by Josef Fortier
> I've tried (transcribed from memory)
>
> \    nnoremap <buffer> q :bwipe<qr> |

You mention it was from memory, but I presume you mean "<cr>" here,
not "<qr>".

But if not, could that be the issue?

-tim


--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: add mapping for buftype=nofile?

Nikolay Aleksandrovich Pavlov
In reply to this post by chemzqm


2016-01-20 14:38 GMT+03:00 赵启明赵 <[hidden email]>:
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 <[hidden email]>:
> 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 [hidden email].
>
> 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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: add mapping for buftype=nofile?

Josef Fortier
In reply to this post by Nikolay Aleksandrovich Pavlov
This works well.
Thank you very much for your thorough and thoroughly informed response.

>     autocmd OptionSet buftype :if v:option_new is# 'nofile' | nnoremap …| endif

Unfortunately, 'OptionSet' event seems a very new event to vim :-(
The Distro provided vim's I use do not support it (but my "latest and greatest" desktop version does).

Best fallback I can think of is to map it to a function call that does the check for nofile post-facto (maybe to a Q? of some sort)

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: add mapping for buftype=nofile?

Josef Fortier
In reply to this post by Josef Fortier
I'm rather pleased with my simple solution, and thought someone else here might appreciate it:

nnoremap q<enter> :q!<cr>

<enter> cannot be mapped to a buffer. It makes a nice "get out of here" mapping :-)

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: add mapping for buftype=nofile?

Justin M. Keyes
On Wed, Jan 27, 2016 at 7:10 PM, Josef Fortier <[hidden email]> wrote:
> I'm rather pleased with my simple solution, and thought someone else here might appreciate it:
>
> nnoremap q<enter> :q!<cr>
>
> <enter> cannot be mapped to a buffer. It makes a nice "get out of here" mapping :-)

The built-in "ZQ" normal mode command already does that.

Justin M. Keyes

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.