Comment #2 on issue 326 by fmerci...@gmail.com: filetype plugin not loaded
when file opened from within vim rather than from command line
https://code.google.com/p/vim/issues/detail?id=326
According to https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces
- Spaces are the preferred indent
Comment #1 on issue 326 by fritzoph...@gmail.com: filetype plugin not
loaded when file opened from within vim rather than from command line
https://code.google.com/p/vim/issues/detail?id=326
Why do you expect typing tab to insert 4 spaces? Where do you define this
rule?
One of the big cha
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 326 by fmerci...@gmail.com: filetype plugin not loaded when file
opened from within vim rather than from command line
https://code.google.com/p/vim/issues/detail?id=326
What steps will reproduce the problem?
1. Use the foll
On Sun, Feb 8, 2015 at 8:56 PM, Justin M. Keyes wrote:
> In addition to what Eliseo said, we will make an effort to label
> relevant coverity issues, etc., with the vim-bug label. At any time,
> you can see all vim-bug issues via this URL:
>
> https://github.com/neovim/neovim/issues?q=label%3Abug-
On Sun, Feb 8, 2015 at 12:54 PM, Bram Moolenaar wrote:
>
> Eliseo wrote:
>
>> Hi, I'm the author of those commits.
>>
>> As I said to Christian, I try to send patches, or at least report, the
>> important issues we find.
>> I can't guarantee doing it always (for minor issues), though. For,
>> fran
I hit similar once as well. Also note that wfoo means write foo or such
- thus spaces can be omitted.
> export VIM_CMD_REINTERPRETE=":;wq!#:wq!"
You can implement this on your own, but such into your .vimrc
let l = split('#", $VIM_CMD_REINTERPRETE)
exec 'cnoremap '.l[0].' '.l[1]
or similar -
Erik,
Thank you for the explanation.
Maybe we should change the interpretation of that ***particular*** command,
not to replace the entire file with the current line. I know that it is a
feature; but i looks like it does more harm than good. When I ever need to
do something like that, i would m
Hi,
I see inconsistent results when typing "dit" to delete content of an XML
element. Result depends on whether the closing XML tag is indented or not.
Observed: Opening and closing tag end up ...
- on different lines when closing tag had no indent (see Case_A below)
- on same line when closing
Mike Williams wrote:
> There are some uses of vim_realloc() that can lead to a memory leak and
> possibly an immediate crash if the call to vim_realloc() fails. A
> little ironic to be leaking memory when failing trying to allocate some.
>
> Attached is a diff against 7.4.622.
Thanks. It's
Hi,
There are some uses of vim_realloc() that can lead to a memory leak and
possibly an immediate crash if the call to vim_realloc() fails. A
little ironic to be leaking memory when failing trying to allocate some.
Attached is a diff against 7.4.622.
There is one occurrence I didn't fix, in
Xavier de Gaye wrote:
> On 02/07/2015 03:59 PM, Bram Moolenaar wrote:
> >> Charles Campbell wrote:
> >>
> >>> Looks like patch#592 stops netrw from working with remote files: vim
> >>> scp://hostname/ no longer works.
> >>
> >> What this patch does is that when ":e filename" is used when
Eliseo wrote:
> Hi, I'm the author of those commits.
>
> As I said to Christian, I try to send patches, or at least report, the
> important issues we find.
> I can't guarantee doing it always (for minor issues), though. For,
> frankly, as code diverges, it becomes more and more difficult to stat
Mike Williams wrote:
> In if_py_both.h there is code there is code that dereferences a pointer
> before checking if it is NULL. Attached patch against .622 fixes.
Thanks!
--
Some of the well known MS-Windows errors:
ETIME Wrong time, wait a little while
ECRASH
Hi Bram and Nice Vim developers,
2015/1/6(Tue) 4:58:27 UTC+9 Bram Moolenaar:
> Yasuhiro Matsumoto wrote:
>
> > bug.vim
> > ---
> > set nocompatible
> >
> > inoremap =ListMonths()
> >
> > func! ListMonths()
> > call complete(col('.'), ['January', 'February', 'March',
> >
On 02/07/2015 03:59 PM, Bram Moolenaar wrote:
>> Charles Campbell wrote:
>>
>>> Looks like patch#592 stops netrw from working with remote files: vim
>>> scp://hostname/ no longer works.
>>
>> What this patch does is that when ":e filename" is used when the
>> 'buftype' is not a file, it does no
One asterisk too many, compilable patch now attached.
Mike
--
Just when you thought you were winning the rat race, along comes a
faster rat.
--
--
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, v
Hi,
In if_py_both.h there is code there is code that dereferences a pointer
before checking if it is NULL. Attached patch against .622 fixes.
Mike
--
Just when you thought you were winning the rat race, along comes a
faster rat.
--
--
You received this message from the "vim_dev" maillist.
On 07/02/2015 18:00, James McCoy wrote:
On Sat, Feb 07, 2015 at 03:42:50PM +, Mike Williams wrote:
I have looked through the potentially uninitialised variables reported for
my usual Windows builds and they all look benign. It seems the compiler is
just spotting branches in the code where t
On Sat, Feb 07, 2015 at 12:26:46PM -0800, Toan Pham wrote:
>
>
> Hi, i am not sure if this is a bug; but when i use vim, and depending on the
> keyboard settings, i usually type the command below to exit.
>
> :wq!
>
> however, because of the keyboard settings, sometimes it will be entered as
>
19 matches
Mail list logo
