Rebbe Malachi: August 2013

Saturday, August 31, 2013

Re: Slowness in Doxygen syntax

Hi, guys.

The version is MacVim 7.4 (Aug 10, 2013). Thats the version information when

typing ':version' in the command line. It is the 'Huge version with MacVim

GUI'.

The slowness is noticed when moving or typing in the problematic commented area.

In Insert or Normal mode.

Below is the result of ':syntime report'. Appears that the '\c', '\ref',

'\e' and '\b' are the culprit. This was tested in a file with 317 lines of

Objective-C code. Sorry that I cannot post the entire file here, since it

belongs to the company where I'm working right now. Even so, below the report,

I put some comment blocks.

TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN

0.835197 16 14 0.195808 0.052200 doxygenSpecialCodeWord \(\_s\+[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.329377 4 4 0.154978 0.082344 doxygenSpecialRefWord \(\_s\+[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.262015 4 4 0.120980 0.065504 doxygenSpecialEmphasisedWord \(\_s\+[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.207733 8 8 0.045915 0.025967 doxygenSpecialBoldWord \(\_s\+[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.035615 71 0 0.001082 0.000502 objcSuperclass $@\(implementation\|interface$\s*\k\+\s*:\)\@<=\s*\k*

0.015586 88 56 0.000803 0.000177 objcMethodName $^\s*[-+]\s*(\_[^)]*)$\@<=\_\s*\_\k\+

0.015504 10 8 0.003243 0.001550 doxygenCodeWord \_s\@<=[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.015495 10 8 0.003165 0.001550 doxygenCodeWord \_s\@<=[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.005707 234 0 0.000038 0.000024 doxygenHyperLink $\s\|^\s*\*\?$\@<=$http\|https\|ftp$:\/\/[-0-9a-zA-Z_?&=+#%/.!':;@~]\+

0.005336 562 0 0.000045 0.000009 objcError \v(NSLogv=\(\s*)@<=[^@]=["'].*

0.005140 87 20 0.000184 0.000059 objcSubclass $@implementation\|@interface$\@<=\s*\k\+

0.004815 2 2 0.002418 0.002408 doxygenRefWord \_s\@<=[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.004310 606 44 0.000031 0.000007 cFunctions \<$\i\+\w*$\s*(

0.004002 576 26 0.000026 0.000007 objcString $@"\|"$

0.003881 234 0 0.000028 0.000017 doxygenHashLink $[a-zA-Z_][0-9a-zA-Z_]*$\?#$\.[0-9a-zA-Z_]\@=\|[a-zA-Z0-9_]\+\|::\|()$\+

0.003703 2 2 0.001860 0.001852 doxygenEmphasisedWord \_s\@<=[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.003690 2 2 0.001854 0.001845 doxygenEmphasisedWord \_s\@<=[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.003219 4 4 0.000813 0.000805 doxygenBoldWord \_s\@<=[-:0-9A-Za-z_%=&+*/!~>|]\@<!\([-0-9A-Za-z_%=+*/!~>|#]\+[-0-9A-Za-z_%=+*/!~>|]\@!\|\

0.002976 562 0 0.000017 0.000005 cString \%(U\|u8\=\)"

0.002663 56 32 0.000066 0.000048 doxygenBrief $\s*\(\n\s*\*\=\s*$[@\\]$[npcbea]\>\|em\>\|ref\>\|link\>\|f\$\|[$\\&<>#]$\@!\)\@=

0.002473 724 162 0.000011 0.000003 cBracket \[\|<::\@!

0.002279 562 0 0.000013 0.000004 cSpecialCharacter L\='\\['\"?\\abfnrtv]'

0.002269 562 0 0.000026 0.000004 cCharacter L\='[^\\]'

0.002232 564 14 0.000015 0.000004 cCppString L\="

0.002231 562 0 0.000012 0.000004 cSpecialError L\='\\[^'\"?\\abfnrtv]'

0.002144 564 14 0.000012 0.000004 cString L\="

0.001844 854 481 0.000011 0.000002 cOperator [%><?!*&|~^=+-]

0.001804 8 0 0.000499 0.000226 objcMessageColon $\_\S\+\_\s\+$\@<=\k\+\s*:

0.001733 562 0 0.000008 0.000003 cSpecialCharacter [Uu]'\\['\"?\\abfnrtv]'

0.001636 562 0 0.000009 0.000003 cCharacter [Uu]'[^\\]'

0.001619 562 0 0.000008 0.000003 cCharacter [Uu]'[^']*'

0.001592 562 0 0.000008 0.000003 cSpecialError [Uu]'\\[^'\"?\\abfnrtv]'

0.001562 274 24 0.000014 0.000006 doxygenSmallSpecial [@\\]$\<[npcbea]\>\|\<em\>\|\<ref\>\|\<link\>\|f\$\|[$\\&<>#]$\@=

0.001413 290 174 0.000013 0.000005 doxygenSpecial [@\\]$\<[npcbea]\>\|\<em\>\|\<ref\|\<link\>\>\|\<f\$\|[$\\&<>#]$\@!

0.001252 68 18 0.000045 0.000018 doxygenBrief $^\s*$\@<!\*/\@!

0.001032 602 40 0.000015 0.000002 objcMethod ^\s*[-+]\s*\_.\{-}[\{;]

0.000883 562 0 0.000006 0.000002 cDefine ^\s*$%:\|#$\s*$define\|undef$\>

0.000880 562 0 0.000004 0.000002 cDefine ^\s*$%:\|#$\s*$define\|undef$\>

0.000855 562 0 0.000004 0.000002 cCppOutWrapper ^\s*$%:\|#$\s*if\s\+0\+\s*$$\|//\|/\*\|&$

0.000855 562 0 0.000008 0.000002 cPreCondit ^\s*$%:\|#$\s*$if\|ifdef\|ifndef\|elif$\>

0.000852 116 116 0.000020 0.000007 objcMethodArg )\@<=\s*\k\+

0.000849 562 0 0.000007 0.000002 cCppInWrapper ^\s*$%:\|#$\s*if\s\+0*[1-9]\d*\s*$$\|//\|/\*\||$

0.000764 122 0 0.000013 0.000006 cNumbers \<\d\|\.\d

0.000700 148 108 0.000011 0.000005 objcMethodColon \k\+\s*:

0.000678 580 64 0.000005 0.000001 doxygenComment /\*$\*/$\@![*!]

0.000643 122 0 0.000012 0.000005 cSpecialCharacter L\='\\\o\{1,3}'

0.000587 642 80 0.000004 0.000001 objcInstMethod ^\s*-\s*

0.000574 562 0 0.000003 0.000001 objcFactMethod ^\s*+\s*

0.000556 598 76 0.000005 0.000001 doxygenCommentL //@\ze[{}]

0.000481 90 24 0.000010 0.000005 doxygenSpecialMultilineDesc ^\s*$\*/\@!\s*$\=$\<\|[@\\]\<\([npcbea]\>\|em\>\|ref\|link\>\>\|f\$\|[$\\&<>#]$\|[^ \t

0.000471 66 66 0.000011 0.000007 doxygenSpecialMultilineDesc .\+

0.000463 134 12 0.000008 0.000003 cParenError [\])]

0.000455 326 116 0.000005 0.000001 doxygenContinueComment ^\s*\*/\@!\s*

0.000448 562 22 0.000021 0.000001 doxygenCommentL //[/!]<\@!

0.000446 122 0 0.000008 0.000004 cSpecialCharacter [Uu]'\\x\x\+'

0.000431 122 0 0.000008 0.000004 cSpecialCharacter [Uu]'\\\o\{1,3}'

0.000416 562 0 0.000003 0.000001 doxygenCommentL //[/!]<

0.000414 120 120 0.000012 0.000003 cBracket ]\|:>

0.000394 90 0 0.000009 0.000004 doxygenPage [\\@]page\>

0.000333 70 22 0.000008 0.000005 doxygenStartSpecial [@\\]$[npcbea]\>\|em\>\|ref\>\|link\>\|f\$\|[$\\&<>#]$\@!

0.000315 252 0 0.000099 0.000001 doxygenHtmlTag \v\</=\ze([biuap]|em|strong|img|br|center|code|dfn|d[ldt]|hr|h[0-3]|li|[ou]l|pre|small|sub

0.000307 70 0 0.000006 0.000004 doxygenFindBriefSpecial [@\\]brief\>

0.000300 570 8 0.000004 0.000001 objcDirective @property\|@synthesize\|@dynamic\|@package

0.000293 562 0 0.000003 0.000001 objcDirective @try\|@catch\|@finally\|@throw\|@synchronized

0.000286 570 8 0.000003 0.000001 objcDirective @encode\|@protocol\|@selector

0.000280 562 11 0.000002 0.000000 objcDirective @class\|@end\|@defs

0.000279 54 0 0.000007 0.000005 doxygenBrief [.]\S\@=

0.000272 952 390 0.000001 0.000000 cParen (

0.000270 56 54 0.000006 0.000005 doxygenBrief [.]

0.000268 562 0 0.000003 0.000000 cocoaClass \<CF$\i\+\w*$Ref\>

0.000264 562 0 0.000003 0.000000 objcScopeDecl @public\|@private\|@protected

0.000263 8 0 0.000071 0.000033 objcMessageName $\[\s*\k\+\s\+\|\]\s*$\@<=\k*\s*\]

0.000258 578 16 0.000003 0.000000 objcDirective @interface\|@implementation

0.000256 562 0 0.000002 0.000000 cocoaFunction \<CF$\i\+\w*$\s*(

0.000245 448 48 0.000002 0.000001 doxygenBody \*/

0.000227 562 0 0.000001 0.000000 cCommentL ////

0.000221 634 138 0.000001 0.000000 cBlock {

0.000212 130 64 0.000003 0.000002 doxygenStart /\*[*!]

0.000211 580 69 0.000001 0.000000 cCommentL //

0.000210 112 112 0.000004 0.000002 doxygenBrief [\\@]$[npcbea]\>\|em\>\|ref\>\|link\>\|f\$\|[$\\&<>#]$\|[^ \t\\@*]

0.000210 122 0 0.000004 0.000002 objcProperty ^\s*@property\>\s*([^)]*)

0.000207 562 0 0.000005 0.000000 cocoaFunction \<NS$\i\+\w*$\s*(

0.000207 122 0 0.000007 0.000002 objcKeyForMethodParam ^\s*[_a-zA-Z][_a-zA-Z0-9]*\s*:\s*(

0.000204 562 0 0.000002 0.000000 cocoaConstant \<kCF$\i\+\w*$\>

0.000201 130 80 0.000003 0.000002 doxygenSyncStart \ze[^*/]

0.000201 562 0 0.000002 0.000000 cCharacter L'[^']*'

0.000201 122 4 0.000004 0.000002 cInclude ^\s*$%:\|#$\s*include\>\s*["<]

0.000199 286 254 0.000002 0.000001 cComment \*/

0.000198 562 0 0.000001 0.000000 cComment /\*\*\*

0.000193 122 0 0.000004 0.000002 cPreConditMatch ^\s*$%:\|#$\s*$else\|endif$\>

0.000193 122 8 0.000004 0.000002 objcImport ^\s*$%:\|#$\s*import\>\s*["<]

0.000193 122 0 0.000005 0.000002 cBitField ^\s*\I\i*\s*:\s*[1-9]

0.000193 598 218 0.000001 0.000000 cComment /\*

0.000189 300 66 0.000002 0.000001 doxygenComment \*/

0.000188 570 8 0.000001 0.000000 objcImp @implementation

0.000185 570 8 0.000001 0.000000 objcHeader @interface

0.000180 122 0 0.000005 0.000001 cUserCont ^\s*\I\i*\s*:[^:]

0.000179 122 0 0.000005 0.000001 cUserCont ^\s*\I\i*\s*:$

0.000163 252 0 0.000004 0.000001 doxygenHtmlCode \c<code\>

0.000153 180 90 0.000003 0.000001 doxygenSpecialMultilineDesc ^

0.000145 420 48 0.000001 0.000000 cBlock }

0.000145 38 0 0.000006 0.000004 doxygenComment2 /\*$\*/$\@![*!]

0.000137 58 58 0.000004 0.000002 doxygenGroupDefine @\@<=[{}]

0.000135 252 0 0.000003 0.000001 doxygenHtmlLink <[aA]\>\s*$\n\s*\*\s*$\=$\(name\|href$=$"[^"]*"\|'[^']*'$\)\=\s*>

0.000131 252 0 0.000002 0.000001 doxygenHtmlItalic \c<i\>

0.000131 252 0 0.000002 0.000001 doxygenHtmlBold \c<b\>

0.000129 252 0 0.000002 0.000001 doxygenHtmlUnderline \c<u\>

0.000119 18 18 0.000008 0.000007 doxygenSpecialTypeOnelineDesc .\+

0.000116 252 0 0.000002 0.000000 doxygenHtmlItalic \c<em\>

0.000109 48 48 0.000004 0.000002 doxygenBody $/\*[*!]$\@<!<\|[^<]\|$

0.000109 252 0 0.000002 0.000000 doxygenHtmlBold \c<strong\>

0.000105 280 0 0.000002 0.000000 objcImp @end

0.000104 68 68 0.000002 0.000002 doxygenBrief \<\k

0.000089 32 32 0.000003 0.000003 doxygenParamName [A-Za-z0-9_:]\+

0.000087 165 0 0.000001 0.000001 cBadContinuation \\\s\+$

0.000081 110 46 0.000003 0.000001 doxygenStartSkip ^\s*\*[^/]

0.000080 22 22 0.000005 0.000004 doxygenBriefL @\k\@!\|[\\@]$[npcbea]\>\|em\>\|ref\>\|link\>\|f\$\|[$\\&<>#]$\|[^ \t\\@]

0.000080 240 240 0.000001 0.000000 cParen )

0.000074 122 36 0.000001 0.000001 cCommentError \*/

0.000073 240 0 0.000001 0.000000 cParen }

0.000073 44 22 0.000002 0.000002 doxygenStartL //[/!]

0.000072 64 0 0.000003 0.000001 doxygenStartSkip ^\s*\*$

0.000072 122 0 0.000003 0.000001 objcDirective @synthesize\|@property\|@optional\|@required

0.000071 122 0 0.000002 0.000001 cUserCont ;\s*\I\i*\s*:[^:]

0.000071 122 0 0.000002 0.000001 cBitField ;\s*\I\i*\s*:\s*[1-9]

0.000070 54 54 0.000002 0.000001 doxygenCommentL $

0.000070 20 20 0.000004 0.000004 doxygenStartSpecial $

0.000070 22 22 0.000004 0.000003 doxygenCommentL $

0.000064 122 0 0.000002 0.000001 cUserCont ;\s*\I\i*\s*:$

0.000063 112 22 0.000003 0.000001 doxygenSpecialContinueComment ^\s*\*/\@!\s*

0.000050 122 0 0.000001 0.000000 objcMessage \[

0.000048 122 0 0.000001 0.000000 cSpecialCharacter L'\\x\x\+'

0.000045 122 0 0.000001 0.000000 objcProtocol <[_a-zA-Z][_a-zA-Z0-9]*>

0.000043 60 0 0.000001 0.000001 cCommentStartError /\*

0.000042 122 0 0.000001 0.000000 cSpecialCharacter '\\x\x\{1,2}'

0.000041 12 8 0.000007 0.000003 cErrInParen [\]{}]\|<%\|%>

0.000037 120 0 0.000001 0.000000 cBracket }

0.000034 22 22 0.000002 0.000002 doxygenBriefL \<

0.000033 14 10 0.000004 0.000002 doxygenSymbol [$\\&<>#n]

0.000033 50 0 0.000001 0.000001 doxygenBriefEndComment \*/

0.000032 11 11 0.000004 0.000003 cCommentL $

0.000029 36 18 0.000002 0.000001 doxygenGroupDefineSpecial @\ze[{}]

0.000025 66 7 0.000002 0.000000 objcHeader @end

0.000025 64 0 0.000001 0.000000 doxygenPrev <

0.000023 18 18 0.000002 0.000001 doxygenSpecialTypeOnelineDesc $

0.000021 22 0 0.000002 0.000001 doxygenCodeRegion \<code\>

0.000019 22 0 0.000002 0.000001 doxygenDotRegion \<dot\>

0.000018 22 4 0.000005 0.000001 doxygenSkipComment ^\s*\*/\@!

0.000014 22 0 0.000002 0.000001 doxygenVerbatimRegion \<verbatim\>

0.000013 20 18 0.000001 0.000001 doxygenStartSpecial \*/

0.000012 12 0 0.000002 0.000001 doxygenOtherLink \<link\>

0.000012 32 0 0.000001 0.000000 doxygenParamDirection \v\[(\s*in>((]\s*\[|\s*,\s*)out>)=|out>((]\s*\[|\s*,\s*)in>)=)\]

0.000008 14 10 0.000001 0.000001 doxygenSpecialEmphasisedWord e

0.000008 14 14 0.000001 0.000001 doxygenSpecialCodeWord c

0.000008 16 8 0.000001 0.000001 objcImported "

0.000007 12 0 0.000001 0.000001 doxygenFormula f\[

0.000007 12 0 0.000001 0.000001 doxygenFormula f\$

0.000006 16 0 0.000001 0.000000 objcImported <[-_0-9a-zA-Z.\/]*>

0.000006 12 4 0.000001 0.000001 doxygenSpecialRefWord ref

0.000006 22 0 0.000001 0.000000 doxygenPrevL <

0.000005 12 0 0.000001 0.000000 doxygenSpecialEmphasisedWord em

0.000005 14 8 0.000001 0.000000 doxygenSpecialArgumentWord a

0.000004 11 0 0.000001 0.000000 cCommentL \\$

0.000004 12 2 0.000001 0.000000 doxygenSpecialCodeWord p

0.000004 4 4 0.000001 0.000001 cIncluded "

0.000003 14 4 0.000001 0.000000 doxygenSpecialBoldWord b

0.000003 8 0 0.000001 0.000000 objcSpecial %@

0.000003 4 4 0.000001 0.000001 cIncluded "

0.000002 4 0 0.000001 0.000001 cIncluded <[^>]*>

0.000002 8 0 0.000001 0.000000 objcImported \\\\\|\\"

0.000002 4 0 0.000001 0.000001 cIncluded \\\\\|\\"

0.000001 8 8 0.000001 0.000000 objcImported "

0.000000 2 2 0.000000 0.000000 objcString "

0.000000 2 0 0.000000 0.000000 objcString \\\\\|\\"

1.823260 39809

Comment blocks (they are in Portuguese), these are the problematic ones:

/**

* Define ou retorna a instância da implementação de HCRequestHandler

* responsável pela comunicação com o equipamento.

* Quando a View é criada, esta propriedade é \b nil até que uma referência

* seja definida pela implementação especializada da tela.

* \note A referência deste objeto será retido nesta operação.

*//* --------------------------------------------------------------------- */

/**

* Obtém a instância do controle ISlider responsável pela dimerização.

* Esta propriedade é \b nil até que o método \c showSliderDimmer seja

* executado.

*//* --------------------------------------------------------------------- */

/**

* Inicializa esta instância da View.

* \param aRect retângulo de tamanho e localização da View. Normalmente

* preenchendo toda a área interna do \e controller.

* \param type Código do tipo do equipamento representado por esta View. Os

* códigos estão disponíveis na lista \ref hc_equipments.

* \param avID Identificador do equipamento conforme lista recebida do

* console.

* \return Este objeto inicializado.

*//* --------------------------------------------------------------------- */

/**

* Chamada quando o usuário faz uma alteração na posição do slider.

* \param position Posição atual do slider. Varia de 0 à 100.

* \remarks Esta função pode ser sobrescrita por classes derivadas para

* obter o valor atualizado imediatamente. A implementação de HCAvdView envia

* a mensagem de alteração ao console e atualiza a propriedade \c

* generalLights do aplicativo.

*//* --------------------------------------------------------------------- */

/**

* Intercepta a notificação \c SM_CONNECTING da comunicação.

* \param socketMsg Objeto que carrega a mensagem.

*//* --------------------------------------------------------------------- */

Thanks for your attention.

2013/8/31 Dominique Pellé <dominique.pelle@gmail.com>

Dominique Pellé wrote:

> Alessandro Antonello <antonello.ale@gmail.com> wrote:
>
>> Hi all.
>>
>> I found some glitches in the new MacVim version and I was wondering if
>> someone else already saw something like this. I talked about MacVim because
>> I
>> couldn't test the Windows version yet.
>>
>> I usually work with ObjC files and I set 'syntax' in the modeline, like
>> this:
>>
>> // vim:syntax=objc.doxygen
>>
>> I use Doxygen for project documentation for years and it is part of my life
>> now. The odd glitch is that, the documented comment slows down Vim
>> substantially. Not in every places. Only when the cursor is in a comment
>> block
>> and if that comment block has a Doxygen command like @c (code), @b (bold),
>> @i
>> (italic) or @ref (cross reference). Commands like @param or @return doesn't
>> has the same behavior. The slowness also happens when using \c, \b, \i,
>> \ref.
>> That is, the '@' character is not the culprit.
>>
>> The slower [G]Vim happens only when the cursor is in the commented block.
>> Soon
>> the cursor gets out of it, the movement responses are back to normal.
>>
>> I try to disable some plugins, like UltiSnips and clang_complete, because I
>> installed them about a week ago. But that doesn't solve the problem. So, as
>> a
>> work around, I came up with:
>>
>> :set syntax=objc
>> :set regexpengine=1
>> :set syntax=objc.doxygen
>>
>> The problem disappeared.
>>
>> I took a look at the Doxygen syntax from the new MacVim version and it
>> didn't
>> change a bit. So, I think this has something to do with the new regular
>> expression engine.
>>
>> Someone saw this problem yet?
>>
>> Regards.
>
> Which version of Vim are you using?
>
> Vim-7.4.* introduced the :syntime command which is
> useful for finding what regexp are the bottlenecks. See
> :help :syntime
>
> Dominique

If you can send an example of doxygen file that shows
the slow behavior that would help others to reproduce the
issue.

Dominique

--
--
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/groups/opt_out.

--
--
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/groups/opt_out.

Re: Slowness in Doxygen syntax

Dominique Pellé wrote:

> Alessandro Antonello <antonello.ale@gmail.com> wrote:
>
>> Hi all.
>>
>> I found some glitches in the new MacVim version and I was wondering if
>> someone else already saw something like this. I talked about MacVim because
>> I
>> couldn't test the Windows version yet.
>>
>> I usually work with ObjC files and I set 'syntax' in the modeline, like
>> this:
>>
>> // vim:syntax=objc.doxygen
>>
>> I use Doxygen for project documentation for years and it is part of my life
>> now. The odd glitch is that, the documented comment slows down Vim
>> substantially. Not in every places. Only when the cursor is in a comment
>> block
>> and if that comment block has a Doxygen command like @c (code), @b (bold),
>> @i
>> (italic) or @ref (cross reference). Commands like @param or @return doesn't
>> has the same behavior. The slowness also happens when using \c, \b, \i,
>> \ref.
>> That is, the '@' character is not the culprit.
>>
>> The slower [G]Vim happens only when the cursor is in the commented block.
>> Soon
>> the cursor gets out of it, the movement responses are back to normal.
>>
>> I try to disable some plugins, like UltiSnips and clang_complete, because I
>> installed them about a week ago. But that doesn't solve the problem. So, as
>> a
>> work around, I came up with:
>>
>> :set syntax=objc
>> :set regexpengine=1
>> :set syntax=objc.doxygen
>>
>> The problem disappeared.
>>
>> I took a look at the Doxygen syntax from the new MacVim version and it
>> didn't
>> change a bit. So, I think this has something to do with the new regular
>> expression engine.
>>
>> Someone saw this problem yet?
>>
>> Regards.
>
> Which version of Vim are you using?
>
> Vim-7.4.* introduced the :syntime command which is
> useful for finding what regexp are the bottlenecks. See
> :help :syntime
>
> Dominique

If you can send an example of doxygen file that shows
the slow behavior that would help others to reproduce the
issue.

Dominique

--
--
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/groups/opt_out.

Re: Slowness in Doxygen syntax

On Fri, Aug 30, 2013 at 4:51 PM, Alessandro Antonello <antonello.ale@gmail.com> wrote:

I use Doxygen for project documentation for years and it is part of my life

now. The odd glitch is that, the documented comment slows down Vim
substantially. Not in every places. Only when the cursor is in a comment block
and if that comment block has a Doxygen command like @c (code), @b (bold), @i
(italic) or @ref (cross reference). Commands like @param or @return doesn't
has the same behavior. The slowness also happens when using \c, \b, \i, \ref.
That is, the '@' character is not the culprit.

The slower [G]Vim happens only when the cursor is in the commented block. Soon
the cursor gets out of it, the movement responses are back to normal.

What is slow: typing in Insert mode? Moving around in Normal mode? Ex mode, like :s/foo_var/bar_var/g ?

Benji Fisher

Friday, August 30, 2013

Re: What is the best way to distinguish the current buffer is location list or quickfix list?

On 30 August 2013, Kent <kent.yuan@gmail.com> wrote:
> Hi all,
>
> I have an autocmd, if ft is qf, it is gonna call some functions to
> modify the quickfix list by get/setqflist()
>
> I know there are another pair of functions get/setloclist(), to handle
> the location list.
>
> My problem is, how to know if the current buffer is qf-list or
> location-list (They both have filetype qf) so that I know which
> functions should be called?

There is no good way to do that. As a partial workaround, you might
try calling getloclist(0), it should return [] if the current buffer is
a quickfix list, and something non-empty if it's a loclist. But this
may or may not work from an autocmd. Also, the filetype of the quickfix
buffer may be empty at that point if the quickfix has just been created.

[...]
> Did I miss some function/flag/variable ?

Not really. Working with loclists is one of the darker corners of
Vim, using them for anything else than the built-in make, grep, and
friends is a huge pain.

[...]
> one answer from @romainl suggested using the variable w:quickfix_title.
> check if the command was beginning with ":l(L)"
[...]

That's even less reliable: if you create loclists with setloclist()
w:quickfix_title can be empty, or ':setloclist()', or something entirely
different.

/lcd

--
--
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/groups/opt_out.

Re: q key

Yeah, that was meant for the list.

Ah, should've guess based on the :verbose map <key> that I needed to :unmap <key>.

I think you're right about not wanting to overwrite defaults. Though you can also use soy from cli by running soywiki (which I would never do since I like one gvim session using tabs) so, I'm not sure if there's a usecase there. I'm tempted to say that you're still right in a stand alone situation as I use the hell out of macros (because I'm too lazy to think of a regex).

On Fri, Aug 30, 2013 at 8:11 PM, Tim Chase <vim@tim.thechases.com> wrote:

[you replied only to me rather than to the list; I'm copying the list]

On 2013-08-30 19:50, shawn wilson wrote:
> Ok, soywiki set it to :close<CR> ... question one answered (that's
> annoying) - and the second part - how to unset it?

It may depend on how it was loaded. If it was part of a plugin, it
might be a bit trickier (I'm not sure how plugin loading interacts
with vimrc settings). Push come to shove, you can manually issue

:unmap q

to clear the mapping. Alternatively, you can nuke the problematic
line from the plugin:

https://github.com/danchoi/soywiki/blob/master/lib/soywiki.vim#L403

Personally, I'd consider the absence of this mapping a great
improvement (overwriting vim's macro functionality is just a kick in
the teeth!) and have no regrets nuking that line.

-tim

Re: q key

[you replied only to me rather than to the list; I'm copying the list]

On 2013-08-30 19:50, shawn wilson wrote:
> Ok, soywiki set it to :close<CR> ... question one answered (that's
> annoying) - and the second part - how to unset it?

It may depend on how it was loaded. If it was part of a plugin, it
might be a bit trickier (I'm not sure how plugin loading interacts
with vimrc settings). Push come to shove, you can manually issue

:unmap q

to clear the mapping. Alternatively, you can nuke the problematic
line from the plugin:

https://github.com/danchoi/soywiki/blob/master/lib/soywiki.vim#L403

Personally, I'd consider the absence of this mapping a great
improvement (overwriting vim's macro functionality is just a kick in
the teeth!) and have no regrets nuking that line.

-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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: q key

On 2013-08-30 19:31, shawn wilson wrote:
> Somehow my q key has gotten hijacked as the quit command. How do I
> figure out what happened and unbind it (not being able to record a
> macro is really messing with my work flow).

You should be able to issue

:verbose map q

and it will point the finger at the offending location.

-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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

q key

Somehow my q key has gotten hijacked as the quit command. How do I figure out what happened and unbind it (not being able to record a macro is really messing with my work flow).

Re: Slowness in Doxygen syntax

Alessandro Antonello <antonello.ale@gmail.com> wrote:

> Hi all.
>
> I found some glitches in the new MacVim version and I was wondering if
> someone else already saw something like this. I talked about MacVim because
> I
> couldn't test the Windows version yet.
>
> I usually work with ObjC files and I set 'syntax' in the modeline, like
> this:
>
> // vim:syntax=objc.doxygen
>
> I use Doxygen for project documentation for years and it is part of my life
> now. The odd glitch is that, the documented comment slows down Vim
> substantially. Not in every places. Only when the cursor is in a comment
> block
> and if that comment block has a Doxygen command like @c (code), @b (bold),
> @i
> (italic) or @ref (cross reference). Commands like @param or @return doesn't
> has the same behavior. The slowness also happens when using \c, \b, \i,
> \ref.
> That is, the '@' character is not the culprit.
>
> The slower [G]Vim happens only when the cursor is in the commented block.
> Soon
> the cursor gets out of it, the movement responses are back to normal.
>
> I try to disable some plugins, like UltiSnips and clang_complete, because I
> installed them about a week ago. But that doesn't solve the problem. So, as
> a
> work around, I came up with:
>
> :set syntax=objc
> :set regexpengine=1
> :set syntax=objc.doxygen
>
> The problem disappeared.
>
> I took a look at the Doxygen syntax from the new MacVim version and it
> didn't
> change a bit. So, I think this has something to do with the new regular
> expression engine.
>
> Someone saw this problem yet?
>
> Regards.

Which version of Vim are you using?

Vim-7.4.* introduced the :syntime command which is
useful for finding what regexp are the bottlenecks. See
:help :syntime

Dominique

--
--
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/groups/opt_out.

What is the best way to distinguish the current buffer is location list or quickfix list?

Hi all,

I have an autocmd, if ft is qf, it is gonna call some functions to modify the quickfix list by get/setqflist()

I know there are another pair of functions get/setloclist(), to handle the location list.

My problem is, how to know if the current buffer is qf-list or location-list (They both have filetype qf) so that I know which functions should be called?

so far what I can think of is, do some change on qf-list, and compare with current buffer, if the current buffer is changed too, it is qf-list, otherwise it should be location list. Finally roll back the changes. But I feel it is stupid... there should be better way to make the decision.

the location list and qf list both could be empty or both were filled with data.

Did I miss some function/flag/variable ?

In fact I've asked the question at SO:

http://stackoverflow.com/questions/18522086/what-is-the-best-way-to-distinguish-the-current-buffer-is-location-list-or-quick

one answer from @romainl suggested using the variable w:quickfix_title. check if the command was beginning with ":l(L)" after I tested a little there are some cases need to be careful:

- the qf/loc list was filled by a script, (using setqflist()/setloclist()), the value of the variable would be the function name. so this could be checked too

- if user manually open an empty quickfixlist, e.g. :copen , reading the variable will throw exception. it could be ok too, because it seems that we cannot manually open an empty location list by :lopen.

- I don't know if there are other (corner) situations, will break the check.

what would be the best way to detect, which list window I am in?

thanx in advance

Kent

Slowness in Doxygen syntax

Hi all.

I found some glitches in the new MacVim version and I was wondering if

someone else already saw something like this. I talked about MacVim because I

couldn't test the Windows version yet.

I usually work with ObjC files and I set 'syntax' in the modeline, like this:

// vim:syntax=objc.doxygen

I use Doxygen for project documentation for years and it is part of my life

now. The odd glitch is that, the documented comment slows down Vim

substantially. Not in every places. Only when the cursor is in a comment block

and if that comment block has a Doxygen command like @c (code), @b (bold), @i

(italic) or @ref (cross reference). Commands like @param or @return doesn't

has the same behavior. The slowness also happens when using \c, \b, \i, \ref.

That is, the '@' character is not the culprit.

The slower [G]Vim happens only when the cursor is in the commented block. Soon

the cursor gets out of it, the movement responses are back to normal.

I try to disable some plugins, like UltiSnips and clang_complete, because I

installed them about a week ago. But that doesn't solve the problem. So, as a

work around, I came up with:

:set syntax=objc

:set regexpengine=1

:set syntax=objc.doxygen

The problem disappeared.

I took a look at the Doxygen syntax from the new MacVim version and it didn't

change a bit. So, I think this has something to do with the new regular

expression engine.

Someone saw this problem yet?

Regards.

Re: ANN: YankRing 17.0

On Fri, Aug 30, 2013 at 11:50 AM, Nikolay Pavlov <zyx.vim@gmail.com> wrote:
> Numbered registers are populated from deletes unless another register was
> specified. The help states though that one-line deletes should not affect
> numbered registers (with some exceptions, but "t" is not the one).

That seems irrelevant to the case I am having a problem with:

| this is a line with a "quote"

Where | is the cursor

dt" triggers the problem. I don't see how the register matters. From the help:

t{char} Till before [count]'th occurrence of {char} to the
right. The cursor is placed on the character left of
{char} |inclusive|.
{char} can be entered like with the |f| command.

I'm not a vim expert.

c
--
Chris Lott <chris@chrislott.org>

--
--
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/groups/opt_out.

Re: ANN: YankRing 17.0

On Aug 30, 2013 9:34 PM, "Chris Lott" <chris@chrislott.org> wrote:
>
> On Thu, Aug 29, 2013 at 6:33 PM, Francis Ngoh <yfngoh@gmail.com> wrote:
> > Im away from my computer but I found a workaround ... ie dont use numbered
> > registers for the macro.
>
>
> Maybe I'm missing something, but I don't see how this solves the
> problem. dt" isn't using a numbered register, it's deleting to the
> character "

Numbered registers are populated from deletes unless another register was specified. The help states though that one-line deletes should not affect numbered registers (with some exceptions, but "t" is not the one).

> c
> --
> Chris Lott <chris@chrislott.org>
>
> --
> --
> 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/groups/opt_out.

Re: Path easy-search

Am 30.08.2013 18:47, schrieb ZyX:
> There is an interesting fact that setting `@/` resets //... flags.
> Thus you may try the following:
>
> function s:SetSearch(sstr)
> let @/=@/
> return a:sstr
> endfunction
> noremap <expr> n <SID>SetSearch('Nn'[v:searchforward])
> noremap <expr> N <SID>SetSearch('nN'[v:searchforward])

Nice little observation, thanks for noticing!

Weird: after `?pattern<CR>`, the first `n` goes further back, following
`n`s move downwards. It appears that `:let @/ = @/` sets
v:searchforward to 1.

function s:SetSearch(sstr)
let @/=@/
return a:sstr
endfunction

noremap <expr> n <SID>SetSearch('n')
noremap <expr> N <SID>SetSearch('N')

--
Andy

--
--
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/groups/opt_out.

Re: ANN: YankRing 17.0

On Thu, Aug 29, 2013 at 6:33 PM, Francis Ngoh <yfngoh@gmail.com> wrote:
> Im away from my computer but I found a workaround ... ie dont use numbered
> registers for the macro.

Maybe I'm missing something, but I don't see how this solves the
problem. dt" isn't using a numbered register, it's deleting to the
character "

c
--
Chris Lott <chris@chrislott.org>

--
--
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/groups/opt_out.

Re: Path easy-search

There is an interesting fact that setting `@/` resets //... flags. Thus you may try the following:

function s:SetSearch(sstr)
let @/=@/
return a:sstr
endfunction
noremap <expr> n <SID>SetSearch('Nn'[v:searchforward])
noremap <expr> N <SID>SetSearch('nN'[v:searchforward])

--
--
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/groups/opt_out.

Re: yankring and @: (repeat last ex command)

David Fishburn <dfishburn.vim@gmail.com> wrote, on ven 30 aoû 09:53 :

> On Fri, Aug 30, 2013 at 4:55 AM, Davido <orduval@gmail.com> wrote:
>
> > Hello,
> >
> > Yankring doesn't seem to manage the @: command, so I first tried this
> > workaround :
> >
> > nnoremap @: :<c-r>:<cr>
> >
> > which works, but is not very elegant.
> >
> > Thanks for the report and the code.
>
> I had already addressed this in the next release (18.0) with the following:
>
> if zapto !~ '$\w\|@\|:$'
> " Abort if the user does not specify a register
> call s:YRWarningMsg( "YR:No register specified, aborting macro" )
> return ""
> endif
>
> David

It works fine, thanks !

By the way, is the dev version of yankring available ? (I wouldn't mind
using/testing it)

--
Davido

--
--
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/groups/opt_out.

Re: yankring and @: (repeat last ex command)

On Fri, Aug 30, 2013 at 4:55 AM, Davido <orduval@gmail.com> wrote:

Hello,

Yankring doesn't seem to manage the @: command, so I first tried this workaround :

nnoremap @: :<c-r>:<cr>

which works, but is not very elegant.

Thanks for the report and the code.

I had already addressed this in the next release (18.0) with the following:

if zapto !~ '$\w\|@\|:$'

" Abort if the user does not specify a register

call s:YRWarningMsg( "YR:No register specified, aborting macro" )

return ""

endif

David

yankring and @: (repeat last ex command)

Hello,

Yankring doesn't seem to manage the @: command, so I first tried this workaround :

nnoremap @: :<c-r>:<cr>

which works, but is not very elegant.

So, I suggest the small patch below to fix it. Probably a quick and
dirty one, I hope there is no mistake :

--- .yankring.vim.bkp 2013-08-30 10:29:13.058816243 +0200
+++ yankring.vim 2013-08-30 10:52:43.766806732 +0200
@@ -1673,6 +1673,11 @@
return ""
endif

+ if zapto == ":"
+ normal! @:
+ return ""
+ endif
+
if zapto !~ '$\w\|@$'
" Abort if the user does not specify a register
call s:YRWarningMsg( "YR:No register specified, aborting macro" )

--
Regards,

Davido

--
--
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/groups/opt_out.

Thursday, August 29, 2013

Re: ANN: YankRing 17.0

Im away from my computer but I found a workaround ... ie dont use numbered registers for the macro.

On Aug 29, 2013 1:38 PM, "snowman55" <yfngoh@gmail.com> wrote:

Any update? I have the same problem and have to remove the plugin when I need recording.

--
--
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/gaaW7X5AyDM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get current file name with full path

On Friday, August 30, 2013 1:10:33 AM UTC+2, Jerry Dai wrote:
> Hi David,
> Did you mean I should create a "nmap" for <C-R> ?
> Can you elaborate?

No, it's literal. But you can create a mapping for this if you like of
course. Just as you would type

<C-R>%

in insert mode to get the file name, type the following in insert mode
to get the full file path:

<C-R>=expand("%:p")<Enter>

After this, the full file path will be inserted at the cursor position.

Best,

--
--
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/groups/opt_out.

Re: get current file name with full path

On 30/08/13 00:50, Jerry Dai wrote:
> In insert mode, I will get current file name by:
> <C-R>%
>
> Is there anything similiar can give me a full hierarchical path?
>
> -- --
> Best Regards
> Jerry Dai
>

In a script, expand('%:p') would give you the result as a String. So, to
insert it at the Insert-mode cursor:

<C-R>=expand('%:p')<CR>
or
:map! <expr> <F7> expand('%:p')
(the latter would let you insert it by hitting F7 in Insert or
Command-line mode).

see
:help expand()
:help filename-modifiers
:help quote=
and for use in a mapping or abbreviation
:help :map-<expr>

Best regards,
Tony.
--
"The road to hell is paved with melting snowballs."
-- Larry Wall in <1992Jul2.222039.26476@netlabs.com>

--
--
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/groups/opt_out.

Re: get current file name with full path

Hi David,
Did you mean I should create a "nmap" for <C-R> ?
Can you elaborate?

-- --
Best Regards
Jerry Dai

On Thu, Aug 29, 2013 at 4:03 PM, glts <676c7473@gmail.com> wrote:
> Hey Jerry,
>
> On Friday, August 30, 2013 12:50:47 AM UTC+2, Jerry Dai wrote:
>> In insert mode, I will get current file name by:
>> <C-R>%
>>
>> Is there anything similiar can give me a full hierarchical path?
>
> how about
>
> <C-R>=expand("%:p")<CR>
>
> Best,
> David
>
> --
> --
> 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/groups/opt_out.

--
--
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/groups/opt_out.

Re: get current file name with full path

Hey Jerry,

On Friday, August 30, 2013 12:50:47 AM UTC+2, Jerry Dai wrote:
> In insert mode, I will get current file name by:
> <C-R>%
>
> Is there anything similiar can give me a full hierarchical path?

how about

<C-R>=expand("%:p")<CR>

Best,
David

--
--
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/groups/opt_out.

get current file name with full path

In insert mode, I will get current file name by:
<C-R>%

Is there anything similiar can give me a full hierarchical path?

-- --
Best Regards
Jerry Dai

--
--
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/groups/opt_out.

Re: ANN: YankRing 17.0

On Thu, Aug 29, 2013 at 12:36 PM, snowman55 <yfngoh@gmail.com> wrote:

Any update? I have the same problem and have to remove the plugin when I need recording.

Can you give me some text which you run the macro on, and then show me what the macro you record is.

Then please provide the output from

:set

and

:ver

Can you also try with Vim using the following command line:

vim -u NONE -U NONE -N --noplugins

After Vim launches:

:source $HOME/.vim/plugin/yankring.vim

Or where ever the plugin was installed and see if you get the same behaviour.

You can respond to me directly while we investigate to keep the traffic down on vim_use if you would like.

Thanks,

David

Re: ANN: YankRing 17.0

Any update? I have the same problem and have to remove the plugin when I need recording.

--
--
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/groups/opt_out.

Re: Fwd: vim: what the current best practice to work with excel file (xlsx)?

Hi ping!

On Mi, 28 Aug 2013, ping song wrote:

> hi Chris:
> did you add any new feature to solve this problem?

This problem is better addressed at me directly or using the github
issue tracker. I don't think it makes sense to bother this list with it.

> today I use your plugin to open another 20M csv file, and since I mapped my
> <blank> key into C-f, it froze for quite a while on my keystroke again...
> can I config the plugin to use other keystroke for what it is doing with
> <blank> key?

This problem has been solved since you mentioned it the last time.
Simply set :let g:csv_nomap_<key> = 1 into your .vimrc, e.g. if you
don't want to have space mapped, use

:let g:csv_nomap_space = 1

Note, this is also described in the help at :h csv-mapping

regards,
Christian
--
Man muß, schon aus Welt, dem andern auch nicht das geringste
Unangenehme sagen, sobald man nicht ihn oder sich bessern damit will
oder kann. »Sage nicht zum Mietsherrn, deine Zimmer haben keine
Morgensonne.«
-- Jean Paul

--
--
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/groups/opt_out.

Wednesday, August 28, 2013

Re: Mapping <*-CR>

On Tuesday, August 27, 2013 8:21:06 AM UTC-4, Michael Henry wrote:
> On 08/25/2013 05:00 PM, Thomas E. Dickey wrote:

konsole's keyboard hasn't changed in a while (2008 is the most recent):

http://invisible-island.net/ncurses/terminfo.ti.html#toc-_K_D_E

There are a couple of
general comments about the xterm keys:

a) the \E[ stuff is CSI, used in application mode. \EO is SS3 - normal mode.
conventionally xterm uses application mode, which is okay except for bash
users who aren't running in full-screen mode.
b) the \EOP, \EOQ, etc., are the vt100 PF-keys, which I made xterm use for
F1-F4 in the 1990s. Before that (and still configurable) are codes with
numbers.
c) the modifier stuff came somewhat later (still a long time ago).
I recall noticing that the modified keys used SS3, which isn't really
right - and changed those to use CSI format as you see in the terminal
database. In a quick check, it seems that I did this in 2006.

--
--
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/groups/opt_out.

Re: Unix vim running dos files

On 28/08/13 18:27, Philip Piper wrote:
> Is it standard behavior that vim on my debian install can not run DOS plugins that I download without me converting said plugins to unix fileformat?
>
> The screenshot is after trying open vim after install Unite through pathogen.
>

According to the help, Windows Vim can source a Unix-fileformat plugin
if 'fileformats' includes "unix" but not vice-versa. On a Unix Vim
(including Vim for Mac OS X), all lines of all plugins must end in a
linefeed with no carriage-return. The carriage return character would be
interpreted as a control-M. I suppose that lines ending in a comment
would not generate an error, but it is impractical to make sure that all
lines end in a comment: for some commands this would mean wrapping them
in an :execute followed by a bar and quote.

See the third paragraph under :help :source_crnl

Best regards,
Tony.
--
/earth: file system full.

--
--
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/groups/opt_out.

Re: Fwd: vim: what the current best practice to work with excel file (xlsx)?

hi Chris:

did you add any new feature to solve this problem?

today I use your plugin to open another 20M csv file, and since I mapped my <blank> key into C-f, it froze for quite a while on my keystroke again...

can I config the plugin to use other keystroke for what it is doing with <blank> key?

thanks!

On Fri, Apr 5, 2013 at 5:08 PM, ping <songpingemail@gmail.com> wrote:

thanks!

On 04/05/2013 02:47 PM, Christian Brabandt wrote:

Hi ping!

On Fr, 05 Apr 2013, ping wrote:

[CSV filetype plugin]

been nearly a year now...
from time to time I use this plugin, and it mostly of the time works great.

another issue I got annoying is , the <space> was re-mapped to some
folding functions.
I understand this is a neat feature, but that overides my previous
map, to use <space> as c-f (page down).
is there a way for me to undo this? (or can I define my own key for
the folding?)

Hm, no, currently there is no way to prevent the mapping of keys. I'll
take care of that.

For the time being, I suggest put your favorite mapping into a file
~/.vim/after/ftplugin/csv.vim

That should take care of it.

regards,
Christian