fully disable xterm title?
Hi, I want to fully disable vim's xterm title bar manipulation. Web searches offer ten thousand advices on how to turn it *on*, but very little on turning it off. sigh. Using -- $ script -c 'vim foobar' /tmp/junk -- I can see that even with "set notitle" in my .vimrc, vim still sets the title to "foobar", then sets it back to the original string. For instance, these strings appear in the output of `vim -u NONE foobar`, with "set notitle; set t_ts=" in .vimrc: \033]2;foobar (~) - VIM\007 \033]1;foobar\007 \033]2;old_title\007 \033]1;old_title\007 None of the following attempts were sufficient to stop it from doing that: "set notitle" in .vimrc "set t_ts=" in .vimrc $ vim -u NONE $ vim --cmd "set notitle" $ vim -C # not even 'compatible mode' does it These DO prevent it, but have additional effects -- I don't want to totally disengage vim's X11 capabilities, only the title manipulation: $ vim -X $ DISPLAY= vim I could create a special terminfo entry with no title manipulation facilities for vim's use only, but ugh. vim 7.4 "Included patches: 1-1689" "Extra patches: 8.0.0056", on Ubuntu 16.04.02 x86_64. [Future patch 7.4.2264 says "Improve handling of the title.", but code does not look like it would affect my issue; did not try to build with it.] Thanks, >Bela< PS: SOLVED! But I think worth injecting where other people may eventually find it as a solution to the same or related issues. I was being misled: the '\033]1' sequence has to do with the *icon* of an xterm (what the window manager would show if it were minimized). I think in some cases I had gotten it down to only showing that sequence in the output; which means I had already fixed my problem, but followed a false indicator that it wasn't fixed. After downloading the source, I noticed the Makefile creating something called "no_title.vim"; this included the command "set noicon". Putting: set notitle noicon into my .vimrc *is* sufficient to fully prevent title manipulations, including those icon manipulation sequences which I was falsely identifying (but which, truthfully, I also don't want). -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug in ftdetect?
FYI I reproduced this with a recent checkout and also a 7.3 build, so I'm pretty sure it's neither fixed nor a regression. I will look into profiling the issue, but I am still baffled. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Bug in ftdetect?
I recently discovered that using ftdetect is absurdly slower than filetype.vim.
To reproduce, try this:
mkdir -p ~/.vim/ftdetect
echo 'autocmd BufNew,BufNewFile,BufRead *.md :set filetype=markdown' >
~/.vim/ftdetect/markdown.vim
mkdir testing
cd testing
touch {1..500}.md
vim
:args *
Here's vim --version:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 17 2017 12:13:35)
Included patches: 1-95
Modified by pkg-vim-maintain...@lists.alioth.debian.org
Compiled by pkg-vim-maintain...@lists.alioth.debian.org
Huge version with GTK3 GUI. Features included (+) or not (-):
+acl +file_in_path+mouse_sgr +tag_old_static
+arabic +find_in_path-mouse_sysmouse -tag_any_white
+autocmd +float +mouse_urxvt +tcl
+balloon_eval+folding +mouse_xterm +termguicolors
+browse -footer +multi_byte +terminfo
++builtin_terms +fork() +multi_lang +termresponse
+byte_offset +gettext -mzscheme+textobjects
+channel -hangul_input+netbeans_intg +timers
+cindent +iconv +num64 +title
+clientserver+insert_expand +packages+toolbar
+clipboard +job +path_extra +user_commands
+cmdline_compl +jumplist+perl+vertsplit
+cmdline_hist+keymap +persistent_undo +virtualedit
+cmdline_info+lambda +postscript +visual
+comments+langmap +printer +visualextra
+conceal +libcall +profile +viminfo
+cryptv +linebreak -python +vreplace
+cscope +lispindent +python3 +wildignore
+cursorbind +listcmds+quickfix+wildmenu
+cursorshape +localmap+reltime +windows
+dialog_con_gui +lua +rightleft +writebackup
+diff+menu+ruby+X11
+digraphs+mksession +scrollbind -xfontset
+dnd +modify_fname+signs +xim
-ebcdic +mouse +smartindent +xpm
+emacs_tags +mouseshape +startuptime +xsmp_interact
+eval+mouse_dec +statusline +xterm_clipboard
+ex_extra+mouse_gpm -sun_workshop-xterm_save
+extra_search-mouse_jsbterm +syntax
+farsi +mouse_netterm +tag_binary
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/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: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread
-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/x86_64-linux-gnu/dbus-1.0/include
-I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/mirclient
-I/usr/include/mircore -I/usr/include/mircookie -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/gdk-pixbuf-2.0
-I/usr/include/libpng16 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wdate-time -g -O2
-fdebug-prefix-map=/build/vim-8krYYf/vim-8.0.0095=. -fPIE
-fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now
-fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E
-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o
vim -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 -lSM -lICE -lXpm
-lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm
-ldl -L/usr/lib -llua5.2 -Wl,-E -fstack-protector-strong -L/usr/local/lib
-L/usr/lib/x86_64-linux-gnu/perl/5.24/CORE -lperl -ldl -lm -lpthread -lcrypt
-L/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu -lpython3.5m -lpthread -ldl
-lutil -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lieee -lm
-lruby-2.3 -lpthread -lgmp -ldl -lcrypt -lm
The docs *do* say that if you are detecting files based purely on names you
should instead use an autload group in a filetype.vim file, but it's pretty far
down in the docs and a *lot* of people seem to have made this mistake:
Re: "superscript" asterisk is gone!
Tony Mechelynck wrote: > In Bitstream Vera Sans Mono 8 in gvim 8.0.600 for GTK3 (which I just > made using "make reconfig" after an update of the python2, python3 and > IIRC lua packages), U+20F0 is present in the buffer and gvim > recognises it as a composing character, but its display is easy to > miss: AFAICT only 3 pixels are in the foreground colour, at top right > of the character cell, in this shape (shown here by one asterisk per > pixel): > ** > * > > When the cursor is on it, ga and g8 give the expected values below the > status line. > Hello: The glyph doesn't have much to show, but frequently its not showing anything. Sometimes when I press ctrl-L for a refresh it will appear. Sometimes. Regards, Chip Campbell -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Bug/non-determinism in output of maparg() and map commands
I would like to be able to save and restore mappings programmatically. In
order to do so, however, I need to be able to determine the exact lhs and
rhs used to create the mapping. I had assumed the lhs/rhs members of the
dictionary returned by maparg() would provided this information, but as the
simple example below illustrates, it does not. The problem is that both the
4 character mapping...
""
...and the single character function key mapping produce the same output
for maparg()['lhs'] and `nmap '. (The nmap output does at least
colorize the function key, but the text output is identical.) The 'rhs'
member seems to be treated slightly differently, but still inconsistently:
in particular, for the maps created under default 'cpo', 'rhs' looks
correct, but for (created with '<' in 'cpo'), it looks wrong. I
suspect what's happening is that 'rhs' is always reporting exactly what was
typed, but since in the general case I have no way of knowing what 'cpo'
was in effect when the map was created, this isn't very helpful.
Is there a programmatic way to determine lhs and rhs in some sort of
canonical form? Also helpful would be if hasmapto() (or something like it)
told you exactly which lhs was mapped to the specified rhs. (I realize
there could be more than one, since hasmapto() doesn't require an exact
match, but there's a similar situation with mapcheck(), and it just picks
one mapping to return, which can be useful in certain use cases.) More
generally, it seems there should be some way to determine a list of lhs
from a given rhs...
-- Test commands --
set cpo&
nmap
nmap F8> F8>
set cpo+=<
nmap
set cpo&
-- Output of nmap and maparg --
nmap
n @
n @
n @
echo maparg('', 'n', 0, 1)
{'silent': 0, 'noremap': 0, 'lhs': '', 'mode': 'n', 'nowait': 0,
'expr': 0, 'sid': 66, 'rhs': '', 'buffer': 1}
echo maparg('F8>', 'n', 0, 1)
{'silent': 0, 'noremap': 0, 'lhs': '', 'mode': 'n', 'nowait': 0,
'expr': 0, 'sid': 66, 'rhs': 'F8>', 'buffer': 1}
echo maparg('F9>', 'n', 0, 1)
{'silent': 0, 'noremap': 0, 'lhs': '', 'mode': 'n', 'nowait': 0,
'expr': 0, 'sid': 66, 'rhs': '', 'buffer': 1}
Thanks,
Brett Stahlman
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Search highlighting that honors syntax coloring
On Saturday, May 20, 2017 at 2:49:45 AM UTC-5, Steve Simmons wrote: > Advance apologies if my google-fu has failed and there's already an answer to > this somewhere - > > I'd like to have search highlighting honor the current state of syntax > coloring but inverting foreground and background. Thus if I search for a > string and its found in some thing displayed as green on black, the > highlighted search is displayed as black on green. If the next instance is > found in something displayed as black on yellow, the highlighted search is > displayed as yellow on black. > > Advance thanks, > > Steve In your colorscheme, find the "hi Search" line and change it to: hi Search gui=inverse term=inverse cterm=inverse Don't specify any guifg, guibg, etc. colors. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: :right command on Chinese characters
On 2017-05-22 01:49, Joey Ling wrote: > On Sunday, May 21, 2017 at 8:15:50 PM UTC+8, Tim Chase wrote: > > I suspect what's happening is that, since Vim does the > > right-justification with spaces, Word is displaying all those > > spaces and then not having enough room to display the last > > character, so it bumps it to the next line. So the first > > "solution" would have vim add fewer spaces before the > > right-justified text in the actual document, while the second & > > third ideas increase the number of characters that Word should be > > able to fit on a line. > > I have set the same 80 characters per line for both Vim and Word, > in my opion, they should display the same, am I wrong? In vim, 80 characters is 80 character-cells so it fits exactly. In Word, AFAIK, there is no "make the width 80 characters" but rather margins (set in units of inches/mm/cm/whatever) and variable fonts (set in units of points, potentially monospace, potentially proportional). So Vim is giving you 80 actual characters, but Word is not giving you 80 full-width-Chinese-glyph characters. Rather, Word may be giving you 80 of *some* average character (usually an "M") and doing whatever it wishes with the spacing. For best results in Word, you'd want to specify a monospace font and paste 80 wide characters, then set your margins & font-size accordingly. -tim -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: :right command on Chinese characters
On Sunday, May 21, 2017 at 8:15:50 PM UTC+8, Tim Chase wrote: > On 2017-05-21 19:54, Joey wrote: > > When I run :right command in gvim, it's ok, like this: > > > >彼外道常说自然，我说因缘。——楞严经 > > > > But if I open the txt file with Word, it's like this: > > > > 彼外道常说自然，我说因缘。——楞严 > > 经 > > > > The last character is returned to the next line, what's wrong? > > Does the result change in any of the following cases: > > - you set 'tw' to something smaller or 'wm' slightly larger? > > - you set the font smaller in Word? > > - you increase your left/right margins in Word? > > > I suspect what's happening is that, since Vim does the > right-justification with spaces, Word is displaying all those spaces > and then not having enough room to display the last character, so it > bumps it to the next line. So the first "solution" would have vim > add fewer spaces before the right-justified text in the actual > document, while the second & third ideas increase the number of > characters that Word should be able to fit on a line. > > -tim I have set the same 80 characters per line for both Vim and Word, in my opion, they should display the same, am I wrong? -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
