* Emacs with Cocoa/GNUstep
@ 2011-04-27 0:39 Germán Arias
2011-04-27 1:19 ` David Reitter
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Germán Arias @ 2011-04-27 0:39 UTC (permalink / raw
To: Emacs
Hi, I'm trying to run emacs with GNUstep, but it seems to be totally
broken. So my question is if someone is running emacs with Cocoa and if
it works fine. Because with latest gnustep packages don't work (compile
but can't run). And after the last update in file configure.in, the
class nsmenu.m can't compile. So I can guess there isn't testing in
GNUstep/Cocoa. Is just a question before trying to get working emacs
with gnustep. Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 0:39 Emacs with Cocoa/GNUstep Germán Arias
@ 2011-04-27 1:19 ` David Reitter
2011-04-27 3:56 ` CHENG Gao
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: David Reitter @ 2011-04-27 1:19 UTC (permalink / raw
To: german; +Cc: Emacs
On Apr 26, 2011, at 8:39 PM, Germán Arias wrote:
>
> broken. So my question is if someone is running emacs with Cocoa and if
> it works fine.
Yes, it works as intended, at least as of April 1st, when the last sync to the Git repository took place.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 0:39 Emacs with Cocoa/GNUstep Germán Arias
2011-04-27 1:19 ` David Reitter
@ 2011-04-27 3:56 ` CHENG Gao
2011-04-27 4:38 ` Germán Arias
2011-04-27 4:15 ` Pascal J. Bourguignon
2011-04-27 19:13 ` David De La Harpe Golden
3 siblings, 1 reply; 11+ messages in thread
From: CHENG Gao @ 2011-04-27 3:56 UTC (permalink / raw
To: emacs-devel
It works for me. I build from bzr repo frequently and now I am using
Apr. 25 build.
,----
| GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.7.0, NS apple-appkit-1038.35)
| of 2011-04-25
`----
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 0:39 Emacs with Cocoa/GNUstep Germán Arias
2011-04-27 1:19 ` David Reitter
2011-04-27 3:56 ` CHENG Gao
@ 2011-04-27 4:15 ` Pascal J. Bourguignon
2011-04-27 19:13 ` David De La Harpe Golden
3 siblings, 0 replies; 11+ messages in thread
From: Pascal J. Bourguignon @ 2011-04-27 4:15 UTC (permalink / raw
To: emacs-devel
Germán Arias <german@xelalug.org> writes:
> Hi, I'm trying to run emacs with GNUstep, but it seems to be totally
> broken. So my question is if someone is running emacs with Cocoa and if
> it works fine. Because with latest gnustep packages don't work (compile
> but can't run). And after the last update in file configure.in, the
> class nsmenu.m can't compile. So I can guess there isn't testing in
> GNUstep/Cocoa. Is just a question before trying to get working emacs
> with gnustep. Thanks.
Emacs works very well in MacOSX:
http://emacsformacosx.com/
I don't know about gnustep, it's been a long time.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 3:56 ` CHENG Gao
@ 2011-04-27 4:38 ` Germán Arias
2011-04-27 4:56 ` CHENG Gao
2011-04-27 6:13 ` Paul Eggert
0 siblings, 2 replies; 11+ messages in thread
From: Germán Arias @ 2011-04-27 4:38 UTC (permalink / raw
To: CHENG Gao; +Cc: emacs-devel
On mié, 2011-04-27 at 11:56 +0800, CHENG Gao wrote:
> It works for me. I build from bzr repo frequently and now I am using
> Apr. 25 build.
>
> ,----
> | GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.7.0, NS apple-appkit-1038.35)
> | of 2011-04-25
> `----
Hi, I have the revision:
revision-id:
bkey76@gmail.com-20110427021744-cs2b8xl1kzfv0sj4
date: 2011-04-26 21:17:44 -0500
build-date: 2011-04-26 22:24:07 -0600
revno: 104022
branch-nick: trunk
In gNewSense Delta H with GCC 4.2 and latest GNUstep packages. Compiling
with:
./autogen.sh
./configure --with-ns
make bootstrap (if necessary)
make install
First I noticed some methods that are not present on GNUstep:
nsterm.m: In function ‘ns_update_end’:
nsterm.m:738: warning: ‘NSView’ may not respond to
‘-unlockFocusNeedsFlush:’
nsterm.m:738: warning: (Messages without a matching method signature
nsterm.m:738: warning: will be assumed to return ‘id’ and accept
nsterm.m:738: warning: ‘...’ as arguments.)
...
...
nsfns.m: In function ‘Fns_convert_utf8_nfd_to_nfc’:
nsfns.m:1974: warning: ‘NSString’ may not respond to
‘-precomposedStringWithCanonicalMapping’
nsfns.m:1974: warning: (Messages without a matching method signature
nsfns.m:1974: warning: will be assumed to return ‘id’ and accept
nsfns.m:1974: warning: ‘...’ as arguments.)
This is not a problem, for the moment, the problem is:
gcc -c -Demacs -DHAVE_CONFIG_H -I. -I/home/german/Instalados/emacs/src -I../lib -I/home/german/Instalados/emacs/src/../lib -D_REENTRANT -fPIC -fno-strict-aliasing -I/usr/include/libxml2 -MMD -MF deps/nsmenu.d -Wimplicit-function-declaration -Wold-style-definition -Wdeclaration-after-statement -g -O2 -fgnu-runtime -Wno-import -fconstant-string-class=NSConstantString -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN -DGSDIAGNOSE nsmenu.m
nsmenu.m: In function ‘ns_update_menubar’:
nsmenu.m:229: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m:230: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m:231: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m:233: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m:235: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m:349: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m:410: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m:437: error: ‘struct Lisp_Vector’ has no member named ‘size’
nsmenu.m: In function ‘-[EmacsMenu fillWithWidgetValue:]’:
nsmenu.m:690: warning: passing argument 1 of ‘setAction:’ from
incompatible pointer type
nsmenu.m: In function ‘-[EmacsMenu addSubmenuWithTitle:forFrame:]’:
nsmenu.m:711: warning: passing argument 2 of
‘addItemWithTitle:action:keyEquivalent:’ from incompatible pointer type
make[2]: *** [nsmenu.o] Error 1
make[2]: Leaving directory `/home/german/Instalados/emacs/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/home/german/Instalados/emacs'
make: *** [bootstrap] Error 2
I get this error after the update I did today. Before it, the app
compiled OK, but had problems to launch. I was investigating that issue,
but after the update I can't compile the app again. Because I get the
error above.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 4:38 ` Germán Arias
@ 2011-04-27 4:56 ` CHENG Gao
2011-04-27 6:13 ` Paul Eggert
1 sibling, 0 replies; 11+ messages in thread
From: CHENG Gao @ 2011-04-27 4:56 UTC (permalink / raw
To: emacs-devel
Just found out I forgot to mention something. I mean it works for me on
MacOSX.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 4:38 ` Germán Arias
2011-04-27 4:56 ` CHENG Gao
@ 2011-04-27 6:13 ` Paul Eggert
2011-04-27 23:54 ` Germán Arias
1 sibling, 1 reply; 11+ messages in thread
From: Paul Eggert @ 2011-04-27 6:13 UTC (permalink / raw
To: german; +Cc: emacs-devel
On 04/26/11 21:38, Germán Arias wrote:
> nsmenu.m:229: error: ‘struct Lisp_Vector’ has no member named ‘size’
That problem was due to my change to lisp.h in revno 104021.
Sorry about that. I committed the following fix in revno 104024.
This patch can be applied independently of the earlier
lisp.h change, and it isolates nsmenu.m from that implementation
detail of lisp.h so it should be a win independently of the
lisp.h change.
2011-04-27 Paul Eggert <eggert@cs.ucla.edu>
* nsmenu.m: Replace all uses of XVECTOR with ASIZE and AREF.
This makes this file independent of the recent pseudovector change.
--- src/nsmenu.m 2011-03-27 09:23:52 +0000
+++ src/nsmenu.m 2011-04-27 06:01:43 +0000
@@ -218,7 +218,7 @@
/* Save the frame's previous menu bar contents data */
if (previous_menu_items_used)
- memcpy (previous_items, XVECTOR (f->menu_bar_vector)->contents,
+ memcpy (previous_items, &AREF (f->menu_bar_vector, 0),
previous_menu_items_used * sizeof (Lisp_Object));
/* parse stage 1: extract from lisp */
@@ -226,19 +226,19 @@
menu_items = f->menu_bar_vector;
menu_items_allocated = VECTORP (menu_items) ? ASIZE (menu_items) : 0;
- submenu_start = (int *) alloca (XVECTOR (items)->size * sizeof (int *));
- submenu_end = (int *) alloca (XVECTOR (items)->size * sizeof (int *));
- submenu_n_panes = (int *) alloca (XVECTOR (items)->size * sizeof (int));
+ submenu_start = (int *) alloca (ASIZE (items) * sizeof (int *));
+ submenu_end = (int *) alloca (ASIZE (items) * sizeof (int *));
+ submenu_n_panes = (int *) alloca (ASIZE (items) * sizeof (int));
submenu_top_level_items
- = (int *) alloca (XVECTOR (items)->size * sizeof (int *));
+ = (int *) alloca (ASIZE (items) * sizeof (int *));
init_menu_items ();
- for (i = 0; i < XVECTOR (items)->size; i += 4)
+ for (i = 0; i < ASIZE (items); i += 4)
{
Lisp_Object key, string, maps;
- key = XVECTOR (items)->contents[i];
- string = XVECTOR (items)->contents[i + 1];
- maps = XVECTOR (items)->contents[i + 2];
+ key = AREF (items, i);
+ string = AREF (items, i + 1);
+ maps = AREF (items, i + 2);
if (NILP (string))
break;
@@ -311,11 +311,11 @@
/* FIXME: this ALWAYS fails on Buffers menu items.. something
about their strings causes them to change every time, so we
double-check failures */
- if (!EQ (previous_items[i], XVECTOR (menu_items)->contents[i]))
+ if (!EQ (previous_items[i], AREF (menu_items, i)))
if (!(STRINGP (previous_items[i])
- && STRINGP (XVECTOR (menu_items)->contents[i])
+ && STRINGP (AREF (menu_items, i))
&& !strcmp (SDATA (previous_items[i]),
- SDATA (XVECTOR (menu_items)->contents[i]))))
+ SDATA (AREF (menu_items, i)))))
break;
if (i == previous_menu_items_used)
{
@@ -346,10 +346,10 @@
/* Parse stage 2a: now GC cannot happen during the lifetime of the
widget_value, so it's safe to store data from a Lisp_String */
wv = first_wv->contents;
- for (i = 0; i < XVECTOR (items)->size; i += 4)
+ for (i = 0; i < ASIZE (items); i += 4)
{
Lisp_Object string;
- string = XVECTOR (items)->contents[i + 1];
+ string = AREF (items, i + 1);
if (NILP (string))
break;
/* if (submenu && strcmp (submenuTitle, SDATA (string)))
@@ -407,7 +407,7 @@
/* check if no change.. this mechanism is a bit rough, but ready */
- n = XVECTOR (items)->size / 4;
+ n = ASIZE (items) / 4;
if (f == last_f && n_previous_strings == n)
{
for (i = 0; i<n; i++)
@@ -434,9 +434,9 @@
}
[menu clear];
- for (i = 0; i < XVECTOR (items)->size; i += 4)
+ for (i = 0; i < ASIZE (items); i += 4)
{
- string = XVECTOR (items)->contents[i + 1];
+ string = AREF (items, i + 1);
if (NILP (string))
break;
@@ -794,7 +794,7 @@
i = 0;
while (i < menu_items_used)
{
- if (EQ (XVECTOR (menu_items)->contents[i], Qnil))
+ if (EQ (AREF (menu_items, i), Qnil))
{
submenu_stack[submenu_depth++] = save_wv;
save_wv = prev_wv;
@@ -802,21 +802,21 @@
first_pane = 1;
i++;
}
- else if (EQ (XVECTOR (menu_items)->contents[i], Qlambda))
+ else if (EQ (AREF (menu_items, i), Qlambda))
{
prev_wv = save_wv;
save_wv = submenu_stack[--submenu_depth];
first_pane = 0;
i++;
}
- else if (EQ (XVECTOR (menu_items)->contents[i], Qt)
+ else if (EQ (AREF (menu_items, i), Qt)
&& submenu_depth != 0)
i += MENU_ITEMS_PANE_LENGTH;
/* Ignore a nil in the item list.
It's meaningful only for dialog boxes. */
- else if (EQ (XVECTOR (menu_items)->contents[i], Qquote))
+ else if (EQ (AREF (menu_items, i), Qquote))
i += 1;
- else if (EQ (XVECTOR (menu_items)->contents[i], Qt))
+ else if (EQ (AREF (menu_items, i), Qt))
{
/* Create a new pane. */
Lisp_Object pane_name, prefix;
@@ -906,7 +906,7 @@
make the call_data null so that it won't display a box
when the mouse is on it. */
wv->call_data
- = !NILP (def) ? (void *) &XVECTOR (menu_items)->contents[i] : 0;
+ = !NILP (def) ? (void *) &AREF (menu_items, i) : 0;
wv->enabled = !NILP (enable);
if (NILP (type))
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 0:39 Emacs with Cocoa/GNUstep Germán Arias
` (2 preceding siblings ...)
2011-04-27 4:15 ` Pascal J. Bourguignon
@ 2011-04-27 19:13 ` David De La Harpe Golden
2011-04-28 0:24 ` Germán Arias
3 siblings, 1 reply; 11+ messages in thread
From: David De La Harpe Golden @ 2011-04-27 19:13 UTC (permalink / raw
To: german; +Cc: Emacs
On 27/04/11 01:39, Germán Arias wrote:
> Hi, I'm trying to run emacs with GNUstep, but it seems to be totally
> broken. So my question is if someone is running emacs with Cocoa and if
> it works fine. Because with latest gnustep packages don't work (compile
> but can't run). And after the last update in file configure.in, the
> class nsmenu.m can't compile. So I can guess there isn't testing in
> GNUstep/Cocoa.
Probably not a whole lot.... FWIW, I built it successfully several times
a few months back, and though it was not really especially useful once
built, it was not completely unusable either, it was working enough for
me to debug some pasteboard interaction issues without having access to
macosx.
I'm not personally up to doing much it about it at the moment, so here
are some notes (Stefan: mostly same ones I passed offlist to you at the
time) as a braindump, some of the below is probably obsolete:
First and foremost, DO NOT use any debian packages of GNUstep at time of
writing, they're obsolete and hopelessly buggy, especially on 64-bit. I
wasted basically a weekend's worth of emacs-time that way, I switched to
an svn checkout of GNUstep installed to /usr/local/GNUstep and was up
and running fairly rapidly.
GNUstep itself is fairly painless to build from source (though n.b. I am
used to underdocumented build scripts from hell from work, my perception
may be skewed), the most tricky bit was getting building the
gnustep-back backend right, so that I could use cairo.
http://wiki.gnustep.org/index.php/GNUstep_Installation_Process
The other build-time issue is that emacs "./configure --with-ns" doesn't
seem to discover the ObjC headers properly in the gnustep case -
specifying CPPFLAGS "fixed" that, but I suspect TRT would be to have
emacs' configure use "gnustep-config --objc-flags" to discover the flags
(or maybe just $GNUSTEP_MAKEFILES and the right part of gnustep's
Makefiles, but gnustep-config seems interesting 'cos it apparently works
much like other blah-config type tools).
I wouldn't say it is _totally_ unusable, but neither is it at all
pleasant . There are probably plenty more smaller issues that I'm
presently not noticing given the big ones:
0. Make sure the relevant gnustep daemons are running.
I mean the gpbs / gdnc /gdomap daemons. Not really an emacs problem,
and documented in the gnustep docs, just something to be aware of.
gpbs is particularly important, as it's the GNUstep PasteBoard Server,
and without it, clipboard/primary/secondary just ain't gonna work.
http://gnustep.made-it.com/BuildGuide/index.html#GNUSTEP.SERVICES
1. frame resizing.
The single most major annoyance (or at least tied with repaint) is that
it doesn't handle being resized by the window manager, you have to
(set-frame-width/height) from within emacs for it to work. I guess
macosx handles resizing differently.
2. repaint
There are nasty repaint issues sometimes too upon partial scrolling, a
bit like the ones you used to see on w32 emacs under wine. A
page-scroll up and down has thus far largely dispelled them when they
occur. Some of the colors seem way off (my yellow-on-black fringes come
out cyan-on-white).
3. toolbar/scrollbar.
The toolbar doesn't work, and the scrollbars only work sometimes, but
it's not like I use either much. The menu bar is fine.
4. choice of fonts and gui backend:
Wrong choice of font can render it difficult to use too - its metric
computation isn't always right I guess, with one font I ended up with
something like a 3-pixel high minibuffer.
Remember that GNUstep also has multiple graphics backends with different
font behaviours, I used the cairo backend which reputedly has slightly
poorer font rendering than art, but OTOH worked.
Remember to try with "openapp Emacs -Q", because your ~/.emacs (which
gnustep will see) might be setting a problematic font, mine initially was.
It sometimes makes "interesting" font choices itself, I don't know where
it found some sort of comic-sans alike on my system but it did.
5. Non-latin chars.
Doesn't seem to do well here at all.
6. keyboard modifier mapping
One thing that helped a lot was to reconfigure the gnustep-level
keyboard modifier mapping so that the keys in ns emacs ultimately wound
up similar to x11 emacs with its out-of-box defaults.
http://www.gnustep.org/resources/documentation/Developer/Back/General/DefaultsSummary.html
I used (with Help on Super_R because I wanted to see what it did, turns
out ns emacs treats it as Hyper...):
NSGlobalDomain GSFirstControlKey Control_L
NSGlobalDomain GSSecondControlKey Control_R
NSGlobalDomain GSFirstAlternateKey Alt_L
NSGlobalDomain GSSecondAlternateKey NoSymbol
NSGlobalDomain GSFirstCommandKey Super_L
NSGlobalDomain GSSecondCommandKey NoSymbol
NSGlobalDomain GSFirstHelpKey Help
NSGlobalDomain GSSecondHelpKey Super_R
7. [new since I passed this to Stefan]. No timers/idle???
Timers and idle stuff mostly not running, I think. Emacs processes stuff
when there's input i.e. wiggle the mouse to make stuff happen ?!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 6:13 ` Paul Eggert
@ 2011-04-27 23:54 ` Germán Arias
0 siblings, 0 replies; 11+ messages in thread
From: Germán Arias @ 2011-04-27 23:54 UTC (permalink / raw
To: Paul Eggert; +Cc: emacs-devel
On mar, 2011-04-26 at 23:13 -0700, Paul Eggert wrote:
> On 04/26/11 21:38, Germán Arias wrote:
> > nsmenu.m:229: error: ‘struct Lisp_Vector’ has no member named ‘size’
>
> That problem was due to my change to lisp.h in revno 104021.
> Sorry about that. I committed the following fix in revno 104024.
> This patch can be applied independently of the earlier
> lisp.h change, and it isolates nsmenu.m from that implementation
> detail of lisp.h so it should be a win independently of the
> lisp.h change.
Thanks, now compile again.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-27 19:13 ` David De La Harpe Golden
@ 2011-04-28 0:24 ` Germán Arias
2011-04-28 15:30 ` Stefan Monnier
0 siblings, 1 reply; 11+ messages in thread
From: Germán Arias @ 2011-04-28 0:24 UTC (permalink / raw
To: David De La Harpe Golden; +Cc: Emacs
On mié, 2011-04-27 at 20:13 +0100, David De La Harpe Golden wrote:
>
> Probably not a whole lot.... FWIW, I built it successfully several times
> a few months back, and though it was not really especially useful once
> built, it was not completely unusable either, it was working enough for
> me to debug some pasteboard interaction issues without having access to
> macosx.
>
> I'm not personally up to doing much it about it at the moment, so here
> are some notes (Stefan: mostly same ones I passed offlist to you at the
> time) as a braindump, some of the below is probably obsolete:
Thanks, Stefan sent me a copy of that email some days ago.
>
> First and foremost, DO NOT use any debian packages of GNUstep at time of
> writing, they're obsolete and hopelessly buggy, especially on 64-bit. I
> wasted basically a weekend's worth of emacs-time that way, I switched to
> an svn checkout of GNUstep installed to /usr/local/GNUstep and was up
> and running fairly rapidly.
>
> GNUstep itself is fairly painless to build from source (though n.b. I am
> used to underdocumented build scripts from hell from work, my perception
> may be skewed), the most tricky bit was getting building the
> gnustep-back backend right, so that I could use cairo.
>
> http://wiki.gnustep.org/index.php/GNUstep_Installation_Process
>
I'm a contributor to GNUstep project since 2 years ago. So I really
don't have problems to install it from source. In fact I have more or
less (with some additions from SVN) the latest stable release of
GNUstep. And many apps that run perfectly.
> The other build-time issue is that emacs "./configure --with-ns" doesn't
> seem to discover the ObjC headers properly in the gnustep case -
> specifying CPPFLAGS "fixed" that, but I suspect TRT would be to have
> emacs' configure use "gnustep-config --objc-flags" to discover the flags
> (or maybe just $GNUSTEP_MAKEFILES and the right part of gnustep's
> Makefiles, but gnustep-config seems interesting 'cos it apparently works
> much like other blah-config type tools).
./configure --with-ns works fine form me (with stable release of
GNUstep).
>
> I wouldn't say it is _totally_ unusable, but neither is it at all
> pleasant . There are probably plenty more smaller issues that I'm
> presently not noticing given the big ones:
I tried Emacs.app like a year ago. I don't remember exactly what
version. I tested it and worked (with problems and sometimes crashed).
But currently, when I try to launch it I get the error:
german@german-desktop:~/Instalados/emacs$ openapp ./nextstep/Emacs.app/
/home/german/Instalados/emacs/nextstep/Emacs.app/Emacs: Uncaught
exception NSInternalInconsistencyException, reason: NSApp's run called
recursively
>
> 0. Make sure the relevant gnustep daemons are running.
>
> I mean the gpbs / gdnc /gdomap daemons. Not really an emacs problem,
> and documented in the gnustep docs, just something to be aware of.
>
> gpbs is particularly important, as it's the GNUstep PasteBoard Server,
> and without it, clipboard/primary/secondary just ain't gonna work.
>
> http://gnustep.made-it.com/BuildGuide/index.html#GNUSTEP.SERVICES
>
> 1. frame resizing.
>
> The single most major annoyance (or at least tied with repaint) is that
> it doesn't handle being resized by the window manager, you have to
> (set-frame-width/height) from within emacs for it to work. I guess
> macosx handles resizing differently.
>
> 2. repaint
>
> There are nasty repaint issues sometimes too upon partial scrolling, a
> bit like the ones you used to see on w32 emacs under wine. A
> page-scroll up and down has thus far largely dispelled them when they
> occur. Some of the colors seem way off (my yellow-on-black fringes come
> out cyan-on-white).
>
> 3. toolbar/scrollbar.
>
> The toolbar doesn't work, and the scrollbars only work sometimes, but
> it's not like I use either much. The menu bar is fine.
>
> 4. choice of fonts and gui backend:
>
> Wrong choice of font can render it difficult to use too - its metric
> computation isn't always right I guess, with one font I ended up with
> something like a 3-pixel high minibuffer.
>
> Remember that GNUstep also has multiple graphics backends with different
> font behaviours, I used the cairo backend which reputedly has slightly
> poorer font rendering than art, but OTOH worked.
>
> Remember to try with "openapp Emacs -Q", because your ~/.emacs (which
> gnustep will see) might be setting a problematic font, mine initially was.
>
> It sometimes makes "interesting" font choices itself, I don't know where
> it found some sort of comic-sans alike on my system but it did.
>
> 5. Non-latin chars.
>
> Doesn't seem to do well here at all.
>
> 6. keyboard modifier mapping
>
> One thing that helped a lot was to reconfigure the gnustep-level
> keyboard modifier mapping so that the keys in ns emacs ultimately wound
> up similar to x11 emacs with its out-of-box defaults.
>
> http://www.gnustep.org/resources/documentation/Developer/Back/General/DefaultsSummary.html
>
> I used (with Help on Super_R because I wanted to see what it did, turns
> out ns emacs treats it as Hyper...):
>
> NSGlobalDomain GSFirstControlKey Control_L
> NSGlobalDomain GSSecondControlKey Control_R
>
> NSGlobalDomain GSFirstAlternateKey Alt_L
> NSGlobalDomain GSSecondAlternateKey NoSymbol
>
> NSGlobalDomain GSFirstCommandKey Super_L
> NSGlobalDomain GSSecondCommandKey NoSymbol
>
> NSGlobalDomain GSFirstHelpKey Help
> NSGlobalDomain GSSecondHelpKey Super_R
>
>
> 7. [new since I passed this to Stefan]. No timers/idle???
>
> Timers and idle stuff mostly not running, I think. Emacs processes stuff
> when there's input i.e. wiggle the mouse to make stuff happen ?!
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emacs with Cocoa/GNUstep
2011-04-28 0:24 ` Germán Arias
@ 2011-04-28 15:30 ` Stefan Monnier
0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2011-04-28 15:30 UTC (permalink / raw
To: german; +Cc: Emacs, David De La Harpe Golden
> I tried Emacs.app like a year ago. I don't remember exactly what
> version. I tested it and worked (with problems and sometimes crashed).
> But currently, when I try to launch it I get the error:
The problem with the GNUstep version of Emacs is that it has never
worked satisfactorily, not noone uses it, so we never learn about
regressions, such as ones introduced by changes for Mac OS X using
features that don't work quite the same under GNUstep.
Any help in getting the GNUstep version to a usable state would be very
welcome, and subsequently to keep it usable as well, of course.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-04-28 15:30 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-27 0:39 Emacs with Cocoa/GNUstep Germán Arias
2011-04-27 1:19 ` David Reitter
2011-04-27 3:56 ` CHENG Gao
2011-04-27 4:38 ` Germán Arias
2011-04-27 4:56 ` CHENG Gao
2011-04-27 6:13 ` Paul Eggert
2011-04-27 23:54 ` Germán Arias
2011-04-27 4:15 ` Pascal J. Bourguignon
2011-04-27 19:13 ` David De La Harpe Golden
2011-04-28 0:24 ` Germán Arias
2011-04-28 15:30 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).