Re: Mercurial problems
On Tue, Aug 17, 2010 at 8:38 PM, björn wrote:
> Hi,
>
> This is most likely a complete newbie problem, but ever since the
> branch renaming business I get warnings when I pull from the Mercurial
> repo. I did a fresh clone this morning thinking the problems would go
> away, but they did not. Here's what happens:
>
> $ hg fetch
> pulling from https://vim.googlecode.com/hg/
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 2 changes to 2 files
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
> updating to 2191:b619655b31db
> 476 files updated, 0 files merged, 38 files removed, 0 files unresolved
> merging with 2576:2a8bf2ba504f
> local changed README_lang.txt which remote deleted
> elete? danged version or (d)
>
> Note the weird prompt. Well, I hit "d" and get lots of merge
> conflicts and finally
>
> 320 files updated, 180 files merged, 6 files removed, 8 files unresolved
> use 'hg resolve' to retry unresolved file merges or 'hg update -C' to abandon
> Spectre:vim winckler$ hg update -C
> 508 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> Can anybody tell me what's the matter? I have not switched branches
> or anything, so I'd assume hg would just pull the changesets and "fast
> forward" (and here you see my problem, I have a basic of understanding
> of Git but am completely bewildered by Mercurial).
>
> I used to be able to "hg fetch" ("fetch" is an extension, btw) with no
> problems.
It's fine here (though hg-fast-export had some troubles interpreting the
branch rename thing). How about a simple "hg pull", still get the same
problem?
- Jiang
--
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: Mercurial repository available for Vim
Hi Ben, On Sat, Feb 13, 2010 at 12:05 PM, Ben Schmidt wrote: > Ulterior motive: It would make a lot of sense, and certainly make my > life easier, if the MacVim repository could be based on the Vim > repository. Of course, ideally I'd love to see MacVim using hg, too, but > with the help of that extension above, it could continue using git and > still use the official Vim repository, plus I could maintain my own hg > repository with the patches I regularly apply, test, and so on. > > Bjorn, how does this sound to you? I know it could be a challenge to set > it up, particularly preserving old MacVim history and the way it > interacts with old Vim history, but would you be willing to pursue this? > I'm willing to help with that initial conversion. I am also interested in maintaining a git repository based on vim hg repo, either directly or indirectly. Currently both mine (vim-cocoa) and MacVim repo are based on the Subversion repo at sf.net, which is synced manually with git-svn, so I am also curious about the technical approach to switch from git-svn to this hg or git repo set up by upstream. - Jiang -- You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php
Re: Out-of-tree build
Hi Chris,
On Mon, Jan 25, 2010 at 12:06 PM, Chris Sutcliffe wrote:
> Is it possible to configure vim in such a way as to not needing to be
> built in the /vim/src directory? I'd like to use the same source
> repository to build vim and gvim for Cygwin and MinGW and the target
> names conflict if both build in the /vim/src directory.
For vim-cocoa I made a CMake script to build it in out-of-directory fashion.
However that's only for Mac OS X configurations. You may want to adapt it to
other platforms so I attached it here.
- Jiang
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php# CMakeLists.txt: cmake config file for vim-cocoa build
cmake_minimum_required(VERSION 2.6)
project(VIM)
set(VIMMAJOR 7)
set(VIMMINOR 2)
set(VIM_VERSION "${VIMMAJOR}.${VIMMINOR}")
if (NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE "Debug")
endif (NOT CMAKE_BUILD_TYPE)
if (NOT GUI)
if (APPLE)
set(GUI "Cocoa")
endif(APPLE)
endif(NOT GUI)
if (APPLE)
set(PROGNAME Vim)
set(VIM_PREFIX"/Applications")
# Only build Universal Binary when it's release build
if (CMAKE_BUILD_TYPE STREQUAL "Release")
set(CMAKE_OSX_ARCHITECTURES i386;ppc)
endif (CMAKE_BUILD_TYPE STREQUAL "Release")
set(OS_EXTRA_SOURCES os_macosx.m os_mac_conv.c)
set(PYTHON_INTERP 1)
set(RUBY_INTERP 1)
else (NOT APPLE)
set(PROGNAME vim)
endif (APPLE)
if (CMAKE_COMPILER_IS_GNUCC)
set(CMAKE_C_FLAGS_DEBUG "-g -Wall -Werror")
set(CMAKE_C_FLAGS_RELEASE "-O2 -pipe -fomit-frame-pointer")
endif (CMAKE_COMPILER_IS_GNUCC)
find_path(PYTHON_INCLUDE_DIR Python.h)
find_path(RUBY_INCLUDE_DIR ruby.h HINTS "/System/Library/Frameworks")
find_path(COCOA_INCLUDE_DIR Cocoa/Cocoa.h)
find_path(PSMTBC_INCLUDE_DIR PSMTabBarControl/PSMTabBarControl.h
${VIM_SOURCE_DIR}/mac/build/Release)
include_directories(${CMAKE_CURRENT_BINARY_DIR}
${VIM_SOURCE_DIR} ${VIM_SOURCE_DIR}/proto
${PYTHON_INCLUDE_DIR} ${RUBY_INCLUDE_DIR}
${COCOA_INCLUDE_DIR} ${PSMTBC_INCLUDE_DIR})
# -DHAVE_CONFIG_H -DFEAT_GUI_MAC -DFEAT_GUI_COCOA
add_definitions(-DHAVE_CONFIG_H -DFEAT_GUI_MAC -DFEAT_GUI_COCOA -DMACOS_X_UNIX
-D_FORTIFY_SOURCE=1)
set(PYTHON_INTERP_SOURCES if_python.c)
set(RUBY_INTERP_SOURCES if_ruby.c)
if (PYTHON_INTERP)
set(INTERP_SOURCES ${INTERP_SOURCES} ${PYTHON_INTERP_SOURCES})
endif (PYTHON_INTERP)
if (RUBY_INTERP)
set(INTERP_SOURCES ${INTERP_SOURCES} ${RUBY_INTERP_SOURCES})
endif (RUBY_INTERP)
set(COCOA_GUI_SOURCES pty.c gui.c gui_mac.m)
if (GUI STREQUAL "Cocoa")
set(GUI_SOURCES ${COCOA_GUI_SOURCES})
endif(GUI STREQUAL "Cocoa")
set(VIM_DIR_PATH"/Resources/vim")
set(PATHDEF_SOURCE "${CMAKE_CURRENT_BINARY_DIR}/pathdef.c")
set(CONFIG_H"${CMAKE_CURRENT_BINARY_DIR}/auto/config.h")
set(VIM_SOURCES version.c buffer.c charset.c diff.c digraph.c edit.c eval.c
ex_cmds.c ex_cmds2.c ex_docmd.c ex_eval.c ex_getln.c fileio.c
fold.c getchar.c hardcopy.c hashtab.c if_cscope.c if_xcmdsrv.c
main.c mark.c memfile.c memline.c menu.c message.c misc1.c
misc2.c move.c mbyte.c normal.c ops.c option.c os_unix.c
popupmnu.c quickfix.c regexp.c screen.c search.c spell.c
syntax.c tag.c term.c ui.c undo.c window.c
${PATHDEF_SOURCE}
${OS_EXTRA_SOURCES}
${INTERP_SOURCES}
${GUI_SOURCES})
# Simply treat it as C source should be fine, otherwise cmake will choose
# a C++ compiler to build it
set_source_files_properties(gui_mac.m PROPERTIES LANGUAGE C)
find_library(m m)
find_library(ncurses ncurses)
find_library(iconv iconv)
find_library(COCOA_FRAMEWORK Cocoa)
find_library(PYTHON_FRAMEWORK Python)
find_library(RUBY_FRAMEWORK Ruby)
set(PSMTBC_PATH ${VIM_SOURCE_DIR}/mac/build/Release)
find_library(PSMTBC_FRAMEWORK PSMTabBarControl ${PSMTBC_PATH})
set(VIM_LIBRARIES ${m} ${ncurses} ${iconv}
${COCOA_FRAMEWORK} ${PSMTBC_FRAMEWORK} ${PYTHON_FRAMEWORK}
${RUBY_FRAMEWORK})
file(GLOB ICON_FILES os_mac_rsrc/*.icns)
set_source_files_properties(${ICON_FILES} PROPERTIES
MACOSX_PACKAGE_LOCATION Resources)
set_source_files_properties(PSMTabBarControl.framework PROPERTIES
MACOSX_PACKAGE_LOCATION Frameworks)
add_executable(${PROGNAME} MACOSX_BUNDLE ${VIM_SOURCES} ${ICON_FILES})
target_link_libraries(${PROGNAME} ${VIM_LIBRARIES})
# Variables used in pathdef.c.in
set(VIM_DEFAULT_VIM_DIR "${VIM_PREFIX}/${PROGNAME}${VIM_DIR_PATH}")
set(VIM_DEFAULT_VIMRUNTIME_DIR "")
# How to get these two variables remains to be a question
set(VIM_ALL_CFLAGS "")
set(VIM_ALL_LFLAGS "")
set(VIM_COMPILED_USER ${COMPILED_BY})
if (NOT COMPILED_BY)
site_name(VIM_COMPILED_SYS)
endif(NOT COMPILED_BY)
# Create pathdef.c, which describes the configuration of this build
configure_fil
Re: [PATCH] Add clipboard support for running without GUI in Mac OS X
Hi, On Sat, Aug 1, 2009 at 10:45 PM, björn wrote: > A few comments on this patch: > > 1. Why have you not included the code that handles block-wise copy in > clip_mch_request_selection() from the MacVim sources? This is a bad > idea since it means that every time you copy from Vim the pasteboard > will only keep a "line-wise" copy. E.g. if you enter visual block > mode, copy, then paste, the text will be pasted line-wise even though > it should be pasted block-wise. Why did you "derive" the clipboard > code from MacVim instead of just copying it? Because that code was included in vim-cocoa long time ago, you are right, I should have checked the recent MacVim code before send out this patch. > 2. I'm not decided on this myself, but maybe it would be cleaner to > implement this using the Carbon Pasteboard Manager instead of using > Cocoa (so that you don't have to use the Objective-C compiler, fiddle > around with autorelease pools, link against Cocoa etc.): > > http://developer.apple.com/documentation/Carbon/Reference/Pasteboard_Reference/Reference/reference.html I think Pasteboard Manager belongs to the part of Carbon that won't have 64-bit version. So it will prevent vim to be built as a 64-bit binary in future Mac OS X releases. > At any rate, I would not merge this patch until #1 is resolved. The > second issue is more delicate but I have myself implemented copy/paste > using Pasteboard Manager once and I know that it is not that much of > an effort, but then again the current MacVim clipboard code works and > has been in use for quite some time so it is maybe a better idea to > just include it verbatim. I agree. Would you like me to update this patch or maybe you prefer to separate that part of the code in MacVim as one patch yourself? - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[PATCH] Add clipboard support for running without GUI in Mac OS X
Running vim under Mac OS X terminal do not support copy to/from
system clipboard currently, this patch add this feature. To have
this feature in mainstream, we receive the following benifits:
1. We can copy from/to system clipboard without running GUI.
(Default vim builds shipped with Mac OS X do not have GUI
enabled, so it can share this feature.)
2. We don't need to duplicate code in GUI implementations like
MacVim or vim-cocoa.
The clipboard handling code is derived from MacVim.
To use Cocoa APIs, we need to convert os_macosx.c into an Obj-C
file. Other changes are trivial.
---
src/Makefile |4 +-
src/configure.in |4 +-
src/main.c |4 +
src/os_macosx.c | 611 ---
src/os_macosx.m | 694 ++
src/vim.h|1 +
6 files changed, 703 insertions(+), 615 deletions(-)
delete mode 100644 src/os_macosx.c
create mode 100644 src/os_macosx.m
diff --git a/src/Makefile b/src/Makefile
index 707a20e..e6d5bbb 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -2512,8 +2512,8 @@ objects/os_beos.o: os_beos.c
objects/os_qnx.o: os_qnx.c
$(CCC) -o $@ os_qnx.c
-objects/os_macosx.o: os_macosx.c
- $(CCC) -o $@ os_macosx.c
+objects/os_macosx.o: os_macosx.m
+ $(CCC) -o $@ os_macosx.m
objects/os_mac_conv.o: os_mac_conv.c
$(CCC) -o $@ os_mac_conv.c
diff --git a/src/configure.in b/src/configure.in
index b911b81..af8abd2 100644
--- a/src/configure.in
+++ b/src/configure.in
@@ -101,7 +101,7 @@ if test "`(uname) 2>/dev/null`" = Darwin; then
if test "$enable_darwin" = "yes"; then
AC_MSG_RESULT(no)
AC_MSG_CHECKING(if Darwin files are there)
-if test -f os_macosx.c; then
+if test -f os_macosx.m; then
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT([no, Darwin support disabled])
@@ -152,7 +152,7 @@ if test "`(uname) 2>/dev/null`" = Darwin; then
if test "$enable_darwin" = "yes"; then
MACOSX=yes
-OS_EXTRA_SRC="os_macosx.c os_mac_conv.c";
+OS_EXTRA_SRC="os_macosx.m os_mac_conv.c";
OS_EXTRA_OBJ="objects/os_macosx.o objects/os_mac_conv.o"
dnl TODO: use -arch i386 on Intel machines
CPPFLAGS="$CPPFLAGS -DMACOS_X_UNIX -no-cpp-precomp"
diff --git a/src/main.c b/src/main.c
index 8a5aa98..991b865 100644
--- a/src/main.c
+++ b/src/main.c
@@ -706,6 +706,10 @@ main
qnx_clip_init();
#endif
+#if defined(MACOS_X_UNIX) && defined(FEAT_CLIPBOARD)
+clip_init(TRUE);
+#endif
+
#ifdef FEAT_XCLIPBOARD
/* Start using the X clipboard, unless the GUI was started. */
# ifdef FEAT_GUI
diff --git a/src/os_macosx.c b/src/os_macosx.c
deleted file mode 100644
index 48023e3..000
--- a/src/os_macosx.c
+++ /dev/null
@@ -1,611 +0,0 @@
-/* vi:set ts=8 sts=4 sw=4:
- *
- * VIM - Vi IMproved by Bram Moolenaar
- *
- * Do ":help uganda" in Vim to read copying and usage conditions.
- * Do ":help credits" in Vim to see a list of people who contributed.
- * See README.txt for an overview of the Vim source code.
- */
-
-/*
- * os_macosx.c -- Mac specific things for Mac OS/X.
- */
-
-#ifdef MACOS_X_UNIX
-# ifdef HAVE_CONFIG_H /* Using Makefile. */
-# include "vim.h"
-# else
-# include "os_unix.c" /* Using Project Builder */
-# endif
-#else
-Error: MACOS 9 is no longer supported in Vim 7
-#endif
-
-#ifdef _DEBUG
-void
-Trace(char* fmt, ...)
-{
-char buf[2048];
-va_list args;
-
-va_start(args, fmt);
-/* vsnprintf(buf, sizeof(buf), fmt, args);*/
-fprintf(stderr, "%s", buf);
-va_end(args);
-}
-#endif
-
-#ifdef MACOS_X_ICONVEMU
-/*
- * Libiconv emulation layer
- */
-
-struct _iconv_t
-{
-TECObjectRef tec;
-TECObjectRef tecReverse;
-TECSnifferObjectRef sniff;
-TextEncoding from;
-TextEncoding to;
-};
-/* typedef struct _iconv_t *iconv_t; */
-
-
-static int last_errno = 0;
-
-/*
- * Get TextEncoding from iconv's encoding name
- */
-static TextEncoding
-get_textencoding(const char* encodename)
-{
-static struct {
- const char* name;
- TextEncoding encode;
-} encodetable[] = {
- /* ISO-8859 encodings family */
- {"latin1", kTextEncodingISOLatin1},
- {"latin2", kTextEncodingISOLatin2},
- {"latin3", kTextEncodingISOLatin3},
- {"latin4", kTextEncodingISOLatin4},
- {"latin5", kTextEncodingISOLatin5},
- {"latin6", kTextEncodingISOLatin6},
- {"latin7", kTextEncodingISOLatin7},
- {"latin8", kTextEncodingISOLatin8},
- {"latin9", kTextEncodingISOLatin9},
- {"iso-8859-1", kTextEncodingISOLatin1},
- {"iso-8859-2", kTextEncodingISOLatin2},
- {"iso-8859-3", kTextEncodingISOLatin3},
- {"iso-8859-4", kTextEncodingISOLatin4},
- {"iso-8859-5", kTextEncodingISOLatinCyrillic},
- {"iso-8859-6", kTextEncodingISOLatinArabic},
- {"iso-8859-7", kTextEncodingISOLatinGreek},
- {"iso-8859-8", kTextEncodingISOLatinHebrew},
- {"iso-8859-9", kTextEncodingI
Re: Objective-c syntax file
Hi Xavier, On Mon, Dec 8, 2008 at 5:54 AM, Xavier Glattard <[EMAIL PROTECTED]> wrote: > Attached to this message is an Objective-c syntax file. > I started from the default syntax file, but it's now almost fully rewritten. > It probably needs some improvements but it looks nice for me :) > Any suggestion will be appreciated ! Any words on its Obj-C 2.0 [1] support? I just skimmed through it but Obj-C 2.0 keywords like @property seemed to be missing. - Jiang [1] http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/chapter_1_section_1.html --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A small patch for gui_mac.c to let ATSUI support NON-antialias.
Hi, On Sun, Aug 24, 2008 at 12:24 AM, LC Mi <[EMAIL PROTECTED]> wrote: > New to submitting a patch. Please let me know how to submit if folks agree > with this patch. :-) Thanks! As the last one touching the Carbon vim GUI code, I'd say this patch looks fine for me. However you may want to check out [EMAIL PROTECTED] since most Mac vim users have move on to use Cocoa based vim GUI. Just in case you haven't noticed that. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Weird underline highlight problem in vim-cocoa
Hi, On Sun, May 25, 2008 at 4:49 AM, björn <[EMAIL PROTECTED]> wrote: > Hi Jiang, > > This is a guess, but could it be that you need to add FEAT_GUI_COCOA > (?) to the following lines in gui.c (starting at line 2246)? Note > that this is taken from the MacVim's gui.c so line numbers may differ > and obviously the FEAT_GUI_MACVIM isn't in the original gui.c. Thanks Björn, that's exactly the reason! I missed the # ifndef MSWIN16_FASTTEXT part when I first debugging that. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Weird underline highlight problem in vim-cocoa
Hi folks, Recently I observed a weird problem in vim-cocoa when doing syntax highlighting, however after some debugging, I discovered that's not related to the GUI code. The problem is, if a :highlight rule contains "gui=italic", then it will be interpreted as underline (HL_UNDERLINE) rather than italic, resulting the GUI part drawing underlined string instead of italic ones. The tricky thing is, I only observed this in vim-cocoa, MacVim doesn't have this problem -- but I could see the differences between their code in relevant part. vim-cocoa does load the highlight rule correctly, which can be confirmed by typing :highlight , it does show "gui=italic" just like MacVim, but then emitting strings for drawing in ui_write(), the attribute contains HL_UNDERLINE, that's the part I really can't find out why. Here are two screenshots to demonstrate this briefly (note the highlight of comment): http://jjgod.org/document/images/vim-cocoa-highlight.png http://jjgod.org/document/images/macvim-highlight.png So here I'm looking for further advices, is there any other configuration may affect this behavior? Thanks. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: atsui
Hi, 2007/9/16, Noah Levitt <[EMAIL PROTECTED]>: > > Hello, > > Using mac os x carbon vim, I experience the same buggy behavior > described here: http://bike-nomad.com/vim/macatsuibug.html > > Basically, with macatsui set, unicode characters work properly, but > antialiasing doesn't work and it looks ugly. With macatsui unset, > antialiasing works, but unicode characters don't. > > The patch at http://wiki.macvim.org/wiki/VimPatches/ATSUI seems to > work for me. I'd love to see it committed. Just a quick note, this patch might be a bit out of sync with current vim code. Bram, if you'd like to merge this, please let me know, I can provide an updated one. (Interestingly, macports even remove this patch in their ports because it's out of sync..) - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: problem with MacVim
Hi, 2007/9/12, Nikola Knežević <[EMAIL PROTECTED]>: > > Hi, > I don't know whether this is the right group to post, but I have > strange problem with Vim on Mac. I've took the latest code from vim's > svn, and patched it with vim-cocoa-p95 patch. When I try to You mean vim-cocoa-r95.patch? > :e file-opened-in-another-session > vim just crashes. Terminal version survives somehow. I can not reproduce it here, what do you mean by "file-opened-in-another-session"? It will be even better if you would like to submit a new issue in http://code.google.com/p/vim-cocoa/issues/list so that I can track it. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: pum behaviour
Hi, 2007/8/22, A.Politz <[EMAIL PROTECTED]>: > Since a couple of weeks or even months, I use a custom build vim. > I was annoyed by the `flickering` popup menu (pum), so I dived > right into the vim-code. It was daunting for me, still had issues with > the language. > So I tried to find the right spots, by mass spamming statements > that prevented a redraw followed by incrementally deleting them again. > > As a result, I understood 1% of the code and had a 'behaving` pum, > which only redraws the screen at the start,end and when hiding the pvw. > If there is any interest, I can post that patch. I'm interested too, besides, I think in GVIM we can try add a native GUI based approach to create these popup menus programatically, then it's drawing should be more efficient and only limit to a small area. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim-cocoa source code for GSoC final evaluation
Hi, Sorry but I have made a mistake on generating that patch, so some content had been copied into that file twice, which will eventually made the patched code unbuildable. For people already downloaded that patch, please download it again in the same location: http://vim-cocoa.googlecode.com/files/vim-cocoa-r94.patch Thanks. (The tar.bz2 archive is fine.) - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
vim-cocoa source code for GSoC final evaluation
Hi Bram, As stated by Google Summer of Code 2007 Final Evaluation Period Information, Monday, August 20th at 19:00 UTC is student "Pencils down" time. So I've created the following source code snapshot for you to check: http://vim-cocoa.googlecode.com/files/vim-cocoa-r94.patch This patch can be applied to vim 7.1.83. For complete build instructions, see: http://code.google.com/p/vim-cocoa/wiki/BuildInstructions There is also a compressed archive of Vim.app (including all binaries and runtime files): http://vim-cocoa.googlecode.com/files/vim-cocoa-r94.tar.bz2 I also created a tag in subversion: http://vim-cocoa.googlecode.com/svn/tags/gsoc-final-evaluation/ Code in http://vim-cocoa.googlecode.com/svn/trunk will be continue updated. At present, vim-cocoa has implemented most features the original vim on mac has with Cocoa framework. But it still lacks major features like toolbar and tabline. A lot of code came from Björn Winckler's MacVim implementation. Though in some low level details, me and Björn experimented different solutions, but his work definitely made my job much easier. Thanks a lot, Björn! - Jiang [1] http://groups.google.com/group/google-summer-of-code-announce/web/midterm-survey-information-2 --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for mac-specific bug in :winpos
Hi, 2007/8/19, Bram Moolenaar <[EMAIL PROTECTED]>: > So is Michael's solution preferred? Simpler doesn't always mean better. Yes, I prefer his solution. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for mac-specific bug in :winpos
Hi, 2007/8/19, Bram Moolenaar <[EMAIL PROTECTED]>: > I have not seen your patch for this from you. Can you send it again? Sure. It's now sent to [EMAIL PROTECTED] again. Please note I used an approach slightly different than Michael's: get the title bar height, save it as a global variable, add this height to y coordinate in gui_mch_set_win_pos(). Of course Michael's solution is simpler. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for mac-specific bug in :winpos
Hi, 2007/8/19, Michael Henry <[EMAIL PROTECTED]>: > > All, > > The mac port of gvim has a bug in the implementation of :winpos. > > Version: 7.1.82 (mac only) I can confirm this, I've sent a (different) patch to [EMAIL PROTECTED] before it was down last time. It seems Bram didn't notice that. Hopefully this patch will get merged. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
