Re: [proposal] Project Information for vim

[lith]

While a basically agree, wrt

- root directory

Why not allow many root markers? Since a VCS directory is usually created in 
the project's root directory, these VCS directories would be a natural choice. 
The autoproject plugin[1] does it this way, and IMHO (but I'm biased :-)) it 
works quite well. I think it would be a mistake to require the existence of 
some magic marker.

- file list

I'm not sure this should be provided by vim. Sooner or later you'd want to 
cache this information. Then you'd have to check if the info is still up to 
date. I'm not sure if this is within the scope of the standard vim 
distribution. In this respect, one could ask whether vim should actually 
provide the functionality or just define a standard api that is provided for by 
a user-chosen plugin -- i.e. let one plugin provide filelists for projects. One 
plugin uses more clever chaching, the other relies on this or that external 
tool.

E.g.

set project_roots_provider=foobar#GetProjectRoots
set project_filelist_provider=foobar#GetFileList
echo project_filelist(project_root("project name"))
" which would actually call foobar#GetFilelist()

- buffer-local options

If I got it right, the vim team tends towards EditorConfig for this?


[1] https://github.com/tomtom/autoproject_vim

-- 
-- 
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/vim] packadd autocmd (#3739)

[lith]

> I imagine something like this:
> autocmd PackLoadPre neomake packadd some-dependency
> autocmd PackLoadPost neomake call neomake#configure#automake('nrwi', 500)

Not exactly what you want but the autopack plugin[1] support loading configs 
from `packrc/before/PLUGIN.vim` and `packrc/after/PLUGIN.vim` (from somewhere 
in &runtimepath).

Maybe this help


[1]
https://github.com/tomtom/autopack_vim (current version)
https://www.vim.org/scripts/script.php?script_id=5526

-- 
-- 
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: What do Vim plugin authors want from Vim?

[lith]

> I often wonder what next to add or improve in Vim.  These days plugin
> authors are a very important group of people who help making Vim more
> useful.  Thus I would like to hear from them what they want.

Since the question is put on hold on SO: IMHO the only feature really missing 
is some sort of overlays (à la emacs: 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Overlays.html). This 
would provide for region-local maps, variables etc. This way information could 
be stored with some part of the text.

The last time I tried, I found it rather difficult to work with subprocesses in 
way reliable across OSs -- e.g. linux + windows.

As a user, I would prefer a standardized APIs for project-related information 
(e.g. file lists, root directory, VCS type etc.) provided by the vim standard 
library.

Regards

-- 
-- 
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 7.4.530

[lith]

> My guess is that the
> implementation of `tcomment#Comment` must have change or before it was
> defined with `-range=1`.

The implementation of `tcomment#Comment` has changed but it still works 
perfectly well with 7.3-460.

`-range=1` wasn't used.

-- 
-- 
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: Either fnameescape or shellescape should also escape "(" and ")", shoudn't it?

[lith]

Hi!

Let's assume files is ['foo(bar).txt']. Let's try

:exec 'grep' fnameescape(join(files))

This throws an error (on ubuntu 12.04).

The following solves the problem:

:exec 'grep' escape(fnameescape(join(files)), '()')

I think though this shouldn't be necessary since it somehow undermines the 
usefulness of fnameescape(). IMHO fnameescape() should also escape '()', 
shoudn't it?

Regards,
Tom

-- 
-- 
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] add sortuniq() function

[lith]

> > I think some of us would be rather surprised if the result weren't
> > [1,2,3].
> 
> Well, the more experienced among us would know that full (unsorted)
> unique would be nice, but expensive. :)

It eluded my mind that vimscript aims at high performance computing. I was 
talking about user expectations given that probably the majority of vim users 
are ruby, python, javascript developers -- at least from my perspective, which 
could be biased.

-- 
-- 
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] add sortuniq() function

[lith]

> In other words, I'd expect this for example:
> 
>   :echo uniq([1, 2, 3, 3, 2, 2, 1])
>   [1, 2, 3, 2, 1]

I think some of us would be rather surprised if the result weren't [1,2,3].

-- 
-- 
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: Is there any way to get the vim executable path from within vim?

[lith]

> I was hoping using the python sys.argv would return the vim path as the first 
> item, but its filled with garbage? Is there any way to get it, either from a 
> built-in viml function or from the python interface?

The executable name is in v:progname. If it is in $PATH, you should be set.

-- 
-- 
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 - Detect Whether a Plugin is Active/Running/Open?

[lith]

> You can close a plugin by its name?
> You can close a plugin when it loses focus?
> The goal is to create keyboard shortcuts (conditional) to be configured in 
> "vimrc" so I can easily switch between plugins!

I personally don't quite understand what you're aiming at. Could you please 
give some sort of example what you mean by "closing a plugin" or "a plugin 
losing focus"?

Regards

-- 
-- 
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.

Re: paredit.vim

[lith]

> Could you add paredit : http://www.vim.org/scripts/script.php?script_id=3998 
> to the vim plugin runtime files ? 

I'd rather vote for adding an official package manager and leave it to the 
users to decide whether they want to add this plugin.

-- 
-- 
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.

Re: Plans for Vim 7.4

[lith]

> I'm sure everybody has their favorite patch that he would like to see
> included.

Maybe one should rather think of the breakindent patch as a basic feature of a 
modern text editors that fully supports "soft" word wrap.

-- 
-- 
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.

Re: Plans for Vim 7.4

[lith]

> I'd like to see the breakindent patch included.

Yes, please!

-- 
-- 
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.

Re: Bug win32 gui: window position is changed when invoking :vert under certain conditions

[lith]

> > I sometimes use gvim 7.3 @ win7 (64 bit). When I move the gvim window by 
> > means of the  key combination to the left or 
> > right half of the screen, it seems gvim doesn't properly notice this 
> > change. When I invoke any command with :vert prepended (e.g. :vert split), 
> > gvim moves the gvim window back to the previous position on the screen.
>
> This also happens with the :vnew command.
> 
> This looks like a bug. Opening a split window should not move the application 
> window.

In case somebody cares about this problem, it seemingly also affects 
tab-related commands like :tabnew.

Regards,
Tom

-- 
-- 
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.

Bug win32 gui: window position is changed when invoking :vert under certain conditions

[lith]

Hi!

I sometimes use gvim 7.3 @ win7 (64 bit). When I move the gvim window by means 
of the  key combination to the left or right half of 
the screen, it seems gvim doesn't properly notice this change. When I invoke 
any command with :vert prepended (e.g. :vert split), gvim moves the gvim window 
back to the previous position on the screen.

Steps:
1. Open gvim -> gvim window opens at position #1
2. Press  -> gvim window is moved to the left (position #2)
3. Type :vert split

Result: The gvim window is back at position #1.

This problem seems to affect only the win gui. At least with gnome/gtk 
everything seems ok.

Regards,
Tom

-- 
-- 
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.

Re: Bug? shellslash options exists in vim-gtk for ubuntu

[lith]

> you should use
> 
>   :echo exists('+shellslash')

Ah, I see. Thanks a lot.

Regards,
Tom

-- 
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

Bug? shellslash options exists in vim-gtk for ubuntu

[lith]

I use vim-gtk 7.3.429-2ubuntu2.1 on ubuntu 12.04. The docs for shellslash state 
that it's only defined only for MSDOS, MS-Windows and OS/2. In vim-gtk,

echo exists('&shellslash')

prints 1. And the value of &shellslash is 0.

I'd expect the option to be either undefined (that's my understanding of the 
doc) or maybe that the value is 1 since bash uses slashes and not backslashes 
(but I guess I'm missing something here).

Regards

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: printf() vs. unicode (multi-byte encodings)

[lith]

Am Sonntag, 11. November 2012 10:03:49 UTC+1 schrieb ZyX:
> > Is this intended? Is there an (easy) way to make printf() respect 
> > multi-byte encodings?
> It is clearly stated in documentation that printf() operates with bytes.

My question rather was am I missing something since I personally find this 
behaviour rather useless in the context of a text editor.

A formatted string usually is something that should eventually be displayed in 
a vim buffer. When I want to get a string padded with whitespace, I'm almost 
always rather interested in its display width than in its size in bytes -- and 
I can hardly imagine a use case where it would be otherwise.

I can work around this problem by adjusting the width dependent on the 
difference between len(s) and strwidth(s) but I personally find this 
unnecessarily complicated.

-- 
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

printf() vs. unicode (multi-byte encodings)

[lith]

Hi!

The following command:

:echo strwidth(printf("%10s", "äöü"))

prints 7 if enc=utf8. I naively assumed it would print 10.

Is this intended? Is there an (easy) way to make printf() respect multi-byte 
encodings?

Regards,
Tom

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Bug since one of the later patches: :redraw during startup (e.g. from vimrc) causes gvim to redraw on the terminal

[lith]

Hi,

Am Dienstag, 13. Dezember 2011 20:24:01 UTC+1 schrieb Christian Brabandt:
>
> Can you provide a minimal example of the crash?


Since I don't own a Mac, I cannot give an example for the crash, but the 
following example triggers the problem described above. I assume this was 
also what caused MacVim to crash since not placing a sign solved the 
problem.

gvim -u vimrc.test

where vimrc.test is

sign define Foo text=F
sign place 1 line=1 name=Foo buffer=1

Rehards,
Tom

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Bug since one of the later patches: :redraw during startup (e.g. from vimrc) causes gvim to redraw on the terminal

[lith]

> First, the problem was introduced during the latest patches.


This should read: the problem was *not* ...

Regards,
Tom

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Bug since one of the later patches: :redraw during startup (e.g. from vimrc) causes gvim to redraw on the terminal

[lith]

Hi,

The startup sequence for the GUI was indeed changed.  Calling :redraw in
> the startup script is weird, you probably need to change that.  If there
> really are redrawing problems use a VimEnter or GUIEnter autocommand.
>
I now had time to investigate this a little bit further.

First, the problem was introduced during the latest patches. It's simply 
that I noticed the problem myself after recompiling vim.

Secondly, the original problem wasn't caused by a :redraw command but by 
setting a sign during startup. This seems to be a related bug report about 
a crash with MacVim: https://github.com/tomtom/quickfixsigns_vim/issues/13

I usually don't call :redraw during startup. This was meant as a minimal 
example to trigger the problem described.

Summary: The real culprit is :sign place that caused the original problem 
described above and seemingly causes macvim to crash. To add :redraw to 
vimrc is simply a way to trigger the same symptom. The problem probably has 
gone unnoticed for a longer time.

Regards,
Tom

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Bug since one of the later patches: :redraw during startup (e.g. from vimrc) causes gvim to redraw on the terminal

[lith]

> The bug report is not that the GUI does not come up, it's that the
terminal that gVim is invoked from gets drawn by gVim, then the GUI does
come up.

Sorry for being imprecise. This is exactly what happens. The GUI comes up
as always. It's just that a :redraw command in vimrc causes gvim to paint
its view on the terminal first ... Then the gui is being displayed.

Regards,
Tom

-- 
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

Bug since one of the later patches: :redraw during startup (e.g. from vimrc) causes gvim to redraw on the terminal

[lith]

Hi,

After recompiling vim from the current sources, I noticed the following 
bug: A :redraw command that is called during startup, causes gvim to print 
its screen view on the terminal -- as if vim were called. This happens when 
I run gvim from gnome-terminal.

Unfortunately, I cannot tell which patch causes this but this bug must have 
been introduced after 340, I'd say.

Regards,
Tom

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Cannot edit plugin description vimscript #3780

[lith]

> There is a redirect error if you are not logged in.  I'll fix it.
>
Thank you very much. It works now.

Regards,
Tom

-- 
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

Cannot edit plugin description vimscript #3780

[lith]

Hi,

Yesterday, I uploaded a small plugin:
http://www.vim.org/scripts/script.php?script_id=3780

I then wanted to make minor changes to the plugin description. Unexpectedly, 
I was redirected to the login-page (I was already logged in). After logging 
in, I get the error message enclosed below. Since I can still edit the 
descriptions of my other plugins, I suspect that something in the DB went 
wrong. Since it could be that this affects also other scripts I send this 
report to this list.

Regards,
Tom


An error has been encountered in accessing this page. 

1. *Server:* www.vim.org 
2. *URL path:* /script_edit.php 
3. *Error notes:* NONE 
4. *Error type:* 404 
5. *Request method:* GET 
6. *Request query string:* NONE 
7. *Time:* 2011-10-22 05:37:42 UTC (1319261862) 

*Reporting this problem:* The problem you have encountered is with a project 
web site hosted by SourceForge.net. This issue should be reported to the 
SourceForge.net-hosted project (not to SourceForge.net). 

*If this is a severe or recurring/persistent problem,* please do one of the 
following, and provide the error text (numbered 1 through 7, above): 

   1. Contact the project via their designated support 
resources.
 
   
   2. Contact the project administrators of this project via email (see the 
   upper right-hand corner of the Project Summary 
pagefor their 
usernames) at 
   *user-name*@users.sourceforge.net

If you are a maintainer of this web content, please refer to the Site 
Documentation regarding web 
servicesfor
 further assistance. 

NOTE: As of 2008-10-23 directory index display has been disabled by default. 
This option may be re-enabled by the project by placing a file with the name 
".htaccess" with this line: 

Options +Indexes


-- 
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

Aw: Re: filetype.vim: could R be the default instead of Rexx?

[lith]

>
> OK, I'm convinced.  I'll make the default R.  I'll add a note in the
> docs for Rexx users how they can change the default.
>
Thanks. I'd like to add though that R itself and most libraries usually use 
an upper case R as extension. It might be confusing for some users but vim 
could use lower case r for rexx and upper case R for R. Just a thought.

Regards,
Tom

-- 
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

Aw: Re: filetype.vim: could R be the default instead of Rexx?

[lith]

Hi,
 

> I don't know how to read these graphs.  Also, it's Debian only, suppose
> the picture is very different for mac or MS-Windows users?
>
R is at position 33 in the tiobe index:
http://www.tiobe.com/content/paperinfo/tpci/index.html

rexx isn't listed at all. I doubt it has much of a following anymore.

We could add a g:filetype_r variable to allow users to change the
> fallback:
>
>   " Nothing recognized, use user default or assume Rexx
>   if exists("g:filetype_r")
> exe "setf " . g:filetype_r
>   else
> setf rexx
>   endif
>
Would this special solution that works only for this extension

let g:filetype_r = "r"

really be an advantage over that

au filetypedetect BufRead,BufNewFile *.R setf r

New users would have to edit personal configuration files one way or the 
other.

I could imagine some use of turning this into a general solution that's 
valid for all extensions though -- and thus replacing the filetypedetect 
autocommand group.

Regards,
Tom

-- 
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