On 2022-07-19, Kutty, Rejeesh wrote:
> Hi,
>
> I recently ran the installer and it updated vim to 8.2
>
> :version
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24)
> Included patches: 1-4372
>
>
> Now when I open a perl script, I get the following message:
>
> Command
Hi,
I recently ran the installer and it updated vim to 8.2
:version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24)
Included patches: 1-4372
Now when I open a perl script, I get the following message:
Command terminated
Error detected while processing BufRead Autocommands
Thank you very much. It works.
---
From:
Fxzx mic
fxzx...@outlook.com<mailto:fxzx...@outlook.com>
---
发件人: Brian Inglis<mailto:brian.ing...@systematicsw.ab.ca>
发送时间: 2021年6月28日 3:25
收件人: cygwin@cygwin.com<mailto:cygwin@cygwin.com>
主题: Re: A warning about GVIM
On 2021-06-27 07:
On 2021-06-27 07:51, ㅤ Fxzx mic via Cygwin wrote:
I have such a warning:
** (gvim:1682): WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message
bus without replying
Can this be fixed?
Please read the previous
Hello, everyone.
I have such a warning:
** (gvim:1682): WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message
bus without replying
Can this be fixed?
---
From:
Fxzx mic
fxzx...@outlook.com<mailto:f
On 2021/04/08 04:19, Andrey Repin wrote:
It has it in every version starting Windows 95/NT4.
@Linda: try http://joelpurra.com/Projects/X-Mouse_Controls/
---
Just had the occasion to need it, since had to re-inst W7.
Unfortunately, it immediately dumps core. Very odd.
Dependency walker
> ** (gvim:1682): WARNING **: Error retrieving accessibility bus address:
> org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from
> message bus without replying
>
> Can this be fixed?
I get the same warning from gvim, emacs, zenity, and gitg.
--
Problem repo
On 15.06.2021 03:10, Claude Sylvain wrote:
On 2021-06-14 3:23 a.m., Fxzx mic via Cygwin wrote:
** (gvim:1682): WARNING **: Error retrieving accessibility bus
address: org.freedesktop.DBus.Error.NoReply: Message recipient
disconnected from message bus without replying
Can this be fixed
On 2021-06-14 3:23 a.m., Fxzx mic via Cygwin wrote:
** (gvim:1682): WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message
bus without replying
Can this be fixed?
---
From:
Fxzx mic
fxzx...@outlook.com
Andrey Repin writes:
>> Windows never had "focus follows mouse" in any version I can remember.
>
> It has it in every version starting Windows 95/NT4.
The last time I tried it it didn't quite work, though. Specifically it
does "focus strictly follows mouse" and it had problems with raising
it would be along the lines of detecting when windows had grabbed
control via its time -- for cygwin to use a timer to detect when it
lost control. Ex. in cygwin's blink routine, it would need to check
There is no 'cygwin blink routine' - this is something that the X client
(e.g. gvim in your example
windows had grabbed
control via its time -- for cygwin to use a timer to detect when it
lost control. Ex. in cygwin's blink routine, it would need to check
There is no 'cygwin blink routine' - this is something that the X client
(e.g. gvim in your example) is doing, while it believe that it has
On 09/04/2021 16:12, Thomas Wolff wrote:
See [1] et seq. for a discussion of what I think is the same problem,
where the Cygwin X server doesn't notify X windows of a focus loss
when the focus moves to a non-X window.
Hmm, when I start xterm -bc and click out of xterm (e.g. mintty or
On 2021/04/09 08:12, Thomas Wolff wrote:
Hmm, when I start xterm -bc and click out of xterm (e.g. mintty or
Thunderbird), the cursor stops blinking for me.
---
That's the key difference "click out of xterm" -- in pointer follows
focus, no clicking is used. The active window becomes the one
On 2021/04/10 12:14, L A Walsh wrote:
On 2021/04/09 07:41, Jon Turney wrote:
I think so, yes.
===
That's unfortunate. Well, I wasn't sure if it was new
or old. At least its not some new problem. Sigh.
Thanks for the backstory.
[1]
On 2021/04/09 07:41, Jon Turney wrote:
I think so, yes.
===
That's fine, I guess I hadn't noticed it before --
had about 3-X and maybe 2 native and couldn't figure out why I
occasionally had typing going to the wrong window when I realized I
had been relying on the blinking for the
Am 09.04.2021 um 16:41 schrieb Jon Turney:
On 07/04/2021 01:27, L A Walsh wrote:
I don't recall this always being this way as I keep running into
a problem with my input going into the wrong window.
I've noted I seem to be relying on which editor(i.e. gvim)
window in X11 has focus by noting
On 07/04/2021 01:27, L A Walsh wrote:
I don't recall this always being this way as I keep running into
a problem with my input going into the wrong window.
I've noted I seem to be relying on which editor(i.e. gvim)
window in X11 has focus by noting that it has a
blinking square cursor
Greetings, Achim Gratz!
> L A Walsh writes:
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?
> Windows never had "focus follows
On April 7, 2021 8:47 PM Achim Gratz wrote:
>L A Walsh writes:
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?
>
>Windows never
On 2021/04/07 11:46, Achim Gratz wrote:
L A Walsh writes:
If I move the windows cursor to another editor window in X11,
the blinking cursor moves to the new window, but if I move
it to a native window, the blinking doesn't stop.
Has this always been this way?
Windows never had "focus
L A Walsh writes:
> If I move the windows cursor to another editor window in X11,
> the blinking cursor moves to the new window, but if I move
> it to a native window, the blinking doesn't stop.
>
> Has this always been this way?
Windows never had "focus follows mouse" in any version I can
I don't recall this always being this way as I keep running into
a problem with my input going into the wrong window.
I've noted I seem to be relying on which editor(i.e. gvim)
window in X11 has focus by noting that it has a
blinking square cursor in the window at the cursor's
current position
On 2020-09-09 00:55, L A Walsh wrote:
> I was trying to edit files in
> /etc/ssh:
> /etc/ssh> gvim sshd_config
>
> Error: Current working directory has restricted permissions which render it
>
> inacc
I was trying to edit files in
/etc/ssh:
/etc/ssh> gvim sshd_config
Error: Current working directory has restricted permissions which render it
inaccessible as Win32 working direct
The latest Vim/GVim package currently available on Cygwin Packages has
broken ruby support.
Here is the stackoverflow question about the same:
https://stackoverflow.com/questions/47356294/cygwin-installing-vim-with-ruby-support
and here is the short list of the status of ruby support on Vim.
vim
I installed Cygwin yesterday and I am unable to startup GVIM in a
separate window. I verified Xwin is running and I tried a few
different types of DISPLAY;
:0
:0;0
localhost:0.0 (with the XWin server started with -listen inet)
All failed with the following errors:
Vim: Caught deadly signal SEGV
I have an issue running gvim (under X11) where subprocesses invoked
with the bang command will hang.
For example, I might run:
! git pull
and the process will never complete. If I look at task manager, I will
see a gvim.exe subprocess with around 30% CPU occupying the top of the
CPU usage
On Wed, Jan 23, 2013 at 11:58 PM, Andy andymhanc...@gmail.com wrote:
Guys, thanks for your replies. I might not have been clear enough in
my original post, but the problem is in attempting to copy from a
Windows app and pasting into Cygwin's gvim. Correct me if I'm wrong,
but your responses
Alan Thompson thompson2526 at gmail.com writes:
Everything I said works both ways, both Cygwin-Windoze and
Windoze-Cygwin. The only difference in GVim is whether you use
yank
(Y) or put (P). This works for both the win32 version of GVim
and
the Cygwin X11 version of GVim. To be specific
Chris Sutcliffe ir0nh34d at gmail.com writes:
|On 22 January 2013 11:55, Andy wrote:
| I installed cygwin's gvim on Windows 7. I found that pasting from
| the Windows clipboard into gvim doesn't work by clicking the middle
| mouse button unless I go through a weird ritual that I discovered
I installed cygwin's gvim on Windows 7. I found that pasting from the
Windows clipboard into gvim doesn't work by clicking the middle mouse
button unless I go through a weird ritual that I discovered by
accident. If I don't do this, I get E353: Nothing in register *.
First, I have to highlight
I installed cygwin's gvim on Windows 7. I found that pasting from the
Windows clipboard into gvim doesn't work by clicking the middle mouse
button unless I go through a weird ritual that I discovered by
accident. If I don't do this, I get E353: Nothing in register *.
First, I have to highlight
On 22 January 2013 11:55, Andy wrote:
I installed cygwin's gvim on Windows 7. I found that pasting from the
Windows clipboard into gvim doesn't work by clicking the middle mouse
button unless I go through a weird ritual that I discovered by
accident. If I don't do this, I get E353: Nothing
On Tue, Jan 22, 2013 at 11:55 AM, Andy andymhanc...@gmail.com wrote:
I installed cygwin's gvim on Windows 7. I found that pasting from the
Windows clipboard into gvim doesn't work by clicking the middle mouse
button unless I go through a weird ritual that I discovered by
accident. If I
as usual
Also, note that for some things I use the Cygwin version of GVim (have
to start the X11 server first), and for some things I use the native
Windows version of GVim.
Alan Thompson
On Tue, Jan 22, 2013 at 9:18 AM, Chris Sutcliffe ir0nh...@gmail.com wrote:
On 22 January 2013 11:55, Andy
On Sun, Aug 05, 2012 at 12:34:25AM -0400, ping wrote:
folks/experts:
I just successfully recompiled vim with GUI support under cygwin.
so now gvim is OK if I launch it from cygwin terminal (yes I have X running)
then I'm trying to make it the default text editor for my window7
application
(like
folks/experts:
I just successfully recompiled vim with GUI support under cygwin.
so now gvim is OK if I launch it from cygwin terminal (yes I have X running)
then I'm trying to make it the default text editor for my window7
application
(like outlook, to open attachment), but then I got a dialog
Hiya,
I am having similar problems with gvim as noted by K Stahl kdstahl at
gmail dot com on Fri, 11 May 2012 12:33:16 -0400. gvim has become
unusable. Based on the results of ldd and my typical update
frequency, I believe one (or more) of the following files may be the
culprit:
2012-04-30 01
On 6/8/2012 12:51 PM, Brett DiFrischia wrote:
Hiya,
I am having similar problems with gvim as noted by K Stahlkdstahl at
gmail dot com on Fri, 11 May 2012 12:33:16 -0400. gvim has become
unusable. Based on the results of ldd and my typical update
frequency, I believe one (or more
.
Fortunately for emacs users, the problem doesn't seem to occur with
emacs-24. (Can anyone else confirm this?) But that doesn't help the
gvim users who have reported similar problems.
Yaakov, could you take a look? Maybe you could also make the previous
version of libglib2.0_0 available so
get echoed until you release the key.
Fortunately for emacs users, the problem doesn't seem to occur with
emacs-24. (Can anyone else confirm this?) But that doesn't help the gvim
users who have reported similar problems.
Yaakov, could you take a look? Maybe you could also make the previous
' to switch to the *scratch* buffer.
4. Press and hold one key. It echoes once, but the repeated key strokes
don't get echoed until you release the key.
Fortunately for emacs users, the problem doesn't seem to occur with
emacs-24. (Can anyone else confirm this?) But that doesn't help the gvim
users who
Ken Brown kbrown at cornell.edu writes:
Fortunately for emacs users, the problem doesn't seem to occur with
emacs-24. (Can anyone else confirm this?)
Hi Ken,
So I just upgraded to emacs-24 (24.0.96.1), and while it is certainly better, I
wouldn't say it's fixed.
Try opening a text file (I
On 6/1/2012 7:00 AM, Ken Brown wrote:
I found an XP system that hadn't been upgraded in a few weeks, and I
upgraded libglib2.0_0 but nothing else. This was enough to trigger the
problem.
I've checked the git repository for glib at
http://git.gnome.org/browse/glib/log/?h=glib-2-32
and there
This morning, I reverted GLib2.0 to a previous version and it did not
solve the issue.
Steps used in testing:
Extracted libglib2.0_0-2.30.2-1.tar.bz2 and ran /etc/postinstall/glib2.0.sh
Started XWin and attempted to edit a file via gvim (performance issue
still remain)
On Fri, Jun 1, 2012 at 2
Modified from my original email on the XFree mailing list:
After updating yesterday (2012-05-10) I am experiencing the following
behavior when using GVim within an X-Session:
While scrolling through a file in visual mode using either H, J,
K, or L, the cursor is slow to respond.
What I am
Mon, May 14, 2012 at 02:55PM -0400 K Stahl wrote:
What I am witnessing is that if you hold down any of these keys, the
cursor remains in place until the key is released.
I'm seeing about the same think in emacs-X11.
I hold down an arrow key and the cursor stays still until I release
it
Greetings,
After updating yesterday (2012-05-10) I am experiencing the following
behavior when using GVim within an X-Session:
While scrolling through a file in visual mode using either H, J,
K, or L, the cursor is slow to respond.
What I am witnessing is that if you hold down any of these keys
Hi,
I usually start the non-cygwin gvim.exe via the rxvt cygwin console
doing something like:
% gvim filename.py
the problem is that, when inside GVIM, when I do:
:py print os.environ['PATH']
I see a lot of cygwin paths which messes up the Python path that GVIM
wants to use
On Mon, Feb 06, 2012 at 01:04:28PM -0800, reckoner wrote:
Hi,
I usually start the non-cygwin gvim.exe via the rxvt cygwin console
doing something like:
% gvim filename.py
the problem is that, when inside GVIM, when I do:
:py print os.environ['PATH']
I see a lot of cygwin paths which messes
Saxon, Will Will.Saxon at sage.com writes:
My script works, but if I do run it from a command window it generates a stack
dump:
Exception: STATUS_GUARD_PAGE_VIOLATION at eip=61020137
I had a similar problem, what fixed it for me was to move /cygwin to
/cygwin.save and re-install cygwin.
be grateful for advice on compiling gvim under cygwin to work as a Windows
application.
Regards,
Clyde
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml
be grateful for advice on compiling gvim under cygwin to work as a
Windows application.
As you are building a standalone version of vim, you are a bit off topic here.
Regards,
Clyde
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq
On Tue, 2011-03-01 at 01:08 +0100, Paul Maier wrote:
Hi,
my gvim dies when I select file-open from gvim's menu (see screenshot in
file gvim.jpg.uuencode.txt).
100 % reproducable.
Same, if I start gvim with a file to edit or without.
WFM. How are you starting gvim?
Yaakov
--
Problem
Hello,
I am trying to run gvim via Cygwin using run.exe and a shell script. The reason
I am doing this is so that I can assign the command to a button vs. opening
gvim from a shell.
My script works, but if I do run it from a command window it generates a stack
dump:
Exception
On 10/11/2010 02:52, Rodrigo Medina wrote:
Some time ago I have reported a problem with gvim,
it stops because it receives a SEGV signal when the
OPEN menu-item is selected. I have installed the new
XWin server, but the problem persists.
Does gvim functions correctly for any body?
Probably
Hi,
Some time ago I have reported a problem with gvim,
it stops because it receives a SEGV signal when the
OPEN menu-item is selected. I have installed the new
XWin server, but the problem persists.
Does gvim functions correctly for any body?
Thanks in advance for any replay
RM
--
Unsubscribe
On 28/10/2010 01:53, Frédéric Bron wrote:
But perhaps you mean that gvim is the only application which shows this
problem?
When I have the problem, it is not only gvim but also gv for example.
It seems it has to do with screen resolution change (see my previous
email).
Frédéric
Aha
On 28/10/2010 02:41, David T-G wrote:
Jon, et al --
...and then Jon TURNEY said...
%
% On 25/10/2010 11:25, David T-G wrote:
%
...
%Any more ideas? :-(
%
...
% But perhaps you mean that gvim is the only application which shows this
% problem?
Yup -- so far, anyway.
%
% You might compare
with xfd loaded now. Sure enough, the two are distinctly
% different; the former is smaller than the latter, although not so tiny as
% to be invisible as in gvim. This sure sounds like a lead, though!
...
%
% The fonts aren't supposed to be visually identical, as they are potentially
% different
Jon, et al --
...and then Jon TURNEY said...
%
% On 25/10/2010 11:25, David T-G wrote:
%
...
% Any more ideas? :-(
%
% More questions, certainly.
%
...
% You might compare the appearance of the fonts shown by 'xfd -fa Courier'
% and 'xfd -fn -*-courier-medium-r-*-*-*-120-*-*-*-*-*-*' to test
Frédéric --
...and then Frédéric Bron said...
%
% But perhaps you mean that gvim is the only application which shows this
% problem?
%
% When I have the problem, it is not only gvim but also gv for example.
% It seems it has to do with screen resolution change (see my previous
% email).
I
On 25/10/2010 11:25, David T-G wrote:
Hi again, folks --
...and then David T-G said...
%
...
% I hate these kinds of errors because it's so incredibly hard to get a
% real resolution to the problem, but I'll not turn down having my gvim
% work again :-)
Even that is taken from me now. I had
Hi again, folks --
...and then David T-G said...
%
...
% I hate these kinds of errors because it's so incredibly hard to get a
% real resolution to the problem, but I'll not turn down having my gvim
% work again :-)
Even that is taken from me now. I had gvim happily open on a file,
closed
If this may help, I experienced again this problem today, right after
switching to a second monitor (which changed my screen resolution).
I restart the X server and it came back again.
Frédéric
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Jon, et al --
...and then Jon TURNEY said...
%
% On 01/10/2010 11:23, David T-G wrote:
%
...
% When I first started gvim after my install, the font was invisibly tiny
% both for the content and for the menus. [Note that both xterm and rxvt-X
...
%
% I'm assuming gvim is behaving as if you
--- Mar 5/10/10, Larry Hall (Cygwin X) ha scritto:
On 10/4/2010 6:23 AM, James Anderson
wrote:
Rodrigo Medinarodmedinaat
cantv.net writes:
Hi,
I have just installed gvim. I have never used it
before.
After starting Xwin -multiwindow I run gvim. A
window appears,
but when
Hi when I try to run Gvim under X this is the error I am getting. I am
not technically knowledged about these messages, maybe someone can
shed light into this issue.
510575 [main] gvim 1988 exception::handle: Exception: STATUS_ACCESS_VIOLATION
510805 [main] gvim 1988 open_stackdumpfile
On 10/1/10, Rodrigo Medina rodmed...@cantv.net wrote:
Hi,
I have just installed gvim. I have never used it before.
After starting Xwin -multiwindow I run gvim. A window appears,
but when the OPEN or SAVE AS menu-items are selected the program ends
$ gvim
[1] 1144
$ Vim: Caught deadly
On 22/09/2010 16:34, David T-G wrote:
Hi, all --
[Let's see if I can provide all of the details the first time instead of
having to go back and forth just for foundation... :-]
Can you attach your /var/log/XWin.0.log, please?
I have used Cygwin for years and have been using the cygwin gvim
Hi again, all --
...and then David T-G said...
%
% Hi, all --
%
...
% When I first started gvim after my install, the font was invisibly tiny
% both for the content and for the menus. [Note that both xterm and rxvt-X
[snip]
Frederic asked if I had restarted my X server. I have logged out
When I first started gvim after my install, the font was invisibly tiny
both for the content and for the menus.
It is funny, I got exactly the same a few days ago. What is funny is
that today it works perfectly. Have you tried to restart your X
server?
Frédéric
--
Unsubscribe info: http
The following package has been updated for the Cygwin distribution:
*** gvim-7.3.003-1
gVim provides a GTK+ GUI for the Vim text editor.
This is an update to the latest upstream version with the current
patchset, and requires a simultaneous 7.3.x update to the vim package in
order to operate
STATUS_ACCESS_VIOLATION, but I
discovered by accident that if I use xterm -e vim-nox $@ instead of
xterm -e vim $@, I do not get the gvim stackdumps when using fmt.
There is a related issue. If I start a new X window using the shortcut
in the Start Menu, it will occasionally fail to start. But if I hit
Hi,
I can't get gVim to work using X forwarding over SSH. Both xeyes and
xemacs work fine, but not gVim. gVim works when running it locally,
but gets a deadly signal when trying to run it from an SSH connection.
Any and all help would be greatly appreciated!
Here is some relevant console output
2009/12/4 Christopher Faylor:
Hang on, if I do this:
$ setsid gvim -display :0
in a bash console and then close the console, gvim continues to work,
so either setsid or gvim itself does detach from the console.
That makes sense. Cygwin sends explicit SIGHUPs to other members of the
console
), Gvim
is killed. Why should bash or the console exiting kill off any processes
running in the background?
I have had the same frustration for a while. When in a bash shell start
gvim with:
cmd /c gvim
then you can exit the bash shell without killing gvim.
FWIW:
I am using gvim v7.0 for 32bit MS
), Gvim
is killed. Why should bash or the console exiting kill off any processes
running in the background?
Were you closing the console window by pressing the close button?
In that case, the problem is that gvim is built as a console program,
which means that it will have attached to bash's
running in a console window), Gvim
is killed. Why should bash or the console exiting kill off any processes
running in the background?
Were you closing the console window by pressing the close button?
In that case, the problem is that gvim is built as a console program,
which means
by bash exiting).
Yet when I exit the bash window (bash running in a console window), Gvim
is killed. ??Why should bash or the console exiting kill off any processes
running in the background?
Were you closing the console window by pressing the close button?
In that case, the problem
In bash I start a copy of gvim.exe (64-bit windows version) in background.
I disown the job in bash so bash no longer manages the job -- it should be
a free and clear process (unaffected by bash exiting).
Yet when I exit the bash window (bash running in a console window), Gvim
is killed. Why
this correction
silently.
Yeah...
Probably not that here, but whatever. It's probably still true with x
progs, but they aren't where I left them. (gvim in particular)...
That's what I'm talking about -- things appear to show up in some
locations but then are not there when I look later or in explorer.
Very
with
the same patchlevel for gvim later today.
As for matching sources, I just have been using the upstream sources and
patches, and building with --with-features=huge --enable-gui=gtk2. Do
you apply any Cygwin-specific patches?
No, vim is plain upstream. I build it with
--enable-multibyte
moved gvim into place now. Thanks,
Yaakov
The following package has been updated for Cygwin 1.7:
*** gvim-7.2.264-1
gVim provides a GTK+ GUI for the Vim text editor.
This release is an update to the latest patch for 7.2.
This release also uses the alternatives system, together with
the concurrent vim release. By installing gvim
On Sep 30 00:38, Yaakov S wrote:
On 16/09/2009 20:49, Yaakov (Cygwin/X) wrote:
Corinna,
I would like to change how we are handling the vim/gvim installation.
gvim.exe still includes the terminal interface, and will use it if
$DISPLAY is unset or if called as vim, except that it accepts
On 30/09/2009 03:05, Corinna Vinschen wrote:
Well, it sounds good. I'll try to come up with a new vim package in the
next couple of days, which follows your suggestion. I guess we can base
vim and gvim on the same latest bugfix level 264 then, right?
Sounds good. Thanks,
Yaakov
On Sep 30 04:00, Yaakov S wrote:
On 30/09/2009 03:05, Corinna Vinschen wrote:
Well, it sounds good. I'll try to come up with a new vim package in the
next couple of days, which follows your suggestion. I guess we can base
vim and gvim on the same latest bugfix level 264 then, right?
Sounds
On Sep 30 21:33, Corinna Vinschen wrote:
On Sep 30 04:00, Yaakov S wrote:
On 30/09/2009 03:05, Corinna Vinschen wrote:
Well, it sounds good. I'll try to come up with a new vim package in the
next couple of days, which follows your suggestion. I guess we can base
vim and gvim on the same
. I guess we can base
vim and gvim on the same latest bugfix level 264 then, right?
Sounds good. Thanks,
~corinna/vim in sourceware contains the new files. For 1.7, built with
Dave's latest gcc, which requires to add libgcc1 to setup.hint.
Would you mind to take a look and see
script. Hang on...
Should be ok now.
alternatives needs to be added to requires:. Besides that, looks fine
to me; go ahead and move these into release-2, and I'll follow up with
the same patchlevel for gvim later today.
As for matching sources, I just have been using the upstream sources
On 16/09/2009 20:49, Yaakov (Cygwin/X) wrote:
Corinna,
I would like to change how we are handling the vim/gvim installation.
gvim.exe still includes the terminal interface, and will use it if
$DISPLAY is unset or if called as vim, except that it accepts the '-g'
argument. (Same goes for view
Christopher Faylor wrote:
To clarify: I see nothing in any of the chain of messages that you
referred to which indicates that this is the same problem. You're
asserting that this is the case but not providing any details to
back that statement up.
I *think* (my guess) it is the same problem
Yaakov (Cygwin/X) wrote:
Could you put your emacs-gtk tarballs somewhere, or if not, at least your
.cygport?
Yaakov,
I still do not use cygport to build Emacs. :-(
In any case, I have a Cygwin-1.5 build here(*) for Emacs-23 with which
the problems I flagged are reproducible (at least by
On 9/25/2009 4:53 AM, Angelo Graziosi wrote:
If you want a 'native' 1.7 build, I can write how I do (mainly
configure+make+make install). However, the current method used by Ken
(the Emacs maintainer) should be valid if one remove 'lucid' and uses
'gtk' to obtain a GTK build.
Yes, that
On Fri, Sep 25, 2009 at 10:30:33AM +0200, Angelo Graziosi wrote:
Christopher Faylor wrote:
To clarify: I see nothing in any of the chain of messages that you
referred to which indicates that this is the same problem. You're
asserting that this is the case but not providing any details to
Cesar Strauss wrote:
Christopher Faylor wrote:
If you could test this and confirm that the snapshot fixes the problem I'll
roll a new release. It turns out to be a pretty serious bug.
http://cygwin.com/snapshots/
I am not the OP, but I could reproduce the problem, and I confirm it is
On Fri, Sep 25, 2009 at 02:39:38AM +0200, Angelo Graziosi wrote:
Cesar Strauss wrote:
Christopher Faylor wrote:
If you could test this and confirm that the snapshot fixes the problem I'll
roll a new release. It turns out to be a pretty serious bug.
http://cygwin.com/snapshots/
I am not
On Thu, Sep 24, 2009 at 09:30:34PM -0400, Christopher Faylor wrote:
On Fri, Sep 25, 2009 at 02:39:38AM +0200, Angelo Graziosi wrote:
Cesar Strauss wrote:
Christopher Faylor wrote:
If you could test this and confirm that the snapshot fixes the problem I'll
roll a new release. It turns out to
1 - 100 of 263 matches
Mail list logo
