[bug] netrw remote delete
Hi all, I'm getting this error message when trying to delete (pressing D) a file on a remote directory: Error detected while processing function 28_NetrwRemoteRm[32]..28_NetrwRemoteRmFile: line 60: E488: Trailing characters: else if ret != 0 Doing the same operation on a local directory works fine. Also, a remote rename works. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[bug] netrw not redrawing
Hi all, try doing a remote editing (I'm using scp) of some file, then executing :Lexplore, and pressing Enter to open a different file. The new file is shown in a new window as expected, but the netrw window won't be redrawn. The problem seems to be the commented out redraw! at line 2856 (version 155, Feb 16, 2016). Uncommenting it fixed the problem, at least for my use case. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] Relative/absolute filenames mess (#549)
Hi Bram, > Not quite so. The absolute file name is always used, so that no matter > what you do with the current directory you are still editing the same > file. The shorter file name is displayed when this is appropriate. I'm not quite following you. I was just talking about how names are shown, not the way vim uses them. It's ok that "the absolute file name is always used". So I think we agree on this point. > Depends on how you look at it. In any way ":cd ." shortens all file > names, so use that if you prefer short names. If we would always use At first I rationalized the behavior as: "the original name is like I entered it (absolute or relative); then, if I want to make it relative, I use cd". But IMO this doesn't hold because I may use cd for other reasons than making paths (show) relative. In other words, if my intention was to keep some name (being shown) absolute, now every cd or lcd will anyways relativize it, defeating my goal. So I don't think the current behavior can be justified on the basis of giving the user the choice of showing buffer names relative or absolute. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] Buffer name resolution and simplification (#444)
(Sorry, I accidentaly submit the issue in github and it was half sent here. The complete text follows.). I have suggested some workarounds at the bottom of this thread: https://groups.google.com/forum/#!topic/vim_use/Vq0z2DJH2So but, nevertheless, I think the behavior is bizarre and specially confusing when using the quickfix list. Why not always make the buffer name relative to the current working directory? -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Visual mode movements for python.vim
Perhaps you would like to take over maintenance of this file? I would be glad to. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Visual mode movements for python.vim
Updated patch with a couple of text objects (]] and ]m) defined on top of my
previous n and v maps.
Regarding the maintenance I know nothing about the formalities yet but I
promise to get informed ASAP.
Cheers
--
Carlos
--
--
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
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From 0b00f3c692a59590ae03e571cfa6d37b4d2e1f44 Mon Sep 17 00:00:00 2001
From: memeplex carlosjosep...@gmail.com
Date: Fri, 31 Jul 2015 12:31:37 -0300
Subject: [PATCH] Python plugin: movements in visual mode.
---
runtime/ftplugin/python.vim | 50 +
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/runtime/ftplugin/python.vim b/runtime/ftplugin/python.vim
index 75c7e87..f5e03a9 100644
--- a/runtime/ftplugin/python.vim
+++ b/runtime/ftplugin/python.vim
@@ -1,8 +1,8 @@
Vim filetype plugin file
Language: python
Maintainer: Johannes Zellner johan...@zellner.org
- Last Change: 2014 Feb 09
Last Change By Johannes: Wed, 21 Apr 2004 13:13:08 CEST
+ Last Change: Fri Jul 31 12:29:55 ART 2015 (carlosjosep...@gmail.com)
if exists(b:did_ftplugin) | finish | endif
let b:did_ftplugin = 1
@@ -21,28 +21,38 @@ setlocal omnifunc=pythoncomplete#Complete
set wildignore+=*.pyc
-nnoremap silent buffer ]] :call SIDPython_jump('/^\(class\\|def\)')cr
-nnoremap silent buffer [[ :call SIDPython_jump('?^\(class\\|def\)')cr
-nnoremap silent buffer ]m :call SIDPython_jump('/^\s*\(class\\|def\)')cr
-nnoremap silent buffer [m :call SIDPython_jump('?^\s*\(class\\|def\)')cr
+nnoremap silent buffer ]] :C-Ucall SIDPython_jump(0, 0, 1)CR
+nnoremap silent buffer [[ :C-Ucall SIDPython_jump(1, 0, 1)CR
+nnoremap silent buffer ]m :C-Ucall SIDPython_jump(0, 0, 0)CR
+nnoremap silent buffer [m :C-Ucall SIDPython_jump(1, 0, 0)CR
+
+vnoremap silent buffer ]] :C-Ucall SIDPython_jump(0, 1, 1)CR
+vnoremap silent buffer [[ :C-Ucall SIDPython_jump(1, 1, 1)CR
+vnoremap silent buffer ]m :C-Ucall SIDPython_jump(0, 1, 0)CR
+vnoremap silent buffer [m :C-Ucall SIDPython_jump(1, 1, 0)CR
+
+onoremap silent buffer ]] :C-Uexecute 'normal ]][[V' . v:count1 . ']]'CR
+onoremap silent buffer ]m :C-Uexecute 'normal ]m[mV' . v:count1 . ']m'CR
if !exists('*SIDPython_jump')
- fun! SIDPython_jump(motion) range
- let cnt = v:count1
- let save = @/ save last search pattern
- mark '
- while cnt 0
- silent! exe a:motion
- let cnt = cnt - 1
- endwhile
- call histdel('/', -1)
- let @/ = save restore last search pattern
- endfun
+fun! SIDPython_jump(back, visual, top)
+let n = v:count1
+let pattern = '^' . (a:top ? '' : '\s*') . '\(class\|def\)'
+if a:visual
+normal gv
+let pattern = '\n' . pattern
+endif
+let pattern = '\(\%^\|\%$\|' . pattern . '\)'
+mark '
+for _ in range(1, n)
+call search(pattern, 'W' . (a:back ? 'b' : ''))
+endfor
+endfun
endif
if has(browsefilter) !exists(b:browsefilter)
let b:browsefilter = Python Files (*.py)\t*.py\n .
- \ All Files (*.*)\t*.*\n
+ \ All Files (*.*)\t*.*\n
endif
As suggested by PEP8.
@@ -50,11 +60,7 @@ setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8
First time: try finding pydoc.
if !exists('g:pydoc_executable')
-if executable('pydoc')
-let g:pydoc_executable = 1
-else
-let g:pydoc_executable = 0
-endif
+let g:pydoc_executable = executable('pydoc') == 1
endif
If pydoc was found use it for keywordprg.
if g:pydoc_executable
--
2.4.5
Re: [Patch] Python syntax: avoid highlighting attributes as builtins
OK. But there still remains the question of discrepancy between: class A: filter = None Here filter is a variable locally scoped to the block defined by A, in that sense this is not different from: def a(): filter = None Both clashes with the auto-global builtin. Fortunately the most common case will be: class A: def filter(...): ... where filter would be highlighted because of the def anyway. and: a = A() a.filter = 2 Here a (and even A) is a potential offender but not filter, which is resolved inside a. The rule is simple: an unqualified variable named like a builtin is highlighted to signal potential mistakes / bad smell. There already is a variable to control highlighting of builtins. Currently it's a toggle but it could have 3 levels instead: 0: never. 1: only unqualified. 2: always. Heuristically I think 1 does a better job, but you can set the default to 2 if you prefer. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Python syntax: avoid highlighting attributes as builtins
class A: filter = None You could also avoid highlighting left hand sides as they're easy to match. A variable that is always assigned to would be weird but never confused with a builtin, as it's clear it's being bound at that point. Now, any potential *use* of a builtin (i.e. not a lhs) will be highlighted as usual. I don't care a lot about this case though. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Python syntax: avoid highlighting attributes as builtins
Here filter is a variable locally scoped to the block defined by A, in that
sense this is not different from:
No, it’s not a locally scoped variable (binding in Python).
It’s a class attribute.
How can it be an attribute of a class that doesn't exist yet? You must
differentiate a class being created from a class already created:
class A:
x = 1 # x is a local, A doesn't even exist at this point.
print(locals())
print(getattr(A, 'x')) # x is an attribute.
==
{'__module__': '__main__', '__qualname__': 'A', 'x': 1}
1
Despite semantic subtleties, the point is that unqualified names are susceptible
of name clashes with builtins, while qualified named aren't.
I understand fully what you ask for. It’s still inconsistent for the case of
class attributes.
Again: differentiate between the class local scope at the point of
definition and proper class attributes. Then the rule is consistent.
I just wonder if there is really a value to complicate the highlighting code
Well, it's a oneliner, but then I wouldn't mind putting it inside my
.vimrc, laissez-faire, laissez-passer ;).
for a small use case like this compared to the value this “warning” gives.
Warnings are good when you can selectively disable false positives.
Otherwise they become distractions and you tend to overlook the real
ones. What I'm suggesting disables just a subset of false positives
(another subset is left hand sides). I don't see how it could hurt in
this sense.
You do realize that this highlighting always existed and never bothered
anybody until now. What if this gets changed and then users start
complaining about the fact it’s not highlighted any more.
I suggested to keep the current behavior as default and adding one or
two lines of code to offer a new mode, without additional config
variables and retaining backward compatibility (just set
0=never,1=always and 2=non-qualified). Again, I wouldn't mind putting
that in my personal configuration. I just posted a patch that may be
useful for someone else, feel free to include it in the distributed
module (I can update it to add the 2=non-qualified mode, though).
I’m taking a break this weekend.
Enjoy it.
Cheers
--
Carlos
--
--
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
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Patch] Python syntax: avoid highlighting attributes as builtins
Hi all, the syntax rules for python incorrectly consider, say, both `filter` and `obj.filter` as instances of the builtin `filter`. I've added a rule to explicitly set the group of attributes (defined as an identifier following a dot) to none. Maybe it's better to create a new group for attributes, I'm not sure. I will update the patch with any improving suggestion. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. From cc25cc6ee83f1c0e1ca9349bb2cf1f9858bd28bb Mon Sep 17 00:00:00 2001 From: memeplex carlosjosep...@gmail.com Date: Fri, 31 Jul 2015 13:40:51 -0300 Subject: [PATCH] Python syntax: don't highlight attrs as builtins. --- runtime/syntax/python.vim | 2 ++ 1 file changed, 2 insertions(+) diff --git a/runtime/syntax/python.vim b/runtime/syntax/python.vim index f99153f..d944e76 100644 --- a/runtime/syntax/python.vim +++ b/runtime/syntax/python.vim @@ -197,6 +197,8 @@ if !exists(python_no_builtin_highlight) syn keyword pythonBuiltin ascii bytes exec non-essential built-in functions; Python 2 only syn keyword pythonBuiltin apply buffer coerce intern + Avoid highlighting attributes as builtins + syn match none /\.\i\+/hs=s+1 endif From the 'Python Library Reference' class hierarchy at the bottom. -- 2.4.5
[Patch] Visual mode movements for python.vim
Hi all,
I've patched the python.vim ftplugin in order it to support [[,]],]m,[m
movements in visual mode also. The patch simplifies the logic of the previous
implementation by using the search() function instead of user-oriented commands.
There are a couple of minor improvements also:
* Explicitly check executable('pydoc') == 1 (to avoid the -1 trap).
* Expand a couple of tabs to spaces to normalize indentation a bit.
Hope you find it useful. I tried to contact the maintainer before but to no
avail so I'm submitting this directly to this list.
Cheers
--
Carlos
--
--
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
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From 66783b5ca11f2c4ec6a76cf666dadd48d475b58b Mon Sep 17 00:00:00 2001
From: memeplex carlosjosep...@gmail.com
Date: Fri, 31 Jul 2015 12:31:37 -0300
Subject: [PATCH] python plugin: movements in visual mode.
---
runtime/ftplugin/python.vim | 46 +++--
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/runtime/ftplugin/python.vim b/runtime/ftplugin/python.vim
index 75c7e87..3c0eb2e 100644
--- a/runtime/ftplugin/python.vim
+++ b/runtime/ftplugin/python.vim
@@ -1,8 +1,8 @@
Vim filetype plugin file
Language: python
Maintainer: Johannes Zellner johan...@zellner.org
- Last Change: 2014 Feb 09
Last Change By Johannes: Wed, 21 Apr 2004 13:13:08 CEST
+ Last Change: Fri Jul 31 12:29:55 ART 2015 (carlosjosep...@gmail.com)
if exists(b:did_ftplugin) | finish | endif
let b:did_ftplugin = 1
@@ -21,28 +21,34 @@ setlocal omnifunc=pythoncomplete#Complete
set wildignore+=*.pyc
-nnoremap silent buffer ]] :call SIDPython_jump('/^\(class\\|def\)')cr
-nnoremap silent buffer [[ :call SIDPython_jump('?^\(class\\|def\)')cr
-nnoremap silent buffer ]m :call SIDPython_jump('/^\s*\(class\\|def\)')cr
-nnoremap silent buffer [m :call SIDPython_jump('?^\s*\(class\\|def\)')cr
+nnoremap silent buffer ]] :C-Ucall SIDPython_jump(0, 0, '')CR
+nnoremap silent buffer [[ :C-Ucall SIDPython_jump(1, 0, '')CR
+nnoremap silent buffer ]m :C-Ucall SIDPython_jump(0, 0, '\s*')CR
+nnoremap silent buffer [m :C-Ucall SIDPython_jump(1, 0, '\s*')CR
+
+vnoremap silent buffer ]] :C-Ucall SIDPython_jump(0, 1, '')CR
+vnoremap silent buffer [[ :C-Ucall SIDPython_jump(1, 1, '')CR
+vnoremap silent buffer ]m :C-Ucall SIDPython_jump(0, 1, '\s*')CR
+vnoremap silent buffer [m :C-Ucall SIDPython_jump(1, 1, '\s*')CR
if !exists('*SIDPython_jump')
- fun! SIDPython_jump(motion) range
- let cnt = v:count1
- let save = @/ save last search pattern
- mark '
- while cnt 0
- silent! exe a:motion
- let cnt = cnt - 1
- endwhile
- call histdel('/', -1)
- let @/ = save restore last search pattern
- endfun
+fun! SIDPython_jump(back, visual, ws)
+let n = v:count1
+let pattern = '^' . a:ws . '\(class\|def\)'
+if a:visual
+normal gv
+let pattern = (a:back ? '' : '\n') . pattern
+endif
+mark '
+for _ in range(1, n)
+call search(pattern, 'W' . (a:back ? 'b' : ''))
+endfor
+endfun
endif
if has(browsefilter) !exists(b:browsefilter)
let b:browsefilter = Python Files (*.py)\t*.py\n .
- \ All Files (*.*)\t*.*\n
+ \ All Files (*.*)\t*.*\n
endif
As suggested by PEP8.
@@ -50,11 +56,7 @@ setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8
First time: try finding pydoc.
if !exists('g:pydoc_executable')
-if executable('pydoc')
-let g:pydoc_executable = 1
-else
-let g:pydoc_executable = 0
-endif
+let g:pydoc_executable = executable('pydoc') == 1
endif
If pydoc was found use it for keywordprg.
if g:pydoc_executable
--
2.4.5
Re: [Patch] Visual mode movements for python.vim
PS: maybe worth noticing, the new implementation also fixes a potential bug related to the approach to get the v:count argument the previous implementation adopts: it defines a range function, but then the argument must be valid as a range not just as a count. In practice this shouldn't be a problem, but it's not entirely correct. Moreover, it is a problem for implementing the visual mode map. All in all I feel the new approach is cleaner. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Python syntax: avoid highlighting attributes as builtins
- Is there any value in making an exception for only a.filter line? Yes, you can say for (99%) sure that a.filter is not a builtin, at least no more than a.x. Instead it's dubious practice to name a global or local variable as a builtin, that's looking for trouble. But attributes and variables are different beasts, differently scoped. There's little to say against value.set(3) or point.set(x=3, y=2) but a lot against def set(obj, attr, val): or set = [1, 2, 3]. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Visual mode movements for python.vim
Here is an updated patch with a couple of improvements:
1. Reach BOF/EOF when there are no more class/method text objects remaining.
2. In visual mode select the object up to its beginning/end without matching
the first line/char of the next object (I think it's not difficult to implement
the omap version from here, but I don't have the time to do it right now).
Cheers
--
Carlos
--
--
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
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From 48aa0fa45b64e87b56d4442c2e1e3257d068ec02 Mon Sep 17 00:00:00 2001
From: memeplex carlosjosep...@gmail.com
Date: Fri, 31 Jul 2015 12:31:37 -0300
Subject: [PATCH] Python plugin: movements in visual mode.
---
runtime/ftplugin/python.vim | 47 -
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/runtime/ftplugin/python.vim b/runtime/ftplugin/python.vim
index 75c7e87..8563749 100644
--- a/runtime/ftplugin/python.vim
+++ b/runtime/ftplugin/python.vim
@@ -1,8 +1,8 @@
Vim filetype plugin file
Language: python
Maintainer: Johannes Zellner johan...@zellner.org
- Last Change: 2014 Feb 09
Last Change By Johannes: Wed, 21 Apr 2004 13:13:08 CEST
+ Last Change: Fri Jul 31 12:29:55 ART 2015 (carlosjosep...@gmail.com)
if exists(b:did_ftplugin) | finish | endif
let b:did_ftplugin = 1
@@ -21,28 +21,35 @@ setlocal omnifunc=pythoncomplete#Complete
set wildignore+=*.pyc
-nnoremap silent buffer ]] :call SIDPython_jump('/^\(class\\|def\)')cr
-nnoremap silent buffer [[ :call SIDPython_jump('?^\(class\\|def\)')cr
-nnoremap silent buffer ]m :call SIDPython_jump('/^\s*\(class\\|def\)')cr
-nnoremap silent buffer [m :call SIDPython_jump('?^\s*\(class\\|def\)')cr
+nnoremap silent buffer ]] :C-Ucall SIDPython_jump(0, 0, '')CR
+nnoremap silent buffer [[ :C-Ucall SIDPython_jump(1, 0, '')CR
+nnoremap silent buffer ]m :C-Ucall SIDPython_jump(0, 0, '\s*')CR
+nnoremap silent buffer [m :C-Ucall SIDPython_jump(1, 0, '\s*')CR
+
+vnoremap silent buffer ]] :C-Ucall SIDPython_jump(0, 1, '')CR
+vnoremap silent buffer [[ :C-Ucall SIDPython_jump(1, 1, '')CR
+vnoremap silent buffer ]m :C-Ucall SIDPython_jump(0, 1, '\s*')CR
+vnoremap silent buffer [m :C-Ucall SIDPython_jump(1, 1, '\s*')CR
if !exists('*SIDPython_jump')
- fun! SIDPython_jump(motion) range
- let cnt = v:count1
- let save = @/ save last search pattern
- mark '
- while cnt 0
- silent! exe a:motion
- let cnt = cnt - 1
- endwhile
- call histdel('/', -1)
- let @/ = save restore last search pattern
- endfun
+fun! SIDPython_jump(back, visual, ws)
+let n = v:count1
+let pattern = '^' . a:ws . '\(class\|def\)'
+if a:visual
+normal gv
+let pattern = '\n' . pattern
+endif
+let pattern = '\(\%^\|\%$\|' . pattern . '\)'
+mark '
+for _ in range(1, n)
+call search(pattern, 'W' . (a:back ? 'b' : ''))
+endfor
+endfun
endif
if has(browsefilter) !exists(b:browsefilter)
let b:browsefilter = Python Files (*.py)\t*.py\n .
- \ All Files (*.*)\t*.*\n
+ \ All Files (*.*)\t*.*\n
endif
As suggested by PEP8.
@@ -50,11 +57,7 @@ setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8
First time: try finding pydoc.
if !exists('g:pydoc_executable')
-if executable('pydoc')
-let g:pydoc_executable = 1
-else
-let g:pydoc_executable = 0
-endif
+let g:pydoc_executable = executable('pydoc') == 1
endif
If pydoc was found use it for keywordprg.
if g:pydoc_executable
--
2.4.5
Re: [Bug] Hit Enter twice after make
Hi Bram,
As a compromise the error is shortened when the cursor moves. When you
jump to an error in the same line, then the full error is echoed, so
that you can read it.
You're assuming there is a long error involved but this also happens
when the message is empty! The reported condition is a sufficient
condition. It only requires the current line to be the target line.
For example:
1) Write this simple 3-line python script:
#
#
1/0
2) let l:errorformat=' File %f\, line %l%.%#' | let l:makeprg='python %'
3a) Move the cursor to the first line and :make
= Fine
3b) Move the cursor to the third line and :make
= Double Hit Enter prompt
Notice the error is just empty because of the way errorformat was defined.
There is another situation when the Hit Enter prompt is shown twice
and yet it's also unrelated to long messages: when there are no valid
entries in the qf list. In the example above, replace `1/0` for
`print('hello')` and repeat the steps. Now both 3a and 3b end up
showing a double prompt, despite there is nowhere to jump to and no
valid error message to show.
This last point also illustrates something I've posted about
yesterday: the treatment of completely non-valid errors qf lists. IMO
they're best seen as ok output in their own than as a special case of
error output that happens to contain 0 errors by chance. In
particular: the || prefix is just noise in this case, and the current
error highlight (Search) makes no sense. To keep DRY I won't replicate
my full arguments here, though, but I would like to hear what do you
think about it (there).
Best regards
--
Carlos
I don't think there is a better compromise.
--
I wish there was a knob on the TV to turn up the intelligence.
There's a knob called brightness, but it doesn't seem to work.
/// Bram Moolenaar -- b...@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_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
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Quickfix window for general output
There is another inconvenient behavior I forgot to mention: c) When there are no valid errors but the output is not empty, make still jumps to the first (non-valid) error (that is, line 1 of quickfix). This is awkward (and affected by issue [1]). Two remarks: i. this is annoying no matter you want to see the output displayed in the qf window or not, so it's not strictly related to cases 1, 2 and 3 above; ii. make! is no solution, because you may still want to jump to the first valid error when there are valid errors. All in all I feel that quickfix is extremely tailored to cases in which you expect strictly valid error output or nothing at all. For most other cases it's a bit quirky. You can circumvent this writing some vimscript (I've done that indeed), but maybe it would be not that difficult to modify the current behavior a bit in order to acommodate the cases I've described. Nowadays a lot of languages are interpreted and there is no clear boundary between execution, testing, log-debugging and compilation. This dynamic nature of languages also means that errors tend to be in the form of dynamic stack traces, for which context (i.e. non-valid qf entries) is important. Again, I would like to hear your opinions. Cheers -- Carlos [1] https://code.google.com/p/vim/issues/detail?id=378sort=-id -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Add show-mode-in-prompt to readline syntax
Hi Christian! Done, sorry for the noise. I wouldn't hold my breath anyway, as this was reported quite a few years ago: https://groups.google.com/forum/#!searchin/vim_dev/readline/vim_dev/wXSl7kshVYI/5xI8WriMb7oJ Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Add show-mode-in-prompt to readline syntax
I wouldn't hold my breath anyway, as this was reported quite a few years ago: My bad, that was for 6.2. So I'm holding my breath after all :) -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Quickfix window for general output
Hi all, I would like to discuss a simple generalization of quickfix for outputs that are mostly non valid errors or have no errors/matches at all. It's not that the qf window doesn't already support the use cases I'm describing below, just that it has some quirks and rough edges when dealing with them. There are three scenarios that I came across that are pretty common but don't completely fit the way the quickfix window presents its contents: 1) Long stack traces, for which you want to see the context as much as the error lines themselves. 2) Long unit testing framework outputs, with lists of failing tests that show error lines interspersed with a hierarchy of test suites and test cases names. 3) Non error outputs. Sometimes your program won't fail and you still would like to see the output in an unified interface like the quickfix window. That is, you press make and see the output in the qf window: error or not. The problem I see is that the quickfix window is too much oriented to highlighting errors/matches, which is almost fine as this is its main use case. But for the scenarios above sometimes it shows too much clutter: a) The prefix || before each non valid line. b) The blinding highlight (Search) of the current line. What I would like is one or two flags to control (a) and (b) (or both at the same time). That is, to suppress the || prefix and to avoid the Search highlighting for non valid lines. Suppressing highlighting will lose some context; for example it will not be clear from the qf window where a :cnext will jump, but this is not a problem for (3) and almost not a problem for (1) and (2), as in general there is no point in setting the line to a non-valid one. Besides, the flags would be optional. The worst combinations are (3-a) and (3-b). So, alternatively, a flag no extra decorations when there is no valid error/match could fit the bill also. What do you think? Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Bug] Hit Enter twice after make
The fact that the hit enter prompt is shown twice sometimes after :make when an error is found by quickfix was asked a number of times in the user list and in stackoverflow, but AFAIK it was just workarounded by making make silent or cmdheight larger. Now I've found a specific situation when the problem seem to be clearly reproducible: when the cursor was already on the line containing the first qf valid error immediately before running the make command (that is, the curaor was already on the line where make will automatically jump). In this case the qf error message is echoed as usual, except that the editor hasn't been redrawn yet and the hit enter prompt is presented again. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Add show-mode-in-prompt to readline syntax
It's a new option which was added in 6.3. Btw, the option is particularly relevant to vimers, because it's mainly intended for readline vi mode. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Add show-mode-in-prompt to readline syntax
Also, now that I'm on it, I noticed the edit-and-execute-command function is either not highlighted. On Monday, June 22, 2015 at 2:32:42 PM UTC-3, Carlos Pita wrote: It's a new option which was added in 6.3. Btw, the option is particularly relevant to vimers, because it's mainly intended for readline vi mode. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Bug?] BufRead and quickfix window
Setting an autocommand like: autocmd BufRead dir/* stuff will trigger stuff for the quickfix buffer when the working directory is dir. I tried the dir/?* pattern also, just in case the match for quickfix is against an empty string prefixed by the current directory: the same happens. I'm not sure what's the rule here, if any. Are special buffers intended to match any cwd/* pattern for a BufRead event? I workarounded this with an if buftype == '' clause, but I would like to understand what's happening here and to report a bug, supposing it is one. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [bug?] lazyredraw and mapping
indeed redraw! removes the double highlighting. That is, calling redraw! again explicity after the mapping was executed, not the redraw! in the Make function. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[bug?] lazyredraw and mapping
Hi all, when the lazyredraw option is set I've been observing a bizarre behavior which I'm not sure whether is a bug or not. Say I'm editing the following python script: def f1(): f3() def f2(): f1() f2() And I've defined the following function and map: function! Make(makeprg, errorformat) write let l:makeprg = a:makeprg let l:errorformat = a:errorformat silent make redraw! cw endfunction map buffer silent Leadermp \ :call Make(python %, ' File %f\, line %l%.%#')CR \ :clastCR:cprevCR If I press Leadermp once the error window is opened and the last error (out of three in the backtrace) with a filename in it is highlighted as expected. If I press Leadermp again then the first and last errors with a filename are highlighted at the same time (see attached screenshot). This seems a problem in redrawing, and indeed redraw! removes the double highlighting. Now, maybe this is expected when lazyredraw is on: :redr[aw][!] [...] Also when halfway a mapping and 'lazyredraw' is set. Although I'm not halfway a mapping. So maybe not. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: colorcolumn and foldtext
Hi again, an update: it's a bit worst than I've described, as the number columns at the left also look splitted. See the attached screenshot. I'm not sure whether this is an argument pro or con fold header being above whatever special column. At least the idea of the fold header being above every special column is already implemented and has it's rationale, as Bram exposed it. Of course, it looks bad when one tries to make it transparent, as the visual effect is to make every special column look splitted instead of just at a lower layer. Maybe the solution is to refrain from trying to style the fold headers in a more modest fashion and always give them a distinctive here I am background. I don't know. Cheers -- Carlos On Sun, Mar 8, 2015 at 2:19 PM, Christian Brabandt cbli...@256bit.org wrote: Hi Bram! On So, 08 Mär 2015, Bram Moolenaar wrote: I have to admit that it's now inconsistent, having cursorcolumn and colorcolumn behave differently. Did anybody complain about the behavior of cursorcolumn? Perhaps then it's best to do the same for colorcolumn. Consistency is more important in this case. Not that I know of. Carlos as the original Poster did ask how to make it the colorcolumn work with folded regions and it looks like he has asked the same question on Stackoverflow: http://stackoverflow.com/questions/28892305 I wouldn't call it a complain however. Best, Christian -- Es muß für einen Architekten schon blöd sein, wenn ihm dauernd was einfällt. -- -- 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 a topic in the Google Groups vim_use group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/BIIH2PaY0jQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: colorcolumn and foldtext
Hi Bram, The idea of 'colorcolumn' is that it applies to the text. So you can align items or make sure they are in a certain column. I don't see how that is useful in a folded region. I would think it makes the closed fold look odd. I have the idea that the closed fold is above the text and the 'colorcolumn' is under the text. So, why would someone want to change this? I see the rationale behind what you're saying and I do agree. But there is a gotcha. It's related to the way the fold line is filled with chars (as in 'fillchars'). Say I find it too invasive so I set the fold fillchar to space and its background to the normal background, in order to turn it invisible. Now I have a colorcolumn splitted here and there and that *really* looks odd. Maybe the solution is not to force filling the fold line all the way to the right margin but to make it the length of the string foldtext() returned. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
lazyredraw while scrolling
Hi all, a cursory google search shows many posts about cursorline and relativenumber turning vim slower. In an old low-end netbook I'm using right now this is all too evident. Say I keep j pressed for a while while editing my (relatively small) .vimrc. As I understand the issue, cursorline and relativenumber trigger frequent screen redraws and the redraws, in turn, drag in the syntax highlighting machinery, which is presumably the culprit of general slowdown. The net result is slow, rough scrolling. Now, the lazyredraw option helps a lot in the way to smooth scrolling. And one would say: obviously, as the problem was triggered by the constant redrawing, wasn't it? But looking at the documentation of lazyredraw it's not that obvious how it is helping in this case. Moreover, while scrolling the cursorline still moves and the relativenumbers still change (although the cursor itself is not shown or intermittently shown), so there is some redrawing happening. So, mostly out of curiosity I'm asking for the savvy people here to explain me what is exactly happening when I'm scrolling with cursorline and relativenumber set, and why lazyredraw could possibly help to ameliorate the slowdown. Thank you in advance -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: colorcolumn and foldtext
Maybe the solution is not to force filling the fold line all the way to the right margin but to make it the length of the string foldtext() returned. Something like an empty fillchar (which is currently impossible AFAIK) would do the trick while still allowing for the current behaviour in a backward compatible way, albeit I don't know if a generalization like that is desirable and/or easy to implement. Cheers -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: bad interaction between ui and preview window for omnifunc with extra info
What do you think about supressing events in the specific way I described above? Is it possible without a lot of work? Could it be problematic for some reasonable use case? -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: bad interaction between ui and preview window for omnifunc with extra info
You can selectively supress autocommands at vimscript level with noautocmd and eventignore. Can you do that at the C level? Do you think it's undesirable to do so? I'm not able to think of a listener interested in this particular buffer switch as it's more of a subproduct of a particular implementation than of an intentional switch. Cheers -- Carlos On Jul 4, 2014 7:37 AM, h_east h.east@gmail.com wrote: Hi Bram, 2014/7/4(Fri) 19:05:30 UTC+9 Bram Moolenaar: Hirohito Higashi wrote: Hi Carlos, 2014/7/3(Thu) 5:04:10 UTC+9 Carlos Pita: When the omnifunc provides extra info to be shown in the preview window (in case preview is included in completeopt) there is a permanent focus switching back and forth between the current window and the preview window, which produces several annoying and very noticeable visual artifacts: 1) The window title flickers (it changes too fast so the change is perceived as a flickering artifact). 2) The window name at the taskbar also flickers. 3) Plugins like vim-airline, which are able to show a buffer list highlighting the current buffer, will madly switch the highlight back and forth. I think an implementation which doesn't switch focus is in order. Attached patch fixed 1) and 2). Bram, what do you think? It's a nice simple solution, even though it won't fix everything. I haven't looked at the code yet, but often it's unavoidable to switch to the buffer to be changed, which also requires switching windows, which then requires triggering autocommands to have editing work as expected... Perhaps it could be done with one switch and back, instead of switching multiple times. I think so, my patch is really good solution. If we don't think about autocommands. :-( autocommands is too powerful. -- Best regards, Hirohito Higashi -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/z-ABEOyJMFc/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: bad interaction between ui and preview window for omnifunc with extra info
You can selectively supress autocommands at vimscript level with noautocmd and eventignore. Can you do that at the C level? Do you think it's undesirable to do so? I'm not able to think of a listener interested in this particular buffer switch as it's more of a subproduct of a particular implementation than of an intentional switch. I have autocmds to set certain options on the preview window; for example, nowrap. I was thinking just about the focus related events. It's fine to react to the preview window creation event but I see no point reacting to a permanent flow of focus in/out events triggered by the autocomplete mechanism. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: bad interaction between ui and preview window for omnifunc with extra info
I was thinking just about the focus related events. More precisely, about the focus related events triggered by the particular implementation of the autocomplete mechanism, not by the user or other plugins or parts of vim where they could arguably be of interest. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Bug: bad interaction between ui and preview window for omnifunc with extra info
When the omnifunc provides extra info to be shown in the preview window (in case preview is included in completeopt) there is a permanent focus switching back and forth between the current window and the preview window, which produces several annoying and very noticeable visual artifacts: 1) The window title flickers (it changes too fast so the change is perceived as a flickering artifact). 2) The window name at the taskbar also flickers. 3) Plugins like vim-airline, which are able to show a buffer list highlighting the current buffer, will madly switch the highlight back and forth. I think an implementation which doesn't switch focus is in order. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
slow syntax folding revisited
Hi all, I know this subject has been addressed a number of times, it's in the todo list, it's in the faq also and even there is a workaround suggested in the wiki. I just would like to add that I've been dealing with it for a time now using foldmethod=expr with an expression that gets some hints from the syntax engine by means of synID and related methods. The performance is good even if folding is still relying on the syntax engine. But I've never implemented a generic solution based on this idea, that is an expression that looks for a fold syntax item in the current line in a language agnostic way. I don't think that it's possible because I don't know of a way to retrieve the fold flag from a syntax item and also start/end matches could be 0-length and so have no representative char in the current line. But in general the approach seems to work reasonable well as a workaround. exprs are much easier to write when you can get advantage of syntactic hints at strategic points. What do you think about this approach? I'm afraid it could incur the same performance issues that foldmethod=syntax although, in practice, it didn't. I've no idea why this is so. Anyway +1 for the slow syntax folding issue. Regards -- Carlos -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Performance issues: region vs match for syntax folding
Hi all, I'm writing a syntax plugin for multimarkdown which is expected to
support folding with foldmethod=syntax. In (multi)markdown there is the notion
of a multiparagraph list item that has a pretty simple grammar: starting a new
paragraph with a first line that is at least 1-tab or 4-space indented
continues the previous item. So I defined a region to capture this:
syn region mkdMultiParagraph start=/./ end=/\n\s*\n\ze \{,3}\S/ contains=TOP
contained
Out of curiosity I tried to do the same with a (somewhat imperfect) match:
syn match mkdMultiParagraph /\(\s*\S.*\n\)\+\(\(\s*\n\)\+\(
\{4}\|\t\)\(\s*\S.*\n\)\+\)*/ contains=TOP contained
I tried a number of simpler match variants also, but the point is that
performance degrades awfully with every one of them, while things speed up a
lot with the region. This is particularly noticeable when I set
foldmethod=syntax. Then vim freezes for some seconds thinking about the
folding. Once the folds are created performance becomes acceptable again.
I could give you the details to reproduce this, which are pretty convolved (for
example, this only happens when the html syntax plugin in sourced inside mine).
But first I would like to ask if there are good a priori reasons to avoid this
kind of multiline matches in favor of regions. I was not able to find any
advice regarding this in the vim documentation.
Also I'm curious about the internals of vim syntax highlighting and the syntax
engine in general. Any description would be very much appreciated. A more solid
understanding of the inner workings of the engine would help me to decide in
matters like the above.
Best regards
--
Carlos
--
--
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
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
