filetype for errorformat clang++ output

Hi,

How to set file type to match output of clang++ compilation (cpp source) ?

Thank you
NiVa

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to use an external indenter for a specific type of files?

On 2019-02-26, Peng Yu wrote:

> For example, I'd like to use clang-format to indent only .c and .cpp
> files. Is there a way to config vim to do so? Thanks.

Short answer:

:help =
:help 'equalprg'

Set 'equalprg' using setlocal in your ~/.vim/after/ftplugin/c.vim
and/or ~/.vim/after/ftplugin/cpp.vim file.

HTH,
Gary

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to use an external indenter for a specific type of files?

Hi,

For example, I'd like to use clang-format to indent only .c and .cpp
files. Is there a way to config vim to do so? Thanks.

--
Regards,
Peng

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Colorscheme vanishes after edit

> On 24 Feb 2019, at 09:38, meine <trialero@gmx.com> wrote:
>
> On Sat, Feb 23, 2019 at 07:28:58PM -0800, Ben Fritz wrote:
>> Try increasing the 'redrawtime' option.
>>
>> Just a wild guess though because I've been hitting that a lot on my old computer recently, so it's fresh on my mind. It likely won't work.
>
> Another thing I encountered with the same problem is to look for
> certain characters that are in your edited and/or pasted text. backticks
> (`) or missing paired parenthesis and braces can mess up the coloring of
> your text or stop it altogether. Just look from what point proper coloring
> stops, test by adding 'syntax coloring' triggers, to find the disturbing
> beast.

Thank you for pitching in, here.
As it happens, Ben nailed thr problem and, althogh I haven't tested it exhaustively yet, it's going in the right direction.
I was fairly sure that it wasn't a badly formatted file, as the file opens cleanly and displays all syntax colouring until you do 'something' to it.
THanks again.
Reggards, Andy

--
Andrew Long
Andrew dot Long at Mac dot com



--
Andrew Long
Andrew dot Long at Mac dot com

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Colorscheme vanishes after edit

> On 24 Feb 2019, at 03:28, Ben Fritz <fritzophrenic@gmail.com> wrote:
>
> Try increasing the 'redrawtime' option.
>
> Just a wild guess though because I've been hitting that a lot on my old computer recently, so it's fresh on my mind. It likely won't work.

Pretty good guess, nonetheless!
I doubled the value from the default (2000 mx) to 4000 ms and so far it's working.
I haven't worked it hard yet, though. I'll have to wait and see.

Thanks for your help.
Regards, Andy

--
Andrew Long
Andrew dot Long at Mac dot com



--
Andrew Long
Andrew dot Long at Mac dot com

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: possible RFE - open existing window w/file already being edited

On Mon, Feb 25, 2019 at 3:34 PM Efraim Yawitz <efraim.yawitz@gmail.com> wrote:
>
> Have you tried tabs instead of separate windows?
>
> Everyone has the way they like to work, so maybe this isn't appropriate for you, but right now I have 77 tabs open for maybe 15 projects, and I can find whatever I want with a simple :tabs command (and I'm sure there must be some plugin to make it even easier.)

There is also the "usetab" setting of the 'switchbuf' option: after
":set swb+=usetab", the command ":sbuffer /path/to/filename.ext" will
bring you to the window for filename.ext if there is one in any tab.
If there isn't, I'm not sure, maybe it will give an error, but even if
it does, you know that that file isn't yet loaded so you can open a
new window (and possibly a new tab) for it.

Best regards,
Tony.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: possible RFE - open existing window w/file already being edited

Have you tried tabs instead of separate windows?

Everyone has the way they like to work, so maybe this isn't appropriate for you, but right now I have 77 tabs open for maybe 15 projects, and I can find whatever I want with a simple :tabs command (and I'm sure there must be some plugin to make it even easier.)

All the best,

Ephraim Yawitz

On Mon, Feb 25, 2019 at 3:00 AM L A Walsh <vim@tlinx.org> wrote:

Very often I have many gvim windows open -- sometimes for unrelated
projects because I hit a snag in 1 project that sends me off to another.

Add that to breaks, and I forget which windows are minimized over in the
the tray.

Just like now, I wanted to open a file that has a list I wanted
browse to find the right error code for a program I was working
in.  I tried to open errnos.shh but got the message it found a
.swp file, I scan for the process info to see if it says it is
still active.  It is.  So then 'abort' that and then go
to taskbar and only see 1 icon for vim with 5 files hiding
under it.

I move my mouse over the taskbar icon and it displays the names
each of them is editing, then I click on it to open and continue work.

What would really speed up my work flow is if it would behave like
some apps (like web browsers), where if I already have the file
open in a gvim instance, if my 'invocation' of a new gvim on the
same file could send the other one a command to restore itself to the
desktop and pop-to-the top.

Then I can just skip all the reading on the duplicate scanning for pid,
scanning for 'still running', then going to find the current one.

Is that possible or is it something that might be added?

Currently running gvim via 'X' from a linux machine but
displaying on a windows machine, but we're really talking about
an 'X' window being bumped to the top, though the same situation
could arise if I was using the Windows GUI version (just that most
of my editing is of files on the linux machine).

Might this be possible?

Thanks!

--
--
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 vim_use+unsubscribe@googlegroups.com.
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: possible RFE - open existing window w/file already being edited

On So, 24 Feb 2019, L A Walsh wrote:

> Very often I have many gvim windows open -- sometimes for unrelated
> projects because I hit a snag in 1 project that sends me off to another.
>
> Add that to breaks, and I forget which windows are minimized over in the
> the tray.
>
> Just like now, I wanted to open a file that has a list I wanted
> browse to find the right error code for a program I was working
> in. I tried to open errnos.shh but got the message it found a
> .swp file, I scan for the process info to see if it says it is
> still active. It is. So then 'abort' that and then go
> to taskbar and only see 1 icon for vim with 5 files hiding
> under it.
>
> I move my mouse over the taskbar icon and it displays the names
> each of them is editing, then I click on it to open and continue work.
>
> What would really speed up my work flow is if it would behave like
> some apps (like web browsers), where if I already have the file
> open in a gvim instance, if my 'invocation' of a new gvim on the
> same file could send the other one a command to restore itself to the
> desktop and pop-to-the top.
>
> Then I can just skip all the reading on the duplicate scanning for pid,
> scanning for 'still running', then going to find the current one.
>
> Is that possible or is it something that might be added?
>
> Currently running gvim via 'X' from a linux machine but
> displaying on a windows machine, but we're really talking about
> an 'X' window being bumped to the top, though the same situation
> could arise if I was using the Windows GUI version (just that most
> of my editing is of files on the linux machine).
>
> Might this be possible?

Have you tried the editexisting vim script, that comes distributed with
Vim and lives below /usr/share/vim/vim80/pack/dist/opt/editexisting/

Best,
Christian
--
Vati, was heißt "FORMATIERE LAUFWERK C:?"

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Gvim remote press enter to continue

Thank you Tony.

Works perfectly now. I am very grateful.

Andrew


--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Gvim remote press enter to continue

On Mon, Feb 25, 2019 at 2:34 AM Andrew Bernard <andrew.bernard@gmail.com> wrote:
>
> I am using the Lilypond open source music engraving program on Ubuntu 18.10. It supports point and click from objects in the output PDF score to various different editors. Now attempting to use gvim, it is not working correctly for me in the same smooth way that emacs does. Clicking on a note should simply take you to the line and column in the editor. This is the command invoked to do that with gvim:
>
> gvim --remote +:line:normcolumn file
>
> What is getting in the way of this working is that for each click, the following message is displayed by gvim:
>
> :if !exists('+acd')||!&acd|if haslocaldir()|cd -|lcd -|elseif getcwd() ==# '/home/andro'|cd -|endif|endif
> ::1898:norm3|cal foreground()|if &im|star|en|redr|f
>
> And also 'Press ENTER or type command to continue'.
>
> I'd like to solve this problem, and also stop gvim asking you to press ENTER every time a remote command is received. What is causing this?
>
>
> Andrew

This is usually due to a too small 'cmdheight' setting (q.v.). The
default is 1 but 2 or 3 often gives a smoother functioning.

I have the following in my vimrc for this; if you still get the error
after making the change and restarting Vim, then try replacing the
digit 2 (twice) by a 3:

if exists('+cmdheight') && (&ch < 2)
set ch=2
endif


Best regards,
Tony.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

possible RFE - open existing window w/file already being edited

Very often I have many gvim windows open -- sometimes for unrelated
projects because I hit a snag in 1 project that sends me off to another.

Add that to breaks, and I forget which windows are minimized over in the
the tray.

Just like now, I wanted to open a file that has a list I wanted
browse to find the right error code for a program I was working
in. I tried to open errnos.shh but got the message it found a
.swp file, I scan for the process info to see if it says it is
still active. It is. So then 'abort' that and then go
to taskbar and only see 1 icon for vim with 5 files hiding
under it.

I move my mouse over the taskbar icon and it displays the names
each of them is editing, then I click on it to open and continue work.

What would really speed up my work flow is if it would behave like
some apps (like web browsers), where if I already have the file
open in a gvim instance, if my 'invocation' of a new gvim on the
same file could send the other one a command to restore itself to the
desktop and pop-to-the top.

Then I can just skip all the reading on the duplicate scanning for pid,
scanning for 'still running', then going to find the current one.

Is that possible or is it something that might be added?

Currently running gvim via 'X' from a linux machine but
displaying on a windows machine, but we're really talking about
an 'X' window being bumped to the top, though the same situation
could arise if I was using the Windows GUI version (just that most
of my editing is of files on the linux machine).

Might this be possible?

Thanks!

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gvim remote press enter to continue

I am using the Lilypond open source music engraving program on Ubuntu 18.10. It supports point and click from objects in the output PDF score to various different editors. Now attempting to use gvim, it is not working correctly for me in the same smooth way that emacs does. Clicking on a note should simply take you to the line and column in the editor. This is the command invoked to do that with gvim:

gvim --remote +:line:normcolumn file

What is getting in the way of this working is that for each click, the following message is displayed by gvim:

:if !exists('+acd')||!&acd|if haslocaldir()|cd -|lcd -|elseif getcwd() ==# '/home/andro'|cd -|endif|endif
::1898:norm3|cal foreground()|if &im|star|en|redr|f

And also 'Press ENTER or type command to continue'.

I'd like to solve this problem, and also stop gvim asking you to press ENTER every time a remote command is received. What is causing this?


Andrew

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Colorscheme vanishes after edit

On Sat, Feb 23, 2019 at 07:28:58PM -0800, Ben Fritz wrote:
> Try increasing the 'redrawtime' option.
>
> Just a wild guess though because I've been hitting that a lot on my old computer recently, so it's fresh on my mind. It likely won't work.

Another thing I encountered with the same problem is to look for
certain characters that are in your edited and/or pasted text. backticks
(`) or missing paired parenthesis and braces can mess up the coloring of
your text or stop it altogether. Just look from what point proper coloring
stops, test by adding 'syntax coloring' triggers, to find the disturbing
beast.

//meine

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Colorscheme vanishes after edit

Try increasing the 'redrawtime' option.

Just a wild guess though because I've been hitting that a lot on my old computer recently, so it's fresh on my mind. It likely won't work.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Colorscheme vanishes after edit

Hi all.
Just upgraded from a VERY old copy of Cygwin (with a pre version 8 gvim) to a much newer version with vim 8.
I have a custom syntax recogniser for my primary language (VME SCL) which has been quite stable for the past however lomg it's been.
Now however, the colours al go away after an extensive edit on a file (forex ':%retab')
The file opens normally with all indents, folds and colours in place.
After the edit through, the only colours in evidence are on the closed folds and the 'fold depth' marker column.
If i place the cursor on a term and do '\hlt' it knows about the syntax item.
Has anyone seen this behaviour before? If so, any ideas on how to solve the problem?
Old system was an HP box running Windows XP (can't go back to it., the company trashed it!) New system is a Fujitsu laptop running Windows 10.1.
Output of the ':version' command appended below
Regards, Andy

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 4 2018 23:26:14) Included patches: 1-1567 Modified by <cygwin@cygwin.com> Compiled by <cygwin@cygwin.com> Huge version with GTK3 GUI. Features included (+) or not (-): +acl +cryptv -footer +mksession +path_extra +syntax +viminfo +arabic +cscope +fork() +modify_fname +perl/dyn +tag_binary +vreplace +autocmd +cursorbind +gettext +mouse +persistent_undo +tag_old_static +wildignore -autoservername +cursorshape -hangul_input +mouseshape +postscript -tag_any_white +wildmenu +balloon_eval +dialog_con_gui +iconv +mouse_dec +printer -tcl +windows +balloon_eval_term +diff +insert_expand -mouse_gpm +profile +termguicolors +writebackup +browse +digraphs +job -mouse_jsbterm +python/dyn +terminal +X11 ++builtin_terms +dnd +jumplist +mouse_netterm +python3/dyn +terminfo -xfontset +byte_offset -ebcdic +keymap +mouse_sgr +quickfix +termresponse +xim +channel +emacs_tags +lambda -mouse_sysmouse +reltime +textobjects +xpm +cindent +eval +langmap +mouse_urxvt +rightleft +timers +xsmp_interact +clientserver +ex_extra +libcall +mouse_xterm +ruby/dyn +title +xterm_clipboard +clipboard +extra_search +linebreak +multi_byte +scrollbind +toolbar -xterm_save +cmdline_compl +farsi +lispindent +multi_lang +signs +user_commands +cmdline_hist +file_in_path +listcmds -mzscheme +smartindent +vertsplit +cmdline_info +find_in_path +localmap +netbeans_intg +startuptime +virtualedit +comments +float +lua/dyn +num64 +statusline +visual +conceal +folding +menu +packages -sun_workshop +visualextra system vimrc file: "/etc/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "/etc/gvimrc" user gvimrc file: "$HOME/.gvimrc" 2nd user gvimrc file: "~/.vim/gvimrc" defaults file: "$VIMRUNTIME/defaults.vim" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/etc" f-b for $VIMRUNTIME: "/usr/share/vim/vim80" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -D_REENTRANT -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/ -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -ggdb -O2 -pipe -Wall -Werror=format-security -fstack-protector-strong --param=ssp-buffer-size=4 -fdebug-prefix-map=/usr/src/ports/vim/vim-8.0.1567-1.x86_64/build=/usr/src/debug/vim-8.0.1567-1 -fdebug-prefix-map=/usr/src/ports/vim/vim-8.0.1567-1.x86_64/src/vim-8.0.1567=/usr/src/debug/vim-8.0.1567-1 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: gcc -L. -fstack-protector -L/usr/local/lib -Wl,--as-needed -o vim.exe -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lelf -lnsl -lncursesw -liconv -lacl -lattr -lintl -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong -L/usr/lib/perl5/5.26/x86_64-cygwin-threads/CORE -lperl -lpthread -ldl -lcrypt "~/version.txt" "~/version.txt" 0L, 0C


--
Andrew Long
Andrew dot Long at Mac dot com



--
Andrew Long
Andrew dot Long at Mac dot com

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jump away from terminal tab?

Wow, thanks a lot!

Am Freitag, 22. Februar 2019 16:11:30 UTC+1 schrieb Bram Moolenaar:
> CTRL-W gt makes sense, let me add that.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Looks like Vim Tips wiki is moving

On Thursday, February 21, 2019 at 3:49:41 AM UTC+11, Ben Fritz wrote:
> Wikia has a banner announcement on the Vim wiki pages that they're moving us to a new domain name:
>
> https://community.wikia.com/wiki/Help:Fandom_domain_migration

The Vim wiki is now at https://vim.fandom.com

I have been talking with Wikia support for a couple of days. There is a review (at my request) that the Vim wiki be moved to vim.wikia.org (it used to be at vim.wikia.com). If that happens, incoming requests to pages at vim.fandom.com would redirect to vim.wikia.org.

On the plus side, the new sites (fandom.com and wikia.org) use https (the old site was http).

Incoming links to the now defunct vim.wikia.com are redirected to vim.fandom.com (or vim.wikia.org if we end up there).

Other than marketing spiel, there is no information about why all this turmoil is occurring or what use will be made of the wikia.com URL in the future. I gather that the great majority of successful Wikia sites (those with activity and lots of readers) concern topics where "fandom" is appropriate.

John

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Clipboard triggering CursorHold?

Are there documented cases in Vim 7 of CursorHold being triggered by the clipboard's usage? I'm running into this scenario:

1. Set CursorHold to do something
2. Set a clipboard value from within Vim (set @+ = "X")
3. Paste anywhere outside of Vim
4. CursorHold is (randomly) executed

A few notes:
* Running Ubuntu 16.04 + Gnome, Vim 7.4. Problem isn't triggered in Vim 8.1.
* It may take a few 'pastes' outside of Vim before CursorHold is triggered (may be one, may be fifty)
* In all cases, CursorHold is triggered before its timeout (I'm using 500 seconds)
* Always happens exactly when pasting (ie as far as I've noticed, it's not randomly triggered by other events)
* CursorHold is not triggered if the contents of the clipboard are not set within Vim (ie: set the contents of the clipboard within Vim, copy something else from outside Vim, the CursorHold isn't triggered until its timeout)

I'm using the script copied below to test this out (run with vim -u ./script.vim) - after Vim started, I :call XX() and paste anywhere outside Vim - usually after 1 or 2 tries I get a "Ping".

Any ideas what may be triggering CursorHold and how to avoid it?


function! XX()
let @+ = "XX"
endfunction

set updatetime=500000
autocmd CursorHold * echo "Ping"

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jump away from terminal tab?

> Is there a key combination to jump away from a tab that only contains
> a terminal window? Something like 'Ctrl-W g t', (but not 'Ctrl-W N g
> t')?

CTRL-W gt makes sense, let me add that.

--
Me? A skeptic? I trust you have proof.

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GVIM: alt/meta keys: inconsistent results for getchar(0)

> I don't see how you can get a modifier sequence without anything
> following. Would require some debugging.

I submitted a bug report as a reminder.

Regards

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GVIM: alt/meta keys: inconsistent results for getchar(0)

> > When I run this code in Windows GVIM and press, e.g., <m-down> in a row:
> >
> > sleep 1|for i in range(10) | echo string(getchar(0)) | sleep 50m | endfor
> >
> > I get a mix of '<80><fc>^H<80>ku' and '<80><fc>^H'.
>
> Additional question: When I press <m-down> only once, I get one '<80><fc>^H<80>ku' and 9 '<80><fc>^H' although no key is pressed at that time.
>
> This can also be done with:
>
> echo getchar()|for i in range(10) | echo string(getchar(0)) | sleep 50m | endfor
>
> Is that expected? In this situation, I'd naivly expect the first getchar() to return '<80><fc>^H<80>ku', and the subsequent getchar(0) to return 0.

I don't see how you can get a modifier sequence without anything
following. Would require some debugging.

--
All good vision statements are created by groups of people with bloated
bladders who would rather be doing anything else.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jump away from terminal tab?

Is there a key combination to jump away from a tab that only contains a terminal window? Something like 'Ctrl-W g t', (but not 'Ctrl-W N g t')?

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GVIM: alt/meta keys: inconsistent results for getchar(0)

> When I run this code in Windows GVIM and press, e.g., <m-down> in a row:
>
> sleep 1|for i in range(10) | echo string(getchar(0)) | sleep 50m | endfor
>
> I get a mix of '<80><fc>^H<80>ku' and '<80><fc>^H'.

Additional question: When I press <m-down> only once, I get one '<80><fc>^H<80>ku' and 9 '<80><fc>^H' although no key is pressed at that time.

This can also be done with:

echo getchar()|for i in range(10) | echo string(getchar(0)) | sleep 50m | endfor

Is that expected? In this situation, I'd naivly expect the first getchar() to return '<80><fc>^H<80>ku', and the subsequent getchar(0) to return 0.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GVIM: alt/meta keys: inconsistent results for getchar(0)

Hi!

When I run this code in Windows GVIM and press, e.g., <m-down> in a row:

sleep 1|for i in range(10) | echo string(getchar(0)) | sleep 50m | endfor

I get a mix of '<80><fc>^H<80>ku' and '<80><fc>^H'.

When I increase the timeout to 150m, I get only '<80><fc>^H<80>ku', which seems correct.

Is this expected? Is it a bug? Is there another way to make sure I get the right key code other that using sleep?

Regards,
Tom

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows build: STATIC_STDCPLUS=yes no longer works

On Wed, Feb 20, 2019 at 10:04 PM Ken Takata <ktakata65536@gmail.com> wrote:

Hi,

2019/2/20 Wed 22:31:56 UTC+9 Salman Halim wrote:
> Hello,
>
>
> I upgraded my GVim on Windows from 8.1.822 to 8.1.956 yesterday. I noticed that the STATIC_STDCPLUS=yes no longer seems to have an effect and that I need to have both libwinpthread-1.dll and libgcc_s_dw2-1.dll. I didn't for 8.1.822.
>
>
> I build using 32-bit MSys with this:
>
>
>
> cd vim/src
>
>
> mingw32-make -f Make_ming.mak -j$NUMBER_OF_PROCESSORS GUI=yes FEATURES=HUGE PYTHON=c:/Python27 PYTHON_VER=27 DYNAMIC_PYTHON=yes STATIC_STDCPLUS=yes
>
>
> Perhaps the removal of DOS did something?
>
>
> Thank you,

Could you try the attached patch?

Regards,
Ken Takata

Hello, Ken,

That fixed it. I'm glad it was such a trivial fix to the makefile. Thanks very much!

--

 
Salman

I, too, shall something make and glory in the making.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows build: STATIC_STDCPLUS=yes no longer works

# HG changeset patch
# Parent a7fe8a7065f3ebf6b9d67c8a8a157c9ff77a5e92

diff --git a/src/Make_cyg_ming.mak b/src/Make_cyg_ming.mak
--- a/src/Make_cyg_ming.mak
+++ b/src/Make_cyg_ming.mak
@@ -934,7 +934,7 @@ ifeq (yes, $(USE_STDCPLUS))
LINK = $(CXX)
ifeq (yes, $(STATIC_STDCPLUS))
#LIB += -static-libstdc++ -static-libgcc
-LIB += -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
+LIB += -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic
endif
else
LINK = $(CC)
Hi,

2019/2/20 Wed 22:31:56 UTC+9 Salman Halim wrote:
> Hello,
>
>
> I upgraded my GVim on Windows from 8.1.822 to 8.1.956 yesterday. I noticed that the STATIC_STDCPLUS=yes no longer seems to have an effect and that I need to have both libwinpthread-1.dll and libgcc_s_dw2-1.dll. I didn't for 8.1.822.
>
>
> I build using 32-bit MSys with this:
>
>
>
> cd vim/src
>
>
> mingw32-make -f Make_ming.mak -j$NUMBER_OF_PROCESSORS GUI=yes FEATURES=HUGE PYTHON=c:/Python27 PYTHON_VER=27 DYNAMIC_PYTHON=yes STATIC_STDCPLUS=yes
>
>
> Perhaps the removal of DOS did something?
>
>
> Thank you,

Could you try the attached patch?

Regards,
Ken Takata

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Le mercredi 20 février 2019 14:23:32 UTC+1, Salman Halim a écrit :
> I built 956 yesterday, but still don't see the problem you're seeing. Sorry...
>
>
> I do see a problem with DLL dependencies. Will send a separate email message. 
>
>
> --
>
> Salman
>
>
> On Wed, Feb 20, 2019, 02:08 <niva...@gmail.com wrote:
> Windows 10 gvim 8.1.952
>
>
>
> --
>
> --
>
> 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 vim_use+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

Ok so there is no pb. Maybe melting pot of all plugins or _vimrc configuration.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Looks like Vim Tips wiki is moving

Wikia has a banner announcement on the Vim wiki pages that they're moving us to a new domain name:

https://community.wikia.com/wiki/Help:Fandom_domain_migration

I assume it will be "vim.fandom.com" but haven't seen that stated explicitly anywhere yet.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Windows build: STATIC_STDCPLUS=yes no longer works

Hello,

I upgraded my GVim on Windows from 8.1.822 to 8.1.956 yesterday. I noticed that the STATIC_STDCPLUS=yes no longer seems to have an effect and that I need to have both libwinpthread-1.dll and libgcc_s_dw2-1.dll. I didn't for 8.1.822.

I build using 32-bit MSys with this:

cd vim/src

mingw32-make -f Make_ming.mak -j$NUMBER_OF_PROCESSORS GUI=yes FEATURES=HUGE PYTHON=c:/Python27 PYTHON_VER=27 DYNAMIC_PYTHON=yes STATIC_STDCPLUS=yes

Perhaps the removal of DOS did something?

Thank you,

--

 
Salman

I, too, shall something make and glory in the making.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

I built 956 yesterday, but still don't see the problem you're seeing. Sorry...

I do see a problem with DLL dependencies. Will send a separate email message. 

--

Salman

On Wed, Feb 20, 2019, 02:08 <nivaemail@gmail.com wrote:

Windows 10 gvim 8.1.952

--
--
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 vim_use+unsubscribe@googlegroups.com.
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Windows 10 gvim 8.1.952

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Fair point. Unfortunately, no, I cannot: I get the exact same session file whether or not I have a trailing comma. (Diff shows no differences, the file contains nothing off and loading it doesn't add extra buffers.)

I'm on Windows, using GVim 8.1.822. You?

--

Salman

On Tue, Feb 19, 2019, 15:08 <nivaemail@gmail.com wrote:

Can you confirm this first?

--
--
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 vim_use+unsubscribe@googlegroups.com.
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Can you confirm this first?

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

A trailing comma shouldn't be required. Can a Vim dev have a look, please?

--

Salman

On Tue, Feb 19, 2019, 03:49 <nivaemail@gmail.com wrote:

Le lundi 18 février 2019 17:50:01 UTC+1, niva...@gmail.com a écrit :
> Le dimanche 17 février 2019 21:38:38 UTC+1, Salman Halim a écrit :
> > > Okay I've done some further tests.
> >
> > >
> >
> > > :bufdo! bd! >> clear all buffers as you said.
> >
> > >
> >
> > > Yesterday I had copied my session.vim file into ~/desktop so it seems it take care about history actions.
> >
> > >
> >
> > > When I close Vim, no buffer is listed in buffers'list.
> >
> > > When I open Vim again, buffers'list contains my yesterday ~/desktop/sessions.vim which is not exsiting anymore.
> >
> > >
> >
> > > ... see the gif.
> >
> >
> >
> > https://drive.google.com/open?id=1xPX4InUKhYEVrBuosfHqNk_SNRXY7PgT
> >
> >
> >
> > 1. Out of curiosity, what are the values of g:geometry#sessionfile and g:geometry#file?
> Ok rewrite the autoload vimscript as below : now jsut one session.
>
> > 2. Have you tried writing a separate session file out by hand right after doing the bufdo! bd! to see if it that session file contains anything different than the automatically generated one?
>
>
>
> > 3. Have you tried using bufwipe instead of bufdelete? bufdo! bw! (That's "stronger" than deleting a buffer.)
>
> Tried :bufdo! bw! out of :bufdo! bd! then :buffers returns only noname buffer
>
> Then I confirm the the attached mainsession.vim is written at vim leave.
>
> And on reload, buffers command list noname and mainsession.Vim
>
> > 4. The list of buffers is controlled through viminfo, not just sessions. What's the timestamp of your viminfo? Is it getting updated every time you quit? What are its contents? Could the buffer be coming back through that file?
> >
> :rviminfo says nothing.
>
>
> >
> > Here's the thing: I don't have the autocommands that you do. I also cannot reproduce what you're seeing. I remove all my buffers, write out the session file with an empty Vim (by hand), quit and come back. The first thing I do is execute ':buffers' to confirm it's still empty and then load the session file. My second call to :buffers is STILL empty. I also have no buffers or args in my session file.
> >
> > -- 
> >
> >  
> > Salman
> >
> > I, too, shall something make and glory in the making.
>
>
>
> autoload/geometry.vim
> let g:geometry#sessionfile=expand('$vimruntime/sessions/mainSession.vim')
>
> fun! geometry#SaveGeometry() "{{{
>
>   echo 'Save'
>   if !filereadable(g:geometry#sessionfile)
>       call mkdir(expand('$vimruntime/sessions'),0700)
>   endif
>   silent! execute 'mks! '.g:geometry#sessionfile
> endfunction "}}}
>
> fun! geometry#RestoreGeometry() "{{{
>
>   echo 'Restore'
>   if filereadable(g:geometry#sessionfile)
>       silent! execute 'source '.g:geometry#sessionfile       
>   endif
> endfunction "}}}

Solved, after some tests, it appears that sessionoptions in _vimrc need to be written like this :
set sessionoptions=buffers,help,resize,winpos,winsize,
instead of
set sessionoptions=buffers,help,resize,winpos,winsize

Otherwise, there is no restoration of winsize.

--
--
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 vim_use+unsubscribe@googlegroups.com.
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Le lundi 18 février 2019 17:50:01 UTC+1, niva...@gmail.com a écrit :
> Le dimanche 17 février 2019 21:38:38 UTC+1, Salman Halim a écrit :
> > > Okay I've done some further tests.
> >
> > >
> >
> > > :bufdo! bd! >> clear all buffers as you said.
> >
> > >
> >
> > > Yesterday I had copied my session.vim file into ~/desktop so it seems it take care about history actions.
> >
> > >
> >
> > > When I close Vim, no buffer is listed in buffers'list.
> >
> > > When I open Vim again, buffers'list contains my yesterday ~/desktop/sessions.vim which is not exsiting anymore.
> >
> > >
> >
> > > ... see the gif.
> >
> >
> >
> > https://drive.google.com/open?id=1xPX4InUKhYEVrBuosfHqNk_SNRXY7PgT
> >
> >
> >
> > 1. Out of curiosity, what are the values of g:geometry#sessionfile and g:geometry#file?
> Ok rewrite the autoload vimscript as below : now jsut one session.
>
> > 2. Have you tried writing a separate session file out by hand right after doing the bufdo! bd! to see if it that session file contains anything different than the automatically generated one?
>
>
>
> > 3. Have you tried using bufwipe instead of bufdelete? bufdo! bw! (That's "stronger" than deleting a buffer.)
>
> Tried :bufdo! bw! out of :bufdo! bd! then :buffers returns only noname buffer
>
> Then I confirm the the attached mainsession.vim is written at vim leave.
>
> And on reload, buffers command list noname and mainsession.Vim
>
> > 4. The list of buffers is controlled through viminfo, not just sessions. What's the timestamp of your viminfo? Is it getting updated every time you quit? What are its contents? Could the buffer be coming back through that file?
> >
> :rviminfo says nothing.
>
>
> >
> > Here's the thing: I don't have the autocommands that you do. I also cannot reproduce what you're seeing. I remove all my buffers, write out the session file with an empty Vim (by hand), quit and come back. The first thing I do is execute ':buffers' to confirm it's still empty and then load the session file. My second call to :buffers is STILL empty. I also have no buffers or args in my session file.
> >
> > -- 
> >
> >  
> > Salman
> >
> > I, too, shall something make and glory in the making.
>
>
>
> autoload/geometry.vim
> let g:geometry#sessionfile=expand('$vimruntime/sessions/mainSession.vim')
>
> fun! geometry#SaveGeometry() "{{{
>
> echo 'Save'
> if !filereadable(g:geometry#sessionfile)
> call mkdir(expand('$vimruntime/sessions'),0700)
> endif
> silent! execute 'mks! '.g:geometry#sessionfile
> endfunction "}}}
>
> fun! geometry#RestoreGeometry() "{{{
>
> echo 'Restore'
> if filereadable(g:geometry#sessionfile)
> silent! execute 'source '.g:geometry#sessionfile
> endif
> endfunction "}}}

Solved, after some tests, it appears that sessionoptions in _vimrc need to be written like this :
set sessionoptions=buffers,help,resize,winpos,winsize,
instead of
set sessionoptions=buffers,help,resize,winpos,winsize

Otherwise, there is no restoration of winsize.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Le dimanche 17 février 2019 21:38:38 UTC+1, Salman Halim a écrit :
> > Okay I've done some further tests.
>
> >
>
> > :bufdo! bd! >> clear all buffers as you said.
>
> >
>
> > Yesterday I had copied my session.vim file into ~/desktop so it seems it take care about history actions.
>
> >
>
> > When I close Vim, no buffer is listed in buffers'list.
>
> > When I open Vim again, buffers'list contains my yesterday ~/desktop/sessions.vim which is not exsiting anymore.
>
> >
>
> > ... see the gif.
>
>
>
> https://drive.google.com/open?id=1xPX4InUKhYEVrBuosfHqNk_SNRXY7PgT
>
>
>
> 1. Out of curiosity, what are the values of g:geometry#sessionfile and g:geometry#file?
Ok rewrite the autoload vimscript as below : now jsut one session.

> 2. Have you tried writing a separate session file out by hand right after doing the bufdo! bd! to see if it that session file contains anything different than the automatically generated one?



> 3. Have you tried using bufwipe instead of bufdelete? bufdo! bw! (That's "stronger" than deleting a buffer.)

Tried :bufdo! bw! out of :bufdo! bd! then :buffers returns only noname buffer

Then I confirm the the attached mainsession.vim is written at vim leave.

And on reload, buffers command list noname and mainsession.Vim

> 4. The list of buffers is controlled through viminfo, not just sessions. What's the timestamp of your viminfo? Is it getting updated every time you quit? What are its contents? Could the buffer be coming back through that file?
>
:rviminfo says nothing.


>
> Here's the thing: I don't have the autocommands that you do. I also cannot reproduce what you're seeing. I remove all my buffers, write out the session file with an empty Vim (by hand), quit and come back. The first thing I do is execute ':buffers' to confirm it's still empty and then load the session file. My second call to :buffers is STILL empty. I also have no buffers or args in my session file.
>
> -- 
>
>  
> Salman
>
> I, too, shall something make and glory in the making.



autoload/geometry.vim
let g:geometry#sessionfile=expand('$vimruntime/sessions/mainSession.vim')

fun! geometry#SaveGeometry() "{{{

echo 'Save'
if !filereadable(g:geometry#sessionfile)
call mkdir(expand('$vimruntime/sessions'),0700)
endif
silent! execute 'mks! '.g:geometry#sessionfile
endfunction "}}}

fun! geometry#RestoreGeometry() "{{{

echo 'Restore'
if filereadable(g:geometry#sessionfile)
silent! execute 'source '.g:geometry#sessionfile
endif
endfunction "}}}


--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature/plugin dependency checks in plugins

Hi,

> What is the best practice when a plugin needs a minimum version of
> Vim with certain features, or on some other plugin?

1- I try to document the identified requirement
2- I provide emulation of new features I use when this is possible.

See for instance https://github.com/luchermitte/lh-vim-lib/blob/master/autoload/lh/list.vim

3- Regarding the dependency to other plugins I usually expect the plugin I depend on to be up-to-date. And I provide the dependencies in the documentation of my plugin. I also highly recommend people to use plugin managers that understand dependencies (like VAM or vim-flavor). But I'm perfectly aware that people usually fancy plugin managers that download multiple plugins in parallel or have some other smooths feature. Personally I'm mainly interested in dependencies management.

BTW, version requirements can be expressed with vim-flavor.


> Do you check
> for the version (and if so how) or do you check for some each
> feature or for some feature which is indicative that the others
> exist too? Is it best to check when the plugin is loaded or in
> each function which needs a certain feature? What do you do when
> the requirements aren't met --- issue a warning/error message or
> just silently do nothing?

"Ignore" or "error" when the plugin file is loaded. But definitively "error" when a plugin feature is triggered and that the requirements are not met.
It depends on whether the plugin is critical or not. And whether it could be a non-critical dependency on some other plugin. For instance, my refactoring plugin implements a refactoring that depends on a plugin (lh-tags) that depends on ctags. It also implements other refactoring. I don't want to notify the end user that lh-tags cannot be used because ctags is not installed just because lh-tags is automatically installed (VAM) when the refactoring plugin is installed.


> My preference is definitely to issue a
> message, but I'm concerned that it may be too noisy and get lost
> if it is issued at loading time.


> There is also the concern that if
> you are using a plugin manager some other plugin which you depend
> on may not be loaded yet even though it eventually will be.

My plugin manager updates the runtimepath before any file from plugin/ is sourced. Then the dependencies are mainly done through autoloaded function. In case I depend on a mapping or a command, I explicitly source the files that defines it with :runtime.


HTH

--
Luc Hermitte

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

> Okay I've done some further tests.
>
> :bufdo! bd! >> clear all buffers as you said.
>
> Yesterday I had copied my session.vim file into ~/desktop so it seems it take care about history actions.
>
> When I close Vim, no buffer is listed in buffers'list.
> When I open Vim again, buffers'list contains my yesterday ~/desktop/sessions.vim which is not exsiting anymore.
>
> ... see the gif.

https://drive.google.com/open?id=1xPX4InUKhYEVrBuosfHqNk_SNRXY7PgT

1. Out of curiosity, what are the values of g:geometry#sessionfile and g:geometry#file?

2. Have you tried writing a separate session file out by hand right after doing the bufdo! bd! to see if it that session file contains anything different than the automatically generated one?

3. Have you tried using bufwipe instead of bufdelete? bufdo! bw! (That's "stronger" than deleting a buffer.)

4. The list of buffers is controlled through viminfo, not just sessions. What's the timestamp of your viminfo? Is it getting updated every time you quit? What are its contents? Could the buffer be coming back through that file?

Here's the thing: I don't have the autocommands that you do. I also cannot reproduce what you're seeing. I remove all my buffers, write out the session file with an empty Vim (by hand), quit and come back. The first thing I do is execute ':buffers' to confirm it's still empty and then load the session file. My second call to :buffers is STILL empty. I also have no buffers or args in my session file.

-- 

 
Salman

I, too, shall something make and glory in the making.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Le dimanche 17 février 2019 20:53:10 UTC+1, niva...@gmail.com a écrit :
> Le dimanche 17 février 2019 20:17:17 UTC+1, Salman Halim a écrit :
> > On Sun, Feb 17, 2019, 12:45 <niva...@gmail.com wrote:
> > Le dimanche 17 février 2019 18:32:04 UTC+1, Salman Halim a écrit :
> >
> > > On Sun, Feb 17, 2019, 11:54  <niva...@gmail.com wrote:
> >
> > > Le dimanche 17 février 2019 14:52:20 UTC+1, Salman Halim a écrit :
> >
> > >
> >
> > >
> >
> > > > After the "bd!", does listing buffers again confirm that it's gone?
> >
> > >
> >
> > > >
> >
> > >
> >
> > > no.
> >
> > >
> >
> > >
> >
> > >
> >
> > > Ah, so the session and autocommand aren't to blame. If you call "bd!" and the buffer is still there, then maybe bufwipe or something needs to be checked?
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > >
> >
> > >
> >
> > > > Have you examined the contents and timestamp of the session file to see if it contains the details of that buffer?
> >
> > >
> >
> > > >
> >
> > >
> >
> > > timestamp is good at vim leaving and it contains infos of that buffer :
> >
> > >
> >
> > >
> >
> > >
> >
> > > let SessionLoad = 1
> >
> > >
> >
> > > if &cp | set nocp | endif
> >
> > >
> >
> > > let s:so_save = &so | let s:siso_save = &siso | set so=0 siso=0
> >
> > >
> >
> > > let v:this_session=expand("<sfile>:p")
> >
> > >
> >
> > > silent only
> >
> > >
> >
> > > if expand('%') == '' && !&modified && line('$') <= 1 && getline(1) == ''
> >
> > >
> >
> > >   let s:wipebuf = bufnr('%')
> >
> > >
> >
> > > endif
> >
> > >
> >
> > > set shortmess=aoO
> >
> > >
> >
> > > argglobal
> >
> > >
> >
> > > %argdel
> >
> > >
> >
> > > $argadd ~/Desktop/thatbuffer.txt
> >
> > >
> >
> > > winpos 278 74
> >
> > >
> >
> > >
> >
> > >
> >
> > > It seems as if the session process isn't at fault here, but the buffer wiping is. 
> >
> > >
> >
> > >
> >
> > > The call to winpos seems to indicate that the buffer is still open in an active window? That's not consistent with a deleted buffer. 
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > >
> >
> > >
> >
> > > > How about disabling the autocommand and manually saving the session?
> >
> > >
> >
> > > >
> >
> > >
> >
> > > I don't want to lose interest of autocmd but I can try.
> >
> > >
> >
> > >
> >
> > >
> >
> > > I was trying to isolate the three different variables: buffer delete, autocommand and session making. 
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > >
> >
> > >
> >
> > > > Anything in your session options or viminfo that might be contributing something?
> >
> > >
> >
> > > >
> >
> > >
> >
> > > just classical set sessionoptions=help,winsize,winpos
> >
> > >
> >
> > >
> >
> > >
> >
> > > Yeah, that's innocuous. I was wondering whether viminfo might have something to do, but based on your session snippet above, it's clearly not viminfo. 
> >
> > >
> >
> > >
> >
> > > Salman
> >
> >
> >
> > Sorry, for the first point: when I use ":bd! NoOfBuffer", it is not listed yet. So bd is working well.
> >
> >
> >
> > Okay, so what happens if you close all tabs and leave in just one window, wiping/deleting all buffers, verify that :buffers looks good, showing only the open window, and then save the session? Does the session file still have buffers that it shouldn't?
> >
> >
> > Basically, I'm trying to figure out whether there's a bug in buffer deletion, session creation or the autocommand mechanism, but to do that we need to create a simple example that demonstrates the problem and eliminates any potential human error. 
> >
> >
> > Salman
>
> Okay I've done some further tests.
>
> :bufdo! bd! >> clear all buffers as you said.
>
> Yesterday I had copied my session.vim file into ~/desktop so it seems it take care about history actions.
>
> When I close Vim, no buffer is listed in buffers'list.
> When I open Vim again, buffers'list contains my yesterday ~/desktop/sessions.vim which is not exsiting anymore.
>
> ... see the gif.

https://drive.google.com/open?id=1xPX4InUKhYEVrBuosfHqNk_SNRXY7PgT

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Le dimanche 17 février 2019 20:17:17 UTC+1, Salman Halim a écrit :
> On Sun, Feb 17, 2019, 12:45 <niva...@gmail.com wrote:
> Le dimanche 17 février 2019 18:32:04 UTC+1, Salman Halim a écrit :
>
> > On Sun, Feb 17, 2019, 11:54  <niva...@gmail.com wrote:
>
> > Le dimanche 17 février 2019 14:52:20 UTC+1, Salman Halim a écrit :
>
> >
>
> >
>
> > > After the "bd!", does listing buffers again confirm that it's gone?
>
> >
>
> > >
>
> >
>
> > no.
>
> >
>
> >
>
> >
>
> > Ah, so the session and autocommand aren't to blame. If you call "bd!" and the buffer is still there, then maybe bufwipe or something needs to be checked?
>
> >
>
> >
>
> >
>
> >
>
> > >
>
> >
>
> > > Have you examined the contents and timestamp of the session file to see if it contains the details of that buffer?
>
> >
>
> > >
>
> >
>
> > timestamp is good at vim leaving and it contains infos of that buffer :
>
> >
>
> >
>
> >
>
> > let SessionLoad = 1
>
> >
>
> > if &cp | set nocp | endif
>
> >
>
> > let s:so_save = &so | let s:siso_save = &siso | set so=0 siso=0
>
> >
>
> > let v:this_session=expand("<sfile>:p")
>
> >
>
> > silent only
>
> >
>
> > if expand('%') == '' && !&modified && line('$') <= 1 && getline(1) == ''
>
> >
>
> >   let s:wipebuf = bufnr('%')
>
> >
>
> > endif
>
> >
>
> > set shortmess=aoO
>
> >
>
> > argglobal
>
> >
>
> > %argdel
>
> >
>
> > $argadd ~/Desktop/thatbuffer.txt
>
> >
>
> > winpos 278 74
>
> >
>
> >
>
> >
>
> > It seems as if the session process isn't at fault here, but the buffer wiping is. 
>
> >
>
> >
>
> > The call to winpos seems to indicate that the buffer is still open in an active window? That's not consistent with a deleted buffer. 
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > >
>
> >
>
> > > How about disabling the autocommand and manually saving the session?
>
> >
>
> > >
>
> >
>
> > I don't want to lose interest of autocmd but I can try.
>
> >
>
> >
>
> >
>
> > I was trying to isolate the three different variables: buffer delete, autocommand and session making. 
>
> >
>
> >
>
> >
>
> >
>
> > >
>
> >
>
> > > Anything in your session options or viminfo that might be contributing something?
>
> >
>
> > >
>
> >
>
> > just classical set sessionoptions=help,winsize,winpos
>
> >
>
> >
>
> >
>
> > Yeah, that's innocuous. I was wondering whether viminfo might have something to do, but based on your session snippet above, it's clearly not viminfo. 
>
> >
>
> >
>
> > Salman
>
>
>
> Sorry, for the first point: when I use ":bd! NoOfBuffer", it is not listed yet. So bd is working well.
>
>
>
> Okay, so what happens if you close all tabs and leave in just one window, wiping/deleting all buffers, verify that :buffers looks good, showing only the open window, and then save the session? Does the session file still have buffers that it shouldn't?
>
>
> Basically, I'm trying to figure out whether there's a bug in buffer deletion, session creation or the autocommand mechanism, but to do that we need to create a simple example that demonstrates the problem and eliminates any potential human error. 
>
>
> Salman

Okay I've done some further tests.

:bufdo! bd! >> clear all buffers as you said.

Yesterday I had copied my session.vim file into ~/desktop so it seems it take care about history actions.

When I close Vim, no buffer is listed in buffers'list.
When I open Vim again, buffers'list contains my yesterday ~/desktop/sessions.vim which is not exsiting anymore.

... see the gif.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

On Sun, Feb 17, 2019, 12:45 <nivaemail@gmail.com wrote:

Le dimanche 17 février 2019 18:32:04 UTC+1, Salman Halim a écrit :
> On Sun, Feb 17, 2019, 11:54  <niva...@gmail.com wrote:
> Le dimanche 17 février 2019 14:52:20 UTC+1, Salman Halim a écrit :
>
>
> > After the "bd!", does listing buffers again confirm that it's gone?
>
> >
>
> no.
>
>
>
> Ah, so the session and autocommand aren't to blame. If you call "bd!" and the buffer is still there, then maybe bufwipe or something needs to be checked?
>
>
>
>
> >
>
> > Have you examined the contents and timestamp of the session file to see if it contains the details of that buffer?
>
> >
>
> timestamp is good at vim leaving and it contains infos of that buffer :
>
>
>
> let SessionLoad = 1
>
> if &cp | set nocp | endif
>
> let s:so_save = &so | let s:siso_save = &siso | set so=0 siso=0
>
> let v:this_session=expand("<sfile>:p")
>
> silent only
>
> if expand('%') == '' && !&modified && line('$') <= 1 && getline(1) == ''
>
>   let s:wipebuf = bufnr('%')
>
> endif
>
> set shortmess=aoO
>
> argglobal
>
> %argdel
>
> $argadd ~/Desktop/thatbuffer.txt
>
> winpos 278 74
>
>
>
> It seems as if the session process isn't at fault here, but the buffer wiping is. 
>
>
> The call to winpos seems to indicate that the buffer is still open in an active window? That's not consistent with a deleted buffer. 
>
>
>
>
>
>
> >
>
> > How about disabling the autocommand and manually saving the session?
>
> >
>
> I don't want to lose interest of autocmd but I can try.
>
>
>
> I was trying to isolate the three different variables: buffer delete, autocommand and session making. 
>
>
>
>
> >
>
> > Anything in your session options or viminfo that might be contributing something?
>
> >
>
> just classical set sessionoptions=help,winsize,winpos
>
>
>
> Yeah, that's innocuous. I was wondering whether viminfo might have something to do, but based on your session snippet above, it's clearly not viminfo. 
>
>
> Salman

Sorry, for the first point: when I use ":bd! NoOfBuffer", it is not listed yet. So bd is working well.

Okay, so what happens if you close all tabs and leave in just one window, wiping/deleting all buffers, verify that :buffers looks good, showing only the open window, and then save the session? Does the session file still have buffers that it shouldn't?

Basically, I'm trying to figure out whether there's a bug in buffer deletion, session creation or the autocommand mechanism, but to do that we need to create a simple example that demonstrates the problem and eliminates any potential human error. 

Salman

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mksession restore just deleted buffer

Le dimanche 17 février 2019 18:32:04 UTC+1, Salman Halim a écrit :
> On Sun, Feb 17, 2019, 11:54 <niva...@gmail.com wrote:
> Le dimanche 17 février 2019 14:52:20 UTC+1, Salman Halim a écrit :
>
>
> > After the "bd!", does listing buffers again confirm that it's gone?
>
> >
>
> no.
>
>
>
> Ah, so the session and autocommand aren't to blame. If you call "bd!" and the buffer is still there, then maybe bufwipe or something needs to be checked?
>
>
>
>
> >
>
> > Have you examined the contents and timestamp of the session file to see if it contains the details of that buffer?
>
> >
>
> timestamp is good at vim leaving and it contains infos of that buffer :
>
>
>
> let SessionLoad = 1
>
> if &cp | set nocp | endif
>
> let s:so_save = &so | let s:siso_save = &siso | set so=0 siso=0
>
> let v:this_session=expand("<sfile>:p")
>
> silent only
>
> if expand('%') == '' && !&modified && line('$') <= 1 && getline(1) == ''
>
>   let s:wipebuf = bufnr('%')
>
> endif
>
> set shortmess=aoO
>
> argglobal
>
> %argdel
>
> $argadd ~/Desktop/thatbuffer.txt
>
> winpos 278 74
>
>
>
> It seems as if the session process isn't at fault here, but the buffer wiping is. 
>
>
> The call to winpos seems to indicate that the buffer is still open in an active window? That's not consistent with a deleted buffer. 
>
>
>
>
>
>
> >
>
> > How about disabling the autocommand and manually saving the session?
>
> >
>
> I don't want to lose interest of autocmd but I can try.
>
>
>
> I was trying to isolate the three different variables: buffer delete, autocommand and session making. 
>
>
>
>
> >
>
> > Anything in your session options or viminfo that might be contributing something?
>
> >
>
> just classical set sessionoptions=help,winsize,winpos
>
>
>
> Yeah, that's innocuous. I was wondering whether viminfo might have something to do, but based on your session snippet above, it's clearly not viminfo. 
>
>
> Salman

Sorry, for the first point: when I use ":bd! NoOfBuffer", it is not listed yet. So bd is working well.

--
--
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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.