Really sad news.
I admire his dedication to Vim, spending decades of his life improving it,
and his charity work.
Unquestionably his work benefited and improved a lot of people’s lives.
RIP Bram!
Nazri
On Sat, 5 Aug 2023 at 8:53 PM, Maxim Kim wrote:
> https://groups.google.com/g/vim_announce
On Thu, May 16, 2019 at 5:40 AM Vedanth Srinivasan wrote:
>
> Is there any way I can get a local history for a file in vim? I have already
> completed the file and am trying to see my changes at each point.
As Tony said, it's too late for that. For the future checkout :h
'undofile', which tells
On Thu, Feb 7, 2019 at 2:47 PM Ron Aaron wrote:
>
> The attached are ftplugin and syntax files for '8th', a Forth-derivative.
> I'm the maintainer.
> com! -nargs=+ Builtin syn keyword eighthBuiltin
You probably want to add "delcommand Builtin" somewhere near the end
of syntax/8th.vim.
nazri
On Thu, Jan 3, 2019 at 12:28 AM Bram Moolenaar wrote:
>
> + #ifdef FEAT_SYN_HL
> + int use_highlight = (items == (char_u **)features);
> + #endif
Perhaps this is better?:
-intuse_highlight = (items == (char_u **)features);
+intuse_highlig
On Thu, Nov 8, 2018 at 4:50 PM Tony Mechelynck
wrote:
>
> On Thu, Nov 8, 2018 at 6:22 AM Nazri Ramliy wrote:
> >
> > On Tue, Nov 6, 2018 at 3:26 AM Bram Moolenaar wrote:
> > > + static int
> > > + is_valid_mess_lang(char_u *lang)
> > > + {
>
On Tue, Nov 6, 2018 at 4:48 AM Bram Moolenaar wrote:
> There have been no new entries for a couple of days. I removed the
> remarks and discussions, items that can't be voted on.
> If you think something went missing, please ask the author of the item
> you commented on to edit his proposal.
>
>
On Tue, Nov 6, 2018 at 3:26 AM Bram Moolenaar wrote:
> + static int
> + is_valid_mess_lang(char_u *lang)
> + {
> + return lang != NULL && ASCII_ISALPHA(lang[0]) && ASCII_ISALPHA(lang[1]);
Any chance of segfault due to strlen(lang) < 1 here?
nazri
--
--
You received this message from t
On Sun, Oct 28, 2018 at 8:51 PM Bram Moolenaar
wrote:
> Vim has many features that plugin authors can use to achieve their goal. But
> what is still missing? What could be simplified? What is currently impossible?
>
> Please use one comment for each suggestion. Use the thumbs-up and thumbs-down
On Thu, Sep 13, 2018 at 5:16 AM Bram Moolenaar wrote:
> Patch 8.1.0374
> Problem:Moving the cursor is slow when 'relativenumber' is set.
> Solution: Only redraw the number column, not all lines.
This is great! Thanks!
Although one shouldn't get into the habit of holding down j/k keys to
mo
On Mon, Jul 9, 2018 at 8:33 PM, Konstantin Kharlamov
wrote:
> This behavior is hardcoded. You can only modify it and recompile
>
> Actually, I was about to report a bug, but discovered this request for an
> option.
>
> Could alignment be hardcoded to right? I really don't see a reason why would
>
On Sat, Jul 7, 2018 at 4:26 AM, Dominique Pellé
wrote:
> The attached patch "fix-user-name-compl-8.1.155.patch"
> should fix the bug. Can you try it?
It works! Thank you!
nazri
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you ar
On Fri, Jul 6, 2018 at 8:59 PM, Dominique Pellé
wrote:
>> Can you try interactively if happens when
>> typing the Ex command :e ~a
>> where is a single key for CTRL-A
>>
>> On which OS do you see the issue?
>> Is it reproducible with other user names?
>
> I made an experiment on my machine:
> :
On Fri, Jul 6, 2018 at 1:42 AM, Dominique Pellé
wrote:
>
> No, that is not what the test is doing. The \ expands
> all completions. So I would expect the test to pass if multiple
> usernames start with a letter.
Ah right, I didn't read the test carefully.
> On my machine, typing :e ~p I get
Hi,
The test Test_cmdline_complete_user_names() failed on my machine because it
assumes that the current username's first letter is unique, which not the case
on my machine:
if has('unix') && executable('whoami')
let whoami = systemlist('whoami')[0]
let first_letter = whoami[0]
if l
On Thu, Jun 28, 2018 at 3:22 AM, Bram Moolenaar wrote:
> At the moment, yes. We might include more in the default distribution
> in the future, since computers are bigger and faster now. We dropped
> the "has to fit on a floppy" rule long ago, don't know what today's rule
> would be.
How does "
On Sun, Nov 12, 2017 at 8:34 PM, Tony Mechelynck
wrote:
> The way I see it, there was a bug before (which you used as an
> undocumented feature), now the bug has been fixed, and you're
> complaining. The way your pattern is written, it _ought_ to match
> everywhere, though in the case of its last
Hi,
With 'hlsearch' set, typing '/foo\|' highlights everything, presumably
because of the empty branch following the '\|', which is kinda
annoying.
This seems to be a new behavior, because I don't remember vim behaving
this way. I don't know when it starts behaving like this but it surely
don't i
On Sat, Aug 5, 2017 at 5:49 PM, mattn wrote:
> Commit Summary
>
> support 10terminal to make terminal rows 10
Wouldn't it be better if the number range before the :terminal command
is interpreted as the range of lines to be fed to the stdin of the
command to be run?
For example when editing a sh
With 'number' / 'relativenumber' set, the coloring of the finished
terminal is not done correctly:
https://asciinema.org/a/1mAcCnu9hmnVbZ57txlaHEluz
Also there seem to be a little delay (as can be seen in the asciinema
link) between exiting the shell and vim realizing that the shell has
exited.
n
On Wed, Jul 26, 2017 at 11:03 PM, Ozaki Kiichi wrote:
> I propose this patch:
>
> https://gist.github.com/ichizok/9dafd126bb6f6d5f79878a18f5665e6f
>
Thank you for figuring this out!
nazri.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the
On Wed, Jul 26, 2017 at 9:21 PM, Nazri Ramliy wrote:
>
> I tried this twice - first with neovim, and then later with vim,
> running the same command in the terminal window (date, followed by
> exit).
Here are two movies (grab some popcorn!) that shows the invisible
cursor in vim, and
On Wed, Jul 26, 2017 at 6:37 PM, Bram Moolenaar wrote:
>
> Try using this: :term script bash
> (or whatever your shell is called).
>
> Then do "ls" or something and exit. Then the "bash" file should contain
> exactly what was sent from the shell to the terminal.
>
> For me, there is no special
On Wed, Jul 26, 2017 at 8:51 AM, Nazri Ramliy wrote:
>
> Changing TERM=xterm results in invisible cursor:
Clarification: it's not that the cursor is completely invisible. It is
similar to what Marius reported in that for my case this is what I see
when opening :terminal:
1. I see ne
On Wed, Jul 26, 2017 at 3:35 AM, Bram Moolenaar wrote:
>
> I'm using a real xterm and don't see this problem.
> I don't have a blinking cursor, perhaps that is related?
Looks like it's not related.
Running xterm with cursor blinking enabled and disabled works fine
when TERM=ansi:
# Without blin
On Tue, Jul 25, 2017 at 10:10 AM, Nazri Ramliy wrote:
> Cursor visible:
>
> TERM=ansi vi -u NONE -U NONE -c :terminal
>
> Cursor not visible:
>
> TERM=xterm vi -u NONE -U NONE -c :terminal
Sorry I forgot to include the details:
$ uname -a
Linux bear 3.13.0-125-generic #174-
Hi,
Cursor visible:
TERM=ansi vi -u NONE -U NONE -c :terminal
Cursor not visible:
TERM=xterm vi -u NONE -U NONE -c :terminal
help?
nazri
--
--
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
On Sat, 22 Jul 2017 at 11:37 AM, Akria Sheng wrote:
> When vim diff, it will always write buffer to a temp file.
> But if the file is very huge, for example tens of giga bytes
>
I'm curious what kind of file is this, a database dump?
Nazri
>
--
--
You received this message from the "vim_dev
On Fri, Jul 7, 2017 at 6:23 PM, Bram Moolenaar wrote:
>
> Patch 8.0.0694
> Problem:Building in shadow directory does not work. Running Vim fails.
> Solution: Add the new libvterm directory. Add missing change in command
> list.
I'm getting this error when building:
libvterm/s
On Fri, Jul 7, 2017 at 6:09 PM, Nazri Ramliy wrote:
> Did you forget to include the result of "make cmdidxs"?
>
> My vim installation is now in chicken-and-egg state:
>
> $ vim
> E943: Command table needs to be updated, run 'make cmdidxs'
> $
On Fri, Jul 7, 2017 at 5:54 PM, Bram Moolenaar wrote:
>
> Patch 8.0.0693
> Problem:No terminal emulator support. Cannot properly run commands in the
> GUI. Cannot run a job interactively with an ssh connection.
> Solution: Very early implementation of the :terminal command. In
On Mon, Oct 10, 2016 at 6:29 PM, JohnBeckett wrote:
> On Monday, October 10, 2016 at 6:19:35 PM UTC+11, Nazri wrote:
>> So in order to get what can be done with JJ, I have to hit 3J
>> instead, which feels weird.
>
> I noticed that recently. However, ":help J" says "Join [count] lines, with a
> m
Is this a bug?
$ cat a.txt
a
b
c
d
$ vim -u NONE -U NONE a.txt
With cursor is on the first line, hitting J twice results in this
(works as expected - we're joining twice):
a b c
d
But doing 2J only gives this:
a b
c
d
So in order to get what can be done with JJ, I have to hit 3J instead,
whic
On Sat, May 7, 2016 at 5:45 AM, Dominique Pellé
wrote:>
> I get an error when I clone submodules. Any idea?
[snip]
> Warning: Permanently added the RSA host key for IP address
> '192.30.252.122' to the list of known hosts.
> Permission denied (publickey).
> fatal: Could not read from remote reposi
On Wed, Aug 12, 2015 at 6:51 AM, Markus Heidelberg > #!/bin/sh
> # Vim HG repository cleanup
>
> hg config extensions.rebase || (echo -e "Rebase extension has to be enabled
> in ~/.hgrc:\n[extensions]\nrebase =" && exit 1)
The "exit 1" above won't exit the shell script - it exits only the
subshel
On Sat, Jul 4, 2015 at 9:23 PM, Bram Moolenaar wrote:
>
> When running the tests the terminal produces beeps.
> Usually this is caused by the test script having a line break,
> which is the command to move to the next line.
> If there is no next line Vim beeps.
>
> It would be nice if someone can
On Sun, Apr 12, 2015 at 6:50 AM, Yuri wrote:
> Since tolerance to non-terminal is something that obviously only a very tiny
> fraction of users needs, I made this patch that makes such tolerance a
> non-default behavior. New command line option --allow-non-term enables the
> old behavior.
This wi
On Fri, Mar 13, 2015 at 3:58 AM, Christian Brabandt wrote:
> Also further testing shows, this seems only to happen, as long as the
> number column is smaller than the showbreak chars. I can't explain that.
I think it happens if the following conditions are true:
1. The line is long such that it
On Sun, Mar 8, 2015 at 4:59 AM, Christian Brabandt wrote:
> This only happens in vi mode (or more specifically, when cpo contains
> the 'n' flag). Looks like Vim gets confused, because the first visible
> screen line already shows the sbr string and that is not expected for a
> screen row, that co
Hi,
:ver
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 7 2015 10:48:00)
Included patches: 1-657
Here's a reproducible steps (it assumes that the environment variables
$LINES and $COLUMNS are set to the rows and columns of your terminal):
$ { echo -n " a = "; for i in `seq 1 $LINES`; do for
On Wed, Nov 26, 2014 at 3:36 PM, Christian Brabandt wrote:
> Sorry, I missed one part. Please check again.
Looks good :)
Thanks for looking into this.
nazri.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For
On Wed, Nov 26, 2014 at 5:13 AM, Christian Brabandt wrote:
> That bug you reported actually is the same, just that the mentioned
> patch does not fix it for your situation. (since I forgot to reset the
> linebreak for the couple of times, where the screen is redrawn. That
> should be fixed with th
On Tue, Nov 25, 2014 at 2:33 PM, Christian Brabandt wrote:
> Am 2014-11-25 02:58, schrieb Nazri Ramliy:
> Isn't that the same bug, you reported last week at
> https://groups.google.com/d/msg/vim_dev/qORtSGBSnkc/o3pMwJ1Z1A4J
> (Bug 2)?
No I don't think it's the same
Here's how to reproduce in a 120 columns, 69 rows terminal:
foo.txt:
--8<--
:= []..{
...(
`{"hello":".","..":{"..":{":.":"",":.":"..",":":"","":.,""
On Tue, Nov 18, 2014 at 3:42 AM, Christian Brabandt wrote:
> On Mo, 17 Nov 2014, Nazri Ramliy wrote:
>
>> Bug 1: Notice that the relative numbers above the current cursor is no
>> longer correct.
>
> Attached patch should fix it.
Yes it does.
>> Bug 2: Now type one
On Tue, Nov 18, 2014 at 5:46 AM, Christian Brabandt wrote:
> Can you check, if this patch works for you?
>
> diff --git a/src/screen.c b/src/screen.c
> --- a/src/screen.c
> +++ b/src/screen.c
> @@ -4456,6 +4456,9 @@ win_line(wp, lnum, startrow, endrow, noc
> /* TODO: is passing
Steps to reproduce (in a 120 columns by 84 rows terminal):
$ echo $COLUMNS $LINES
74 120
$ {
for i in `seq 1 8`; do printf 'lorem ipsum '; done
echo
for i in `seq 1 4`; do
for i in `seq 1 60`; do printf ' '; done
for i in `seq 1 8`; do printf 'lorem ipsum '; done
echo
done
for i in
On Sat, Nov 15, 2014 at 11:41 AM, Nazri Ramliy wrote:
> $ cat bug.vim
> set nocp
> set breakindent
> set linebreak
> set nu
> " Setting rnu also triggers the bug
I forgot one more detail: The bug will not be triggerred if the "}"
characters are substituted with
On Sat, Nov 15, 2014 at 11:41 AM, Nazri Ramliy wrote:
> $ echo $COLUMNS $LINES
> 10 65
Sorry that 10 should really be 120.
nazri
--
--
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 informa
On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar wrote:
> Although removing arbitrary limits is good, making 'runtimepath' very
> long is a bad idea. Every time Vim searches for a runtime file it will
> visit those directories and request the contents.
Hmmm it seems that ex_cmds2.c:do_in_runtimep
On Wed, Sep 10, 2014 at 11:58 PM, 0xBADDCAFE wrote:
> Nowadays modern plugin managers add many runtimepath that contain scripts.
> These path strings can be over 1024 bytes easily.
Perhaps a new option would be better, 'runtimedir' - all directory found in
there are regarded as individual runtime
Hi,
Attached is a patch that adds a failing test that should show the
buggy behavior on the following text:
-- 8< --
+REMOVE: This text must not be deleted
+REMOVE: aaa...repeat until linebreak kicks in...aaa
+-- >8 --
With linebreak set and doing a character-wise visual selectio
Here's how to reproduce it in an 80-column terminal:
$ vi --version|head -2
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 27 2014 13:10:11)
Included patches: 1-417
$ echo $COLUMNS
80
$ vi -u NONE -U NONE -c 'exec "normal 6i\\31Aa\A a"' -c
'set breakindent showbreak=\> ' -c 'normal ^'
The curso
On Fri, Jun 27, 2014 at 2:05 PM, Christian Brabandt wrote:
> Hm, from a quick look at the problem, it seems that the real problem is
> that scrollbinded windows try to synchronize changes and therefore
> depending on the diff state might scroll another window by more than 1
> line.
>
> In your cas
On Wed, Jun 25, 2014 at 5:49 PM, Bram Moolenaar wrote:
> The filler lines are needed to keep the windows in sync. If you disable
> filler lines they cannot always be in sync. Not a bug.
I think it is a bug :)
The behavior of "vimdiff -u NONE -c 'set diffopt-=filler' -c $ a b" is
inconsistent
d
Hi,
I'm attaching the files (a and b) that produces this bug on my system
with the terminal height set to 15 lines:
$ echo $LINES
15
$ vimdiff -u NONE -c 'set diffopt-=filler' -c $ a b
See that the lines drawn in both windows are out of sync - they
aren't drawn in the same rows.
":windo
On Thu, May 29, 2014 at 5:52 PM, Dhruva Sagar wrote:
> But surely this should be supported natively, doesn't sound like it would
> require huge change, would anyone be able to throw some light into why this
> is the case ?
A made a toy patch about 4 years ago for this[1], based on the
completio
On Tue, May 13, 2014 at 7:52 PM, Bram Moolenaar wrote:
> SRC_ALL = \
> + .hgignore \
Perhaps .hgignore is better added as hgignore (without the leading dot)? This is
similar to the practice of committing "config.conf.sample" to a repository which
is meant to be copied to "conf
On Thu, Dec 12, 2013 at 2:04 AM, William Gardner wrote:
> I've got an autocommand that triggers on TextChanged and does some processing
> (removing
> trailing whitespace) on the just-modified lines, which it finds via the '[
> and '] marks.
Thanks for the idea for improving my vimrc :)
I'll su
On Thu, Nov 14, 2013 at 10:07 AM, Nazri Ramliy wrote:
> On Thu, Nov 14, 2013 at 9:28 AM, Nazri Ramliy wrote:
>> I can reproduce the bug using example.vim above, and multiple times in
>> the same terminal window.
>
> Versions:
>
> $ xterm -version
> XTerm(278)
&g
On Thu, Nov 14, 2013 at 9:28 AM, Nazri Ramliy wrote:
> I can reproduce the bug using example.vim above, and multiple times in
> the same terminal window.
Versions:
$ xterm -version
XTerm(278)
:ver
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 14 2013 08:14:53)
Included patc
On Thu, Nov 14, 2013 at 12:24 AM, Patrick Brisbin wrote:
> Here's a new truly minimal case, which can indeed be triggered with vim
> -u example.vim:
>
> " example.vim
> set nocompatible
>
> function RegenerateCtags()
> silent! execute '!true'
> endfunction
>
> autocmd BufEnter * call
On Sat, Aug 3, 2013 at 8:11 PM, Bram Moolenaar wrote:
> + /* Change NUL into SOH, otherwise the string is truncated. */
> + for (i = 0; i < len; ++i)
> + if (buffer[len] == NUL)
> + buffer[len] = 1;
The loop above doesn't look right to. Shouldn't it be like thi
Hi,
If I were you I'd try reducing the vimrc a'la binary search.
Just a suggestion.
Nazri
--
--
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 rec
On Mon, Jun 10, 2013 at 3:12 AM, dag.odenh...@gmail.com
wrote:
> In any case it would be killer for me if :lcd used 'cdpath' for
> completions!
I sent a toy patch to do this about 3 years ago:
https://groups.google.com/forum/?fromgroups#!msg/vim_dev/uKsDbqUhr4w/TEXZEDMySdQJ
It shouldn't be too
On Thu, May 30, 2013 at 3:07 PM, Christian Brabandt wrote:
> Forwarding to vim-dev
>
> On Mi, 29 Mai 2013, Ben Fritz wrote:
>
>> I like the proposal by "glts" myself:
>>
>> > - ":set nonu nornu" means: I don't want any line numbers;
>> > - ":set nu nornu" means: I want to see only absolute numbers
On Wed, Feb 6, 2013 at 11:06 PM, Bram Moolenaar wrote:
> No, I don't want to remove or deprecate existing options. It's very
> annoying for people who get a new Vim version, especially if they didn't
> install it themselves.
>
> I'm not sure the whole 'linenumber' option thing is the right way to
On Thu, Apr 18, 2013 at 10:11 PM, Nazri Ramliy wrote:
> Thanks for the notice. I'll look into this again. My initial approach at
> solving this was to replace all backslashes in the expanded path parts
> into forward slashes but that seemed a bit too blankety of a solution
On Thu, Apr 18, 2013 at 9:06 PM, Ingo Karkat wrote:
> Please note that for the root directory, C:\ is different than C: (which
> means the current working directory of the C drive), so leaving off the
> trailing path separator may cause problems in this case. (I haven't
> checked your patch, but :
On Tue, Apr 16, 2013 at 4:31 PM, Nazri Ramliy wrote:
> I can reproduce this with my gvim 7.3.46 (on linux vim 7.3.892 there's> no
> problem). I'll investigate and hopefully post a fix soon.
I found the problem and the solution.
Problem summary:
expand_path_option() l
On Mon, Apr 15, 2013 at 6:56 PM, Suresh Govindachar
wrote:
> My c:\opt is not below the pwd. Anyway, for the test,
> leave path at the default value of ".,,".
>
> > :pwd
> > D:\foo
>
> When starting from d:, :pwd will show d:\
>
> > Now doing
>
> In gvim, open file
On Mon, Apr 15, 2013 at 1:56 PM, Nazri Ramliy wrote:
> Is there anything different in my settings here that might not show the
> problem that you're seeing?
>
I forgot to add my vim version (it's older than yours):
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 1
On Mon, Apr 15, 2013 at 1:56 PM, Nazri Ramliy wrote:
> 15/04/2013 01:32 PM11 700_vimrc
> 15/04/2013 01:33 PM10 fish.txt
> 15/04/2013 01:33 PM12 fish.txt
>
One of those fishes should really be a finger.txt ;)
nazri
--
--
Hi Suresh!
On Mon, Apr 15, 2013 at 10:22 AM, Suresh Govindachar
wrote:
> Hitting after entering a partial argument to :find will offer
> suggestions for completing the command line by searching inside
> non-trivial components of the 'path' -- but it does not search in "."
> and in ",," component
On Fri, Apr 12, 2013 at 9:48 AM, Yegappan Lakshmanan wrote:
> 1. Open an empty buffer
> 2. Enter insert mode using 'i'
> 3. Insert 262040 characters using =repeat('a', 262040)
> 4. Press
> 5. Select and yank all the characters using 'V' and 'y'
> 6. Wait for a few seconds and move the cursor
>
>
On Mon, Apr 1, 2013 at 11:16 PM, Lech Lorens wrote:
> The problem is that if Vim reads such a file with ff=unix, it will fail
> to find tags if the tag pattern searched should match on a DOS-style
> line. The attached patch handles the problem in a naïve but surprisingly
> effective way: if a patt
On Fri, Feb 22, 2013 at 10:00 PM, Roland Eggner
wrote:
> On 2013-02-20 Wednesday at 16:48 +0100 Bram Moolenaar wrote:
>>
>> Patch 7.3.826
>> Problem:List of features in :version output is hard to read.
>> Solution: Make columns. (Nazri Ramliy)
>> Files:
On Fri, Feb 22, 2013 at 10:00 PM, Roland Eggner
wrote:
> On 2013-02-20 Wednesday at 16:48 +0100 Bram Moolenaar wrote:
> On wide terminals the feature list in :version message is interrupted by empty
> lines, observed with e.g. COLUMNS=320. Bugfix attached.
Maybe it's better if we limit the featu
On Wed, Feb 20, 2013 at 7:34 PM, Bram Moolenaar wrote:
> Thanks, this defenitely looks better. It takes more space on screen,
> but that's not really a problem.
>
> The for loop is a bit strange. Instead of using sprintf() it's simpler
> to make a loop that outputs the filler spaces. And not do
Hi,
My eyes hurts everytime I had to hunt for a specific feature in the
listing shown by :version.
Attached patch formats the feature list shown by :version into a more
readable, columnar style. It's the same style used for listing a
book's index - it's easier to scan as the items are sorted top
Hi,
It seems like the colorcolumn highlighting has higher priority than
hlsearch, which I think it shouldn't, as it defeats the purpose of
highlighting the matched search pattern. To reproduce:
$ (echo 12345678; echo 5678)|vim -u NONE -U NONE -c 'set cc=5,8
hlsearch' -c 'let @/ = "5678"' -
Expec
This is a reply of an almost 3-year old thread (but still relevant :)
On Fri, Jul 30, 2010 at 4:19 AM, Bram Moolenaar wrote:
> Nazri Ramliy wrote:
>> What if we had some helper command that dumps how the
>> current screen look like so that it can be compared with
>> so
Hi!
I'm fooling around with gcov[1] at $dayjob and I think vim would
benefit from it too. Attached is a patch to produce both gcov
(text-only) and lcov (html) reports from vim's test suite.
You may need to install lcov. gcov should come preinstalled with gcc.
After applying the patch, do the fol
On Wed, Feb 6, 2013 at 2:58 AM, Ben Fritz wrote:
> For example:
>
> :set number
> :set relativenumber
> :set linenumber=number
> :set number? relativenumber? linenumber?
> number norelativenumber linenumber=number
Yes, this is what the patch does. See the set_line_number_style() in
the patch.
On Tue, Feb 5, 2013 at 5:11 PM, Nazri Ramliy wrote:
> Attached is an updated patch for the 'linenumber' option (it's getting
> hairier and hairier! But not that much. I'd say it's less toy-ish by
> now :)
>
> It contains a bugfix - "set (inv|no)(nu|
Attached is an updated patch for the 'linenumber' option (it's getting
hairier and hairier! But not that much. I'd say it's less toy-ish by
now :)
It contains a bugfix - "set (inv|no)(nu|rnu)" did not correctly set
'linenumber' as well.
Earlier in the thread someone complained about the alignment
On Fri, Feb 1, 2013 at 7:18 PM, Nazri Ramliy wrote:
> The patch do not include Christian's fix for the problem
> reported by François Ingelrest.
Attached is the updated (and less buggy) toy patch that include
Christian's fix and test89, and also test90 for testing the
new op
On Fri, Feb 1, 2013 at 8:42 AM, Charles E Campbell
wrote:
> When some users of some simulation s/w I helped write have a problem, I
> usually end up with 10-150G long debugging traces; I usually break these up
> into 1G chunks and "edit" (more usually, examine) these. So I often end up
> with fil
On Tue, Jan 29, 2013 at 10:51 PM, Nazri Ramliy wrote:
> For better distinction the current line number ca be left-aligned
> (for left-to-right text orientation) to make it look different than the
> relative-line-numbers (I made no attempt at this in the patch below).
Here's a
On Tue, Jan 29, 2013 at 6:21 PM, Paul Ruane wrote:
> Whilst it is not that hard to scan the status line, I find that I hit
> this glitch in my workflow many, many times a day: when I want to know
> what line I am on, I intuitively scan the gutter for the line number.
> I then realise that relative
On Wed, Nov 14, 2012 at 5:30 PM, Mostafa Shahverdy wrote:
> How can I find a good overall structural documentation of vim codebase?
>
A good place to start is the data structures. Read src/structs.h.
nazri
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your rep
On Tue, Jun 19, 2012 at 3:42 PM, Clark WANG wrote:
> My vim settings: wildignore=*.o,*.so wildmode=longest,list,full
>
> On my system (Solaris 11, x86) I have a dir (named foo) under which there're
> about 200 files (the foo dir itself is part of a big project which has many
> dirs and files). E
On Mon, Apr 9, 2012 at 9:36 AM, David Pope wrote:
> 1. Build vim in the src directory with 'nmake -f Make_mvc.mak FEATURES=HUGE
> MBYTE=yes'
> 2. Run tests in the testdir directory with 'nmake -f Make_dos.mak clean',
> followed by 'nmake -f Make_dos.mak'.
>
> Nazri, can you check that those three
On Wed, Apr 4, 2012 at 1:36 PM, David Pope wrote:
> These three tests output in ff=unix, either explicitly (test 60) or
> implicitly (tests 71, 74), so the diff fails. Do they run without
> modifications for you?
Initially I ran "nmake -f Make_mvc.mak test" in the src directory
and only test50 f
On Mon, Apr 2, 2012 at 9:04 AM, David Pope wrote:
> It's not working right. When troubleshooting I found this note at the end
> of editing.txt:
>
> Note that completion for ":find", ":sfind", and ":tabfind" commands do
> not
> currently work with 'path' items that contain a url or use the
On Wed, Feb 8, 2012 at 12:06 PM, Nazri Ramliy wrote:
>> But strangely:
>>
>> $ cd $HOME
>> $ mkdir -p 'tmp/**/xxx/yyy'
>> $ cd 'tmp/**'
>> $ vim -u NONE
>> :cd xxx <-- gives error???
Ah sorry for the noise. The problems exi
On Wed, Feb 8, 2012 at 11:59 AM, Nazri Ramliy wrote:
> On Wed, Feb 8, 2012 at 11:50 AM, Nazri Ramliy wrote:
>> On Wed, Feb 8, 2012 at 9:59 AM, Nazri Ramliy wrote:
>>> I'd like to report that the behavior does not exist outside of $HOME:
>>
>> One more deta
On Wed, Feb 8, 2012 at 11:50 AM, Nazri Ramliy wrote:
> On Wed, Feb 8, 2012 at 9:59 AM, Nazri Ramliy wrote:
>> I'd like to report that the behavior does not exist outside of $HOME:
>
> One more detail:
>
> The bug is triggered only when '**' is right under $H
On Wed, Feb 8, 2012 at 9:59 AM, Nazri Ramliy wrote:
> I'd like to report that the behavior does not exist outside of $HOME:
One more detail:
The bug is triggered only when '**' is right under $HOME.
It does not appear for this case:
cd $HOME
$ mkdir -p 'a/**/xxx/yyy
On Mon, Feb 6, 2012 at 5:18 AM, Bram Moolenaar wrote:
> We have had quite a few bugs in the find_file_in_path() code.
> Now the problem is that when the current directory path contains "**"
> then ":cd" fails, because it tries to expand "**" instead of taking in
> literally.
[challenge snipped]
I love the fact that I can get the content of vim's search register
from any terminal.
Currently this is doable for nongui-vim with proper setting of the
--servername option and querying it like this:
$ vim --servername foo --remote-expr @/
On the gui version the servername is set automatically
1 - 100 din 172 matches
Mail list logo
