On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <Bram@moolenaar.net> 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 -- 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 ///
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 '
--
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.
No comments:
Post a Comment