2016-09-02 9:47 GMT+03:00 LCD 47 <[email protected]>: > On 2 September 2016, Justin M. Keyes <[email protected]> wrote: >> On Thu, Sep 1, 2016 at 4:20 PM, LCD 47 <[email protected]> wrote: >> > On 1 September 2016, Nikolay Aleksandrovich Pavlov <[email protected]> >> > wrote: >> >> 2016-09-01 15:47 GMT+03:00 LCD 47 <[email protected]>: >> >> > What is the recommended way to get the buffer number of a file >> >> > starting from the filename? >> >> > >> > [...] >> >> > Based on the above (and taking a peek at the sources), I came up >> >> > with this attempt: >> >> > >> >> > function! Name2Buf(fname) abort >> >> > if exists('+shellslash') >> >> > let old_shellslash = &shellslash >> >> > let &shellslash = 1 >> >> > let buf = bufnr(escape( fnamemodify(a:fname, ':p'), >> >> > '\*?,{}[' )) >> >> > let &shellslash = old_shellslash >> >> > else >> >> > let buf = bufnr(escape( fnamemodify(a:fname, ':p'), >> >> > '\*?,{}[' )) >> >> > endif >> >> > >> >> > return buf >> >> > endfunction >> >> > >> >> > It mostly works, until I try it on a file named a,b\{2,3\}.txt: >> >> > >> >> > :echo expand('%:p') >> >> > /home/lcd047/tmp/a,b\{3.4}.txt >> >> > >> >> > :Name2Buf(expand('%:p')) >> >> > -1 >> >> > >> >> > However the naive bufnr(expand('%:p')) works, but it shouldn't, >> >> > because of the two commas ",": >> >> > >> >> > echomsg bufnr(expand('%:p')) >> >> > 1 >> >> > >> >> > So, what _is_ the right way to do this? >> >> >> >> I would go with `fnameescape()`, but this does not work with your >> >> file name either. Additional problem is that `fnameescape()` does >> >> not work correctly on Windows. >> > >> > fnameescape() is definitely wrong here, it escapes characters >> > that have nothing to do with the "file-pattern" set (f.i. '%' and >> > '#'). Looking at the code, the "bad" characters are a mixture of >> > glob characters with regexp characters. I don't think it's possible >> > to disarm them all with a simple escape(). I wonder why it's >> > possible to do all those weird globbing in bufnr() (does anybody >> > actually use them?), but it isn't possible to do an exact string >> > match. >> >> I use basic regex with bufnr(), to *avoid* bufnr() useless magic: >> >> https://github.com/justinmk/vim-dirvish/blob/master/autoload/dirvish.vim#L306-L330 > > Sadly the "^ ... $" pattern still fails for a,b\{3.4}.txt: > > :echo expand('%:p') > /home/lcd047/tmp/a,b\{3.4}.txt > > :echo bufnr('^' . expand('%:p') . '$') > -1 > > But it succeeds without the anchors: > > :echo bufnr(expand('%:p')) > 1 > >> It seems to me that long ago the decision should have been to only >> have "magic" in _commands_, not functions. Plugin authors (and >> vimrc authors) usually do not want user-configured behavior, it is >> a headache. E.g. there is zero reason that substitute() should care >> about any global option. For typical editing one invokes :substitute, >> not substitute(). > > Absolutely, this is a long-time gripe of mine, too. Among other > things, all regexps in scripts have to be littered with "\m" or "\v", > because somebody, somewhere (presumably under a heavy rock), _might_ > be running with "set nomagic". And it goes only half way in the other > direction too, since there is no such thing as "set verymagic", for > those of us that aren't so fond of ye olde BRE syntax.
`\m` or `\v` is more-or-less fine because of the `\v` effects. What is bothering more, unless you are going to learn which functions do use &ignorecase and which do not all regexps should be littered with `\C` additionally. And &ignorecase is an option which is really used by people. > >> This sort of inconsistency was not "inherited from Vi", since >> FEAT_EVAL was not in Vi. > > Sadly it's still 20+ years too late to fix now. > > /lcd > > -- > -- > You received this message from the "vim_dev" 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_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
