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
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
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
(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
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
---
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
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
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
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
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
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:
*
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
- 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
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
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
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
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
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,
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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
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
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)
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
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
36 matches
Mail list logo
