Fwd: Re: macosx x11/motif gvim-7.3.706+ E250 dialog on startup
hi, i originally started this thread on vim_use but think it might have been better on vim_dev. in short, is there any way i can get an x11/motif gvim-7.3.706+ not to emit a large, ugly E250 message and continue prompt everytime it starts? i include a little patch that i can resort to loocally but it completely eradicates the E250 message which others presumably want so it doesn't seem like a good idea in general. cheers, raf - Forwarded message from raf r...@raf.org - Subject: Re: macosx x11/motif gvim-7.3.706+ E250 dialog on startup From: raf r...@raf.org To: vim_...@googlegroups.com Date: Wed, 17 Apr 2013 12:05:31 +1000 Delivered-To: r...@pooka.fabcat.org Mail-Followup-To: vim_...@googlegroups.com Reply-To: vim_...@googlegroups.com Tony Mechelynck wrote: On 16/04/13 06:47, raf wrote: hi, i just installed an x11/motif version of vim-7.3.905 from source on macosx-10.6.8 and, every time it starts, i get an error dialog that says: E250: Fonts for the following charsets are missing in fontset -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1: [...lots of charsets elided...] my font is: set guifont=-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 it works fine up to patch 7.3.696. the motif version doesn't compile between patches 7.3.697 and 7.3.705. the error message appears as of patch 7.3.706 which got the motif version to compile again. 7.3.697 is about leaking resources when setting GUI font which means at least some font routines were changed. A quick search through ftp://ftp.vim.org/pub/vim/patches/7.3/README shows some other font-related patchlevels after that, but all concerning either MS-Windows or 'guifontwide'. Have you set the 'guifontset' and/or 'guifontwide' options? Doing :verbose set gfs? gfw? will tell you. I recommend to leave them at their empty default unless (a) you know what you do, and (b) you have ÜBER-extra-super-hyper-duper-important reasons not to leave them empty. no. i only set guifont. and, as i said, the problem happens even when guifont is not set to anything (i.e. its default value) and with gvim -u NONE -U NONE. What happens if you use :set gfs= gfw= gfn=-*-courier-medium-r-normal-*-*-120-*-*-m-*-* ? This is a pretty common font, and (I hope) should not give errors. fixed is also a very common font in X11. it's in every installation and always has been. but to answer the question, setting guifont interactively is not an issue. there's no error there whether i use fixed or courier. the problem is setting guifont in ~/.gvimrc (or just starting the gui without setting the font) which causes the error message and the need to Press ENTER or type command to continue before i can see the file content. the error message i get for -*-courier-medium-r-normal-*-*-120-*-*-m-*-* is very similar: E250: Fonts for the following charsets are missing in fontset -*-courier-medium-r-normal-*-*-120-*-*-m-*-*-*: ISO8859-5 KOI8-R ISO8859-7 JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 JISX0201.1976-0 E250: Fonts for the following charsets are missing in fontset -*-courier-medium-r-normal-*-*-120-*-*-m-*-*-*: ISO8859-5 KOI8-R ISO8859-7 JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 JISX0201.1976-0 so it's not the choice of font that is the problem. it is the fact that vim thinks that it needs to warn me about the fact that certain obscure character sets that i don't use are not supported by the chosen (or default) font. OTOH, if even the above generalized Courier font gives you similar errors, then maybe there are needed X11 fonts which haven't been installed on your system. In that case, check the optional packages available for your OS, and see if some of them aren't about fonts, or maybe about language packs. the font is working fine. i shouldn't have to install extra versions of a font for character sets that i am never going to use just to suppress this error message. See also http://vim.wikia.com/wiki/Setting_the_font_in_the_GUI thanks but that doesn't mention anything about suppressing this error message. Best regards, Tony. thanks for the attempt. it's appreciated. what would fix the problem is the following patch: --- src/syntax.c.orig 2013-04-17 10:49:07.0 +1000 +++ src/syntax.c2013-04-17 10:49:21.0 +1000 @@ -8054,7 +8054,7 @@ fontset_name2handle(name, fixed_width) if (STRCMP(name, NONE) == 0) return NOFONTSET; -return gui_mch_get_fontset(name, TRUE, fixed_width); +return gui_mch_get_fontset(name, FALSE, fixed_width); } # endif the FALSE disables the warning but that seems a bit harsh. presumably someone else wants this error message to appear. alternatively, passing --disable-fontset to configure should make it go away but it doesn't. src/feature.h contains the following which turns it back on: # if !defined(FEAT_XFONTSET) defined(HAVE_X11) !defined(FEAT_GUI_GTK) # define
Re: Command line completion doesn't use . and ,, in path: Bug?
On Tue, Apr 16, 2013 at 4:31 PM, Nazri Ramliy ayieh...@gmail.com wrote: I can reproduce this with my gvim 7.3.46 (on linux vim 7.3.892 there's no problem). I'll investigate and hopefully post a fix soon. I found the problem and the solution. Problem summary: expand_path_option() leaves trailing path separators after expanding the path option. These expanded paths are passed to globpath(), which then fed them to copy_option_part() as a comma-separated list of paths. On windows the presence of the trailing path separator before the comma causes copy_option_part() to not work as intended as it treats the backslash as escaping the commas. Solution: Fix expand_path_option to not leave a trailing path separators when expanding the 'path' option. Example problem: With 'path' set to .,,, and editing the file c:\foo\bar.txt, from the directory c:\, and doing :find quutab, expand_path_option() expands the .,, to: c:\foo\,c:\ Which is wrongly treated as a single option value by copy_option_part() Compare the same behavior on unix: when editing /foo/bar.txt and the current directory is /, expand_path_option() expands the .,, to: /foo/,/ This is seen as two option values by copy_option_part() Attached patch fixes this problem. It adds a test case that shows the problem - note that the problem only happen on windows, so the test fails on windows but ran successfully on unix. Nazri. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. findfix.patch Description: Binary data
Re: Command line completion doesn't use . and ,, in path: Bug?
On 18-Apr-2013 14:14 +0200, Nazri Ramliy wrote:
On Tue, Apr 16, 2013 at 4:31 PM, Nazri Ramliy ayieh...@gmail.com wrote:
I can reproduce this with my gvim 7.3.46 (on linux vim 7.3.892 there's no
problem). I'll investigate and hopefully post a fix soon.
I found the problem and the solution.
Problem summary:
expand_path_option() leaves trailing path separators after expanding the
path option. These expanded paths are passed to globpath(), which then
fed them to copy_option_part() as a comma-separated list of paths. On
windows the presence of the trailing path separator before the comma
causes copy_option_part() to not work as intended as it treats the
backslash as escaping the commas.
Solution:
Fix expand_path_option to not leave a trailing path separators when
expanding the 'path' option.
Please note that for the root directory, C:\ is different than C: (which
means the current working directory of the C drive), so leaving off the
trailing path separator may cause problems in this case. (I haven't
checked your patch, but :echo globpath('C:', '*') returns different
results than :echo globpath('C:\', '*') after :cd C:\windows.
-- regards, ingo
Example problem:
With 'path' set to .,,, and editing the file c:\foo\bar.txt, from the
directory c:\, and doing :find quutab, expand_path_option() expands
the .,, to:
c:\foo\,c:\
Which is wrongly treated as a single option value by copy_option_part()
Compare the same behavior on unix:
when editing /foo/bar.txt and the current directory is /,
expand_path_option() expands the .,, to:
/foo/,/
This is seen as two option values by copy_option_part()
Attached patch fixes this problem. It adds a test case that shows the
problem - note that the problem only happen on windows, so the test
fails on windows but ran successfully on unix.
Nazri.
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On Thu, April 18, 2013 15:06, Ingo Karkat wrote:
Please note that for the root directory, C:\ is different than C: (which
means the current working directory of the C drive), so leaving off the
trailing path separator may cause problems in this case. (I haven't
checked your patch, but :echo globpath('C:', '*') returns different
results than :echo globpath('C:\', '*') after :cd C:\windows.
That is interesting, because the echo globpath('C:', '*') result is
rather useless here:
,
|C:111.txt
|C:stats-sql.txt
|C:test.txt
`
Note the missing slash. And C: here stands for c:\temp, so the output
is rather useless in this case.
This looks like another bug here.
regards,
Christian
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On 18-Apr-2013 15:15 +0200, Christian Brabandt wrote:
On Thu, April 18, 2013 15:06, Ingo Karkat wrote:
Please note that for the root directory, C:\ is different than C: (which
means the current working directory of the C drive), so leaving off the
trailing path separator may cause problems in this case. (I haven't
checked your patch, but :echo globpath('C:', '*') returns different
results than :echo globpath('C:\', '*') after :cd C:\windows.
That is interesting, because the echo globpath('C:', '*') result is
rather useless here:
,
|C:111.txt
|C:stats-sql.txt
|C:test.txt
`
Note the missing slash. And C: here stands for c:\temp, so the output
is rather useless in this case.
This looks like another bug here.
No, this is just the unusual but valid notation. Without the backslash
after the drive letter, this means this path from the current working
directory of the preceding drive letter. Therefore, this works:
:cd C:\Windows
:edit C:win.ini
Existing file opens.
:echo expand('%:p')
C:\Windows\win.ini
-- regards, ingo
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On Thu, April 18, 2013 15:32, Ingo Karkat wrote:
On 18-Apr-2013 15:15 +0200, Christian Brabandt wrote:
On Thu, April 18, 2013 15:06, Ingo Karkat wrote:
Please note that for the root directory, C:\ is different than C:
(which
means the current working directory of the C drive), so leaving off the
trailing path separator may cause problems in this case. (I haven't
checked your patch, but :echo globpath('C:', '*') returns different
results than :echo globpath('C:\', '*') after :cd C:\windows.
That is interesting, because the echo globpath('C:', '*') result is
rather useless here:
,
|C:111.txt
|C:stats-sql.txt
|C:test.txt
`
Note the missing slash. And C: here stands for c:\temp, so the output
is rather useless in this case.
This looks like another bug here.
No, this is just the unusual but valid notation. Without the backslash
after the drive letter, this means this path from the current working
directory of the preceding drive letter. Therefore, this works:
:cd C:\Windows
:edit C:win.ini
Existing file opens.
:echo expand('%:p')
C:\Windows\win.ini
I'd still prefer to have the glob return an absolute path an not such
a silly name. You can't even copy and paste that string.
Would it hurt to have globpath() in that case return an
absolute path?
regards,
Christian
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On 18-Apr-2013 15:15 +0200, Christian Brabandt wrote:
On Thu, April 18, 2013 15:32, Ingo Karkat wrote:
On 18-Apr-2013 15:15 +0200, Christian Brabandt wrote:
On Thu, April 18, 2013 15:06, Ingo Karkat wrote:
Please note that for the root directory, C:\ is different than C:
(which
means the current working directory of the C drive), so leaving off the
trailing path separator may cause problems in this case. (I haven't
checked your patch, but :echo globpath('C:', '*') returns different
results than :echo globpath('C:\', '*') after :cd C:\windows.
That is interesting, because the echo globpath('C:', '*') result is
rather useless here:
,
|C:111.txt
|C:stats-sql.txt
|C:test.txt
`
Note the missing slash. And C: here stands for c:\temp, so the output
is rather useless in this case.
This looks like another bug here.
No, this is just the unusual but valid notation. Without the backslash
after the drive letter, this means this path from the current working
directory of the preceding drive letter. Therefore, this works:
:cd C:\Windows
:edit C:win.ini
Existing file opens.
:echo expand('%:p')
C:\Windows\win.ini
I'd still prefer to have the glob return an absolute path an not such
a silly name. You can't even copy and paste that string.
Would it hurt to have globpath() in that case return an
absolute path?
It's not silly, you're just not used to it! (I started with CP/M and
MS-DOS 5; maybe I have a different perspective.) It's a
fixed-drive-relative-path; you wouldn't expect ../../foo to be
copypaste-able, neither, would you?
globpath() does not return absolute paths for other more benign relative
paths such as '.', so I'm against adding a special case. Sorry. Anyway,
I'm more interested whether the proposed patch has a problem...
-- regards, ingo
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On Thu, April 18, 2013 15:45, Ingo Karkat wrote: It's not silly, you're just not used to it! (I started with CP/M and MS-DOS 5; maybe I have a different perspective.) That is the case. I started with MS-DOS 4.X and have never come across that. But ok, may be it is just my expectation. regards, Christian -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On Thu, Apr 18, 2013 at 9:06 PM, Ingo Karkat sw...@ingo-karkat.de wrote:
Please note that for the root directory, C:\ is different than C: (which
means the current working directory of the C drive), so leaving off the
trailing path separator may cause problems in this case. (I haven't
checked your patch, but :echo globpath('C:', '*') returns different
results than :echo globpath('C:\', '*') after :cd C:\windows.
Thanks for the notice. I'll look into this again. My initial approach at
solving this was to replace all backslashes in the expanded path parts
into forward slashes but that seemed a bit too blankety of a solution
at that time.
Maybe it's not a bad idea after all.
nazri
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On Thu, Apr 18, 2013 at 10:11 PM, Nazri Ramliy ayieh...@gmail.com wrote: Thanks for the notice. I'll look into this again. My initial approach at solving this was to replace all backslashes in the expanded path parts into forward slashes but that seemed a bit too blankety of a solution at that time. Maybe it's not a bad idea after all. Here's another attempt. This time we check if the expanded path ends with a path separator then we replace it with forward slash, and we do this only on windows/msdos. Updated patch attached. nazri -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. findfix2.patch Description: Binary data
Re: modeless-selection distorts all characters in gVim
On Wed, Apr 17, 2013 at 4:20 PM, Dimitar DIMITROV mitk...@yahoo.fr wrote: Dimitar wrote: On Wed, Apr 17, 2013 at 11:06 AM, Ben Fritz fritzophre...@gmail.com wrote: See image attached to my next message for what I see. And please bottom-post. Thanks Ben, can't see clearly your image but maybe indeed the bug was fixed in your version. Here is what I see (attached image) Thanks for sending the screenshot. I don't see character distortion, so I assume you're talking about the partial white background on some of the letters. So, it looks to me like the following is a description of your problem: 1. You launched gvim 7.3.409 on operating system. 2. You entered :e and then stayed in command-line mode 3. You selected some text *in the buffer* with the mouse 4. You see white backgrounds under some of your black letters within the selection Is this a correct problem description? If so, WHAT OPERATING SYSTEM ARE YOU USING? I don't see your issue still in Windows 7. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Variable for motion type in Operator-pending mode
Hi, I have recently learnt of a patch that was submitted to the list almost five years ago. Please see here: https://groups.google.com/d/msg/vim_dev/lR5rONDwgs8/iLsVCrxo_WsJ The reception was positive but for some reason the discussion was abandoned. I would like to reopen the discussion. I'd be very interested in this feature and happy if the patch could eventually be included. As for the name of the variable, how about: v:motiontype The documentation says that when no motion type is given the variable will be empty, when an explicit motion type is given (forced) it will be v, V, or C-V. I don't think the word force is strictly required to make the intent of the variable clear. As for the underscore, the majority of v: variables with compound names don't have it and I think this short name would look nice next to the other variables which are relevant in this context: v:register v:count v:count1 v:prevcount v:operator v:motiontype What do you think? -- David Bürgin -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: modeless-selection distorts all characters in gVim
On Wed, Apr 17, 2013 at 11:06 AM, Ben Fritz fritzophre...@gmail.com wrote: See image attached to my next message for what I see. And please bottom-post. Thanks Ben, can't see clearly your image but maybe indeed the bug was fixed in your version. Here is what I see (attached image) Thanks for sending the screenshot. I don't see character distortion, so I assume you're talking about the partial white background on some of the letters. So, it looks to me like the following is a description of your problem: 1. You launched gvim 7.3.409 on operating system. 2. You entered :e and then stayed in command-line mode 3. You selected some text *in the buffer* with the mouse 4. You see white backgrounds under some of your black letters within the selection Is this a correct problem description? If so, WHAT OPERATING SYSTEM ARE YOU USING? I don't see your issue still in Windows 7. Hi Ben, Sorry for not mentioning this. These are my OS details: Distribution: Gentoo Base System release 2.1 Machine hardware name: x86_64 Hardware platform: GenuineIntel Processor type: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz Kernel name: Linux Kernel release: 3.7.10-gentoo Compiled on: #1 SMP Tue Apr 2 13:12:22 BST 2013 Operating system: GNU/Linux You are also correct that this is not distortion but background coloring issues. The background color was white in my screenshot but can be of any color in a syntax highlighted code file. Turns out I used :e but this simply happens in modeless selection and not only *in the buffer* but anywhere, command line included. Regards -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
patch 838 has been mangled by improper recoding: problem investigation and proposed solutions [was: macosx x11/motif vim-7.3.905 test92 fails]
Content
---
(1) Problem investigation
(2) Proposed solutions
(2.1) @ r...@raf.org
(2.2) @ Bram
Hi r...@raf.org!
On 2013-04-18 Thursday at 13:28 +1000 r...@raf.org wrote:
Roland Eggner wrote:
On 2013-04-17 Wednesday at 12:39 +1000 r...@raf.org wrote:
… …
test test92.in file looks wrong here. perhaps multiply-encoded.
i've attached it.
… …
Hi r...@raf.org!
Thank you for your bugreport.
When Bram and I wrote test92, I verified it to work with all 3 of utf8,
latin
and C locale. I did not take into account the case of a system providing
no
utf8-locale at all (would be considered a bit outdated in 21st century ..).
my system (macosx-10.6.8) does provide utf8 locales.
If
there is at least one such vim-using system, I will try to support it,
probably
by just skipping test92.
i think there's an encoding problem in the test92.in file itself.
i downloaded patches from ftp.vim.org. it seems that 7.3.838 is
badly encoded. i've attached it. something like this has happened
before but only for patches on ftp.vim.org itself. other archives
weren't affected.
test93 succeeds for you?
yes, it does.
If you want to help further, please provide the output of
:view src/testdir/test92.in
vim: set ft=vim fenc=utf-8:
Tests if :mksession saves cursor columns correctly in presence of tab
and
multibyte characters when fileencoding=utf-8.
STARTTEST
:so mbyte.vim
:if !has('mksession')
: e! test.ok
: wq! test.out
:endif
:set sessionoptions=buffers splitbelow fileencoding=utf-8
/^start:
:vsplit
j16|:split
j16|:split
j16|:split
j8|:split
j8|:split
j16|:split
j16|:split
j16|:wincmd l
/^start:
:set nowrap
j16|3zl:split
j016|3zl:split
j016|3zl:split
j08|3zl:split
j08|3zl:split
j016|3zl:split
j016|3zl:split
j016|3zl:split
:mksession! test.out
:new test.out
:v/\(^ *normal! 0\|^ *exe 'normal!\)/d
:w
:qa!
ENDTEST
start:
no multibyte chAracter
one leaDing tab
four leadinG spaces
two consecutive tabs
two tabsin one line
one … multibyteCharacter
a “b†two multiByte characters
“c†1€ three mulTibyte characters
:set fileencodings? encoding? fileencoding? termencoding?
fileencodings=utf-8,latin1
encoding=utf-8
fileencoding=utf-8
termencoding=utf-8
:!locale
LANG=en_AU.UTF-8
LC_COLLATE=en_AU.UTF-8
LC_CTYPE=en_AU.UTF-8
LC_MESSAGES=en_AU.UTF-8
LC_MONETARY=en_AU.UTF-8
LC_NUMERIC=en_AU.UTF-8
LC_TIME=en_AU.UTF-8
LC_ALL=
:!locale -a
i've skipped all of the non-english ones.
there are many.
en_AU
en_AU.ISO8859-1
en_AU.ISO8859-15
en_AU.US-ASCII
en_AU.UTF-8
en_CA
en_CA.ISO8859-1
en_CA.ISO8859-15
en_CA.US-ASCII
en_CA.UTF-8
en_GB
en_GB.ISO8859-1
en_GB.ISO8859-15
en_GB.US-ASCII
en_GB.UTF-8
en_IE
en_IE.UTF-8
en_NZ
en_NZ.ISO8859-1
en_NZ.ISO8859-15
en_NZ.US-ASCII
en_NZ.UTF-8
en_US
en_US.ISO8859-1
en_US.ISO8859-15
en_US.US-ASCII
en_US.UTF-8
C
POSIX
Thank you for detailed report.
(1) Problem investigation
--
(1.1) Looks everything ok on your side, apart from file “test92.in”, which
gots
mangled by improper recoding _prior_ to upload to
ftp://ftp.de.vim.org/patches/7.3/7.3.838
and _prior_ to generating of
ftp://ftp.de.vim.org/patches/7.3/MD5SUMS
Currently I have no network access to ftp://ftp.vim.org/ … server seems to be
overloaded or down, or DNS resolving to “ftp.nluug.nl” has been wrong.
(1.2) Patch 7.3.838 exhibits a problem, which mostly does not matter, but in
this case it does: Patch files should generally, and this one _needs_ to be
treated as binary file. This means for transmission e.g. mimetype
“application/octet-stream”, and within vim e.g. “:view ++binary 7.3.838.patch”.
Purpose of the patch is to test vim handling of text files with _different_
encodings on :mksession, and thus contains by design one part, which could be
printed after decoding from binary to utf-8, and another part, which could be
printed after decoding from binary to ISO-8859-1. Decoding and printing of
both
parts _together_ is impossible, instead the patch file needs to be treated as
binary.
(1.3) I must admit, even when I posted the latest version of the patch to the
mailing list, the attachment holding the patch has been declared wrongly as
“Content-Type: text/plain; charset=utf-8“. Even so, we could say “by good
luck”, it hit the mailing list correctly, as I
Re: patch 838 has been mangled by improper recoding: problem investigation and proposed solutions [was: macosx x11/motif vim-7.3.905 test92 fails]
On 2013-04-18 Thursday at 19:36 +0200 Roland Eggner wrote:
Content
---
(1) Problem investigation
(2) Proposed solutions
(2.1) @ r...@raf.org
(2.2) @ Bram
Wrong file attached, sorry. Here is the intended “test92.in”.
--
Regards
Roland Eggner
vim: set ft=vim fenc=utf-8:
Tests if :mksession saves cursor columns correctly in presence of tab and
multibyte characters when fileencoding=utf-8.
STARTTEST
:so mbyte.vim
:if !has('mksession')
: e! test.ok
: wq! test.out
:endif
:set sessionoptions=buffers splitbelow fileencoding=utf-8
/^start:
:vsplit
j16|:split
j16|:split
j16|:split
j8|:split
j8|:split
j16|:split
j16|:split
j16|:wincmd l
/^start:
:set nowrap
j16|3zl:split
j016|3zl:split
j016|3zl:split
j08|3zl:split
j08|3zl:split
j016|3zl:split
j016|3zl:split
j016|3zl:split
:mksession! test.out
:new test.out
:v/\(^ *normal! 0\|^ *exe 'normal!\)/d
:w
:qa!
ENDTEST
start:
no multibyte chAracter
one leaDing tab
four leadinG spaces
two consecutive tabs
two tabsin one line
one … multibyteCharacter
a “b” two multiByte characters
“c”1€ three mulTibyte characters
pgphBLA8vZilF.pgp
Description: PGP signature
Re: patch 838 has been mangled by improper recoding: problem investigation and proposed solutions [was: macosx x11/motif vim-7.3.905 test92 fails]
Roland Eggner wrote: Content --- (1) Problem investigation (2) Proposed solutions (2.1) @ r...@raf.org (2.2) @ Bram [...] (1) Problem investigation -- (1.1) Looks everything ok on your side, apart from file “test92.in”, which gots mangled by improper recoding _prior_ to upload to ftp://ftp.de.vim.org/patches/7.3/7.3.838 and _prior_ to generating of ftp://ftp.de.vim.org/patches/7.3/MD5SUMS I have fixed the patch file now. No idea how this happened. Even more strange, the test92.in file went missing in my source directory. This doesn't make the tests fail, unfortunately. -- I'm in shape. Round IS a shape. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: patch 838 has been mangled by improper recoding: problem investigation and proposed solutions [was: macosx x11/motif vim-7.3.905 test92 fails]
Hi Bram, Bram Moolenaar wrote: I have fixed the patch file now. No idea how this happened. Even more strange, the test92.in file went missing in my source directory. This doesn't make the tests fail, unfortunately. With the new patch, test93.in seems to be encoded in utf-8 (not latin-1). Is it OK? Thanks, Ken Takata -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
inode change when saving changes to a file
I'm new to this forum and hope I'm not missing basic etiquette rules here. There is a discussion going on in the UNIX and Linux Forums UNIX for Dummies Questions Answers forum titled Knowing when a different program modifies a file (see http://www.unix.com/unix-dummies-questions-answers/221357-knowing-when-different-program-modifies-file.html for the full discussion) where it was pointed out that if someone edits a log file with vim while a daemon has the file open for writing all subsequent output written to the log file by the daemon will be lost until the deamon switches to a new log file (or is killed and restarted). I understand that renaming a temp file with the changes incorporated is an atomic operation reducing the amount of time that a large file would be in an inconsistent state. and that it widens (or opens) a window where a file could be damaged due to an anomalous event (e.g., power failure, lack of disk space, etc.). (But I assume that in these cases, vim's recover command could restore the data after the system is rebooted or space is made available.) I know that when there are multiple hard links to a file, the inode is not changed when vim saves the file updates. Given the above scenario, should vim ever change the inode? Clearly a sysadmin that edits a log file should be retrained or fired, and clearly the POSIX standards state that the results produced when two processes are writing to the same file without exchanging active handles produces undefined results; but the fact that a system daemon would continue writing to a file after vim has unlink()ed it and that all future diagnostics written by that daemon could be lost is scary. - Don -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gVim's internal borders
On Monday, October 15, 2012 3:43:30 AM UTC-4, aschneiderg wrote: I understand they may result useful in some situations but I found them annoying. Replacing WS_EX_CLIENTEDGE with WS_EX_LEFT in gui_w32.c did the trick for the top and left ones, but the bottom one is still there and the right one appears when guifont is set.(image) I have no experience in Vim's source yet. Any hints on how this internal borders (which seem to be somehow the same in GTK builds too) are generated ? My best regards. I only noticed this problem when I compiled my own Vim on Windows 8. Solved by running in compatibility mode for Windows 7. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: inode change when saving changes to a file
On 19/04/13 00:31, Don Cragun wrote: I'm new to this forum and hope I'm not missing basic etiquette rules here. There is a discussion going on in the UNIX and Linux Forums UNIX for Dummies Questions Answers forum titled Knowing when a different program modifies a file (see http://www.unix.com/unix-dummies-questions-answers/221357-knowing-when-different-program-modifies-file.html for the full discussion) where it was pointed out that if someone edits a log file with vim while a daemon has the file open for writing all subsequent output written to the log file by the daemon will be lost until the deamon switches to a new log file (or is killed and restarted). I understand that renaming a temp file with the changes incorporated is an atomic operation reducing the amount of time that a large file would be in an inconsistent state. and that it widens (or opens) a window where a file could be damaged due to an anomalous event (e.g., power failure, lack of disk space, etc.). (But I assume that in these cases, vim's recover command could restore the data after the system is rebooted or space is made available.) I know that when there are multiple hard links to a file, the inode is not changed when vim saves the file updates. Given the above scenario, should vim ever change the inode? Clearly a sysadmin that edits a log file should be retrained or fired, and clearly the POSIX standards state that the results produced when two processes are writing to the same file without exchanging active handles produces undefined results; but the fact that a system daemon would continue writing to a file after vim has unlink()ed it and that all future diagnostics written by that daemon could be lost is scary. - Don See :help 'backupcopy' :help FileChangedShell I agree with you that doctoring a logfile is contrary to the very purpose of the logfile itself. Some daemons will restart when sent a SIGHUP signal. I'm not sure of the details, which may vary from daemon to daemon. Best regards, Tony. -- Never count your chickens before they rip your lips off -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: python/python3 quit with raise SystemExit
I found problem of my patch. It doesn't work with here doc. I'll look into it. On Monday, April 15, 2013 8:06:36 PM UTC+9, Bram Moolenaar wrote: Yasuhiro Matsumoto wrote: When :py raise SystemExit, vim exit immediately. I know this is a spec of python. But most of users don't want this behavior. Below is a patch. Thanks. A few remarks. Please define the messages that appear more than once in one place. That avoids problems with translations and duplication isn't good anyway. These usually are in globals.h, but perhaps if_py_both.h could be used for these. It would be good to explain to the user that SystemExit is the wrong way to exit Vim and mention the right way. Most users don't read the source code :-). -- hundred-and-one symptoms of being an internet addict: 170. You introduce your wife as my_l...@home.wife and refer to your children as forked processes. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: python/python3 quit with raise SystemExit
I found problem of my patch. It doesn't work with here doc. I'll look into it. I've updated. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gVim's internal borders
On Thursday, April 18, 2013 3:52:30 PM UTC-5, vee...@veegee.org wrote: On Monday, October 15, 2012 3:43:30 AM UTC-4, aschneiderg wrote: I understand they may result useful in some situations but I found them annoying. Replacing WS_EX_CLIENTEDGE with WS_EX_LEFT in gui_w32.c did the trick for the top and left ones, but the bottom one is still there and the right one appears when guifont is set.(image) I have no experience in Vim's source yet. Any hints on how this internal borders (which seem to be somehow the same in GTK builds too) are generated ? My best regards. I only noticed this problem when I compiled my own Vim on Windows 8. Solved by running in compatibility mode for Windows 7. Hey there. Are your builds available online ? I would like to check them out. All the best. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gVim's internal borders
On Thursday, April 18, 2013 10:18:22 PM UTC-4, aschneiderg wrote: Hey there. Are your builds available online ? I would like to check them out. All the best. Uploaded for you guys. Couldn't find any 64-bit builds myself, might as well save everyone else the trouble. It's also quite a nuisance to build vim (let alone *anything*) on winbloze. Also, I tested build using VS2012 AND VS2010. VS2012 seems to be causing problems with the border, and several other problems including crashes, freezes, missing cursor, etc. VS2010 is building a working executable as expected. Note, this is a 64-bit build, compiled with 64-bit Python33 and Python27 dynamic lib support. Let me know if it gives you any problems. Download: http://solar-blogg.blogspot.ca/2013/04/vim-windows-64-bit-build.html -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
