Re: cpo-=l
On Wed, Oct 19, 2011 at 07:56:14AM -0700, Ben Fritz wrote: On Oct 19, 9:53 am, Ben Fritz fritzophre...@gmail.com wrote: But the encoding options should be respected and accounted for, not modified to suit a script's needs (well, 'fenc' should certainly be modified if needed for a script's buffers, and 'fencs' can be modified temporarily to force detection of a certain 'fenc', but I cannot think of other reasons to mess with these). So maybe, certain options should not be settable via setscript? 'encoding' certainly. I lobbied a while back[0] to not allow setting of 'encoding' at all by the user. All they should really care about is 'fenc' and 'tenc'. If I remember right, the problem with always using an encoding of Unicode for 'encoding' was due to supporting 16-bit platforms. [0]: http://article.gmane.org/gmane.editors.vim.devel/22998 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: GtkFileChooser broken again
On Fri, Sep 23, 2011 at 08:31:00AM -0700, acampbell wrote:
This sounds rather like what I am experiencing, tbough not identical.
I am using vim-7.3 in xmonad. If I start gvim from a terminal it locks
up, and I get these messages:
E852: The child process failed to start the GUI
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has
not been called
[xcb] Aborting, sorry about that.
gvim: ../../src/xcb_io.c:273: poll_for_event: Assertion
`!xcb_xlib_threads_sequence_lost' failed.
The fact that you're getting E852 means you have Tim's patch applied. I
saw some similar crashes on one of my systems and the attached patch
seems to fix the problem. Can you see if it also fixes the problem for
you?
I'm not entirely sure why switching from fread/fwrite to normal
read/write fixes it, especially since I don't see the problem on all of
my systems. I have a feeling it's related to the lseek that the fdopen
does on the pipe fd (which causes a SIGPIPE), though.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
diff --git a/src/gui.c b/src/gui.c
--- a/src/gui.c
+++ b/src/gui.c
@@ -212,7 +212,6 @@
int status;
int exit_status;
pid_t pid = -1;
-FILE *parent_file;
/* Setup a pipe between the child and the parent, so that the parent
* knows when the child has done the setsid() call and is allowed to
@@ -290,19 +289,17 @@
gui_mch_forked();
# endif
-if (!pipe_error)
- parent_file = fdopen(pipefd[1], w);
-else
- parent_file = NULL;
-
/* Try to start the GUI */
gui_attempt_start();
/* Notify the parent */
-if (parent_file != NULL)
+if (!pipe_error)
{
- fputs(gui.in_use ? ok : fail, parent_file);
- fclose(parent_file);
+ if (gui.in_use)
+ write_eintr(pipefd[1], ok, 3);
+ else
+ write_eintr(pipefd[1], fail, 5);
+ close(pipefd[1]);
}
/* If we failed to start the GUI, exit now. */
@@ -323,17 +320,19 @@
static int
gui_read_child_pipe(int fd)
{
-size_t bytes_read;
-FILE *file;
-char buffer[10];
-
-file = fdopen(fd, r);
-if (!file)
+ssize_t bytes_read;
+#define READ_BUFFER_SIZE 10
+char buffer[READ_BUFFER_SIZE];
+
+bytes_read = read_eintr(fd, buffer, READ_BUFFER_SIZE-1);
+#undef READ_BUFFER_SIZE
+if (bytes_read == -1)
+{
+ close(fd);
return GUI_CHILD_IO_ERROR;
-
-bytes_read = fread(buffer, sizeof(char), sizeof(buffer)-1, file);
+}
buffer[bytes_read] = '\0';
-fclose(file);
+close(fd);
if (strcmp(buffer, ok) == 0)
return GUI_CHILD_OK;
return GUI_CHILD_FAILED;
signature.asc
Description: Digital signature
[patch] Correct completion for :compiler command
Hi all,
Since patch 7.3.237, completion for the :compiler command has been
completing colorschemes instead. Attached patch fixes this.
Thanks,
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
--
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
diff --git a/src/ex_getln.c b/src/ex_getln.c
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -4546,7 +4546,7 @@
}
if (xp-xp_context == EXPAND_COMPILER)
{
- char *directories[] = {colors, NULL};
+ char *directories[] = {compiler, NULL};
return ExpandRTDir(pat, num_file, file, directories);
}
if (xp-xp_context == EXPAND_OWNSYNTAX)
[patch] Honor 'switchbuf's newtab with :sb commands
Hi all, According to 'switchbuf's help, it's supposed to be honored for :sb and other buffer related split commands. The documentation is worded a little odd in that it only mentions this for the useopen (and transitively usetab) but not split nor newtab. The code, on the other hand, does honor split and, with the attached patch, will also honor newtab for :sb-type commands. This seems to follow the intent of the feature. Thanks, -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 diff --git a/src/buffer.c b/src/buffer.c --- a/src/buffer.c +++ b/src/buffer.c @@ -1262,7 +1262,11 @@ * page containing buf if one exists */ if ((swb_flags SWB_USETAB) buf_jump_open_tab(buf)) return OK; - if (win_split(0, 0) == FAIL) + /* If 'switchbuf' contains newtab: open new tab page instead of a new + * window */ + if (swb_flags SWB_NEWTAB) + tabpage_new(); + else if (win_split(0, 0) == FAIL) # endif return FAIL; }
Re: Windows scriptin and user input
On Tue, Sep 20, 2011 at 03:50:35AM -0700, Ross Beehler wrote: I'm pretty sure I've found a bug with vim for Windows that I posted to vim_use: http://groups.google.com/group/vim_use/browse_thread/thread/7aae3ec049abb5b5# I haven't been able to reproduce this on the Windows systems I have access to. Can you provide the output of :version? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Any way to just not display ^M characters ?
On Mon, Sep 19, 2011 at 02:42:08AM -0700, Ron Aaron wrote: Therefore I wonder if there is at least some way to just not display the trailing ^M, since it is visual noise for the most part and doesn't cause any other tools we use any problems. Sounds like a use for the conceal feature that was introduced in 7.3. Something like :syn match mixedLineEndings $ conceal :set conceallevel=3 Although, this will only hide the ^M on lines other than the one your cursor is on. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
[patch] Restore behavior of C on blank last line
Patch 7.3.251 inadvertently changed how C behaves on the last line of
the file, when it is blank. Given this command
vim -u NONE -N -c 'call setline($, [11, ])' -c 'call feedkeys(GC)'
pre-7.3.251 would simply leave the cursor in insert mode on line 2.
After 7.3.251, line 2 is deleted and the cursor is in insert mode at the
*start* of line 1.
Since 7.3.251 was just supposed to special case for gHDel, the
attached patch verifies the op is OP_DELETE before using the new
behavior.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
diff --git a/src/ops.c b/src/ops.c
--- a/src/ops.c
+++ b/src/ops.c
@@ -1922,7 +1922,8 @@
curwin-w_cursor.coladd = 0;
}
#endif
- if (oap-inclusive oap-end.lnum == curbuf-b_ml.ml_line_count
+ if (oap-op_type == OP_DELETE oap-inclusive
+ oap-end.lnum == curbuf-b_ml.ml_line_count
n (int)STRLEN(ml_get(oap-end.lnum)))
{
/* Special case: gHDel deletes the last line. */
signature.asc
Description: Digital signature
Re: GtkFileChooser broken again
On Thu, Sep 08, 2011 at 08:06:39PM +1000, Tim Starling wrote: First of all, belated thanks to Bram for applying my patch in July 2010 to fix GtkFileChooser (2301:6f63294a1781). I upgraded recently from Ubuntu 10.10 to 11.04. After the upgrade, I noticed that GtkFileChooser was broken in gvim. The problem is rather strange: when you navigate from one directory to another, about 30-50% of the time it fails to actually go to the directory. The button is highlighted, but the main file listing stays the same. The problem occurs when double-clicking the directory in the main file listing, clicking a shortcut, or clicking one of the parent buttons at the top of the box. When it happens on double-click, the mouse cursor changes to busy until you do something to make it change back. I naturally assumed that it's my fault, so I investigated. It looks like it's not my fault. I discovered that it only happens when vim forks. The problem goes away if you use gvim -f. So I asked on IRC what the standard procedure is for early forking of a GTK+ app. The well-known GTK+ developer Emmanuele Bassi told me to fork before gtk_init() since there are some known issues with forking after gtk_init(). A bug about this interaction was posted to Fedora's bugzilla[0] a couple years ago, but I guess it never made it to the list. As Lennart explains, it's a general problem with initializing a library and then using it across a fork. The problems are likely just more apparent with Gtk. I had meant to look into this when I first found the RedHat bug, but never got around to it. Thanks for bringing up the discussion and potential ideas. [0]: https://bugzilla.redhat.com/show_bug.cgi?id=488652 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Fwd: vim cursor movement on InsertLeave
On Thu, Sep 08, 2011 at 05:42:51PM +0200, Romeo Van Snick wrote: This seems to work as expected, yet there is one problem: imagine I do the following sequence of key presses when in normal mode i esc i esc i esc one would expect that the one is now in normal mode, and the cursor is still at the same character it was before. Yet it isn't: it has moved three characters to the left (as if I had pressed hhh). Actually, one wouldn't expect that once one understands where the cursor is positioned in normal mode vs. insert mode. The reason for this is when the InsertEnter auto command triggers, there is also a cursor movement to the left (h), without me wanting this. This is standard Vim behavior and has nothing to do with your autocmd. If you want the cursor to stay put while you enter/leave insert mode without doing anything else, you need to use aEsc. There's some more explanation and, if you still want to change it, some ideas of how to work around it on the wiki[0]. [0]: http://vim.wikia.com/wiki/Prevent_escape_from_moving_the_cursor_one_character_to_the_left -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Bug in 7.3.301: 'modified' not set when buffer changed by BufRead autocommand
On Wed, Sep 07, 2011 at 02:16:59PM -0700, Gary Johnson wrote: When a buffer is modified by a BufRead autocommand or by a filetype plugin, 'modified' is not set. This is documented in the text below :help gzip-example. The commands executed for the BufNewFile, BufRead/BufReadPost, BufWritePost, FileAppendPost and VimLeave events do not set or reset the changed flag of the buffer. … If you do want the buffer to be marked as modified, set the 'modified' option. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Inconsistent jump after undo of multi-line change
On Sun, Sep 04, 2011 at 10:47:53AM +0800, bootleq wrote: About the automatically added jump: It' reasonable when undoing a single change. But if we do many changes at one function, one undo block, we might want to keep the cursor unchanged after undo. You can use the :keepjumps command to perform an action without altering the jump list. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
[patch] Crash with EOL visual-block over a fold
Bram,
If one uses C-v$ to start visual-block mode, and then moves the cursor
over a fold, Vim will crash. As a simple test, you can follow the
commands below with this email.
:set fdm=marker
zM
C-v$jG
{{{
screen.c:
2534if (wp-w_old_cursor_lcol + txtcol (colnr_T)W_WIDTH(wp))¶
2535len = wp-w_old_cursor_lcol;¶
2536else¶
2537len = W_WIDTH(wp) - txtcol;¶
2538RL_MEMSET(wp-w_old_cursor_fcol + txtcol, hl_attr(HLF_V),¶
2539len - (int)wp-w_old_cursor_fcol);¶
}}}
This is due to wp-w_old_cursor_lcol being set to MAXCOL, so the sum in
the above comparison overflows and incorrectly causes the comparison to
succeed. So, RL_MEMSET walks off the end of ScreenAttrs.
Attached patch fixes the problem.
Thanks,
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
diff --git a/src/screen.c b/src/screen.c
--- a/src/screen.c
+++ b/src/screen.c
@@ -2531,7 +2531,8 @@
/* Visual block mode: highlight the chars part of the block */
if (wp-w_old_cursor_fcol + txtcol (colnr_T)W_WIDTH(wp))
{
- if (wp-w_old_cursor_lcol + txtcol (colnr_T)W_WIDTH(wp))
+ if (wp-w_old_cursor_lcol != MAXCOL
+ wp-w_old_cursor_lcol + txtcol (colnr_T)W_WIDTH(wp))
len = wp-w_old_cursor_lcol;
else
len = W_WIDTH(wp) - txtcol;
signature.asc
Description: Digital signature
Allow expected getchar() behavior in expr maps
According to the help, using getchar() in an expr map should be avoided:
- You can use getchar(), but the existing typeahead isn't seen and new
typeahead is discarded.
I'm not sure this limitation is warranted.
A while back, a user in #vim requested the ability to bracket i_Ctrl-r
with i_Ctrl-g_u so they could more easily undo their changes. My
immediate suggestion was:
inoremap expr C-r \C-gu\C-r.nr2char(getchar()).\C-gu
This actually works fine, unless you have another mapping that starts
with the same {lhs}. Using the following mappings (simplified for
testing):
inoremap expr C-r nr2char(getchar())
inoremap expr C-rxl foo
If I press C-rxa, I would expect to have xa inserted into the buffer.
Instead after C-rxa, getchar() is waiting for me to type a character.
So I type y and yxa gets inserted into the buffer.
The xa that I typed to disambiguate the mapping was part of the existing
typeahead, so when the mapping finally gets triggered it is cached, I'm
prompted for a character (y) which is pushed onto the typeahead, and
then the previous typeahead is restored.
If I instead wait for the mapping to timeout, everything works fine, but
having to wait for the timeout gets pretty annoying.
This same behavior is what was causing the problem ZyX posted[0] about
some time ago and resulted in this TODO entry:
Cannot use getchar() inside :normal and using an expression mapping. Is this
supposed to work? (XyX, 2010 Sep 22)
So, I'm not really sure what stashing/restoring the typeahead is
supposed to protect against. I haven't seen a way to workaround that
stashing with my map disambiguation example and it seems to cause other
uses to break even when there aren't ambiguous maps involved. Based on
that, I propose the attached patch to remove that restriction.
Thanks,
James
[0]: http://mid.gmane.org/201009222031.13720@-zyx
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
diff --git a/runtime/doc/map.txt b/runtime/doc/map.txt
--- a/runtime/doc/map.txt
+++ b/runtime/doc/map.txt
@@ -237,8 +237,6 @@
- Editing another buffer.
- The |:normal| command.
- Moving the cursor is allowed, but it is restored afterwards.
-- You can use getchar(), but the existing typeahead isn't seen and new
- typeahead is discarded.
If you want the mapping to do any of these let the returned characters do
that.
diff --git a/src/getchar.c b/src/getchar.c
--- a/src/getchar.c
+++ b/src/getchar.c
@@ -2460,27 +2460,17 @@
/*
* Handle :map expr: evaluate the {rhs} as an
- * expression. Save and restore the typeahead so that
- * getchar() can be used. Also save and restore the
- * command line for normal :.
+ * expression. Also save and restore the command line
+ * for normal :.
*/
if (mp-m_expr)
{
- tasave_T tabuf;
int save_vgetc_busy = vgetc_busy;
-
- save_typeahead(tabuf);
- if (tabuf.typebuf_valid)
- {
-vgetc_busy = 0;
-save_m_keys = vim_strsave(mp-m_keys);
-save_m_str = vim_strsave(mp-m_str);
-s = eval_map_expr(save_m_str, NUL);
-vgetc_busy = save_vgetc_busy;
- }
- else
-s = NULL;
- restore_typeahead(tabuf);
+ vgetc_busy = 0;
+ save_m_keys = vim_strsave(mp-m_keys);
+ save_m_str = vim_strsave(mp-m_str);
+ s = eval_map_expr(save_m_str, NUL);
+ vgetc_busy = save_vgetc_busy;
}
else
#endif
signature.asc
Description: Digital signature
Re: :python forwarding to :py3 and vice-versa in case of incompatibility
On Tue, Aug 23, 2011 at 08:37:09PM +0400, ZyX wrote:
Reply to message «Re: :python forwarding to :py3 and vice-versa in case of
incompatibility»,
sent 15:57:44 23 August 2011, Tuesday
by Roland Puntaier:
Here I meant the scenario, where we would go without loading the python
shared object (SO).
Then we would have to do a AC_DEFINE() in the configure.in with the
version.
In that scenario has('python3') would not load the SO, but since
configured, would return true.
I suggest seeking for more information at this point: at least, check whether
python3 so or, especially, DLL exists and only then return true. Especially
because if I am not mistaking, vim without cream is compiled with py3
support,
but this does not guarantee that :py3 will actually work (in my Gentoo adding
python USE flag to vim will also install python, so this is not a problem).
Won't the following work: fork and load library in child, then make it report
about errors and exit?
Another option is to make the language-binding code standalone modules
that are linked with the relevant libraries and Vim dlopen()s the
language modules (as Danek Duvall suggested[0]) instead of having the
language bindings dlopen() the language libraries.
This would also fix the current problem that's preventing me from
enabling dynamic loading for the Debian packages (and I'd imagine
similarly for other binary distributions). Basically, the current
implementation makes it difficult to properly express the library
dependency, so when a new version of the library is introduced there's
no easy way to know whether Vim needs to be rebuilt to work with the new
library version (c.f., discussion in Debian's BTS[1]). With the
standalone modules, it's obvious what the library dependency is since
the module is directly linked to the library.
[0]: http://thread.gmane.org/gmane.editors.vim.devel/22759/focus=22765
[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611573
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org
signature.asc
Description: Digital signature
Re: Patch 7.3.220
On Sun, Jun 19, 2011 at 12:28:17AM +0200, Bram Moolenaar wrote:
Patch 7.3.220
Problem:Python 3: vim.error is a 'str' instead of an 'Exception' object,
so 'except' or 'raise' it causes a 'SystemError' exception.
Buffer objects do not support slice assignment.
When exchanging text between Vim and Python, multibyte texts
become
gabage or cause Unicode Expceptions, etc.
'py3file' tries to read in the file as Unicode, sometimes causes
UnicodeDecodeException
Solution: Fix the problems. (lilydjwg)
Files: src/if_py_both.h, src/if_python.c, src/if_python3.c
*** ../mercurial/vim73/src/if_py_both.h 2011-03-22 15:47:18.0
+0100
--- src/if_py_both.h 2011-06-18 23:54:25.0 +0200
***
*** 65,74
OutputWrite(PyObject *self, PyObject *args)
{
int len;
! char *str;
int error = ((OutputObject *)(self))-error;
! if (!PyArg_ParseTuple(args, s#, str, len))
return NULL;
Py_BEGIN_ALLOW_THREADS
--- 65,74
OutputWrite(PyObject *self, PyObject *args)
{
int len;
! char *str = NULL;
int error = ((OutputObject *)(self))-error;
! if (!PyArg_ParseTuple(args, es#, p_enc, str, len))
return NULL;
Py_BEGIN_ALLOW_THREADS
***
*** 76,81
--- 76,82
writer((writefn)(error ? emsg : msg), (char_u *)str, len);
Python_Release_Vim();
Py_END_ALLOW_THREADS
+ PyMem_Free(str);
Py_INCREF(Py_None);
return Py_None;
***
*** 104,113
for (i = 0; i n; ++i)
{
PyObject *line = PyList_GetItem(list, i);
! char *str;
PyInt len;
! if (!PyArg_Parse(line, s#, str, len)) {
PyErr_SetString(PyExc_TypeError, _(writelines() requires list of
strings));
Py_DECREF(list);
return NULL;
--- 105,114
for (i = 0; i n; ++i)
{
PyObject *line = PyList_GetItem(list, i);
! char *str = NULL;
PyInt len;
! if (!PyArg_Parse(line, es#, p_enc, str, len)) {
PyErr_SetString(PyExc_TypeError, _(writelines() requires list of
strings));
Py_DECREF(list);
return NULL;
The above changes to PyArg_Parse break simple scenarios, like the ones
below:
1) Print a string with non-ascii bytes:
:set enc?
encoding=utf-8
:py print '\xc3\xb3'
Traceback (most recent call last):
File string, line 1, in module
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0:
ordinal not in range(128)
2) Print a properly encoded line from the buffer:
:set enc?
encoding=utf-8
:call setline(1, nr2char(243))
:py import vim
:py print vim.current.buffer[0]
Traceback (most recent call last):
File string, line 1, in module
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0:
ordinal not in range(128)
Changing es# to et# appears to fix the problem, but I'm not positive
that's the correct fix.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: Bug in bufexplorer plugin related to 'Show buffers/tab'
Adding bufexplorer's author to Cc.
On Sun, Jul 31, 2011 at 07:34:11AM -0700, rehan wrote:
I wonder if anyone can help me with the following bug, that is
reducing the functionality (for me) of this great plugin.
I am having problems with the 'Show buffers/tab' functionality.
Sometimes it works. Sometimes it gives errors similar to the one
below, especially when I try and change the sort ordering.
Error detected while processing function
SNR17_BEToggleShowTabBuffer..SNR17_BEDisplayBufferList..SNR17_BEBuildBufferList..SNR17_BESortListing:
line8:
E493: Backward range given: 4,$sort ir /\d.\{7}\zs\f\+\ze/
To replicate the bug it is usually enough to open a bunch of files in
a few tabs, then hit 'T', then hit 's'. Doesn't always break
immediately, but after opening and closing the bufexplorer window a
few times, and hitting 'T' and 's' each time it is open, it always
breaks sooner or later.
A separate, but probably related problem is that sometimes when I
enable 'Show buffers/tab' functionality (by hitting 'T', no buffers
appear in the list at all.
I am using vim 7.3 (default ubuntu 11.04 distribution install), and
also have plugins NERD_commenter.vim NERD_tree.vim installed.
Many thanks in advance for any suggestions / fixes,
Rehan
--
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
Re: [PATCH] fix man page viewing with man-db
On Mon, Jul 25, 2011 at 11:50:39PM +0300, Elias Toivanen wrote:
Hello,
I've also experienced man.vim crashing when $MANPAGER had been already
defined to `col -b | vim -R -' in .bashrc. I took a look at the man.vim
file and came up with the following idea.
Instead of asking if $MANPAGER was defined, why not define it
temporarily for the call. It's possible to do this via
let tmp = tempname()
let $MANWIDTH = tw ? tw : 80
let manpager = shellescape('less -s') Fixes problems when user has
defined $MANPAGER
silent execute !MANPAGER=.manpager. /usr/bin/man .args.| col -b
.tmp
Using !env MANPAGER= is better as not all shells support declaring
environment variables to use for a command invocation like that.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: dosini syntax
On Fri, Jul 15, 2011 at 04:01:13PM +0200, Bram Moolenaar wrote: Hong Xu wrote: The attached patch also highlights lines starting with '#' as comment line. Now most dosini parser also regards '#' as comment string, and Debian has already modified dosini.vim to highlight lines starting with '#' as comment lines. Could not get a reply from the original author of this syntax file. And how about the maintaner? I have copied him/her. Debian's patch was sent to Sean back in 2006 and to Sean Nima in 2008, but we never got a response. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Vim taken from http://tuxproject.de.nyud.net/projects/vim/ crashes under wine
On Sun, Jul 10, 2011 at 04:23:17PM +0400, ZyX wrote: Reply to message «Re: Vim taken from http://tuxproject.de.nyud.net/projects/vim/ crashes under wine», sent 15:31:06 10 July 2011, Sunday by ZyX: Building using make -f Make_ming.mak -j5 'CROSS=yes' 'ARCH=i686' 'FEATURES=huge' \ 'CROSS_COMPILE=i686-mingw32-' \ 'PYTHON=/home/zyx/.wine/dosdevices/c:/Python27' \ 'PYTHON_VER=27' 'DYNAMIC_PYTHON=yes' 'GUI=yes' \ 'NETBEANS=no' gvim.exe fails because it cannot find Python.h. It appears that Make_ming.mak is not going to add -I/path/to/python to compiler flags. Why? According to the makefile, it's being set: 200 # my include files are in 'win32inc' on Linux, and 'include' in the standard 201 # NT distro (ActiveState) 202 ifeq ($(CROSS),no) 203 PYTHONINC=-I $(PYTHON)/include 204 else 205 PYTHONINC=-I $(PYTHON)/win32inc 206 endif ... 662 $(OUTDIR)/if_python.o : if_python.c $(INCL) 663 $(CC) -c $(CFLAGS) $(PYTHONINC) -DDYNAMIC_PYTHON_DLL=\python$(PYTHON_VER).dll\ $ -o $@ My guess is that $(PYTHON)/win32inc isn't the correct path for your setup. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Fix [count]gj movement when count 1
Bram, Attach patch fixes incorrect movement when using gj with a count and the initial line is shorter than subsequent wrapped lines. Thanks, -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com # HG changeset patch # User James Vega james...@jamessan.com # Date 1308016431 14400 # Node ID 9181395a34216f28762b545f10a64c3790f1 # Parent c6f8f1957c6630a1bf8f6e58c6ddb438c2efabd5 Fix [count]gj movement when count 1 gj was always using the line length of the initial line it was issued from to perform calculations. Therefore, if the initial line had fewer screen lines than other lines that were being traversed, the motion would move over more screen lines than intended. For example, given the following text (leading column represents line numbers): 1 some test text 2 some more test text that wraps to multiple lines 3 and a final line using 2gj from line 1 would place the cursor on line 3 instead of the second screen line of line 2. diff --git a/src/normal.c b/src/normal.c --- a/src/normal.c +++ b/src/normal.c @@ -4533,6 +4533,7 @@ } curwin-w_cursor.lnum++; curwin-w_curswant %= width2; + linelen = linetabsize(ml_get_curline()); } } } signature.asc Description: Digital signature
Re: Issue 7 in vim: terminal resize during file recovery
On Tue, Jun 07, 2011 at 02:00:01PM -0700, Gary Johnson wrote: On 2011-06-07, v...@googlecode.com wrote: Status: New Owner: Labels: Type-Defect Priority-Medium New issue 7 by michaelj...@gmail.com: terminal resize during file recovery http://code.google.com/p/vim/issues/detail?id=7 What steps will reproduce the problem? 1. open a file with vim 2. in a new terminal, open the same file with another vim instance 3. resize your terminal What is the expected output? What do you see instead? I expect the text to reformat while the terminal resizes. Instead, the text gets garbled and never formats properly again. In some cases, the output remains affected after dismissing the prompt, during editing. In either case, the problem can sometimes be fixed by resizing the terminal window once again while editing. Resizing the terminal while running vim works fine with Vim 7.2.148 and 7.3.189, GNOME Terminal 2.26.3.1, KDE 4.3.1 and Fedora 11. It has worked fine for as long as I can remember in xterm on a variety of Unixes. Did you try this in the specific scenario of a swap file recovery prompt? That was the described scenario and I can reproduce the behavior. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: ; and , functionality with t command
On Fri, May 20, 2011 at 03:56:50PM -0500, Ben Bergman wrote: Linux ubuntu 2.6.32-31-generic #61-Ubuntu SMP Fri Apr 8 18:24:35 UTC 2011 i686 GNU/Linux VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 16 2010 12:40:58) I am trying to use the ; command to repeat a search done with t but since the cursor is already in front of a value that matches the criteria, it does not repeat the search. It does repeat the search, and your cursor ends up in the same spot. This is exactly the same thing that would happen if you used t to perform the search again. After all, tX means find the next X on this line and place the cursor on the character before it. Just because one use case of t/T/;/, doesn't move the cursor doesn't mean that there is a problem. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Ubuntu Natty 11.04: Trouble with the Ruby plugin for VIM
On Thu, May 12, 2011 at 12:31:16PM -0700, Richard Sinclair wrote: Running Ubuntu 11.04 (Natty) which came with vim 7.3.035. It did not have ruby installed There is more than one Vim package, with different feature sets, in Ubuntu. If you just install the vim-gtk package, you will have the ruby language bindings. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Reproducibility of test61
Given that test61 is intended to verify the functionality of the undo tree, it's inherently time sensitive. This test sporadically fails[0][1][2] during the automated build of the Debian package, presumably when the build system is under load. Every failure I've seen is a difference on line 20 of the test output. Since I use a successful run of Vim's test suite as a requirement for a successful build of Debian's Vim packages, I'm wondering if it'd be possible to make this test more robust to completing successfully when the system is under load. [0]: http://deb.li/Yjgx [1]: http://deb.li/3jEll [2]: http://deb.li/p6Vg -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: stderr issue with mksh/pdksh
On Thu, Apr 14, 2011 at 08:22:22PM -0400, Chris Sutcliffe wrote: On 14 April 2011 20:11, Chris Sutcliffe wrote: On 14 April 2011 16:38, Chris Sutcliffe wrote: I've noticed an issue with vim while running under mksh and pdksh. Specifically, the stderr output by gcc (i.e. compilation warnings and errors) is not captured in the QuickFix window. I see the stderr output in the terminal window during the compilation process, however, when vim returns to the editor window and I execute a :cl or :copen, I only see stdout output. Following up with one of the mksh developers he mentioned that mksh sets a close-on-exec flag on filedescriptors, which is a traditional Korn Shell security feature. He's not sure if its related to the issue or not, but I figured I would pass it along. I just realized the issue, looking at :h shellredir The default is . For Unix, if the 'shell' option is csh, tcsh or zsh during initializations, the default becomes . If the 'shell' option is sh, ksh or bash the default becomes %s 21. This means that stderr is also included. For Win32, the Unix checks are done and additionally cmd is checked for, which makes the default %s 21. Also, the same names with .exe appended are checked for. pdksh and mksh aren't captured by the ksh rule, unless I explicitly set the SHELL variable to be ksh. Right. So, either option.c has to learn about mksh/pdksh or people using those shells can add something like if shell =~? '\%(m\|pd\)ksh' set shellredir=%s\ 21 endif to their vimrc. On the bright side, at least Vim behaves better not knowing about mksh/pdksh than it does not knowing about fish. :) fish users get caught by much more subtle (and annoying) issues until they find out they have to set shell=/bin/sh (or some other shell Vim knows how to handle). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: [patch] filetype.vim
Package: vim Version: 2:7.3.135+hg~0139403c8eb0-1 X-Debbugs-Cc: t@gmx.de On Sat, Apr 09, 2011 at 12:05:49AM +0200, Thilo Six wrote: * FIXME: /etc/reportbug.conf should be of type 'conf' but vim insists in using 'mail' instead. I haven´t figured out why though. That's being caused by Debian's system-wide config. Thanks for pointing that out. I've filed a bug with this message and I look into fixing it for the next package upload I do. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Cream without cream 7.3.138 gives errors with Diff
On Mon, Mar 21, 2011 at 08:24:05PM -0400, Steve Hall wrote: On Fri, 2011-03-18 at 18:35 -0400, James Vega wrote: The default vimrc is no vimrc. ...except on Windows... That's an implementation detail of the installer which can be disabled by the user. There's no requirement for there to be $VIM/_vimrc. There's an example vimrc that the installer installs to $VIM (which one can change through the Advanced install options). Part of the confusion, IMO, is that, on Windows, Vim treats $VIM/_vimrc as an alternative location for the user's vimrc instead of as the system-wide vimrc. So, unlike on unix-like platforms, $VIM/_vimrc is *only* sourced if $HOME/_vimrc doesn't exist instead of always being sourced. I'm a little confused here, unless the user adds $HOME/_vimrc, then $VIM/_vimrc will be sourced by default, no? Which means there IS a default vimrc on Windows. See above reply. There are two default locations for a vimrc on Windows ($HOME/_vimrc and $VIM/_vimrc, in order), which seems unnecessary to me. If there are to be system-wide defaults, they should be in $VIM/vimrc. If a user wants a base vimrc to be installed for them when they install Vim, they should explicitly enable that in the installer and it should be installed to $HOME/_vimrc. Having different behavior on different platforms when one of Vim's selling points is that it is a very portable editor doesn't make sense. There are obviously going to be system-dependent features/functionality, but the overall functionality should be consistent across platforms. The other bit is that the Windows installers (both yours and Bram's), have decided to use this to, by default, coddle new users by installing a vimrc to $VIM/_vimrc enabling a bunch of options to make Vim act more like a typical Windows application. That may be the right thing to do for new users, and leave the more experienced users to unselect that option (as I do) when installing Vim on a new Windows system. It depends on what learning curve you want to present to new users. Our installer is simply trying to duplicate the default Vim installer behavior. Whatever gets decided for the default will get adapted to ours. Right, I wasn't trying to call you out specifically. I realize this is also the behavior in the standard installer. I also agree that the mswin option is confusing. I don't think that keeping it makes Vim any more understandable. (One of the reasons Cream was originally developed.) It forks the default Vim behavior by platform. (Ironically, Cream was developed to maintain the standard CUA behavior + features ACROSS platforms.) But then, should nocompatible be set by default on Windows, too? If I remember correctly, the installed vimrc sources vimrc_example.vim, so nocompatible is set. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: [PATCH] First pass at Freedesktop directories
On Mon, Mar 14, 2011 at 02:27:07PM -0400, Benjamin R. Haskell wrote: Freedesktop defines some commonly, but certainly-not-universally used directories for configuration (rather than using $HOME/.file, it's generally, $XDG_CONFIG_HOME/appname/file). This is a very rough first draft of using those names if XDG_DIRECTORIES is defined. With this patch, if $XDG_CONFIG_HOME isn't set (which is the common case) Vim would need to know to use ~/.config. This could likely be done like $VIM is, where the environment is checked first and a default used if it isn't set. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Cream without cream 7.3.138 gives errors with Diff
On Fri, Mar 18, 2011 at 06:26:38AM -0700, Steve Hall wrote: From: Tony Mechelynck, Fri, March 18, 2011 5:51 am On 18/03/11 03:11, Steve Hall wrote: Can we not start distributing .vimrc and _vimrc instead of relying on the installer to create these? [...] If we distribute .vimrc and _vimrc, wouldn't that clobber any existing user vimrc during an upgrade, the way, let's say, $VIMRUNTIME/syntax/vim.vim is overwritten by an upgrade? Depends on how it is distributed. I've always thought it odd that the default vimrc requires any lines at all. The default vimrc is no vimrc. There's an example vimrc that the installer installs to $VIM (which one can change through the Advanced install options). Part of the confusion, IMO, is that, on Windows, Vim treats $VIM/_vimrc as an alternative location for the user's vimrc instead of as the system-wide vimrc. So, unlike on unix-like platforms, $VIM/_vimrc is *only* sourced if $HOME/_vimrc doesn't exist instead of always being sourced. The other bit is that the Windows installers (both yours and Bram's), have decided to use this to, by default, coddle new users by installing a vimrc to $VIM/_vimrc enabling a bunch of options to make Vim act more like a typical Windows application. That may be the right thing to do for new users, and leave the more experienced users to unselect that option (as I do) when installing Vim on a new Windows system. It depends on what learning curve you want to present to new users. Why is the default behavior of the application required to be varied by a vimrc? A vimrc is for a user to alter defaults, but as long as I can remember Vim has distributed one with features differing by distribution. (Raise your hand if you count 100 times you've seen a Windows Vim user confused by the mswin line in _vimrc.) And each installer has to prompt the user whether or not to overwrite the existing vimrc. The installer should be installing to $VIM, not $HOME. Unfortunately, many Windows users aren't used to the concept of $HOME and will tend to edit the vimrc in $VIM instead of creating their own in $HOME. Educating the users to put their own vimrc in $HOME is the right route to avoid it getting overwritten. IMO, the correct behavior should be an empty vimrc named vimrc-example. Various features can be included (commented) with simple explanatory text, like a reference tutorial of the top 100 features most users tamper with. The first line explains how to rename the file to activate it. Something similar to http://vim.wikia.com/wiki/Example_vimrc, but with more settings commented out? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Yank to + also yanks to * when suppressing a in guioptions in unix
On Wed, Mar 16, 2011 at 02:52:19PM -0700, Jean Johner wrote:
Hello,
Zero comment on the below thread in vim_use.
I think it is a bug.
Best regards
Jean Johner
Hello,
Using gvim in unix, a is by default in guioptions.
Yanking a word to the Unix clipboard (with +yw) does not yank the
word to the Selection buffer (*).
When suppressing the a option (with set guioptions-=a), yanking a
word to the Unix clipboard (with +yw) also yanks the word to the
Selection buffer (*).
Is there a reason for this behaviour or is it a bug ?
This was introduced with the unnamedplus setting for 'clipboard' in
patch 7.3.074. The behavior I expect, according to the documentation,
is that * will only mirror +'s content when both unnamed and
unnamedplus are present in 'clipboard' and 'guioptions' doesn't
contain a. The attached patch should implement that behavior.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org
diff --git a/src/ops.c b/src/ops.c
--- a/src/ops.c
+++ b/src/ops.c
@@ -3151,7 +3151,8 @@
/* No need to copy to * register upon 'unnamed' now - see below */
clip_own_selection(clip_plus);
clip_gen_set_selection(clip_plus);
- if (!clip_isautosel() !did_star)
+ if (!clip_isautosel() (clip_unnamed CLIP_UNNAMED)
+ (clip_unnamed CLIP_UNNAMED_PLUS) !did_star)
{
copy_yank_reg((y_regs[STAR_REGISTER]));
clip_own_selection(clip_star);
signature.asc
Description: Digital signature
Re: [PATCH] foldexpr for help files
On Sat, Mar 12, 2011 at 12:32:03AM +0100, Peter Odding wrote: The following patch adds foldexpr option that will fold sections separated by sequences of `=' (foldlevel=1) and `-' (foldlevel=2). Just to confirm: The patch works great, thanks ZyX! What’s the general practice for this? Do we set foldexpr from ftplugin files, or is that up to the user to add to after/ftplugin? I thought the point of /after/ftplugin/ was for users to be able to override unwanted settings in scripts under /ftplugin/? Either way I'd like for this patch to be included because it clearly adds value for people who like text folding (like me). Also people that don't like text folding probably won't have it enabled anyway and thus won't be bothered by the addition. Folding is actually enabled by default. The only saving grace for not completely confusing new users is that 'foldmethod'/'foldexpr' are typically set by ftplugins (or syntax files for syntax-based folding). Of course, those are commonly the first things that get enabled. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: [BUG] getpos(') returns wrong column number
On Tue, Mar 8, 2011 at 9:53 AM, ZyX zyx@gmail.com wrote: Consider the following script: vim -u NONE -s (echo $'gg0VG:call writefile(getpos(\'), getpos)\n:qa!') It will end up having [0, 1, 2147483647, 0] as lines in `getpos' file, while expected to have [0, 1, 1, 0]. That's intentional. Vim defines a MAXCOL value which is used to indicate the cursor is at the end of the line without specifically requiring knowing the line length ahead of time. This allows the behavior to stay the same even if the line length changes. Some of its uses are purely internal, but it does have external visibility in the case of commands like getpos(). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Why does vim link with selinux?
On Tue, Mar 8, 2011 at 10:41 AM, ron r...@ronware.org wrote: If you're using ldd to test that, then that's the problem. ldd reports all recursive library dependencies. objdump -p vim | grep NEEDED will show what the Vim binary directly requires. Nope; vim --version reports -lselinux Are you sure you're using the version that you built with --disable-selinux? That flag works fine for me. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Re: Spelling support doesn’t deal with ‘’’ correctly
On Tue, Mar 8, 2011 at 3:01 PM, Dominique Pellé dominique.pe...@gmail.com wrote: Nikolai Weibull n...@bitwi.se wrote: On Wed, Dec 1, 2010 at 22:00, Nikolai Weibull n...@bitwi.se wrote: On Wed, Dec 1, 2010 at 21:12, Bram Moolenaar b...@moolenaar.net wrote: Nikolai Weibull wrote: Writing “Let’s begin …” marks the ‘s’ as a spelling error. Writing “Let's begin …” works fine. Is this a bug, or am I missing something? Right, only latin1 quotes are supported. OK, so let’s fix that. How do we fix that? Also, I don’t understand what you say latin1 quotes, as it would be a lot clearer if you said ASCII quotes. (Latin1 doesn’t add any additional quotes. That’s one of the main differences between latin1 and cp1252.) Still waiting for a response to this question. The hunspell doc is not very clear but I think this is what the ICONV directive of Hunspell is for. Looking at this English dictionary of OpenOffice 3.x at: http://extensions.services.openoffice.org/en/project/dict-en-fixed ... the en_US.aff file contains: 2839 ICONV 6 2840 ICONV ’ ' 2841 ICONV ffi ffi 2842 ICONV ffl ffl 2843 ICONV ff ff 2844 ICONV fi fi 2845 ICONV fl fl 2846 2847 OCONV 1 2848 OCONV ' ’ My understanding is that ICONV causes to convert the input fancy quote U+2019 into a regular quote (among other conversions) before probing the dictionary. So Let’s and “Let's are both recognized as correct. But Vim currently still uses dictionaries from OpenOffice-2.x and does not support ICONV either. I found the following patch which adds support of Hunspell dictionary in Vim: https://bugzilla.redhat.com/show_bug.cgi?id=219777 Personally, I'd prefer to use something like Enchant[0] over a specific spelling library, if the effort is going to be taken to use something other than Vim's internal spell-checking. I've done some work in a local branch to integrate Enchant, but ran into some larger questions that need to be addressed and haven't had time to draft a reasonable email about them yet. [0]: http://www.abisource.com/projects/enchant/ -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Issues with gnupg.vim - plaintext leakage, file trashing
On Wed, Feb 23, 2011 at 04:53:40PM -0800, AndrewDaviel wrote:
On Feb 22, 8:49 pm, James Vega james...@jamessan.com wrote:
When writing out a modified encrypted file, the plaintext is still
saved in 4 in the temporary directory, although the ciphertext is
not saved to 2 while reading as with the original plugin.
This is related to the 'shelltemp' option. You can, if your system
supports it, use pipes instead of temp files. I guess the plugin could
do the check and automatically use pipes if supported.
That seems to work, if I put set noshelltemp in gnupg.vim
runtime/doc/options.txt says shelltemp defaults to off in Vi but on in
Vim, and other docs say that
temp files will be used anyway unless (has(filterpipe))
Attached version sets 'noshelltemp' and correctly checks for Vim 7.2 or
newer.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
Name:gnupg.vim
Version: $Id: gnupg.vim 3051 2010-02-16 07:56:18Z mbr $
Author: Markus Braun markus.br...@krawel.de
Summary: Vim plugin for transparent editing of gpg encrypted files.
Licence: This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License.
See http://www.gnu.org/copyleft/gpl.txt
Section: Documentation {{{1
Description: {{{2
This script implements transparent editing of gpg encrypted files. The
filename must have a .gpg, .pgp or .asc suffix. When opening such
a file the content is decrypted, when opening a new file the script will
ask for the recipients of the encrypted file. The file content will be
encrypted to all recipients before it is written. The script turns off
viminfo and swapfile to increase security.
Installation: {{{2
Copy the gnupg.vim file to the $HOME/.vim/plugin directory.
Refer to ':help add-plugin', ':help add-global-plugin' and ':help
runtimepath' for more details about Vim plugins.
From man 1 gpg-agent:
...
You should always add the following lines to your .bashrc or whatever
initialization file is used for all shell invocations:
GPG_TTY=`tty`
export GPG_TTY
It is important that this environment variable always reflects the out‐
put of the tty command. For W32 systems this option is not required.
...
Most distributions provide software to ease handling of gpg and gpg-agent.
Examples are keychain or seahorse.
Commands: {{{2
:GPGEditRecipients
Opens a scratch buffer to change the list of recipients. Recipients that
are unknown (not in your public key) are highlighted and have
a prepended !. Closing the buffer makes the changes permanent.
:GPGViewRecipients
Prints the list of recipients.
:GPGEditOptions
Opens a scratch buffer to change the options for encryption (symmetric,
asymmetric, signing). Closing the buffer makes the changes permanent.
WARNING: There is no check of the entered options, so you need to know
what you are doing.
:GPGViewOptions
Prints the list of options.
Variables: {{{2
g:GPGExecutable
If set used as gpg executable, otherwise the system chooses what is run
when gpg is called. Defaults to gpg.
g:GPGUseAgent
If set to 0 a possible available gpg-agent won't be used. Defaults to 1.
g:GPGPreferSymmetric
If set to 1 symmetric encryption is preferred for new files. Defaults to
0.
g:GPGPreferArmor
If set to 1 armored data is preferred for new files. Defaults to 0
unless a *.asc file is being edited.
g:GPGPreferSign
If set to 1 signed data is preferred for new files. Defaults to 0.
g:GPGDefaultRecipients
If set, these recipients are used as defaults when no other recipient is
defined. This variable is a Vim list. Default is unset.
Known Issues: {{{2
In some cases gvim can't decrypt files
This is caused by the fact that a running gvim has no TTY and thus gpg is
not able to ask for the passphrase by itself. This is a problem for Windows
and Linux versions of gvim and could not be solved unless a terminal
emulation is implemented for gvim. To circumvent this you have to use any
combination of gpg-agent and a graphical pinentry program:
- gpg-agent only:
you need to provide the passphrase for the needed key to gpg-agent
in a terminal before you open files with gvim which require this key.
- pinentry only:
you will get a popup window every time you open a file that needs to
be decrypted.
- gpgagent and pinentry:
you will get a popup window the first time you open a file that
needs to be decrypted.
Credits: {{{2
- Mathieu Clabaut for inspirations through his vimspell.vim script.
- Richard Bronosky for patch to enable .pgp suffix.
- Erik Remmelzwaal for patch to enable windows support and patient beta
testing.
- Lars Becker for patch to make gpg2 working
Re: Feature suggestion: option for letting spaces match newlines in search
On Thu, Feb 24, 2011 at 10:49:29AM +0100, Ulf Magnusson wrote:
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 have an option that makes
spaces match newlines in searches.
This idea was brought up a few years ago in response to a Debian bug[0]
and was not accepted. It was then reposed to this list a year or so
later[1] and recieved no response.
I've looked at http://vim.wikia.com/wiki/Search_across_multiple_lines,
but those solutions have the disadvantage of either forcing you to use
an awkward pattern or not supporting incremental searching.
That looks quite similar to the script Stefano ended up writing, except
a bit cleaner since it's taking advantage of 7.0 features and simpler by
not providing the ability to customize the separator.
A solution to a more general class of problems would be to allow the
search pattern to be automatically rewritten (e.g. by a substitution
or a function) prior to being used. That way you could automatically
rewrite spaces to \_s or do other neat things like having foo bar
match foo {\it bar} in LaTeX documents.
Something like this could probably be done with expr cmaps, but you'd
need to be able to restrict them to only run for / not : command lines.
[0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256743#12
[1]: http://thread.gmane.org/gmane.editors.vim.devel/11964
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: Undo bug?
On Sat, Mar 05, 2011 at 01:31:50PM -0500, Donald Allen wrote: On Sat, Mar 5, 2011 at 12:54 PM, Benjamin R. Haskell v...@benizi.com wrote: On Sat, 5 Mar 2011, Donald Allen wrote: If you delete a line, it gets pushed onto the register stack (the line lands in the register). If you then undo the delete with 'u', the register stack doesn't get popped -- it remains as it was just prior to the 'undo'. So the undo has not undone all the effects of the command you are undoing. 7.3 with patches through 138. Undo isn't intended to undo all the effects of the command, per se. It reverses a change (or a block of changes) made to a buffer, not changes to the state of the entire program. Can't quite see where in the help that's documented, but it seems rational to me. Yes, I also checked the documentation before sending my original message and also was not able to find something definitive, which was why I appended the question mark to my subject. Let's consider this a feature request, then. I think it's completely reasonable to expect 'undo' to reverse the side-effects of an undone command, where that's possible (I wouldn't expect it to undo the changes to the filesystem as a result of a write command, for example). In this case, I'd yanked some text that I wanted to 'put' in a bunch of places. While going through the buffer, putting the text where I wanted it, I noticed a line that needed to come out, so I deleted it. Naturally, the next attempt to put gave me that line instead of the original text I'd yanked. Then you should have been putting from register 0 instead of register . Register 0 is the last yank, while register is the last yank or delete. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Issues with gnupg.vim - plaintext leakage, file trashing
On Tue, Feb 22, 2011 at 01:29:59PM -0800, AndrewDaviel wrote: On Feb 21, 10:43 pm, James Vega james...@jamessan.com wrote: I've attached an updated version of the plugin that I sent to Markus a while back which I think addresses these problems. I've described below specifically how the changes should have the desired effect. Would you mind testing it? Thanks. On a recent build of vim 7.3, it appears to work, also on vim 7.2. When writing out a modified encrypted file, the plaintext is still saved in 4 in the temporary directory, although the ciphertext is not saved to 2 while reading as with the original plugin. This is related to the 'shelltemp' option. You can, if your system supports it, use pipes instead of temp files. I guess the plugin could do the check and automatically use pipes if supported. Our production machines are running SL 5 (~= CENTOS 5) with Vim 7.0. Editing an encrypted file gives (on stdout, until it's cleared): Error detected while processing function SNR7_GPGDecrypt: line 92: E118: Too many arguments for function: shellescape E15: Invalid expression: r ! . s:GPGCommand . ' --quiet --decrypt ' . shellescape(filename, 1) . ' ' . s:stderrredirnull line 96: E492: Not an editor command: LANG=C LC_ALL=C gpg --trust-model always --no-use-agent --verbose --decrypt --list-only --dry-run --batch --no- use-agent --logger-fd 1 '/local/home/advax/CCN/trysym.asc' Yeah, it requires functionality that was introduced after 7.0. I'll adjust the checks for the necessary functionality to be more thorough so you get the error message when loading the plugin. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: Issues with gnupg.vim - plaintext leakage, file trashing
Adding the author to Cc.
I've attached an updated version of the plugin that I sent to Markus a
while back which I think addresses these problems. I've described below
specifically how the changes should have the desired effect. Would you
mind testing it?
On Mon, Feb 21, 2011 at 01:56:52PM -0800, AndrewDaviel wrote:
I have gnupg.vim 3026 from
http://www.vim.org/scripts/script.php?script_id=661
This is a plugin to edit a file encrypted with GnuPG.
A few issues:
- when encrypting files, unwiped plaintext is left on the temporary
directory disk. This can be mitigated by setting TMPDIR to point to a
ramdisk
The plugin is now using Buf{Write,Read}Cmd. This means that it is
directly writing to/reading from gnupg's stdin/stdout and avoiding a
temporary file all together.
- if using a symmetric key, if the user makes a mistake and mismatches
the password, the file is trashed (set to zero length). There is ane
error message Message could not be encrypted! File might be empty!
(Press ENTER)
Due to using BufWriteCmd, the plugin can now properly detect command
errors (like invalid passwords) and abort the write instead of the
current workaround of deleting the contents of the buffer before the
save and restoring it afterward.
This change also means that when there's a failure, the buffer is still
flagged as modified. No more unnoticed failures and then exiting when
the file wasn't truly saved.
- if using a public key/private key, if the user's key has expired,
the file can be decrypted and read but on writing the file is trashed
(set to zero length). Specifically, if the private subkey used for
encryption has expired then the file will be trashed.
This is similar to the above scenario. Gnupg will return an error code,
which the plugin will now notice and prevent the original file from
being overwritten.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
Name:gnupg.vim
Version: $Id: gnupg.vim 3051 2010-02-16 07:56:18Z mbr $
Author: Markus Braun markus.br...@krawel.de
Summary: Vim plugin for transparent editing of gpg encrypted files.
Licence: This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License.
See http://www.gnu.org/copyleft/gpl.txt
Section: Documentation {{{1
Description: {{{2
This script implements transparent editing of gpg encrypted files. The
filename must have a .gpg, .pgp or .asc suffix. When opening such
a file the content is decrypted, when opening a new file the script will
ask for the recipients of the encrypted file. The file content will be
encrypted to all recipients before it is written. The script turns off
viminfo and swapfile to increase security.
Installation: {{{2
Copy the gnupg.vim file to the $HOME/.vim/plugin directory.
Refer to ':help add-plugin', ':help add-global-plugin' and ':help
runtimepath' for more details about Vim plugins.
From man 1 gpg-agent:
...
You should always add the following lines to your .bashrc or whatever
initialization file is used for all shell invocations:
GPG_TTY=`tty`
export GPG_TTY
It is important that this environment variable always reflects the out‐
put of the tty command. For W32 systems this option is not required.
...
Most distributions provide software to ease handling of gpg and gpg-agent.
Examples are keychain or seahorse.
Commands: {{{2
:GPGEditRecipients
Opens a scratch buffer to change the list of recipients. Recipients that
are unknown (not in your public key) are highlighted and have
a prepended !. Closing the buffer makes the changes permanent.
:GPGViewRecipients
Prints the list of recipients.
:GPGEditOptions
Opens a scratch buffer to change the options for encryption (symmetric,
asymmetric, signing). Closing the buffer makes the changes permanent.
WARNING: There is no check of the entered options, so you need to know
what you are doing.
:GPGViewOptions
Prints the list of options.
Variables: {{{2
g:GPGExecutable
If set used as gpg executable, otherwise the system chooses what is run
when gpg is called. Defaults to gpg.
g:GPGUseAgent
If set to 0 a possible available gpg-agent won't be used. Defaults to 1.
g:GPGPreferSymmetric
If set to 1 symmetric encryption is preferred for new files. Defaults to
0.
g:GPGPreferArmor
If set to 1 armored data is preferred for new files. Defaults to 0
unless a *.asc file is being edited.
g:GPGPreferSign
If set to 1 signed data is preferred for new files. Defaults to 0.
g:GPGDefaultRecipients
If set, these recipients are used as defaults when no other recipient is
defined. This variable is a Vim list. Default is unset.
Known Issues: {{{2
In some cases gvim can't decrypt files
This is caused by the fact that a running gvim has no TTY and thus
Re: tr() problem ?
On Wed, Feb 9, 2011 at 2:10 PM, James Vega james...@jamessan.com wrote:
On Wed, Feb 9, 2011 at 12:04 PM, Dimitar DIMITROV mitk...@yahoo.fr wrote:
But this doesn't:
command! Translate call setline(line('.'), tr(getline('.'),
\'ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q',
\'АБВГДЕЖЗИЙКЛМНОПРСТУYФХXЦЧШЩЪЬЮЮЯабвгдежзийклмнопрстуyфхxцчшщъьююя'))
then :Translate on any line
The error is:
E475: Invalid argument:
ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q
This has something to do with how Vim is storing the U+0440 character
(which breaks down to \xd1\x80) in the to string. A minimal
reproduction can be done with this simplified version:
command! Translate echo tr(getline('.'), 'r', 'р')
and then use Translate with your cursor on the line defining the
command.
In fact, if you use the following erroneous version of the command, the
error string that Vim prints when you try to use :Translate will show
that the U+0440 character has been corrupted:
command! Translate echo tr(getline('.'), 'r', \'p')
I end up getting: E15: Invalid expression: \'рfeX')
Everything works fine if the command is defined using \u0440 instead
of the literal character.
Another interesting data point is that the workaround of using \u0440
only works when building Vim without GUI support. Building with GUI
type of any support (I tried Athena, motif and Gtk2) causes the problem
to occur even when using \u0440 instead of р.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
--
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
Re: vim 7.3 configure fails to detect missing libiconv on SunOS 5.10
On Thu, Feb 10, 2011 at 05:27:10PM -0600, john.wier...@thomsonreuters.com wrote:
This occurs in src/auto/configure: When /lib/libiconv.so* is not
present, the short program in configure which references iconv_open()
compiles and links successfully, but if run it aborts due to the missing
shared object:
ld.so.1: conftest: fatal: libiconv.so.2: open failed: No such file or
directory
[snip]
This kind of bug is easily reproducible by copying a no-op program into
conftest.c:
int main () { return 0; }
and compiling with:
$ cc -o conftest -g -I/usr/local/include -L/usr/local/lib conftest.c
-lm -ltermlib -lelf -lnsl -lsocket -liconv
conftest.c, line 192: warning: statement not reached
This sounds like a bug with the linker for not erroring out when it
can't link against the libraries it has been told to link with. I tried
that test locally (Linux system, so gcc) and the compile/link failed.
$ ./conftest
ld.so.1: conftest: fatal: libiconv.so.2: open failed: No such file or
directory
Killed
$ echo $?
137
It seems to me that the correct solution is to *not* include -liconv
unless libiconv.so is actually present (and working). I'm not sure how
to achieve that with autoconf-style programs. The function being used
in this case is ac_fn_c_try_link() which has the following comment:
One could change configure to try and run the program, but that's
generally to be avoided since it inhibits cross-compiling.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: tr() problem ?
On Wed, Feb 9, 2011 at 12:04 PM, Dimitar DIMITROV mitk...@yahoo.fr wrote:
But this doesn't:
command! Translate call setline(line('.'), tr(getline('.'),
\'ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q',
\'АБВГДЕЖЗИЙКЛМНОПРСТУYФХXЦЧШЩЪЬЮЮЯабвгдежзийклмнопрстуyфхxцчшщъьююя'))
then :Translate on any line
The error is:
E475: Invalid argument:
ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q
This has something to do with how Vim is storing the U+0440 character
(which breaks down to \xd1\x80) in the to string. A minimal
reproduction can be done with this simplified version:
command! Translate echo tr(getline('.'), 'r', 'р')
and then use Translate with your cursor on the line defining the
command.
In fact, if you use the following erroneous version of the command, the
error string that Vim prints when you try to use :Translate will show
that the U+0440 character has been corrupted:
command! Translate echo tr(getline('.'), 'r', \'p')
I end up getting: E15: Invalid expression: \'рfeX')
Everything works fine if the command is defined using \u0440 instead
of the literal character.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
--
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
Re: Hex viewer/editor with vim
On Wed, Feb 09, 2011 at 01:45:23AM +0100, Tony Mechelynck wrote: On 08/02/11 23:25, Peter de Ridder wrote: Using vim do edit binary files isn't always that easy. With display+=uhex you can make unprintable characters show as hex, but the printable characters are still shown as normal characters. Using xxd so convert a file to hex gives a nice view of the file in both hex and printable characters. But editing is still a bit difficult even with hex editing helper scripts. e.g. insering or removing data isn't easy since all the xxd offsets number need to be renumbered. Maybe you don't need to reinvent the wheel: see :help hex-editing He addressed that in the first paragraph. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: ctrl-o with a mapping
On Sat, Feb 05, 2011 at 07:57:00PM +0300, ZyX wrote:
Reply to message «Re: ctrl-o with a mapping»,
sent 19:38:30 05 February 2011, Saturday
by Ben Fritz:
Perhaps a bug somewhere? It should be redirected to vim_dev, I think.
Original message:
On Feb 5, 4:05 am, ZyX zyx@gmail.com wrote:
Reply to message «Re: ctrl-o with a mapping»,
sent 23:56:30 05 February 2011, Saturday
by AK:
Well, this is a normal mode mapping (nnoremap), by definition all of
its contents should run under normal mode or not at all.
The fact that it is normal mode mapping means that {lhs} will be replaced
by {rhs} if you type {lhs} in normal mode. It never meant that it should
run under normal mode, the fact that first command is run under normal
mode is just a consequence of the fact that you press {lhs} in normal
mode.
It seems strange to me that recorded macros behave differently from
normal mode mappings, especially if you interpret them as above. :help
@ even says the register is executed like a mapping.
Hmm, that was a very recent addition to the help and the behavior
doesn't agree with that. I wonder what the impetus was behind the
addition of that description.
For example:
qa0:echo getfontname()Enterq
iC-O@a
This does not insert the :echo getfontname(), it does exactly as is
done in normal mode.
This makes sense. C-o lets you execute one normal mode command. In
this case that command is @a.
However,
:nnoremap F9 0:echo getfontname()CR
iC-OF9
This inserts the :echo command in the text.
And in this case the one normal mode command is 0, since mappings are
treated just like a user typing.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: Unexpected behavior loading cp1252 file as latin1
On Fri, Jan 28, 2011 at 3:03 PM, Ben Fritz fritzophre...@gmail.com wrote: On Jan 20, 10:03 pm, Ben Fritz fritzophre...@gmail.com wrote: I have a file which if read with the Windows-1252 encoding (cp1252in Vim) has an en dash character (encoded as byte 150). When I load this file in a Vim with enc=latin1, and leave fenc blank, I would expect to see a no character block in place of the en dash. However, I see the en dash as if I loaded with enc/fenc set tocp1252. If I set encoding to utf-8, and load the same file with default fileencodings, it detects as latin1 and I see the no character glyph as expected. If I do :e ++enc=cp1252, or if I modify my fileencodings option to includecp1252instead of latin1, I see the en dash, again as expected. Is this behavior intentional? It certainly could be considered helpful, but it was very unexpected. So, is this expected behavior? Are there special rules when Vim's encoding is an 8-bit one? I remember trying to reproduce your described behavior when I first saw your mail but wasn't able to. Could you give a minimal set of steps along with the output that you're seeing for :set enc? fenc? fencs? in each of the different cases? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Bug or a feature? Appending in visual block mode
On Thu, Jan 20, 2011 at 2:09 PM, Lech Lorens lech.lor...@gmail.com wrote: I found there's a difference in behaviour of Vim when you start appending in visual block mode depending on whether you mark text to the end of the line by pressing $ or by moving the cursor with l. Assume a text file with the following contents: #v+ 1 abcd 2 efgh #v- Move the cursor to the first line and execute: 0faC-vj$AEsc The contents of the file does not change. Now place the cursor in the first line again and execute the almost identical sequence: 0faC-vjAEsc In both cases, before pressing A the cursor is one column past the h. This makes sense since visual mode allows you to select the EOL. For some reason, in the second case, pressing A positions the cursor two columns past the d. This seems like a bug in not recognizing that the cursor's column before pressing A is at the EOL and should stay at the EOL since 'virtualedit' isn't set. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: tab buffer
On Tue, Jan 11, 2011 at 07:33:43AM +0300, ZyX wrote:
On Mon, Jan 10, 2011 at 08:05:12PM -0800, skeept wrote:
Sorry first of all if this is not the right place to ask this.
The vim user list would have been more appropriate.
If I do
:tab split
the current buffer opens in a new tab
but if I do
:tab buffer n
the current tab changes to buffer n (doesn't create a new tab).
This is not a bug, of course. Read `:tab' documentation: it claims `tab' to
open new tabs whenever {cmd} opens a new window. `:buffer' command does not
open any windows.
To expand on ZyX's response, you would want to use :tab split +bn for the
behavior you want.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: Some documentation bugs and wishes
On Tue, Jan 04, 2011 at 03:04:40PM +0200, Stefan Parviainen wrote: On Tue, Jan 4, 2011 at 2:25 PM, Bram Moolenaar b...@moolenaar.net wrote: Follow the tag. This short overview becomes less readable when adding the arguments. I've spoken to a few people (real life, IRC and even on this list) and not a single one new that :visual takes an argument. How many of those people actually use :visual? I wouldn't expect people to know it takes an argument since it's not a common command to use aside for providing compatibility with vi (in which it didn't accept an argument). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Patch 7.3.083
On Fri, Dec 17, 2010 at 11:14 AM, Mike Williams
mike.willi...@globalgraphics.com wrote:
On 17/12/2010 16:09, Cesar Romani wrote:
By building vim 7.3.083 on Win XP with MinGW, I'm getting:
...
gcc -c -Iproto -DWIN32 ... fileio.c -o gobjZ/fileio.o
fileio.c:10306:1: error: expected declaration specifiers or '...' before
'(' token
fileio.c:10306:1: error: expected declaration specifiers or '...' before
'(' token
fileio.c:10306:1: error: expected declaration specifiers or '...' before
'(' token
fileio.c:10306:1: error: conflicting types for 'read'
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/io.h:452:37:
note: previous declaration of 'read' was here
fileio.c: In function 'read':
fileio.c:10309:13: error: declaration for parameter 'bufsize' but no
such parameter
fileio.c:10308:14: error: declaration for parameter 'buf' but no such
parameter
fileio.c:10307:13: error: declaration for parameter 'fd' but no such
parameter
fileio.c: At top level:
fileio.c:10327:1: error: expected declaration specifiers or '...' before
'(' token
fileio.c:10327:1: error: expected declaration specifiers or '...' before
'(' token
fileio.c:10327:1: error: expected declaration specifiers or '...' before
'(' token
fileio.c:10327:1: error: conflicting types for 'write'
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/io.h:458:37:
note: previous declaration of 'write' was here
fileio.c: In function 'write':
fileio.c:10330:13: error: declaration for parameter 'bufsize' but no
such parameter
fileio.c:10329:14: error: declaration for parameter 'buf' but no such
parameter
fileio.c:10328:13: error: declaration for parameter 'fd' but no such
parameter
make: *** [gobjZ/fileio.o] Error 1
Similar with VC8:
fileio.c(10306) : error C2143: syntax error : missing ')' before '('
fileio.c(10306) : error C2143: syntax error : missing ')' before '('
fileio.c(10306) : error C2091: function returns function
fileio.c(10306) : error C2091: function returns function
fileio.c(10306) : error C2059: syntax error : ')'
fileio.c(10306) : error C2373: 'read' : redefinition; different type
modifiers
H:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\io.h(329) : see
declaration of 'read'
fileio.c(10306) : error C2059: syntax error : 'type'
fileio.c(10310) : error C2449: found '{' at file scope (missing function
header?)
fileio.c(10320) : error C2059: syntax error : '}'
fileio.c(10330) : error C2449: found '{' at file scope (missing function
header?)
fileio.c(10348) : error C2059: syntax error : '}'
fileio.c(10348) : error C2014: preprocessor command must start as first
nonwhite space
fileio.c(10350) : fatal error C1070: mismatched #if/#endif pair in file
'h:\vim\vim\src\fileio.c'
A quick look shows that macros for read_eintr and write_eintr are being
defined as well as trying to compiler the code for them. So in vim.h EINTR
is undefined and in fileio.c it is undefined. Not a good idea.
EINTR is defined by errno.h. Attached patch moves include of errno.h to
the relevant os_win*.h from the respective os_win*.c files. The former
are included in vim.h, so EINTR will be defined before trying to define
the read_eintr/write_eintr macros.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
--
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
errno.diff
Description: Binary data
Re: Patch 7.3.083
2010/12/17 Bram Moolenaar b...@moolenaar.net: That's one fix. I think the other problems can be fixed by including vimio.h from vim.h, instead of only where it's needed. I've been thinking of this simplification before, now would be a right time to do it. Let me know if there are still problems after patch 7.3.085. That doesn't fix the EINTR definition problem. My earlier patch works, but maybe it makes sense to move the include of errno.h out of the os_(win*|mswin).c files altogether and into vimio.h? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Patch 7.3.083
On Fri, Dec 17, 2010 at 12:56 PM, Patrick Texier p.tex...@orsennes.com wrote: On Fri, 17 Dec 2010 12:30:01 -0500, James Vega wrote: Let me know if there are still problems after patch 7.3.085. That doesn't fix the EINTR definition problem. My earlier patch works, but maybe it makes sense to move the include of errno.h out of the os_(win*|mswin).c files altogether and into vimio.h? 7.3.083 + your patch gives me: .\fileio.c: Error E2453 .\fileio.c 10339: Size of the type 'void' is unknown or zero in function write_eintr *** 1 errors in Compile *** Yeah, my patch only addresses the EINTR problem. That error was handled by Dominique's patch and is fixed in 7.3.085. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: how to create tags file for vim source code ?
On Mon, Dec 13, 2010 at 09:12:18PM -0800, Gary Johnson wrote: On 2010-12-13, yang wrote: i use ctags ,and in the source code dir vim73/src ,i run ctags -R --c-kinds=+px --c++-kinds=+px --fields=+ialS --extra=+qf to crreate the tags file named tags, then i open the file buffer.c use vim, i can't for the var curbuf- , i get a message -- Omni completion (^O^N^P) Pattern not found ,i think ctags didn't create a tags for the vim source code corrently. That the message refers to omni completion and not to tags would suggest that you used the wrong command to try to find the tag. He's not trying to find the tag. He's trying to use omni-completion to complete curbuf-. That being said, I built the tags file the stated way and was able to perform said completion. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: SIGWINCH causes problems when editing stdin
On Wed, Dec 8, 2010 at 11:34 AM, Benjamin R. Haskell v...@benizi.com wrote: On Wed, 8 Dec 2010, Bram Moolenaar wrote: Xavier de Gaye wrote: On Mon, Dec 6, 2010 at 7:54 PM, Benjamin R. Haskell wrote: If Vim receives a SIGWINCH (_sig_nal that the _win_dow _ch_anged size) while editing stdin, a program piping input to Vim gets killed prematurely. Is there an easy way to avoid this? Actually, it is Vim that terminates prematurely. This is a bug in Vim: when vim receives the SIGWINCH signal, the vim_read() call that is reading stdin, returns -1 and vim handles that as an error in readfile(). [...] This looks like a hack. I think the proper solution is to have vim_read() check for EINTR and retry. I'm a bit confused about what happens when read() is interrupted before reading anything, does it return zero or -1? Perhaps this depends on the system. from `man 2 read` (on OpenSUSE) POSIX allows a read() that is interrupted after reading some data to return -1 (with errno set to EINTR) or to return the number of bytes already read. To me that implies, but doesn't explicitly state, that it *doesn't* return the number of bytes read [which is 0] if it *hasn't* read any bytes. It also seems like it would conflict with being able to detect EOF. Thus, I think it's safe to assume that an interrupted read() with no returned data returns -1. SUS[0] states it a bit more explicitly: If a read() is interrupted by a signal before it reads any data, it shall return -1 with errno set to [EINTR]. If a read() is interrupted by a signal after it has successfully read some data, it shall return the number of bytes read. [0]: http://www.opengroup.org/onlinepubs/009695399/functions/read.html -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Bug in clipboard support with multibyte charactors?
On Sat, Dec 04, 2010 at 04:28:07PM +0800, Yue Wu wrote: I also notice, the yanking is fine for xterm, but after leaving vim, the string will become garbled even when paste in xterm. This is due to the way that copy/pasting works in X. When you copy something, the applications just flags itself as owning the clipboard (*) or primary (+) selection. When you paste, the application receiving the paste checks whether any other application has claimed ownership of the proper selection and, if so, requests that application to provide the copied text. If you close the application which performed the copy, then there's no way to request that text from it. So some applications, like Vim and xterm, will also store the copied text into a deprecated facility called a cut buffer when they lose ownership of the selection (like when they quit). The problem here is that the cut buffer MUST be latin1 encoded. Long story short, if you want non-lossy cut/paste then leave Vim open until after you paste. Alternatively, install a clipboard manager (such as glipper or klipper) which monitors for ownership and immediately requests the contents of the copied text from the asserting application. You can also use a more manual tool like xclip to achieve the same effect. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Regex \%V question
On Thu, Nov 18, 2010 at 6:07 PM, Christian Brabandt cbli...@256bit.org wrote: Hi James! On Mo, 08 Nov 2010, James Vega wrote: On Mon, Nov 8, 2010 at 3:34 PM, Christian Brabandt cbli...@256bit.org wrote: On Fr, 05 Nov 2010, Benjamin R. Haskell wrote: Removing the optionality, it's also weird, as the trailing space (singular!?) isn't matched: /\%V\S\+\s*\%V x VVV VVV VVV x - text - match x VVV x - text - match Can anyone shed some light on this? This is a bug. The regular expression engine is quite complex in Vim. I think, the attached patch fixes it. What I see with your patch is that end of the match is including the first non-whitespace character after the end of the whitespace sequence. This means all matches other than the first start on the second non-whitespace character in the \S sequence and if the last non-whitespace sequence is only one character, the subsequent whitespace sequence won't be matched. Using the style from above (with alternating case for 'm' indicating the distinct matches): x VVV VVV V - text m - match Also, I see inconsistent highlighting with 'incsearch' enabled when the user has typed part of an escape sequence (e.g., '\' or '\%'). The highlighting for every line below some arbitrary line completely disappears until the escape sequence is completed. Performing a :redraw! or /Up may also trigger this. If this happens while typing the search string, complete the escape sequence, backspace to make it incomplete, complete it, etc. You'll see the portion of the file that's properly syntax highlighted increase every time you change the (in)complete status of the escape sequence. Not sure if it's related, but the patch also introduces this warning: regexp.c: In function ‘regtry’: regexp.c:3741: warning: comparison between pointer and integer Here is another patch, including a basic test, that should address all the issues. I couldn't reproduce the highlighting problem, though. This seems to work ok for me now for the test cases I could imagine. This does seem to work better. I'm still seeing the highlighting corruption with set hls is. I seem to have found another problem the patch introduces, though, as well as one that exists without the patch. Here's the introduced problem: $ printf foo\nbar\n testfile $ vim -u NONE -N --cmd 'set hls' testfile Set the visual block to contain both lines and place the cursor just after 'bar' on the second line C-vj$Esc Search for the test pattern, note that the cursor doesn't move off the r /\%V\S\+\s*\%V Attempt to jump to the next match of the pattern, cursor still doesn't move n For some reason, with the patch the r is trapping the cursor. If you move the cursor to the start of the file, and use n to cycle through the matches, you'll correctly land on the 'f' and 'b' and then jump to the 'r' and get stuck there. If you cycle backwards with N, the cursor won't get stuck but it does see the 'r' as a valid match. As for the existing problem that I discovered, use the same test file. Visually select only the foo line and perform the search. Now visually select only the bar line. Both foo and bar will be highlighted until a redraw is forced (via either C-l or :redraw!). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Regex \%V question
On Mon, Nov 22, 2010 at 1:09 PM, James Vega james...@jamessan.com wrote: On Thu, Nov 18, 2010 at 6:07 PM, Christian Brabandt cbli...@256bit.org wrote: Here is another patch, including a basic test, that should address all the issues. I couldn't reproduce the highlighting problem, though. This seems to work ok for me now for the test cases I could imagine. This does seem to work better. I'm still seeing the highlighting corruption with set hls is. I seem to have found another problem the patch introduces, though, as well as one that exists without the patch. The patch also seems to break test24 and test71. ../vim -u unix.vim -U NONE --noplugin -s dotest.in test24.in 21,22c21,22 x a xx a x a xx a --- xx a xx a xx a xx a ../vim -u unix.vim -U NONE --noplugin -s dotest.in test71.in 4,6c4,6 OK 1234567890123456789012345678901234567 OK ine 2 foo bar blah OK ine 3 xx --- OK 01234567890123456789012345678901234567 OK line 2 foo bar blah OK line 3 xx -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Small indent/perl.vim patch concerning bad match patterns
On Thu, Nov 18, 2010 at 07:17:47AM +0300, ZyX wrote:
Reply to message «»,
sent 01:16:59 18 November 2010, Thursday
by f...@herrmann-koenigsberg.de:
I guess i found a little bug in runtime/indent/perl.vim. perl.vim has some
patterns for matching opening and closing brackets. But perl.vim escapes
opening square brackets in square brackets. For example: match(line,
'[(){}\[\]]', bracepos + 1). Using \[ in between [] makes vim searching
for backslashes and opening square brackets. This causes lines following
lines with backslashes to be indented wrong.
I thought it should not (though vim help does contain nothing about
possibility
of escaping `['). Maybe it is better to allow escaping of `[':
Why? The reason ']' needs escaping is so that it isn't recognized as the
end of the character class. Although, I see that the different engines
already treat it differently. PCRE treats '\[' as '['. POSIX (and
extended) regex treat it like Vim does. Since Vim's regex is more like
POSIX's, it makes sense to act similarly, IMO.
I see `\[' in the
collections in the following files inside /usr/share/vim/vim73:
[snip]
These results were obtained after processing
grep -P '(?!\\)\[(\\\]|[^\]\n])*?\\\[' /usr/share/vim/vim73/**/*.vim
output (grep should have pcre support). There are some false positives, but
they
are not included in the above list. It looks like it is Vim who should be
fixed,
not perl syntax file.
Since when is people not following documented behavior a reason to
change the tool? I'd be more understanding if Vim didn't explicitly
outline the escape sequences it does allow inside a collection.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: Small indent/perl.vim patch concerning bad match patterns
On Thu, Nov 18, 2010 at 10:43 AM, ZyX zyx@gmail.com wrote: Reply to message «Re: Small indent/perl.vim patch concerning bad match patterns», sent 15:44:46 18 November 2010, Thursday by James Vega: Since when is people not following documented behavior a reason to change the tool? I'd be more understanding if Vim didn't explicitly outline the escape sequences it does allow inside a collection. Here are the reasons: 1. People assume that `\[' is `[', not `\\[', there are already lots of scripts that do need fixing and treating `\[' as `\\[' is non-obvious. That depends on your background. grep, sed, vi, etc. all exhibit the same behavior as Vim. 2. Other most popular regex engines treat `[\[]' as `\[', not as `(\\|\[)'. That really has no bearing on Vim since Vim doesn't use those other engines. The other engines chose to deviate from POSIX whereas Vim chose to follow vi (and therefore POSIX). The POSIX behavior predates the engines you're referring to. 3. Parenthesis matching has `\['-`\]' and `['-`]' pairs, not `['-`\]'. What does that have to do with anything? These aren't parenthesis. Characters inside a collection are individual. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Completion is painfully slow in Vim 7.3
On Tue, Nov 16, 2010 at 1:10 PM, eckes meliundec...@googlemail.com wrote: Let me guess: 7.2.274 -- Cheers, Lech Lorens No. The version I'm experiencing the problem with is the current Vim 7.3 build. What Lech meant was that the performance problems you're experiencing likely started with 7.2.274. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: saveas - loads ft plugin - changes dir - wrong filename problem
On Tue, Nov 16, 2010 at 2:35 PM, Kevin Klement klem...@philos.umass.edu wrote: Thanks for looking into this. I've removed all manually installed filetype plugins (--I didn't go so far as to change or remove the default ones--), and created a single one inside: ~/.vim/ftplugin/ named html.vim consisting of a single line: setlocal autochdir (it works with set autochdir too, and seems to work with variants of lcd ...) too. This line by itself seems to create the problem. In fact, I've never used a third-party html plugin, and the only other things I've ever had in my html.vim are relatively benign keymaps. In that case, the following seems to generate the problem most of the time. ~/tmp $ vim -u NONE -N :filetype plugin on :saveas ~/tmp/junk.html That made it pretty easy to reproduce. As the attached valgrind log shows, the src variable in home_replace is pointing to free'd memory. This appears to be the same memory being used by curbuf-b_sfname before running the filetype autocmd. I've attached a patch which appears to fix it, although I'm wary of the strcpy since I'm not sure we can guarantee there's enough space for the copy. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 vim.out Description: Binary data saveas.diff Description: Binary data
Re: using shellslash on windows.
On Mon, Nov 15, 2010 at 10:00 AM, mattn mattn...@gmail.com wrote: Bram, I'm looking for your reply. As Ben's said, cmd.exe can treat slash as path separator. That depends on the command that's being run. There are still commands which don't handle / as a path separator properly. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: [BUG] autoload variables are not available inside autoload functions
On Sun, Nov 14, 2010 at 07:06:21PM +0100, Andy Wokula wrote: Am 14.11.2010 18:53, schrieb ZyX: When I launch attached script I get the following output: test#var: abc Error detected while processing function test#Test: line1: E121: Undefined variable: test#var E15: Invalid expression: test#var 2: test#var: abc but the E121 error should not happen here. Tested no vim-7.3 from Gentoo repositories and on vim-7.3.55 (rev fcb916bed51a). ACK, it's a bug in Vim that it requires you to prepend the g: prefix (untested): That's not a bug. The default scope inside a function is l: so if you need to access some other scope, you have to use the proper prefix. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: make hitting enter work like OK button for gtk inputdialog()
On Thu, Nov 11, 2010 at 04:11:37PM -0800, John Little wrote: Thanks for this, it has bugged me for years. I've been pressing tab space to work around it. BTW, ...The Gtk docs ... Can you recommend any GTK docs or guides? I have other vim gtk nits I'd like to pick. http://library.gnome.org/devel/gtk/stable/ -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Patch 7.3.051
On Thu, Nov 11, 2010 at 06:28:49PM -0800, KF Leong wrote: Hi Bram, Does this actually work after hg push? It seems to fix a local repository, not a remote one. It does not, but quote from Mercurial site: You have a well-controlled development environment, where telling everyone to delete repository copies and re-clone is practical. Except for those people that weren't use the clone simply is a way to get the source, but are doing independent development. History editing is only viable before pushing the commits to a public repository or where the public branch/repository is specifically being used with history editing in mind. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Patch 7.3.050
On Wed, Nov 10, 2010 at 9:33 AM, Alexey I. Froloff ra...@altlinux.org wrote: On Wed, Nov 10, 2010 at 17:07, Bram Moolenaar b...@moolenaar.net wrote: It's a bit more complicated than that. Checking for tinfo before ncurses might work on some machines. But does it work everywhere? Or do we need to add checks for what the library needs to contain? If tinfo exists, then the symbols Vim uses will be there instead of in ncurses. AC_SEARCH_LIBS does look like the right way to check whether the system is using the split ncurses libs or the monolithic lib. If you use symbols from a library, you must link your application against this particular library, but not a library that is also linked against it. vim uses no symbols from libncurses itself, That obviously depends on how the libraries are built. Fedora/RedHat build ncurses using the --with-termlib configure option which splits the terminfo library out to its own file. I wonder how common that is and whether all the distributions which build with the split libraries use the same name. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Null reference when $PATH is empty.
On Mon, Nov 08, 2010 at 08:08:17PM -0800, mattn wrote:
vim crash when $PATH is empty.
below is a patch. check please.
- Yasuhiro Matsumoto
diff -r 1ccc1ace9e5b src/ex_getln.c
--- a/src/ex_getln.c Wed Nov 03 22:32:24 2010 +0100
+++ b/src/ex_getln.c Tue Nov 09 13:02:54 2010 +0900
@@ -4746,8 +4746,10 @@
else if ((pat[0] == '.' (vim_ispathsep(pat[1])
|| (pat[1] == '.' vim_ispathsep(pat[2])
path = (char_u *).;
-else
- path = vim_getenv((char_u *)PATH, mustfree);
+else {
+ if ((path = vim_getenv((char_u *)PATH, mustfree)))
+ path = ;
+}
This unilateraly replaces the value of $PATH, when it has one, with .
Instead of this change (which should have included an == NULL check),
why not add a != NULL check in the following for loop? Attached patch
includes that update.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
diff --git a/src/ex_getln.c b/src/ex_getln.c
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -4754,7 +4754,7 @@
* collect them in ga.
*/
ga_init2(ga, (int)sizeof(char *), 10);
-for (s = path; *s != NUL; s = e)
+for (s = path; s != NULL *s != NUL; s = e)
{
if (*s == ' ')
++s; /* Skip space used for absolute path name. */
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -232,7 +232,7 @@
* !xxd it's found in our starting directory. Needed because
* SearchPath() also looks there. */
p = mch_getenv(PATH);
- if (STRLEN(p) + STRLEN(exe_path) + 2 MAXPATHL)
+ if (p != NULL STRLEN(p) + STRLEN(exe_path) + 2 MAXPATHL)
{
STRCPY(temp, p);
STRCAT(temp, ;);
signature.asc
Description: Digital signature
Re: Regex \%V question
On Mon, Nov 8, 2010 at 3:34 PM, Christian Brabandt cbli...@256bit.org wrote: On Fr, 05 Nov 2010, Benjamin R. Haskell wrote: Removing the optionality, it's also weird, as the trailing space (singular!?) isn't matched: /\%V\S\+\s*\%V x VVV VVV VVV x - text - match x VVV x - text - match Can anyone shed some light on this? This is a bug. The regular expression engine is quite complex in Vim. I think, the attached patch fixes it. What I see with your patch is that end of the match is including the first non-whitespace character after the end of the whitespace sequence. This means all matches other than the first start on the second non-whitespace character in the \S sequence and if the last non-whitespace sequence is only one character, the subsequent whitespace sequence won't be matched. Using the style from above (with alternating case for 'm' indicating the distinct matches): x VVV VVV V - text m - match Also, I see inconsistent highlighting with 'incsearch' enabled when the user has typed part of an escape sequence (e.g., '\' or '\%'). The highlighting for every line below some arbitrary line completely disappears until the escape sequence is completed. Performing a :redraw! or /Up may also trigger this. If this happens while typing the search string, complete the escape sequence, backspace to make it incomplete, complete it, etc. You'll see the portion of the file that's properly syntax highlighted increase every time you change the (in)complete status of the escape sequence. Not sure if it's related, but the patch also introduces this warning: regexp.c: In function ‘regtry’: regexp.c:3741: warning: comparison between pointer and integer -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: [patch] Py_SetPythonHome for python3 to make import work
On Sun, Nov 07, 2010 at 06:04:35PM +0200, Roland Puntaier wrote: Hi Bram, After installing vim7.3 on a ubuntu system, I had again the problem that import did not work for .so libraries in lib-dynload. I found that sys.path was initialized with /usr/... instead of /usr/local/ On ubuntu (and probably on other linux distros as well) python3 is installed in /usr/local while python2 is installed in /usr. That's not the case at all[0]. No distribution package should install to /usr/local as that's a reserved directory structure for the system administrator[1]. If your Python3 install is in /usr/local, then whoever admins that system installed it there. The attached patch calls Py_SetPythonHome with PYTHON3_PREFIX defined by configure. This solves the problem. This does make sense for supporting people who have installed Python outside of the standard paths, though. This should probably be done for Python2.x as well. [0]: http://packages.ubuntu.com/maverick/i386/python3.1/filelist [1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: [patch] Py_SetPythonHome for python3 to make import work
On Sun, Nov 07, 2010 at 01:53:05PM -0500, James Vega wrote: On Sun, Nov 07, 2010 at 06:04:35PM +0200, Roland Puntaier wrote: The attached patch calls Py_SetPythonHome with PYTHON3_PREFIX defined by configure. This solves the problem. This does make sense for supporting people who have installed Python outside of the standard paths, though. This should probably be done for Python2.x as well. Would it make more sense to use Py_GetPrefix() or Py_GetExecPrefix() as the input to Py_SetPythonHome() instead? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
[patch] Skip flagging error when error not displayed
Bram,
Various of Vim's builtin functions suppress displaying error messages
(by default) and instead indicate an error via a specific return. A
simple example is expand(), which returns an empty string when the
expansion fails.
If any of these functions are evaluated as part of 'statusline' and
error, the statusline is disabled even though there is no error
message indicating to the user why it got disabled.
Set the following and then move the cursor to a blank line
:set statusline=%{expand('cword')}
The attached patch moves the check for suppressing error messages to
the top of emsg(). This provides the more intuitive behavior of only
flagging an error when a message was actually displayed to the user.
Thanks,
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
diff --git a/src/message.c b/src/message.c
--- a/src/message.c
+++ b/src/message.c
@@ -569,6 +569,10 @@
int severe;
#endif
+/* Skip this if not giving error messages at the moment. */
+if (emsg_not_now())
+ return TRUE;
+
called_emsg = TRUE;
ex_exitval = 1;
@@ -581,10 +585,6 @@
emsg_severe = FALSE;
#endif
-/* Skip this if not giving error messages at the moment. */
-if (emsg_not_now())
- return TRUE;
-
if (!emsg_off || vim_strchr(p_debug, 't') != NULL)
{
#ifdef FEAT_EVAL
signature.asc
Description: Digital signature
Re: getchar.c fails to compile
On Wed, Nov 03, 2010 at 11:24:15PM +0100, tux. wrote: geez - another broken thing... Can't compile getchar.c with VS2010 anymore. orig_rhs not defined @ 3291. Any clues? Line 3291 does contain the identifier orig_rhs, so it seems like you're using patched sources and there's something wrong with the patching. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Patch 7.3.043
On Wed, Oct 27, 2010 at 2:52 PM, tux. der_tux...@arcor.de wrote: Bram Moolenaar schrob am 27.10.2010 16:50: Patch 7.3.043 Problem: Can't load Ruby dynamically on Unix. Now this patch broke my build environment (VS2010): I don't have that auto/config.h file. What to change in order to make it work again? Update to 7.3.046. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: 7.3 unable to load ruby 1.9.2?
On Wed, Oct 20, 2010 at 12:19 PM, Bram Moolenaar b...@moolenaar.net wrote: This patch has made it possible to load Ruby dynamically on Unix. However, there is no patch for configure, thus one can't actually do this. Can somone make a patch for configure to load Ruby dynamically? Attached. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 dynamic-ruby.diff Description: Binary data
Re: [patch] Let helpztags support for other languages
Package: vim-common
Severity: wishlist
Tags: patch
On Fri, Oct 15, 2010 at 07:25:59AM +0900, tyru wrote:
today I found interesting program /usr/bin/helpztags
from output of dpkg -L vim-common on Ubuntu.
Which is something provided by the Debian packaging, so I've opened a
bug for you in the BTS to make sure I keep track of the patch.
so I run it to some of my plugins.
but helpztags only supports for .txt help file.
so I wrote the patch to fix it.
Thanks. Looks useful.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
--- helpztags.bak 2010-10-15 07:03:05.0 +0900
+++ helpztags 2010-10-15 07:11:35.0 +0900
@@ -51,9 +51,9 @@
foreach $dir (@ARGV) {
chdir $dir || die Error: $dir: no such directory\n;
print Processing .$dir.\n;
- open(TAGSFILE,tags) || die Error: Cannot open $dir/tags for writing.\n;
- foreach $file (*.{gz,txt}) {
-next unless $file =~ m/^[\w.-]+\.txt(?:.gz)?$/;
+ foreach $file (*.{gz,txt,??x}) {
+next unless $file =~ m/^[\w.-]+\.(txt|[a-zA-Z]{2}x)(?:.gz)?$/;
+$suffix=$1 eq 'txt' ? '' : -.substr($1, 0, 2);
do { open(GZ, zcat $file|) if ($file =~ /\.gz$/) } or open(GZ,$file);
while (GZ) {
# From vim61/src/ex_cmds.c, lines 5034-5036
@@ -66,8 +66,9 @@
}
}
close(GZ);
+open(TAGSFILE,tags$suffix) || die Error: Cannot open $dir/tags for writing.\n;
+map { print TAGSFILE $_\t$tags{$_}\t/*; s'\\''g; s'/'\/'g; print TAGSFILE $_*\n } sort keys %tags;
+close TAGSFILE;
}
- map { print TAGSFILE $_\t$tags{$_}\t/*; s'\\''g; s'/'\/'g; print TAGSFILE $_*\n } sort keys %tags;
- close TAGSFILE;
chdir $startdir;
}
signature.asc
Description: Digital signature
Re: [Bug Report] After saving a new file, the value of fileencoding does not change
On Mon, Oct 11, 2010 at 01:01:48AM +0800, H Xu wrote: Hello Bram, The way to reproduce it is simple: open a new file: vim test.txt test.txt must not exist. Then input some letters and use :w to save the file. now check the value of fileencoding: it is empty, while it should be some value. I don't think this is what intended to be. Thank you. It is intended and it's documented under the help section for ++enc: Note that when reading, the 'fileformat' and 'fileencoding' options will be set to the used format. When writing this doesn't happen, thus a next write will use the old value of the option. Same for the 'binary' option. :w ++enc=... is specifically for writing out a file with a different encoding but not changing the encoding of the buffer. If you want to actually change the encoding of the buffer and affect the encoding used when writing out the file, then :set fileencoding= -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: I seem to meet a clipboard bug related with unicode
On Tue, Sep 28, 2010 at 8:43 PM, SungHyun Nam gow...@gmail.com wrote: SungHyun Nam wrote: 1. If I don't quit selectcopied-gvim, then paste to gnome-terminal or other-gvim works fine. 2. If I quit selectcopied-gvim: o paste menu in gnome-terminal became disabled (and nothing happened if I click middle mouse button). o when I paste in other-gvim, hangul characters are now corrupted. How about acting like gnome-terminal? I mean 'no paste' for such a case. The reason that gnome-terminal changes from having Paste enabled to disabled is because Vim exited and released ownership of the clipboard. Since no program has ownership of the clipboard, there's nothing that gnome-terminal can paste from. When you paste in the other gvim, it sees that no application has ownership of the clipboard or primary selection, so it looks in CUT_BUFFER0 as a last resort to try and honor your request to paste. After all, you told Vim you want to paste so it's going to try to do what you told it to do. Since the text in CUT_BUFFER0 is the hangul you copied, converted to latin1 (resulting in '?' since it doesn't convert), that's what gets pasted. So, the reasonable approaches to resolve the issue, IMO, are a) leave the initial gvim open while you paste b) run a clipboard manager which, when it sees an application assert ownership of the clipboard, requests the contents from the application so that it can store it after the application quits c) see if Bram will accept a patch to add an option which disables the last ditch effort of storing the clipboard contents to CUT_BUFFER0. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: I seem to meet a clipboard bug related with unicode
On Tue, Sep 28, 2010 at 01:39:25AM +0400, Yuriy Kaminskiy wrote: SungHyun Nam wrote: 2010-09-23 AM 12:49, Young Ho Park wrote: Hello. I am a Vim user from South Korea. I seem to find the bug about cut(or copy) and paste. Let me explain steps to a paste fail. I use Vim7.2 in Gnome2.3 of Fedora13 or Ubuntu10.04 and my locale is ko_KR.utf8 0. I executed Vim. 1. I wrote Alphabet and Hangul mixed string. 2. I clicked a copy(or cut) button. 3. I closed Vim. 4. I executed Vim again. 5. I clicked a paste button. 6. English characters were well copied. But Hangul characters are changed to question marks like: ¿?¿?¿?¿? Is it a bug? Or didn't I turn on some options? More info about this problem. 1. If I don't quit selectcopied-gvim, then paste to gnome-terminal or other-gvim works fine. 2. If I quit selectcopied-gvim: o paste menu in gnome-terminal became disabled (and nothing happened if I click middle mouse button). o when I paste in other-gvim, hangul characters are now corrupted. Regards, namsh I think this was introduced in 7.2.221 patch, that tries a bit too much to follow standard on CUTBUFFER* encoding, rendering it useless for any non-latin1 locales. That's one of the reasons why people should be moving away from using cut buffers. They only support latin1 text and expecting other programs to interpret text in a cut buffer properly if it isn't latin1 isn't likely to work. The way X11's selections work, the client that owns the text being copied is expected to be running so it can respond to any paste requests. If you need to paste, either leave the client (Vim) open or run a clipboard manager so it will store the text between the copy, closing Vim, and pasting to something else. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Documentation update needed
On Tue, Aug 24, 2010 at 11:29:58AM -0700, Ben Fritz wrote:
1. :help :undolist does not include info about the saved column in
the command output
...
On a related note...what *does* the saved column mean? I assume it
has something to do with the :earlier {N}f and :later {N}f commands?
See Christian Brabandt's suggested patch in the [patch] document
undolist save column email from today.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: Plans for Mercurial branches?
On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar wrote: I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. This would have worked just fine (as I had mentioned the first time it was brought up). The expected way to resolve the end of a branch's development cycle is to merge it back into its parent. This would have prevented the problem that Tony raised about the default branch now having two heads. The vim73 head would still exist, but it could be marked as a closed branch if you didn't want it to show up in the default hg heads view. As such, people could still hg up vim73 to get the original version with no patches but it wouldn't clutter the default view. Speaking of extra heads, would it make sense to mark the spurious vim head as closed so it doesn't show up in the default view? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: RFC: use hunspell dictionaries
On Sun, Aug 15, 2010 at 12:47:42PM +1000, Brad Hubbard wrote: Sorry to bump a very old thread. I write in reference to https://bugzilla.redhat.com/show_bug.cgi?id=219777 and https://fedorahosted.org/fedora-engineering-services/ticket/12 As part of my work with Fedora Engineering Services I have been assigned the task of revisiting the possibility of modifying vim to use the hunspell dictionaries in an effort to save some space on our media. Personally, I like the idea of using existing spell-checking libraries and had spent some time working on allowing the use of libenchant[0] instead. I wasn't able to get around to finishing it, but it's still on my list of ideas to revisit. I went with enchant instead of directly using hunspell since enchant seems to provide the capability for better spell-checking across all languages due to being able to use different spell-checkers for different languages. [0]: http://www.abisource.com/projects/enchant/ -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Vim 7.3f: :r file fails when 'compatible'
On Sat, Aug 14, 2010 at 02:41:04PM +0200, Bram Moolenaar wrote: I wrote: Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary I don't know what autocommand that could be since I started Vim without plugins and :scriptnames shows nothing. This works without error if Vim is started in 'noncompatible' mode or when using Vim 6.3. I can reproduce it. Strange that nobody noticed until now. I'll fix it ASAP. It was most likely introduced by patch 7.2.132, sent out March 5 2009. This patch should fix it, please verify it doesn't introduce any new problems: That fixes the error message, but not the issue with the other buffer that I mentioned. $ printf foo\n mary $ vim -u NONE -i NONE existingfile :r mary :ls! 1 %a + existingfile line 2 2u#mary line 1 $ vim -u NONE -i NONE -N :r mary :ls! 1 %a + [No Name]line 2 2u#mary line 1 This only happens in 'nocompatible' mode or if there is an existing buffer loaded. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: test73 fails with shells that don't support '**'
On Mon, Aug 09, 2010 at 07:37:13PM -0400, James Vega wrote:
On Sun, Aug 08, 2010 at 11:12:01PM -0400, James Vega wrote:
On Mon, Aug 09, 2010 at 09:28:01AM +0800, Nazri Ramliy wrote:
I stumbled into this problem (works fine in my environment, but fails in
/bin/dash) when I first attempted to write test73.
At that point the find completion was implemented differently when on
windows (using mch_expandpath()) than when on unix (using globpath())
and it still contained the buggy 'recursive = TRUE' stuff, which is now
fixed in changeset 7ec9ada2cd81.
I could not reproduce the problem that you are reporting with the latest
vim (changeset 06a44c4eb3e5 Prepare for 7.3e release).
I thought I was using changeset 3607f126a661, but I can't reproduce it
now. I guess I was using an older version. Sorry for the noise.
Actually, I am still seeing this. I'll try to dig into why it's still
happening (only in my build environment).
Ok, I finally figured out what the environmental trigger is. The
directory I perform the builds in has a '~' in the name, which triggers
the dive into mch_expand_wildcards. This is happening even though the ~
is in the middle of the path instead of at the beginning. Attached
patch fixes this.
(gdb) bt
#0 mch_expand_wildcards (num_pat=0, pat=0xbffd65fc, num_file=0xbffd677c,
file=0xbffd6778, flags=35) at os_unix.c:5421
#1 0x0811660c in gen_expand_wildcards (num_pat=1, pat=0xbffd65fc,
num_file=0xbffd677c, file=0xbffd6778, flags=35) at misc1.c:9729
#2 0x08116810 in expand_wildcards (num_pat=1, pat=0xbffd65fc,
num_file=0xbffd677c, file=0xbffd6778, flags=35) at misc1.c:8552
#3 0x081169ef in expand_wildcards_eval (pat=0xbffd665c, num_file=0xbffd677c,
file=0xbffd6778, flags=35) at misc1.c:8523
#4 0x080ca9a2 in ExpandFromContext (xp=value optimized out,
pat=0x888fe20
/home/jamessan/src/packages/deb-packages/vim/vim-7.3e.20100809+hg~06a44c4eb3e5/src/vim-nox/testdir/Xfind/**/file*,
num_file=value optimized out,
file=0xbffd6778, options=64) at ex_getln.c:4460
#5 0x080ca446 in globpath (path=0x888fe13 , file=0x888c0f0 file*,
expand_options=value optimized out) at ex_getln.c:5053
#6 0x0811674e in expand_in_path (num_pat=1, pat=0xbffd693c,
num_file=0xbffd6c1c, file=0xbffd6c20, flags=171) at misc1.c:9582
#7 gen_expand_wildcards (num_pat=1, pat=0xbffd693c, num_file=0xbffd6c1c,
file=0xbffd6c20, flags=171) at misc1.c:9751
#8 0x08116810 in expand_wildcards (num_pat=1, pat=0xbffd693c,
num_file=0xbffd6c1c, file=0xbffd6c20, flags=171) at misc1.c:8552
#9 0x081169ef in expand_wildcards_eval (pat=0xbffd699c, num_file=0xbffd6c1c,
file=0xbffd6c20, flags=171) at misc1.c:8523
#10 0x080ca9a2 in ExpandFromContext (xp=value optimized out, pat=0x888c0f0
file*, num_file=value optimized out, file=0xbffd6c20, options=218) at
ex_getln.c:4460
#11 0x080cb82b in ExpandOne (xp=0xbffd6c00, str=0x888c0f0 file*,
orig=0x888c878 file, options=218, mode=3) at ex_getln.c:3488
#12 0x080cd616 in nextwild (xp=0xbffd6c00, type=3, options=value optimized
out) at ex_getln.c:3311
#13 0x080cf65e in getcmdline (firstc=58, count=1, indent=0) at ex_getln.c:803
#14 0x080c13b8 in do_cmdline (cmdline=0x0, getline=0x80d10a0 getexline,
cookie=0x0, flags=value optimized out) at ex_docmd.c:1018
#15 0x0813268f in nv_colon (cap=0xbffd718c) at normal.c:5319
#16 0x081344fc in normal_cmd (oap=0xbffd7220, toplevel=1) at normal.c:1190
#17 0x080f647b in main_loop (cmdwin=0, noexmode=0) at main.c:1263
#18 0x080f8cb3 in main (argc=7, argv=0xbffd7454) at main.c:968
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org
diff --git a/src/misc1.c b/src/misc1.c
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9722,7 +9722,7 @@
* variable, use the shell to do that. Discard previously
* found file names and start all over again.
*/
- else if (vim_strpbrk(p, (char_u *)$~) != NULL)
+ else if (p[0] == '~' || vim_strpbrk(p, (char_u *)$) != NULL)
{
vim_free(p);
ga_clear_strings(ga);
signature.asc
Description: Digital signature
Re: Vim 7.3: Python3 support
On Mon, Aug 09, 2010 at 12:58:20PM +0200, Bram Moolenaar wrote: Roland Puntaier wrote: Hello Bram, sorry about my late response, first I was on holiday, then I was quite busy. I compared the vim7.3d sources to my original ones on Saturday. Most of the functions are basically the same, but I spotted a relevant difference: I had: #define load_dll(n) dlopen((n),RTLD_LAZY) Vim 7.3 has: #define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL) I recalled, that back then I had had the same crash, probably because global static variables got mixed up. I made the test in Vim 7.3: After removing RTLD_GLOBAL there was no crash any more. If I'm not mistaken this flag was added to make import termios work. Or something like that. Right. It's needed to be able to load any of the C extensions on systems where they aren't linked to libpython. I know this is the case on Debian-based systems. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Vim 7.3: Python3 support
On Mon, Aug 9, 2010 at 9:49 AM, Roland Puntaier roland.punta...@br-automation.com wrote: On Mon, 09 Aug 2010 13:49:43 Andy Kittner and...@gmx.de wrote: I made the test in Vim 7.3: After removing RTLD_GLOBAL there wasno crash any more. If I'm not mistaken this flag was added to make import termios work. Or something like that. The issue was that at least on some systems pythons C-Extensions seemingly aren't linked against the python shared library, therefore they can't be imported unless the host application provides the required symbols. See this thread: Linking errors when compiled with both python and python3 http://groups.google.com/group/vim_dev/browse_frm/thread/10be77eb81ad1c2d/fed7c6d9e3932ef5?tvc=1 Hi Bram, I missed that thread. I had the same problem with PyQt 4.7, first, but at a later try it worked, probably because that linked against libpython 3.1.2. Andy reported termios to work as well on his system. Maybe the problematic termios was older or not linked against libpython, because it was not there at the time termios was configured. termios is a standard module in the Python distribution, so it seems to be up to the build process that's used. I've checked my Fedora system and the lib-dynload modules there aren't linked against libpython either. So, it looks like at least Debian and Red Hat based distros don't link the lib-dynload modules against libpython. Maybe we can optimistically assume that for most python libraries / systems it works. I would opt for the following: If only one, Python 2.x xor Python 3.x, is configured (and if DYNAMIC_PYTHON), then use RTLD_GLOBAL: #define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL) If both are configured use without RTLD_GLOBAL: #define load_dll(n) dlopen((n),RTLD_LAZY) I would instead suggest a configure-time check to determine whether it's possible to load one of the lib-dynload modules without RTLD_GLOBAL set. Simply deciding not to use RTLD_GLOBAL because both Python versions have been chosen means that neither will work on systems where the lib-dynload modules aren't linked against libpython since some of the lib-dynload modules are always used by Python. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
[patch] Remove shadowdir symlinks in clean
If a shadowdir is used for building, symlinks for the runtime and pixmaps directory are created in src/ but they aren't removed by the clean target. Attached patch removes them. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 shadowdir-clean.diff Description: Binary data
Re: test73 fails with shells that don't support '**'
On Sun, Aug 08, 2010 at 11:12:01PM -0400, James Vega wrote: On Mon, Aug 09, 2010 at 09:28:01AM +0800, Nazri Ramliy wrote: I stumbled into this problem (works fine in my environment, but fails in /bin/dash) when I first attempted to write test73. At that point the find completion was implemented differently when on windows (using mch_expandpath()) than when on unix (using globpath()) and it still contained the buggy 'recursive = TRUE' stuff, which is now fixed in changeset 7ec9ada2cd81. I could not reproduce the problem that you are reporting with the latest vim (changeset 06a44c4eb3e5 Prepare for 7.3e release). I thought I was using changeset 3607f126a661, but I can't reproduce it now. I guess I was using an older version. Sorry for the noise. Actually, I am still seeing this. I'll try to dig into why it's still happening (only in my build environment). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
test73 fails with shells that don't support '**'
When running tests in my build environment, I noticed that test73 kept
failing while it would work fine in my normal environment. Turns out
this is because my build environment uses dash[0] for /bin/sh, which
doesn't support ** wildcards (since they're not specified by POSIX).
Poking around, I see that unix_expandpath handles ** regardless of shell
by doing its own expansion. Would it make sense to use unix_expandpath
to handle the ** when mch_expand_wildcards needs STYLE_VIMGLOB ('shell'
is sh) or STYLE_ECHO (unknown shell)?
[0]: http://gondor.apana.org.au/~herbert/dash/
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: test73 fails with shells that don't support '**'
On Mon, Aug 09, 2010 at 09:28:01AM +0800, Nazri Ramliy wrote: I stumbled into this problem (works fine in my environment, but fails in /bin/dash) when I first attempted to write test73. At that point the find completion was implemented differently when on windows (using mch_expandpath()) than when on unix (using globpath()) and it still contained the buggy 'recursive = TRUE' stuff, which is now fixed in changeset 7ec9ada2cd81. I could not reproduce the problem that you are reporting with the latest vim (changeset 06a44c4eb3e5 Prepare for 7.3e release). I thought I was using changeset 3607f126a661, but I can't reproduce it now. I guess I was using an older version. Sorry for the noise. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Question about :find completion support in Vim 7.3b
On Thu, Aug 05, 2010 at 09:56:29PM +0200, Bram Moolenaar wrote: Nazri Ramliy wrote: test73.in should now run successfully on both unix and windows. Thank you very much for fixing the problems and enhancing the test. I'll include this and check that it works for me. The Xfind directory wasn't removed, you had the last :cd commented-out. Hmm, the test passes, but it rings the bell a lot. I can fix one (the empty line). The others appear to be for when completion of :find fails. I'm not sure how to avoid that. I'll add :set visualbell. Attached patch also adjusts 'viminfo' appropriately so that the user's viminfo isn't overwritten. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com diff --git a/src/testdir/test73.in b/src/testdir/test73.in --- a/src/testdir/test73.in +++ b/src/testdir/test73.in @@ -5,7 +5,7 @@ : delete the Xfind directory during cleanup : : This will cause a few errors, do it silently. -:set visualbell +:set nocp viminfo+=nviminfo visualbell : :function! DeleteDirectory(dir) : if has(win16) || has(win32) || has(win64) @@ -17,7 +17,6 @@ : On windows a stale Xfind directory may exist, remove it so that : we start from a clean state. :call DeleteDirectory(Xfind) -:set nocp :new :let cwd=getcwd() :!mkdir Xfind signature.asc Description: Digital signature
Re: Vim 7.3: Python3 support
On Fri, Aug 6, 2010 at 3:16 PM, Bram Moolenaar b...@moolenaar.net wrote: Roland - You have been quiet for a while. I still have the workaround that in one Vim session one can only use either :python or :py3 to avoid problems mixing the shared library. Is there a better solution? As far as I know, the only way to do this would be to run distinct processes for each interpreter in order to keep the libraries from running in the same namespace. So, any :py* or :py3* command would start a separate process, dlopen the library, load the symbols, run whatever command was requested, and then exit. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: PHP syntax script problem
On Thu, Aug 05, 2010 at 11:52:58AM -0400, Benjamin R. Haskell wrote: Roughly, from what I can tell: :vglobal/\S/ -- for all lines without non-whitespace (i.e. forall blank lines): ,-- repeat last f F t T search (or does ',' do something different here?) /\S/ -- find next non-whitespace line The comma behavior you describe is for normal mode. Here it is being used to delimit a range (:help cmdline-ranges). ,/\S/ is the same as .,/\S/. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Corrupt display with multi-byte 'listchars'
Using a recent version of the vim73 repo (e037ee8598b3), the below steps show some display corruption. From Vim's source directory, use the attached test.vim as follows and perform a search for text -- /textCR. $ vim -u test.vim -N runtime/syntax/tex.vim Namely, the cursor is displayed in an incorrect position but 'ga' does show that it is on the 't' from texTypeSize. Also, the search causes a fold to open and remnants of the 'foldtext' is still displayed. :redraw! will clear the remnants of the 'foldtext' but the other display corruption still exists. Issuing :set list! to toggle the list characters on and off will show that the cursor is at the start of the match, as expected, and that enabling 'list' changes the display of items other than those being covered by 'list'. For example, some of the groups listed in the contains list for texCmdGroup get garbled when 'list' is enabled. So far, I've only been able to reproduce this when viewing the tex syntax file. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 test.vim Description: Binary data
Re: Corrupt display with multi-byte 'listchars'
On Wed, Aug 4, 2010 at 12:04 PM, James Vega james...@jamessan.com wrote: So far, I've only been able to reproduce this when viewing the tex syntax file. That would be because tex.vim added 'ambiwidth=double' to its modeline in changeset f8f81a88a047. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Corrupt display with multi-byte 'listchars'
On Wed, Aug 4, 2010 at 12:49 PM, James Vega james...@jamessan.com wrote: On Wed, Aug 4, 2010 at 12:04 PM, James Vega james...@jamessan.com wrote: So far, I've only been able to reproduce this when viewing the tex syntax file. That would be because tex.vim added 'ambiwidth=double' to its modeline in changeset f8f81a88a047. Apparently, some of the characters I use in my 'listchars' settings (Middle Dot (U+00B7) and Section Sign (U+00A7)) have ambiguous width. I can workaround the issue with Middle Dot by using Dot Operator (U+22C5) instead, but the only replacement I've found for Section Sign is Paragraph Separator (U+2029). Only problem with that is it's considered whitespace, so it doesn't display anything useful. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: lua available in win32 7.3 beta
On Tue, Aug 03, 2010 at 04:24:00AM +0200, Tux wrote: Luis Carvalho schrob am 03.08.2010 04:15: 2. Compile: after installing Lua, just compile Vim with, say, nmake -f Make_mvc.mak GUI=yes OLE=yes LUA=C:\Progra~1\Lua\5.1 DYNAMIC_LUA=yes That's (almost) how I do it. Hmm, MzScheme; I would have included it in my builds if I had found a native Win32 version. But I haven't, so i haven't. Any hints? Racket (formerly called PLT Scheme) is available at http://www.racket-lang.org/. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: [patch] Add logcheck filetype
On Wed, Jul 28, 2010 at 9:08 AM, Bram Moolenaar b...@moolenaar.net wrote: James Vega wrote: Attached patch adds support for detecting logcheck's[0] rules files[1] as the logcheck filetype. The one use, so far, is to disable automatic wrapping of text since each line is supposed to contain a single regular expression. A pattern that ends in a star needs special handling, otherwise it overrules all other filetype checks. See near the end of the filetype.vim file. Right. I always forget about that. Updated patch attached. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 logcheck.diff Description: Binary data
Re: Upcoming GTK and GDK changes
On Wed, Jul 28, 2010 at 9:50 AM, Dennis Benzinger dennis.benzin...@gmx.net wrote: I've just read http://blogs.gnome.org/otte/2010/07/27/rendering-cleanup/ and did a quick search in Vim's source. It looks like Vim is affected by this changes. But I'm not a GTK or GDK programmer. Could someone please confirm that Vim has to be updated? The changes described in that post are targeted to Gtk3. It is known that Vim will require some significant changes to work with Gtk3. This is something on my list of items to look into, but it will take me some time to get to it so anyone else that has time is welcome to do the work. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: syntax/tex.vim and conceal support
On Wed, Jul 28, 2010 at 9:55 AM, Charles Campbell charles.e.campb...@nasa.gov wrote: The new tex syntax file supports setting conceallevel to 2 with utf-8 by showing appropriate glyphs for Greek in math, a few math symbols in math, and a number of accented characters. Why does the definition of the conceal syntax rely on enc == 'utf-8'? Removing those constraints and specifying the script is in utf-8 encoding (as in the attached patch) seems to work fine for me. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 tex-enc.diff Description: Binary data
Re: syntax/tex.vim and conceal support
On Wed, Jul 28, 2010 at 1:38 PM, Charles Campbell charles.e.campb...@nasa.gov wrote: However, the if has(conceal) enc == utf-8 lines are still needed. With enc.vimrc as: -- set nocp syn on set cole=3 -- and using -- vi -u enc.vimrc -c :e ++enc=latin abc.tex -- The '++enc=latin1' solely changes what fenc is. Since the actual contents of the file are all ASCII, this doesn't actually change anything. If you meant that you're running in a UTF-8 locale (like en_US.UTF-8) and you ran: env LC_ALL=en_US.ISO8859-1 vi -u enc.vimrc abc.tex then you're right, but only because your terminal is expecting UTF-8 bytes and you've told Vim (tangentially) to send latin1 bytes to the terminal. set tenc=utf-8 will cause Vim to display all the glyphs which exist in both UTF-8 and latin1 correctly and the others using the an upside-down question mark (for me) instead of the unknown character glyph. This sounds like maybe the conceal feature is relying on enc instead of tenc for determining whether the concealed characters should be displayed, which would be a bug IMO. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Re: Looking for test coordinator
On Wed, Jul 28, 2010 at 11:18:42PM +0200, Dominique Pellé wrote: 4/ Some bugs can also be found if we test Vim on different OS. How about keeping track of whether Vim successfully compiles and passes all tests on: - Linux (x86, x86_64, ARM, MIPS, ... ) - Windows 95, 98, NT, 2000, XP, Vista, 7 (32 64 bits) - Cygwin-1.5, Cygwin-1.7 - OS-X - OpenBSD, HP-UX, Solaris, AIX... - and the more exotic zOS, vms, qnx, AmigaOS, BeOS, RISC-OS (others?) We sort of get this (at least for Linux) with the Debian packages. As of this email, Debian's packages get built on 14 different architectures. As part of the build, I run the test suite, albeit only with the binary that produces the vim binary package[0]. I could look into changing that to use a binary with the language interpreters enabled so those portions of the test suite get run. I monitor the build logs[1] when I upload a new version of the package to Debian for any test failures and then triage failures. We have a porter team for each architecture (in some state of activity) which can be consulted if there's an architecture-specific problem that's flagged. [0]: --enable-cscope --with-features=huge --enable-multibyte --without-x --enable-gui=no, and --enable-gpm on linux kernels. [1]: https://buildd.debian.org/vim -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
