On Wed, Apr 24, 2013 at 03:52:26PM -0700, Chiel92 wrote:
> On Friday, January 25, 2013 3:36:21 AM UTC+1, Sung Pae wrote:
>
> > On Thu, Jan 24, 2013 at 08:45:45AM -0800, Chiel92 wrote:
> >
> > > Is there any progression on this subject? I'm currently writing a
On Fri, Apr 05, 2013 at 10:45:28AM +0200, Lech Lorens wrote:
> On 03-Apr-2013 Benjamin Fritz wrote:
>
> > I do just check in the file, without undoing the line ending
> > modifications. Where I work we're only really concerned that all
> > changes get peer reviewed. Plus, a good external diff too
, and I mailed a proposed solution in this thread:
https://groups.google.com/d/msg/vim_dev/UNuAJ_lKqng/XRPH6LN9vmQJ
Cheers.
Sung Pae
--
--
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
On Mon, Mar 25, 2013 at 10:14:48PM +0100, glts wrote:
> On Mon, Mar 25, 2013 at 2:08 AM, Sung Pae wrote:
>
> > Let's create a simple (and incomplete) custom motion: …
>
> Anyway, after another session in the debugger I came up with the
> slight amendment in the attach
On Sun, Mar 24, 2013 at 06:43:47PM +0100, glts wrote:
> On Sun, Mar 24, 2013 at 12:40 AM, Sung Pae wrote:
> > I see two issues on first glance:
> >
> > * Counts are not repeated; d2x (x being a custom motion) repeats as
> > dx only
>
> Yes, but this is
making them
> repeatable with the dot command.
Perhaps we will be able to convince Bram if the solution is clean and
unobtrusive.
Sung Pae
--
--
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
h `c`, then write current
line from current column to EOL. Failing test writes `one two`, passing
test writes `two`.
Thank you.
Sung Pae
diff --git a/src/search.c b/src/search.c
index 934e4b0..c8dd6da 100644
--- a/src/search.c
+++ b/src/search.c
@@ -727,7 +727,7 @@ searchit(win, buf, pos, dir, pa
On Sat, Mar 23, 2013 at 04:31:42AM -0500, Sung Pae wrote:
> On Tue, Mar 19, 2013 at 03:28:07PM +0100, Bram Moolenaar wrote:
> >
> > Patch 7.3.871
> > Problem:search('^$', 'c') does not use the empty match under the cursor.
> > Solution: Specia
case without affecting all other
searches with the 'c' flag.
Simple patch is attached.
Sung Pae
--
--
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.
On Tue, Mar 19, 2013 at 04:39:11PM -0700, Kana Natsuno wrote:
> On Wed, Mar 20, 2013 at 7:21 AM, Sung Pae wrote:
>
> > The motion mappings created by the above function work with both
> > native operators and with the custom operators provided by two other
> > plugins b
On Tue, Mar 19, 2013 at 05:21:42PM -0500, Sung Pae wrote:
> On Sun, Mar 17, 2013 at 05:08:29AM -0700, Kana Natsuno wrote:
>
> > Especially, the "solution" posted in the discussion
> >
> > https://github.com/tpope/vim-repeat/issues/8#issuecomment-13951082
> >
custom operators provided by two other plugins by
Tim Pope: vim-surround and vim-commentary. I don't know offhand if Tim
had to put in any extra work to make this possible, but I don't believe
so.
Sung Pae
¹ Not perfect. The `c` command is special cased for now and the final
On Fri, Mar 08, 2013 at 10:44:37PM +0100, Bram Moolenaar wrote:
>
> Sung Pae wrote:
>
> > On Fri, Jan 25, 2013 at 03:07:45AM -0600, Brian Lewis wrote:
> >
> > > After ":silent !", vim looks blank. I have to ^L or ":redraw!" to make
> > > i
On Fri, Jan 25, 2013 at 03:07:45AM -0600, Brian Lewis wrote:
> After ":silent !", vim looks blank. I have to ^L or ":redraw!" to make
> it look normal.
I decided I wanted to change this as well; simple patch is attached. It
appears that when do_shell() is called while msg_silent > 0, the screen
i
ves and restores both settings after the
'indentexpr' evaluation.
Thank you,
Sung Pae
From d3b2700ff6a115b1b90bab91188da24235c726ac Mon Sep 17 00:00:00 2001
From: guns
Date: Sat, 9 Feb 2013 12:43:37 -0600
Subject: [PATCH] Restore curswant settings after indentexpr evaluation
get_expr_inde
The documentation explicitly states that moving the cursor is okay in
an indentexpr, but this is only true when moved directly with cursor(),
setpos(), search(), etc. Moving the cursor via `normal! w` has side
effects that frustrate the attempts of get_expr_indent() to restore the
original cursor p
x file
instead of the ftplugin is problematic because the setting becomes local
to the buffer and not to the filetype, which will cause confusion if a
user changes filetypes for a buffer.
Do you think it is an acceptable compromise if I change the `syntax
keyword` definitions to `syntax match` an
inclusion into the Vim source tree so that
new Clojure users may have builtin support when editing Clojure (*.clj)
and ClojureScript (*.cljs) files.
I am eager to see Vim ship with Clojure support and am ready to answer
any questions about the implementation.
Thank you,
Sung Pae
¹ https
nd always by gw), which is used
primarily for editing prose, not code.
That said, I still stand behind my argument for switching 'formatprg' to
a buffer-local option and have been happily using it in my own build of
Vim without issue.
Sung Pae
--
--
You received this message from
p
search of multi-byte characters.
Failing test transforms:
j 0123❤x
into
j 023❤
instead of
j 012❤
Cheers,
Sung Pae
---
src/testdir/test44.in | 4
src/testdir/test44.ok | 1 +
2 files changed, 5 insertions(+)
diff --git a/src/testdir/test44.in b/src/testdir/test44.in
index
Fix case where searching backwards from a multibyte character on the
same line results in a wrong cursor offset. Given the buffer:
0123❤
With the cursor on the 3-byte UTF-8 character ❤ (U+2764), calling the
command
:call search('.', 'b')
places the cursor on "1" instead of "3". This is
On 9 Nov 2011, at 12:18 AM, lilydjwg wrote:
> Oops... I attach it now, and my vim handles mouse events well in
> urxvt+tmux.
Thank you.
I am curious though, does the mouse work correctly in urxvt+tmux when
`set ttymouse=urxvt`? That combination continues to be broken for me.
Otherwise, setting
On Wed, Oct 26, 2011 at 11:42:17PM +0800, lilydjwg wrote:
> Sorry my patch is wrong.
>
> After applied patch 343, when I enter Vim, the mouse is not recognized
> by vim. Setting 'ttymouse' to 'xterm' or 'xterm2' will enable it.
> Before the patch, I do not need to set 'ttymouse' to use mouse
> sup
ences to Autofmt [3], and questions about the proper use
of `formatexpr`.
It's clear many people are very comfortable with filtering text
through an external formatter, and many choose to set `filterprg` to a
language-specific tidy program. This is another compelling reason to
implement t
?
Cheers,
Sung Pae
--
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
other filterprg options (`equalprg`, `grepprg`,
`keywordprg`, and `makeprg`) are already global-local, so there is
precedent for this change.
More details in the patch header, following inline and as an attachment.
Cheers,
Sung Pae
[1]:
http://groups.google.com/group/vim_use/browse_thread/thread
clip_yank_selection, which calls str_to_reg in
turn.
I've been trying to reproduce the previously posted test results before
replying back to the thread (thanks again for the testing Gary); I think
now I'll go back and clean up this other patch and submit that instead.
Cheers,
Sung Pae
-
ince it allows very granular control of
the selection's motion type, but I surmised that it would be rejected
because it would change the behavior of all the OS versions, instead of
just one.
Also, this control is annoyingly incompatible with Firefox since it does
not seem to allow you to sel
ne, since it no
longer just looks at the last character to determine the motion type.
Cheers,
Sung Pae
---
runtime/doc/gui.txt |7 ---
runtime/doc/gui_x11.txt |5 +++--
src/gui_gtk_x11.c |4
src/gui_riscos.c|6 +-
src/ui.c| 12 +
Hi Gary,
Thank you very much for testing the patch. Here is what I have found:
> Test 1
>
> * Start Firefox (3.5.3).
> * Go to vim.sf.net.
> * Triple-click the Vim 7.3 release announcement.
I can confirm that triple-clicking on a line in Firefox 4 on my Arch
Linux box does not act
.
On the Mac, setting unnamedplus and enabling the native clipboard sync
is a disaster, because the sync annoyingly overwrites the contents of
the X CLIPBOARD with the same text but in the non-vim format. This is
a bug of the X11 server application on OS X, but it highlights this
particular incompatibility
Blockwise selections, of course, cannot be distinguished from linewise
selections after the selection is converted into compound_text, but that
seems like a small issue since most applications do not allow blockwise
selections.
Cheers,
Sung Pae
--
You received this message from the "vim_dev
UTO).
Since it is easy in most GUI programs to explicitly make linewise
selections (typically via triple-click), this small patch marks strings
requested from the X clipboard as MLINE if they end in a NL or CR
character.
This is a very cheap operation.
Cheers,
Sung Pae
---
src/ui.c |6
33 matches
Mail list logo
