Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

opening a directory in a new tab from within a try block #1353

Closed
nhooyr opened this issue Jan 5, 2017 · 6 comments
Closed

opening a directory in a new tab from within a try block #1353

nhooyr opened this issue Jan 5, 2017 · 6 comments

Comments

@nhooyr
Copy link

nhooyr commented Jan 5, 2017 •
edited
Loading

try | tab split /bin | endtry doesn't work.

See junegunn/fzf.vim#102 and https://groups.google.com/forum/#!msg/vim_use/EeQM4EWP7IY/yFrhedMDWCAJ
@vim-ml
Copy link

vim-ml commented Jan 6, 2017 via email

@pavoljuhas
Copy link

try | tab split /bin | endtry doesn't work.

What do you want to happen if the /bin directory did not exist?
As it stands, vim would open a new file /bin in a new tab, but that does not seem very predictable.

Perhaps an if block is more appropriate here than the try one:

if isdirectory('/bin')
    tab split /bin
endif

@nhooyr
Copy link
Author

nhooyr commented Jan 6, 2017

@pavoljuhas that's not the point of the issue. The snippet doesn't open the directory even if it exists is the problem.

@nhooyr nhooyr mentioned this issue Jan 6, 2017
Closed
@justinmk
Copy link
Contributor

Patch here: neovim/neovim#5933

justinmk added a commit to justinmk/neovim that referenced this issue Jan 12, 2017
@justinmk
open_buffer(): Raise BufEnter for directories.
a6b630b 
Abuse NOTDONE to give some nuance to the return value of readfile(), so
that open_buffer() can distinguish between "failed, lol", and "failed
because the path is a directory".

Before this change, Vim *already* creates a new buffer when a directory
is edited. So there is no reason it should not raise BufEnter, that was
an implementation of ye olde readfile().

The explicit changes in this commit merely preserve the old semantics.
The "passive" change that we actually are interested in, is this line in
`open_buffer()`, where `&retval` being non-FAIL allows EVENT_BUFENTER to
be applied:

    apply_autocmds_retval(EVENT_BUFENTER, NULL, NULL, FALSE, curbuf, &retval);

References vim/vim#1353
justinmk added a commit to justinmk/neovim that referenced this issue Jan 12, 2017
@justinmk
open_buffer(): Raise BufEnter for directories.
c78cebf 
Abuse NOTDONE to give some nuance to the return value of readfile(), so
that open_buffer() can distinguish between "failed, lol", and "failed
because the path is a directory".

Before this change, Vim *already* creates a new buffer when a directory
is edited. So there is no reason it should not raise BufEnter, that was
an implementation of ye olde readfile().

The line we are interested in is in `open_buffer()`, where `&retval` being
non-FAIL allows EVENT_BUFENTER to be applied:

    apply_autocmds_retval(EVENT_BUFENTER, NULL, NULL, FALSE, curbuf, &retval);

References vim/vim#1353
justinmk added a commit to justinmk/neovim that referenced this issue Jan 12, 2017
@justinmk
open_buffer(): Raise BufEnter for directories.
a6a9c9d 
Abuse NOTDONE to give some nuance to the return value of readfile(), so
that open_buffer() can distinguish between "failed, lol", and "failed
because the path is a directory".

Before this change, Vim *already* creates a new buffer when a directory
is edited. So there is no reason it should not raise BufEnter, that was
an implementation of ye olde readfile().

The explicit changes in this commit merely preserve the old semantics.
The "passive" change that we actually are interested in, is this line in
`open_buffer()`, where `&retval` being non-FAIL allows EVENT_BUFENTER to
be applied:

    apply_autocmds_retval(EVENT_BUFENTER, NULL, NULL, FALSE, curbuf, &retval);

References vim/vim#1353
@brammool
Copy link
Contributor

brammool commented Jan 12, 2017 via email

@justinmk
Copy link
Contributor

justinmk commented Jan 12, 2017 •
edited
Loading

I'll post a vim patch shortly. (done: #1375)

justinmk added a commit to justinmk/vim that referenced this issue Jan 12, 2017
@justinmk
Do BufEnter for directories.
d346a28 
Abuse NOTDONE to give some nuance to the return value of readfile(), so
that open_buffer() can distinguish between "general failure" and "failed
because the path is a directory".

Before this change, Vim *already* creates a new buffer when a directory
is edited. So there's no reason it should not raise BufEnter, that was
an implementation detail of readfile().

Most of the changes in this commit merely preserve the old semantics.
The "implicit" change that we actually are interested in, is this line
in `open_buffer()`, where `&retval` being non-FAIL allows EVENT_BUFENTER
to be applied:

    apply_autocmds_retval(EVENT_BUFENTER, NULL, NULL, FALSE, curbuf, &retval);

Closes vim#1353
@justinmk justinmk mentioned this issue Jan 12, 2017
Closed
justinmk added a commit to justinmk/neovim that referenced this issue Jan 12, 2017
@justinmk
open_buffer(): Do BufEnter for directories.
42c922b 
Abuse NOTDONE to give some nuance to the return value of readfile(), so
that open_buffer() can distinguish between "failed, lol" and "failed
because the path is a directory".

Before this change, Vim *already* creates a new buffer when a directory
is edited. So there is no reason it should not raise BufEnter, that was
an implementation detail of ye olde readfile().

Most of the changes in this commit merely preserve the old semantics.
The "implicit" change that we actually are interested in, is this line
in `open_buffer()`, where `retval` being non-FAIL allows EVENT_BUFENTER
to be applied:

    apply_autocmds_retval(EVENT_BUFENTER, NULL, NULL, FALSE, curbuf, &retval);

References vim/vim#1353
justinmk added a commit to justinmk/neovim that referenced this issue Mar 21, 2017
@justinmk
vim-patch:8.0.0177
68af851 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
justinmk added a commit to justinmk/neovim that referenced this issue Mar 21, 2017
@justinmk
vim-patch:8.0.0177
2dc7f7f 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
justinmk added a commit to justinmk/neovim that referenced this issue Mar 21, 2017
@justinmk
vim-patch:8.0.0177
ecd59a1 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
justinmk added a commit to justinmk/neovim that referenced this issue Mar 21, 2017
@justinmk
vim-patch:8.0.0177
f432108 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
justinmk added a commit to justinmk/neovim that referenced this issue Mar 22, 2017
@justinmk
vim-patch:8.0.0177
3ff9070 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
justinmk added a commit to justinmk/neovim that referenced this issue Mar 22, 2017
@justinmk
vim-patch:8.0.0177
5111c2b 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
justinmk added a commit to justinmk/neovim that referenced this issue Mar 22, 2017
@justinmk
vim-patch:8.0.0177
cba68c3 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
justinmk added a commit to justinmk/neovim that referenced this issue Mar 23, 2017
@justinmk
vim-patch:8.0.0177
ca853ed 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim/vim#1375,
            closes vim/vim#1353)

vim/vim@e13b9af
desvp pushed a commit to desvp/vim that referenced this issue May 30, 2017
@brammool @desvp
patch 8.0.0177: BufEnter autocommand not fired for a directory
e01fd2e 
Problem:    When opening a buffer on a directory and inside a try/catch then
            the BufEnter event is not triggered.
Solution:   Return NOTDONE from readfile() for a directory and deal with the
            three possible return values. (Justin M. Keyes, closes vim#1375,
            closes vim#1353)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@justinmk @pavoljuhas @brammool @nhooyr @vim-ml