On 24/02/11 8:49 PM, Ulf Magnusson wrote:
Hi,
One problem with searching for phrases in files that contain wrapped
text (LaTeX source files, e-mails, source code comments, etc.) is that
you never know whether two words will be separated by a space or a
newline. Therefore, it would be handy to
Hello,
Please open a file1.
Open a file file2 in a new tab.
Use the File/Close menu to close file2 tab.
The tab is not closed, instead an empty buffer with name No Name
replaces file2.
So the File/Close menu is not a synonym for :close.
Is it a feature or a bug ?
I think it's a bug.
Zero reaction on this thread.
Any idea what was in it? Nothing was quoted.
Please think of desperate EasyVim users who never see search hit
BOTTOM, continuing at TOP when using the menu Edit/find then Next.
Please think of busy mailing list subscribers who don't find it easy to go back
On 10/03/11 9:20 AM, John Little wrote:
On Mar 9, 8:31 pm, Axelaxel.ben...@cip-kommunal.de wrote:
Entering :echow[tab] in 7.3 138 is giving me - instead of the first
option starting with w - the following wildmenu expansion:
[1] [No Name]
7.3.135, I get warn, which I imagine you should be.
On 9/03/11 6:39 PM, Christian J. Robinson wrote:
On Tue, 8 Mar 2011, Axel wrote:
Addendum:
The same happens for
:set all
The OS is Windows XP.
Does it still happen if you do :set nolazyredraw? A recent patch to fix
something else seems to have introduced this problem with 'lazyredraw'.
I would like to propose a patch which suppresses the conversion of
NL toCR when evaluaation ('\=') is used inside substitute()
function.
Simply this patch is what makes x == y true in the following code.
let x = substitute('a', '.', \n, )
let y = substitute('a', '.', '\=\n', )
Regardless
On 9/03/11 1:00 AM, Sebastian Humenda wrote:
Hello,
I would like to make a suggestion for the graphical Vim. When using
Orca, a screenreader for the graphical desktop, I can't use GVim.
Since the menu's and button's are written in GTK+, there are perfectly
usable, but not the main text body.
Dear Patrick,
Your comment is not clear to me.
Help says:
a options results in a word selected using Visual is automatically
yanked to the selection register (*).
It works.
With a suppressed, a Visual selected word is no longer yanked to
the selection buffer (*).
It works.
Now, I see no reason
On 18/03/11 8:38 PM, Philippe Vaucher wrote:
As long as the two triplets of keypresses I suggested originally can all
be represented uniquely, and without reference to timing information in
the Escape vs Alt+ case, then I'm happy with whatever internal
implementation makes it happen.
The two
On 23/03/11 3:21 AM, Kevin wrote:
Wanted to suggest adding support for terminal colors to gvim.
I want this, too, and it's on my to-do list to investigate implementing some
time.
That certainly shouldn't stop anyone else jumping in and doing it, though. No idea
when I might have enough time
On 31/03/11 3:51 PM, Mun wrote:
Hi,
My OS: Red Hat Enterprise Linux 5.6
My configure command:
configure --with-features=huge --enable-perlinterp --enable-pythoninterp
--enable-gui
I must apologize that I don't have too much to go on with this issue,
but I'll provide what I have and I will
Rather than reinventing the wheel, have you tried using the :options
command?
I don't think he meant *Vim* options. He's just wanting to present the
user with a menu of sorts, I think.
Ben.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the
So, what about executing
1000@@
as
@@999@@
(where in turn 999@@ is executed as
@@998@@
and so on ... and 2@@ as
@@1@@
and 1@@ as
@@
)?
I like the idea. Hadn't thought of using recursion when I wrote about
the issue earlier, but yes, of course, that's an obvious and simple way
to implement it.
So, what about executing
1000@@
as
@@999@@
(where in turn 999@@ is executed as
@@998@@
and so on ... and 2@@ as
@@1@@
and 1@@ as
@@
)?
I like the idea. Hadn't thought of using recursion when I wrote about
the issue earlier, but yes, of course, that's an obvious and simple way
to implement it.
On 10/04/11 11:51 PM, Ernie Rael wrote:
Could that change affect undo chunking?
I don't think so, but I could be wrong.
Ben.
--
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
On 16/04/11 12:45 AM, Paul LeoNerd Evans wrote:
Having recently dredged this topic up again - what is the current state
of plan? Are we happy we have a working model of how things will work
and are just awaiting time to write some code, or are there still
questions lingering about?
I think
as entered literally and in key
notation in the various places in which they could appear. Ben Schmidt
laid out several of those places in his response[4].
Actually, the specific paragraph you referenced in [4] is not a good
one. That was part of an argument I was building against a specific
For backward compatibility reasons, existing -notation should be
considered ambiguous, but we should come up with an extension of this
notation to be considered specific. Perhaps just adding an extra
character after the opening ''--for instance !Enter could mean
Enter, specifically. When
- It sounds like changing the internal Vim byte-stream representation for
keypresses to actually be CSI could be a good idea. By making careful use of the
private area we could ensure Vim can represent everything it needs to, plus
almost by definition it can represent all the keys/modifiers
APPROACH 2:
- -notation LHS defines specific and ambiguous maps
- C-M defines ^M and CSI-Ctrl-M
- Enter defines ^M and CSI-Enter
APPROACH 3:
- Ambiguous LHS defines ambiguous and specific maps
- ^M defines ^M, CSI-Ctrl-M and CSI-Enter
- -notation LHS defines specific and ambiguous maps
- C-M
If A3's not a showstopper, though, maybe the best next step would be
to start a test suite, to ensure things are working the way they're
supposed to work. Plus it gives a spec to shoot for. Things to
include would definitely be these sets:
Tab Ctrl-I Ctrl-Shift-I ^I
C-m Enter ^M
C-[ Esc
- Whatever byte-stream representation we land on, though, we would need
a more careful survey of what internal Vim things are needed, and a
sensible design for using the private area. That shouldn't be too hard
and probably doesn't need to involve the community too much.
What things
On 19/04/11 12:43 AM, Paul LeoNerd Evans wrote:
On Mon, Apr 18, 2011 at 12:11:01PM +1000, Ben Schmidt wrote:
- Ambiguous key triggers ambiguous map
- ^M triggers ^M
- Specific key triggers specific map, or ambiguous if none
- CSI-Ctrl-M triggers CSI-Ctrl-M or ^M
- CSI-Enter
On 21/04/11 10:10 AM, Ben Fritz wrote:
On Apr 19, 4:40 am, Yukihiro Nakadairayukihiro.nakada...@gmail.com
wrote:
When assigning or deleting list item no error raised for out-of-range index.
:let list = []
:let list[0] = 0
:echo list
[]
:let list = []
:unlet list[0]
I
Jason wrote:
There is no A record for the domain name vim.org. That is,
this link shouldn't work:
http://vim.org/
That's correct, actually. Not only doesn't it work, but it shouldn't
work. It is a shame people have abused DNS and expect it to work.
Marc wrote:
There have been lot's of
Perhaps the simplest thing is to get some cheap 'DNS hosting' that
offers a 'redirect' function. Basically the function just has a
server listen on port 80 for requests and return a 3xx (preferably
301 in our case) redirect (to http://www.vim.org/ in our case)
whenever it gets one.
I've taken
On 23/04/11 2:33 PM, Ben Schmidt wrote:
Perhaps the simplest thing is to get some cheap 'DNS hosting' that
offers a 'redirect' function. Basically the function just has a
server listen on port 80 for requests and return a 3xx (preferably
301 in our case) redirect (to http://www.vim.org/ in our
http://groups.google.com/group/vim_dev/browse_thread/thread/36b81acf60548c20
I pointed out that it is a simple DNS issue, and gave some
examples of Sourceforge sites that have chosen to add an
A record for the domain (vim.org for us) in their DNS.
...
216.34.181.97 vim.org
Turns out you're
On 23/04/11 6:29 PM, John Beckett wrote:
Ben Schmidt wrote:
Turns out you're right, John, though I couldn't find any
actual evidence in your mail or the thread you cited to prove it. :-)
However, this page does prove it:
http://sourceforge.net/apps/trac/sourceforge/wiki/Custom%20VHOSTs
On 3/05/11 1:04 PM, sc wrote:
On Monday, May 02, 2011 20:02:03 Jean-Rene David wrote:
Can someone reproduce this item from the todo list:
When 'lines' is 25 and 'scrolloff' is 12, j scrolls zero or
two lines instead of one. (Constantin Pan, 2010 Sep 10)
I can't. And I didn't find a
Well, what if I yank (in Firefox, say, or in Thunderbird) a multiline sentence
from the middle of a paragraph? As in the example below, I mean? With this
newfangled system, I won't be able to insert it in the middle of a different
paragraph in Vim, except by calling setreg('+', '', 'ac') to force
I love vim, but must admit to not being so fond of the fairly old
looking icon. I recently created a new logo for my own use, and
would be more than happy if you'd like to use it for an actual app
icon or logo.
I quite like the icon, too. I agree the old one (which in recent times, I've only
On 4/05/11 12:11 AM, Jean-Rene David wrote:
* Lech Lorens [2011.05.03 10:00]:
On 03-May-2011 Jean-Rene Davidjrdavid...@magma.ca wrote:
Can someone reproduce this item from the todo list:
When 'lines' is 25 and 'scrolloff' is 12, j scrolls zero or two lines
instead of one. (Constantin Pan,
Here is the version information:
...
+python/dyn +python3/dyn +quickfix +reltime +rightleft -ruby +scrollbind +signs
...
However, :echo has('python') returns 0.
Does the :python command work? If not, perhaps it can't find the python
library at runtime, as it's only dynamically linked.
Have
:python command doesn't work. It gives the following message:
OK. So you need to install Python where Vim can find it. :-)
See :help python-dynamic
Once Python is properly installed, Vim should find it on startup, and
:python should start working and has('python') should return 1.
Also note
I've recently been trying to write a 'foldtext' setting that is specific
to LaTeX and would include useful information like for a example the
caption information for a folded environment. But then I discovered that
the 'foldtext' setting is local to a window and not to a buffer, making
I've tried to look into the code to find the source of this behavior,
but eventually decided that trying to understand what it does would
take me too much time so I gave up.
I had a quick look, too, and haven't spotted the bug yet.
Note that your second example is a red herring:
a[aaa]a
On 14/05/11 10:27 PM, Ben Schmidt wrote:
I've tried to look into the code to find the source of this behavior,
but eventually decided that trying to understand what it does would
take me too much time so I gave up.
I had a quick look, too, and haven't spotted the bug yet.
I have tracked
On 15/05/11 9:07 PM, H Xu wrote:
On 05/10/2011 11:22 PM, Bram Moolenaar wrote:
[snips entire patch description including 150+ lines of patches]
Hello Bram,
[...]
Another winner for the worst quote trimming ever.
I have no idea what you even wrote in your other messages, because I
On 18/05/11 1:50 AM, Radek wrote:
Another strange behavior of syntax engine. Though it occurs only when
there's at least one syntax group with 'containedin=' attribute, it
affects even completely unrelated syntax items. As before, I feel that
an example will explain it best.
Found it. Not sure
The other question is whether a sizeable population works on camelcase
code and would like to have this solved :).
I would like to see a camelcase and/or underscore-seperation movement
commands. But I think if done, it has to be done really carefully so it
doesn't end up using obscure keys or
On 18/05/11 1:50 AM, Radek wrote:
Another strange behavior of syntax engine. Though it occurs only when
there's at least one syntax group with 'containedin=' attribute, it
affects even completely unrelated syntax items. As before, I feel that
an example will explain it best.
The patch below
[redirected from vim_use to vim_dev]
Good idea!
OK, I got confused. I think in vim.h FEAT_GUI should be defined even
when NO_X11_INCLUDES is defined. If there is some place where FEAT_GUI
causes trouble then add a check for NO_X11_INCLUDES there. That should
be a lot cleaner an avoids
Below is a message from vim_use where we've partially identified the
cause of some bug. Maybe there's a Windows dev here who has some more
ideas, or could reproduce it and track it down? I'm afraid I'm pretty
useless from here.
Smiles,
Ben.
On Thu, May 26, 2011 at 5:00 PM, Ben Schmidt
On 3/06/11 9:45 AM, Tony Mechelynck wrote:
On 02/06/11 23:27, Bram Moolenaar wrote:
ZyX wrote:
Is this expected:
try
throw 'Throw'
catch
echoe 'Echoe'
echom 'Echom'
endtry
will show only 'Echoe', but not 'Echom'? I though that «When used
inside a try conditional» refers only to the first
On 8/06/11 2:38 PM, Bram Moolenaar wrote:
fabian greffrath wrote:
Am 07.06.2011 05:40, schrieb Bram Moolenaar:
This tries to expand a file pattern starting with ~/, which won't work
when $HOME isn't set. However, it should not crash.
You say the shell chokes on the command, but how does
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 22 2011 13:03:19)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-142
Vim maintains the numbered registers 0-9. These are maintained
automatically by Vim.
I had a request for the YankRing plugin to also manage these registers
On 19/06/11 3:52 AM, Ian Liu Rodrigues wrote:
Dear list,
When I press ALT_C in GVim, it generates the character ã (a tilde).
This is problematic since I can't create an imap to ALT_C, for typing
ã will also trigger the mapping.
I'm interested in fixing this bug and providing a patch, but I've
On 21/06/11 12:13 AM, Paul LeoNerd Evans wrote:
On Sun, Jun 19, 2011 at 09:16:00PM +1000, Ben Schmidt wrote:
Yeah, this is a known limitation. We have planned out a roadmap to
fix it, but it is quite a large job, and I don't think anybody is
actually working on it yet. There are plenty
On 22/06/11 9:37 PM, Paul LeoNerd Evans wrote:
On Tue, Jun 21, 2011 at 10:45:57AM +1000, Ben Schmidt wrote:
I think as far as we got is a 'model' for how mappings should work.
Approach 4 built on all our discussions and clearly set out how mappings
should conceptually work. There were a number
On 26/06/11 11:15 AM, ZyX wrote:
Reply to message «Re: [BUG] `verbose set sw?' is not working in help buffer»,
sent 04:12:57 26 June 2011, Sunday
by Bram Moolenaar:
In help files the option values are set to sane values. Option values
set in the program don't have a verbose location.
If I
I extracted a couple of lines from regexp.c (143,144): (vim 7.3.244)
#define BRANCH 3 /* node Match this alternative, or the
* next... */
and put them in a file junk.c. Then
vim -u NONE -N --noplugin junk.c
:syn on
shows the comment-ending pair of characters, */, in error highlighting.
No
Does this have some documentation with it? How will anybody find out about it
if not?
Ben.
On 21/07/11 1:27 AM, Bram Moolenaar wrote:
Patch 7.3.258
Problem:MS-Windows: The edit with existing vim context menu entries can be
unwanted.
Solution: Let a registry entry disable
On 3/08/11 6:30 AM, Bram Moolenaar wrote:
Christian Brabandt wrote:
this patch fixes this issue from the todo list:
,
| 8 Add a command to jump to the next character highlighted with
| Error.
`
It implements the [e and ]e movement commands, which move to the
previous or next
Spencer Collyer wrote:
On Sun, 8 Feb 2009 20:40:09 -0800, Garrett Whelan wrote:
... Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043
Adding the ability to easily diff the recovered buffer
against the on-disk file (the action recommended to the user)
is a valid request.
I'm not proposing the following as a solution, but I will
mention that there is a related tip:
Hi, Matthew,
Have you managed to do any work on this to bring it up to date?
If not, I'll volunteer, as I love this functionality, and have noted a couple of
areas which need fixing/improving since the last patch I have.
Either way, could you send me the latest version of the patch? Or
Hi, Bram,
I'm getting back into doing some Vim coding, and mailing list
interaction and so on, and have come across this old patch (attached;
originally on vim_use).
The changes to ex_cmds.c are obsoleted by patch 7.2.082, but the change
to option.c is still relevant.
The problem is that when
FOUND IT!
Correct behaviour relies on a long overflowing, which it does on 32 bit
machines, but not on 64 bit machines.
From onepage(...) in move.c:
long n;
...
while (n = curwin-w_height loff.lnum = 1)
{
topline_back(loff);
n += loff.height;
}
if (n = curwin-w_height) /* at begin of file */
On 11/7/20 2:36 am, Tony Mechelynck wrote:
On Fri, Jul 10, 2020 at 5:00 PM Yegappan Lakshmanan wrote:
Hi Tony,
On Fri, Jul 10, 2020 at 7:37 AM Tony Mechelynck
wrote:
On Fri, Jul 10, 2020 at 3:41 AM Yegappan Lakshmanan wrote:
Hi all,
Is anyone able to successfully build GUI Vim on
201 - 260 din 260 matches
Mail list logo
