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.

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

Ignore netrw buffers #213

Conversation

pmeinhardt
Copy link
Contributor

@pmeinhardt pmeinhardt commented Mar 8, 2023

Previously, when starting Neovim with a directory, opening a netrw buffer, it would encounter the following errors when trying to close (:q):

E37: No write since last change
E162: No write since last change for buffer "…"

Since editorconfig is concerned with source files, not directory listings (as in the case of netrw buffers), I thought it makes sense to not apply the config for such buffers.

For further details of the issue and my investigation, please see: #212

Thank you so much for this awesome project. 💚

Previously, when starting Neovim with a directory, opening a netrw buffer,
it would encounter the following errors when trying to close (:q):

    E37: No write since last change
    E162: No write since last change for buffer "…"

editorconfig#212
Copy link
Member

@xuhdev xuhdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, thanks!

@xuhdev xuhdev merged commit 6e2b092 into editorconfig:master Mar 10, 2023
@@ -383,6 +383,11 @@ function! s:ApplyConfig(config) abort " Set the buffer options {{{1
return
endif

" Do not process netrw buffers
if &b:filetype == 'netrw'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are global and local options [1]. There are no 'buffer' options. This is a syntax error that yields

E113: Unknown option: b

Unfortunately, this error is hidden by the try-catch from the call site.

@pmeinhardt Please have a look. Maybe a change to &l is sufficient? I could not reproduce your original problem and therefore don't know if this is the right fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #215 for better visibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the catch -- I opened #216 to fix this.

Copy link
Contributor Author

@pmeinhardt pmeinhardt Mar 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kaihowl ❤️ Unfortunately with the change from #216 the problem re-appeared. 🤔

Copy link
Contributor

@kaihowl kaihowl Mar 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is indeed unfortunate.

I can even reproduce this with nerdtree instead of netrw. There already is a condition that should take care of not messing non-editable buffers. Nerdtree for example hijacks the FileExplorer event group and instead sets the necessary options, including buftype, as part of a new set of autocommands. These are sequenced after the editorconfig autocommands (or more precisely: they happen later in my setup, yet there is no guarantee of ordering AFAIK). Therefore, the buftype appears as editable when editorconfig sees it. The final value is of course nofile.

I am not an expert on autocommands. Therefore, my proposal for a fix is rather hacky: #217

inkarkat added a commit to inkarkat/editorconfig-vim that referenced this pull request Mar 24, 2023
…ditorconfig#213, 6e2b092)

Neovim may have buffer-scoped options that can be accessed via a &b: prefix,
but in vanilla Vim these have to be accessed via the &l: prefix.

That invalid prefix causes a (silent) script error and completely breaks the plugin!

(This corrects commit 6e2b092)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants