On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <[email protected]> wrote:
>
> Renato Fabbri wrote:
>
> > Would you call these bugs?
> >
> > 1)
> > vim script (vimL) syntax highlighting highlights on (:only) as an option
> > value, e.g.
> > if a ==# 'banana'
> > on
> > en
>
> Doesn't happen for me.
>
Thanks. I could not reproduce it either, maybe context dependent
or a previously messy .vim tree.
But I found other things as such (that's why I made this thread and item 1).
Just tested this one:
if 1==2
ec 'x'
en (<--- this guy only unindent when I put the d at the end. I write d
and delete it. And abbrev might resolve, but...)
(at the end of the msg is my :version)
>
> > 2)
> > termguicolors was (AFAIU) mostly or only for GUI, including the
> > colorscheme gui= guibg= and guibf= settings....
> > in terminal vim, if you set termguicolors, you loose the
> > SpellBad visual cue, which entail an impaired spell check.
> > One have to execute
> > :hi SpellBad cterm=undercurl
> > to achieve what is probably desired by Vim developers.
>
> That's a tricky one. When 'termguicolors' was introduced the idea was
> to keep using the cterm attributes and only get the colors from guifg
> and guibg. But for this highlight that doesn't work. And I don't see a
> workaround.
>
> We could add the "termgui" attributes, which would then only be used
> when 'termguicolors' is set. I don't like adding another attribute
> though.
>
> Another solution would be to not use the GUI colors if there aren't any.
> Maybe a bit inconsistent, but it would work.
>
>
Why not just add cterm=undercurl to SpellBad's basic settings?
Also, it should be fairly simple to loop though syntax groups
and copy the gui=X to cterm=X
I almost made a one-liner for this, but I don't need it now,
so maybe when I do I post back, but it entails that
the user will get a consistent tgc context, right?
i am also not all about a new attribute, but one other value in the
syntax (hi SpellBad cterm=undercurl), at least in this case,
seems valuable from here.
Another idea is an option or flag to make cterm=NONE use cterm={whats X on
gui=X}
I was not able to follow you on this sentence:
"Another solution would be to not use the GUI colors if there aren't any."
When I try, I touch the void.
> 3)
> > pack/xxx/opt/yyy/after/
> > are not run after :packadd yyy
> > (which is just tear-jerking)
>
> Was already reported (by you). Still wondering why you would have an
> "after" directory, why not load the script there right away?
>
Some reasons which I came across:
- If I am using opt/ (or packs in general) to organize things, load this
and not that,
some after/ commands might be only for stuff x (plugin, workflow,
experiments etc).
- If I want to assure that such commands are executed with as much of the
final context as possible.,
but don't fell convenient to make a function with them, and run them
afterwards, nor detach
them from the associated file tree.
- Non-default settings.
I am trying to move away from these after/ files, but they are too
convenient,
so I repeatedly find myself sourcing these after files by hand.
- One might clone a plugin repo (the whole tree) into pack/xx/(start/ or
opt/),
and be happy with loading auto or keeping things lean and
having an easy way to loading it if wanted.
Fantastic weather, but there is a catch: if the tree has an after/ dir, you
keep
the whole tree in opt/ but copy the after files into the working after
(usually .vim/after).
If you cloned into opt/, not executing packadd in vimrc might raise errors.
- Another one: the pack/*/*/*/after are added to rtp, but are not working
as other after/ dirs (actually, I only trust the .vim/after/ dir at the
moment).
I get that in the manual most often (or always?) a "plugin" is considered
a one file add-on that stays in plugin/.
In practice, as Vimball allows and we all make them, plugins are very often
file trees in the template decribed at :h 'rtp'.
Right? (I am really asking, of course)
A more explicit ordering of the files sourcing is also something I miss not
understanding still. I made some tests on this with global variables,
but found my way out before grasping the issue well.
Thank you for your reply and time.
>
> --
> My Go, this amn keyboar oesn't have a .
>
> /// Bram Moolenaar -- [email protected] -- 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
> ///
>
=====
my :version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Feb 24 2018 10:17:16)
Included patches: 1-1532
Compiled by renato@xps
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +comments +file_in_path +linebreak
+mouse_urxvt +quickfix +terminal +windows
+arabic +conceal +find_in_path +lispindent
+mouse_xterm +reltime +terminfo +writebackup
+autocmd +cryptv +float +listcmds
+multi_byte +rightleft +termresponse +X11
-autoservername +cscope +folding +localmap
+multi_lang -ruby +textobjects -xfontset
+balloon_eval +cursorbind -footer -lua
-mzscheme +scrollbind +timers +xim
+balloon_eval_term +cursorshape +fork() +menu
+netbeans_intg +signs +title -xpm
+browse +dialog_con_gui +gettext +mksession
+num64 +smartindent +toolbar +xsmp_interact
++builtin_terms +diff -hangul_input +modify_fname
+packages +startuptime +user_commands +xterm_clipboard
+byte_offset +digraphs +iconv +mouse
+path_extra +statusline +vertsplit -xterm_save
+channel +dnd +insert_expand +mouseshape
-perl -sun_workshop +virtualedit
+cindent -ebcdic +job +mouse_dec
+persistent_undo +syntax +visual
+clientserver +emacs_tags +jumplist -mouse_gpm
+postscript +tag_binary +visualextra
+clipboard +eval +keymap -mouse_jsbterm
+printer +tag_old_static +viminfo
+cmdline_compl +ex_extra +lambda +mouse_netterm
+profile -tag_any_white +vreplace
+cmdline_hist +extra_search +langmap +mouse_sgr
+python/dyn -tcl +wildignore
+cmdline_info +farsi +libcall -mouse_sysmouse
+python3/dyn +termguicolors +wildmenu
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/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -g
-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0
-lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0
-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype
-lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -ldl
'
--
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
--
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
