Please disregard all patches i sent before.
The latest patch breaks current behaviour of ':[N]buffer' for buffers with
bufhidden=delete.
The issue may be fixed on plugin level, and here is the fix for dbext's
dbext#DB_auBufDelete():
--- autoload/dbext.vim 2011-05-31 11:20:40.000000000 +0400
+++ autoload.new/dbext.vim 2011-11-19 14:44:44.000000000 +0400
@@ -5800,62 +5800,72 @@
function! dbext#DB_auBufDelete(del_buf_nr) "{{{
" This function will delete any temporary dictionary files that were
" created and disconnect any DBI or ODBC connections
" Save the current buffer to switch back to
let cur_buf = bufnr("%")
" Some trickery to make sure this value is considered
" a number and not a string for use in the index() function.
let del_buf = a:del_buf_nr + 0
" This can happen if the buffer does not have a name associated
" with it, bufnr(expand("<afile">)) can return the current buffer
if cur_buf == del_buf
return
endif
let idx = index(s:dbext_buffers_with_dict_files, del_buf)
if idx > -1 || exists('g:loaded_dbext_auto')
+ " Do not let current buffer and syntax highlighting go which may
+ " happen when current value of 'bufhidden' is 'delete', 'wipe' etc.
+ let cur_bufhidden = &bufhidden
+ let cur_syntax = &syntax
+ setlocal bufhidden=
+
" Switch to the buffer being deleted
silent! exec del_buf.'buffer'
" If the buffer connection parameters have not been
" defaulted, dbext has not been used.
if s:DB_get("buffer_defaulted") == 1
" If using the DBI layer, drop any connections which may be
active
if s:DB_get('type') =~ '\<DBI\>\|\<ODBC\>'
call dbext#DB_disconnect()
endif
endif
" If the buffer number being deleted is in the script
" variable that lists all buffers that have temporary dictionary
" files, then remove the temporary dictionary files
call s:DB_DictionaryDelete( 'Table' )
call s:DB_DictionaryDelete( 'Procedure' )
call s:DB_DictionaryDelete( 'View' )
" Switch back to the current buffer
silent! exec cur_buf.'buffer'
+
+ " Switch back value of 'bufhidden' and syntax
+ exec "setlocal bufhidden=".cur_bufhidden
+ exec "setlocal syntax=".cur_syntax
endif
endfunction "}}}
"}}}
" Result buffer {{{
function! s:DB_resBufName()
if s:DB_get('use_sep_result_buffer') == 1
" Get the file name (no extension)
let res_buf_name = "Result-" . expand("%:t:r")
else
let res_buf_name = "Result"
endif
return res_buf_name
endfunction
" }}}
" orientationToggle {{{
function! dbext#DB_orientationToggle(...)
let sql = s:dbext_prev_sql
let refresh = 0
let curr_bufnr = s:dbext_prev_bufnr
So we just put 'setlocal bufhidden=' before unloading of 1st buffer (which
should not be unloaded) and when it returned back, just revert saved values
of 'bufhidden' and 'syntax'. This works fine.
Cheers, Alexey.
2011/11/19 Alexey Radkov <[email protected]>
> Here is the latest patch attached which fixes syntax highlighting with
> bufhidden=delete and autocommands for BufDelete that can temporarily unload
> current buffer (like in plugin dbext).
> I added a new field b_p_bkl ('keep loaded') in struct file_buffer to be
> used in set_curbuf() to flag close_buffer(prevbuf) not to 'del_buf' or
> 'wipe_buf' and not to syntax_clear() in buf_freeall().
>
> Cheers, Alexey.
>
>
>
> 2011/11/18 Alexey Radkov <[email protected]>
>
>> There is no issue with '#' in
>>
>>
>> autocmd BufReadPost * if &modeline == 1 | call dbext#DB_checkModeline() |
>> endif
>>
>> This '#' just triggers further loading of
>>
>> autocmd BufDelete * if exists('g:loaded_dbext_auto') != 0 | exec 'call
>> dbext#DB_auBufDelete( expand("<abuf>") )' | endif
>>
>> (due to setting g:loaded_dbext_auto drom autoload/dbext.vim). So the
>> problem of syntax highlighting disappearance still exists in unloading
>> buffer algorithm.
>>
>> Anyway the latest patch fixes unexpected buffer unloading, and also
>> syntax highlighting when closing quickfix window from normal buffer.
>>
>> Cheers, Alexey.
>>
>>
>> 2011/11/16 Alexey Radkov <[email protected]>
>>
>>> Here is the latest patch attached where i fixed those segfaults: this
>>> was really stupid to me to change first character in a static buffer, i
>>> just did not know how b_p_bh was using memory.
>>>
>>> Syntax also works fine. Except.... You won't believe!
>>>
>>> I said that i used plugin dbext. It has autogroup commands:
>>>
>>> augroup dbext
>>> au!
>>> autocmd BufEnter * if exists('g:loaded_dbext_auto') != 0 | exec
>>> "call dbext#DB_setTitle()" | endif
>>> autocmd BufReadPost * if &modeline == 1 | call
>>> dbext#DB_checkModeline() | endif
>>> autocmd BufDelete * if exists('g:loaded_dbext_auto') != 0 | exec
>>> 'call dbext#DB_auBufDelete( expand("<abuf>") )' | endif
>>> autocmd VimLeavePre * if exists('g:loaded_dbext_auto') != 0 | exec
>>> 'call dbext#DB_auVimLeavePre()' | endif
>>> augroup END
>>>
>>> Syntax highlight when switching back from last window in tabpage won't
>>> work in this original state. It will work if i remove autocmd BufReadPost.
>>> I made some investigations and found that if i use modeline == 0, in which
>>> case function dbext#DB_checkModeline() won't be called syntax hl won't work
>>> either. Of course i thought that there was something in the vim code that
>>> prevented normal work of the syntax when any BufReadPost autocmd had been
>>> just declared. But occasionally i found that something like
>>>
>>> autocmd BufReadPost * if &modeline == 1 | echo "AAA" | endif
>>>
>>> worked perfectly (e.g. highlighted reverted buffer). Eventually i found
>>> that symbol '#' in
>>>
>>> autocmd BufReadPost * if &modeline == 1 | call
>>> dbext#DB_checkModeline() | endif
>>>
>>> prevents normal loading of the syntax. This is extremely weird. And i
>>> even do not want to search what could be the cause of the issue. But of
>>> course this smells like a bug.
>>>
>>> In my dbext plugin i fixed this by simply moving
>>> dbext#DB_checkModeline() from autoload to plugin/dbext.vim and renaming it
>>> to DB_checkModeline(). Now the autocmd is
>>>
>>> autocmd BufReadPost * if &modeline == 1 | call DB_checkModeline() |
>>> endif
>>>
>>> and all works perfectly, i.e. syntax highlighting is OK and buffer is
>>> not unloaded. Also i checked that folds are kept and all the same for
>>> quitting from quickfix window.
>>>
>>>
>>> Cheers, Alexey.
>>>
>>>
>>>
>>> 2011/11/15 Alexey Radkov <[email protected]>
>>>
>>>> Thank you all, guys, for response.
>>>>
>>>> Actually the patch i attached is not perfect: it may lead to segfaults
>>>> if bufhidden is empty. Currently i am working on another patch which fixes
>>>> the issue, and i am struggling with syntax issue which is not working if
>>>> dbext plugin is used because dbext uses additional BufReadPost autocmd
>>>> which somehow prevents syntax in buffer where we return from highlighting.
>>>> If i remove this single autocmd then syntax works fine. Surprisingly it
>>>> does not matter which content of this autocmd is, it only matters the fact
>>>> of presence of autocmd itself. Looks weird.
>>>>
>>>>
>>>> 2011/11/15 Thilo Six <[email protected]>
>>>>
>>>>> Alexey Radkov wrote the following on 14.11.2011 20:41
>>>>>
>>>>> Hello Alexey,
>>>>>
>>>>> -- <snip> --
>>>>> > You will be returned to the original file, but... Now there is no
>>>>> > syntax highlight and ':ls' will show that there is no current buffer!
>>>>> > ':ls!' will show that the current buffer is unloaded. Same behaviour
>>>>> > can be found when using quickfix window instead tabpage.
>>>>> -- <snip> --
>>>>>
>>>>>
>>>>> Thank you for the detailed analysis and the patch. I assume that your
>>>>> foundings
>>>>> are also related to an issue that i had myself recently without being
>>>>> able to
>>>>> come to any useful solution.
>>>>> http://thread.gmane.org/gmane.editors.vim
>>>>> /100772<http://thread.gmane.org/gmane.editors.vim/100772>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Thilo
>>>>>
>>>>> 4096R/0xC70B1A8F
>>>>> 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
>>>>>
>>>>>
>>>>> --
>>>>> 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 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
