[BUG] Strange behavior when cchar is a special character
If you launch vim the following way: vim -u NONE --cmd 'set nocompatible conceallevel=2' --cmd $'syn keyword Ctest cchar=\t conceal abc' -c $'normal! aabc\n' then you will see only two empty lines on the terminal. If you then press j and k, then you will first see ``abc'' on the first line and then ``a''. Nothing is higlighted with Concealed highlight group. The same thing will happen if you replace ``\t'' with ``\n'', ``\r'', ``\C-t'' (Control+T, ``\x14'', looks like that escape is not working in bash) and other ``\C-*''. I think that ``:syn'' command should throw an error on this characters instead of trying to use them in some way. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] link.sh: do not reduce library if linker supports --as-needed
On Mon, Aug 23, 2010 at 03:44:12PM +0300, Kirill A. Shutemov wrote: link.sh tries to avoid overlinking in a hackish way. At least GNU ld supports --as-needed which provides the same functionality at linker level. Let's use it. Any comments? Signed-off-by: Kirill A. Shutemov kir...@shutemov.name --- src/Makefile |2 +- src/config.mk.in |1 + src/configure.in | 17 + src/link.sh |6 +- 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/src/Makefile b/src/Makefile index 5c0729f..0156084 100644 --- a/src/Makefile +++ b/src/Makefile @@ -1688,7 +1688,7 @@ $(VIMTARGET): auto/config.mk objects $(OBJ) version.c version.h $(CCC) version.c -o objects/version.o @LINK=$(PURIFY) $(SHRPENV) $(CClink) $(ALL_LIB_DIRS) $(LDFLAGS) \ -o $(VIMTARGET) $(OBJ) objects/version.o $(ALL_LIBS) \ - MAKE=$(MAKE) sh $(srcdir)/link.sh + MAKE=$(MAKE) NO_LINK_SH=$(NO_LINK_SH) sh $(srcdir)/link.sh xxd/xxd$(EXEEXT): xxd/xxd.c cd xxd; CC=$(CC) CFLAGS=$(CPPFLAGS) $(CFLAGS) \ diff --git a/src/config.mk.in b/src/config.mk.in index 7154114..cd334c6 100644 --- a/src/config.mk.in +++ b/src/config.mk.in @@ -30,6 +30,7 @@ TAGPRG = @TAGPRG@ CPP = @CPP@ CPP_MM = @CPP_MM@ DEPEND_CFLAGS_FILTER = @DEPEND_CFLAGS_FILTER@ +NO_LINK_SH = @NO_LINK_SH@ X_CFLAGS = @X_CFLAGS@ X_LIBS_DIR = @X_LIBS@ X_PRE_LIBS = @X_PRE_LIBS@ diff --git a/src/configure.in b/src/configure.in index 3b9f812..a4e5e74 100644 --- a/src/configure.in +++ b/src/configure.in @@ -3479,6 +3479,23 @@ else fi AC_SUBST(DEPEND_CFLAGS_FILTER) +dnl link.sh tries to avoid overlinking in a hackish way. +dnl At least GNU ld supports --as-needed which provides the same functionality +dnl at linker level. Let's use it. +AC_MSG_CHECKING(linker --as-needed support) +NO_LINK_SH= +# Check if linker supports --as-needed and --no-as-needed options +if $CC -Wl,--help 2/dev/null | grep as-needed /dev/null; then + LDFLAGS=$LDFLAGS -Wl,--as-needed + NO_LINK_SH=yes +fi +if test $NO_LINK_SH = yes; then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi +AC_SUBST(NO_LINK_SH) + dnl write output files AC_OUTPUT(auto/config.mk:config.mk.in) diff --git a/src/link.sh b/src/link.sh index 3d90f3c..06632dc 100755 --- a/src/link.sh +++ b/src/link.sh @@ -16,11 +16,15 @@ echo $LINK link.cmd exit_value=0 +if test $NO_LINK_SH = yes; then + echo link.sh: \$NO_LINK_SH set to 'yes': no needed in reducing library set. + echo auto/link.sed +elif test -f auto/link.sed; then + # # If auto/link.sed already exists, use it. We assume a previous run of # link.sh has found the correct set of libraries. # -if test -f auto/link.sed; then echo link.sh: The file 'auto/link.sed' exists, which is going to be used now. echo link.sh: If linking fails, try deleting the auto/link.sed file. echo link.sh: If this fails too, try creating an empty auto/link.sed file. -- Kirill A. Shutemov -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php -- Kirill A. Shutemov -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Fwd: Possible bug: cchar not applied to region start token when cole=2
Forwarded from vim_use...potentially the changeset mentioned below missed a change or two. -- Forwarded message -- From: Stahlman Family brettstahl...@comcast.net Date: Aug 24, 7:35 pm Subject: Possible bug: cchar not applied to region start token when cole=2 To: vim_use Ben Fritz wrote: On Aug 21, 9:15 am, Stahlman Family brettstahl...@comcast.net wrote: Now comes the unexpected part... With the cursor on the 2nd line (the one containing the yz region), and Vim in normal mode, the region end token (Z) is displayed as cchar (`-') (as expected), but the start token (Y) is *completely* concealed (as it would be for conceallevel=3). If I enter insert mode, both start and end tokens are displayed as the actual text highlighted as Error. While the insert mode behavior makes sense, I would have expected the treatment of the start and end tokens to be identical in normal mode: i.e., I would expect them both to be replaced by cchar. This sounds very similar to one of the 2 bugs reported a few weeks ago here: http://groups.google.com/group/vim_dev/browse_thread/thread/e49bf0f57... These bugs were both fixed, I believe in changeset da067045878f: Fix for concealends. (Vince Negri). I'm seeing this issue with a version of Vim 7.3 proper (checked out and compiled on or around August 21), which, if I understand correctly, should have the fix to which you refer. I looked at your test file and verified that I don't see the issue you reported; however, you can reproduce my issue with your test file, simply by adding the cchar argument to your concealends region definition (e.g., cchar=-), then using your map to increase conceallevel from 1 to 2. When you do this, I believe you will find that the cchar at the start of the region disappears, whereas the one at the end of the region remains. It is as though the fix was implemented only for conceallevel=1... Brett Stahlman Maybe the root cause is similar? I don't see the issue described in the test file attached to the linked vim_dev thread when using the test file in that thread. I have not yet tried your test file.- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: Possible bug: cchar not applied to region start token when cole=2
From: Ben Fritz [mailto:fritzophre...@gmail.com] Forwarded from vim_use...potentially the changeset mentioned below missed a change or two. Chip Campbell noticed this, although in his case it turned out there was an easier way to do what he was trying to do. Nothing got missed out from the changeset, I think there is still a funny with specifying a cchar for concealends. I never imagined someone would want to do that (since cchar was for things like entity replacement.) Chip's original comment: A cchar with concealends seems to show up only on the right side, and the left side persistently shows [the default conceal character] Vince -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Vim 7.3 Lua plugins
Is anyone working on one yet? would love to take a peek at the code :p -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3 Lua plugins
Hi Tom, I wrote a Vim plug-in [1] that uses LuaInspect [2] to perform semantic highlighting of different variable types in Lua source code. The plug-in can use the Lua interface for Vim but also works without the interface, by running Lua as an external process using Vim's system() function. - Peter Odding [1] http://peterodding.com/code/vim/lua-inspect/ [2] http://lua-users.org/wiki/LuaInspect -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Suggest ':TOhtml' to use 'fileencoding' rather than 'encoding' as default html charset
I think this will be more reasonable than before. If the encoding of edited text file differ form the system/vim encoding, it's inconvenient to set default HTML charset to be 'encoding'. Thus, after ':TOhtml', we should modify the generated HTML file to make the file encoding the same as HTML charset. e.g. If the system/vim encoding is 'UTF-8', but a text file encoding is 'latin-1'. If the default HTML charset is 'encoding', after ':TOhtml', we should change the HTML charset to 'iso-8859-1', or save the generated HTML file by ':w ++enc=utf-8'. But if the default HTML charset is 'fileencoding', we should do nothing after ':TOhtml'. Changes as the attachment. Best regards, Yanwei. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php tohtml.diff Description: Binary data
