mac-emacs-users

[Mac-emacs-users] viper mode

[John C L. <jc...@po...>]

I've built and installed Emacs 21 on OS 10.1. All seems well, thus far.
I can't seem to start viper-mode, however. It works in the term window. 
But when .app version is run from finder, I get the following lisp error: 
Symbol's function definition is void: iconify-or-deiconify-frame. Tried 
make and make bootstrap. Same error. Any thoughts? Thanks in advance.

John Lamoreaux
Department of Religious Studies
Southern Methodist University

[Mac-emacs-users] make better use of SourceForge?

[Max H. <ma...@qu...>]

Maybe it would be a good thing to make better use of SourceForge for 
this project? In particular the bug tracker could be useful.


Also, I'd love if the current binary version (and the source maybe, 
too), could also be made available via the File Release System. From 
Andrew's site, I only get 4-5KB/s, while from SourceForge I can get 
much faster speeds.

If there are techincal problems with this (e.g. FRS giving you 
trouble or whatever), I am willing to help out if I somehow can. I am 
experienced with the use of SF, being admin and member in various 
other projects.
Or maybe you have other fundamental reasons for not making more use 
of SF, in that case, maybe you can enlighten us as to what those are? 
Thanks!


Just my two cent of course :) Please keep up the good work,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Re: [Mac-emacs-users] emacs-on-aqua vs. mac-emacs

[Andrew C. <ak...@cs...>]

> I was noodling around sourceforge, and noticed that there is a
> sourceforge project called emacs-on-aqua, now. How is this different
> from the mac-emacs project?
> 
> Bill

Hi Bill,

These are two separate efforts.  Some of the advantages of the
mac-emacs project are:

+ It is based on GNU Emacs 21.1.  So it has most of the features of
  version 21.

+ The Mac OS Classic code is part of the standard GNU Emacs source
  distribution.  The Mac OS X code will probably be part of 21.3 (you
  can currently get this as a patch).

+ It has international font/fontset and LEIM support.

The following is a distinguishing characteristic and not an advantage:

+ It uses the Carbon API to implement the GUI.

Andrew.

[Mac-emacs-users] emacs-on-aqua vs. mac-emacs

[Bill R. <br...@lo...>]

I was noodling around sourceforge, and noticed that there is a 
sourceforge project called emacs-on-aqua, now. How is this different from 
the mac-emacs project?

Bill

Re: [Mac-emacs-users] Font tool for OSX

[Palle G. <gi...@pa...>]

Maybe t1utils, http://www.lcdf.org/~eddietwo/type/, does what you want?

Regards,
Palle

--On Friday, December 21, 2001 23:19:26 +0900 Shun Iguchi 
<kar...@ma...> wrote:

> Hi,
>
> I'm tring to make an additional font suitcase from a set of Japanese
> bdf fonts to use on Emacs21.1 for Mac OS X. I found a font tool
> (intlfonts-1.2-mac-src-1.0.smi.bin) in mac-emacs site, but it seems
> not to support Mac OS X.
>
> Does anyone have information about tools which convert bdf fonts to
> Mac font suitcase on Mac OS X?
>
>
> --
> Shun
>
> _______________________________________________
> Mac-emacs-users mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/mac-emacs-users

[Mac-emacs-users] =?euc-kr?B?WyC3r7rqvK3HwbimIMPfw7XH1bTPtNkuIF0=?=

[<gol...@ve...>]

tNQuLiC+yLPnx8+8vL/kPyANCg0KW2NsaWNrIHRvIHNlZSBdDQo8aHR0cDovL3d3dy5sb3Zlc3Vy
Zi5jby5rci9kZWZhdWx0LmFzcD9zPTExMTMzNDEmZW1haWw9bWFjLWVtYWNzLXVzZXJzQGwNCmlz
dHMuc291cmNlZm9yZ2UubmV0PiAgCQ0KDQoiu+e2+yDHz7jpvK0gxKOxuLfOILi4s6q0wrDUILmr
vbwgwMe5zLChIMDWwdI/IiANCiK52bbzuLgguri0wiC757b7tbUgwNa+7r/kLiINCiK/1iCx17ex
ILvntvvAuyDHz8HSPyCwxbrOtOfH0rChILXOt8G/9r/kPyIgDQois60gsdcgu+e298C7ILvntvvH
z7TCsMXB9iwgu+e2+7neseK4piC/+MfPtMKwxyC+xrPXv+QuLi4iDQoNCnd3dy5Mb3Zlc3VyZi5j
by5rcg0KPGh0dHA6Ly93d3cubG92ZXN1cmYuY28ua3IvZGVmYXVsdC5hc3A/cz0xMTEzMzQxJmVt
YWlsPW1hYy1lbWFjcy11c2Vyc0BsDQppc3RzLnNvdXJjZWZvcmdlLm5ldD4gKiDH0bHbxsfAuiDD
0SAyOSwwMDAgxuTAzMH2t84gtNzAz7HitMkgwKUgu+fAzMaut860wiDH0bG5wLogubC30CC8vLDo
IMPWtOux1LjwwMcNCrvnwMzGrrfOILy6wM4gW7OysPq/qV0sIFuzsrD6s7JdLCBbv6m/zb+pXSwg
w7u80rPiW7OysPq/qV3AxyA0ILCzwMcgxL+5wrTPxry4piC48LXOILz2v+vH0SC758DMxq63ziC9
zLHbILbzwMzHwcDHDQq757v9yLCxx8DHILq4yKO/zSC9usXkxL/AxyC55sH2uKYgw9a/7LyxwLi3
ziDBtsH3tcggwKUgu+fAzMauIMDUtM+02S4gDQrDu7zSs+LAuyDAp8fRILvnwMzGrrTCIHd3dy5t
eWdhbC5jby5rciA8aHR0cDovL3d3dy5teWdhbC5jby5rci9kZWZhdWx0LmFzcD4gIMDUtM+02S4g
DQoNCsPfw7XAziAtIA0KDQoNCsDMILjewM/AuyC+1cC4t84gud6w7SC9zcH2IL7KwLi9w7TZuOkg
uN7Az7z2vcWwxcD9DQo8aHR0cDovL3d3dy5sb3Zlc3VyZi5jby5rci90b3Bhci9yZWplY3QuYXNw
P3M9MTExMzM0MSZlbWFpbD1tYWMtZW1hY3MtdXMNCmVyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+
ICDAuyDFqbivIMfPvLy/5C4gDQoNCg==

[Mac-emacs-users] Slow Redisplay Bug Fix [Corrected Version]

[Andrew C. <ak...@cs...>]

Hi Everyone,

I posted a bug fix to the patch emacs-21.1-2-mac.patch.gz that was
supposed to improve the speed of redisplay.  Turns out it didn't
really do anything (it didn't do any harm either).  My apologies.

Here is one that really works!  This fix makes a big difference for
people using a quail input method for typing Chinese or Japanese.
Without it, input is very sluggish because there's a long delay (to
regenerate and reinstall the menus) after each key press.  It may fix
other input-related sluggishness too.  You'd never know :-).

Please apply the following patch to src/macmenu.c (without applying
the previous one; undo it if you have already applied that one).

Andrew.
-----
--- macmenu.c.orig	Fri Nov  2 10:50:08 2001
+++ macmenu.c	Thu Jan  3 15:48:06 2002
@@ -1336,11 +1336,13 @@
       = (Lisp_Object *) alloca (previous_menu_items_used
                                 * sizeof (Lisp_Object));
 
+#if 0
     /* If we are making a new widget, its contents are empty,
        do always reinitialize them.  */
     if (! menubar_widget)
       previous_menu_items_used = 0;
-
+#endif
+      
     buffer = XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer;
     specbind (Qinhibit_quit, Qt);
     /* Don't let the debugger step into this code
@@ -1370,12 +1372,13 @@
     inhibit_garbage_collection ();
 
     /* Save the frame's previous menu bar contents data.  */
-    bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
-	   previous_menu_items_used * sizeof (Lisp_Object));
+    if (previous_menu_items_used)
+      bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
+	     previous_menu_items_used * sizeof (Lisp_Object));
 
     /* Fill in the current menu bar contents.  */
     menu_items = f->menu_bar_vector;
-    menu_items_allocated = XVECTOR (menu_items)->size;
+    menu_items_allocated = VECTORP (menu_items) ? ASIZE (menu_items) : 0;
     init_menu_items ();
     for (i = 0; i < XVECTOR (items)->size; i += 4)
       {
@@ -1407,9 +1410,10 @@
        of the menu bar, skip redisplaying it.  Just exit.  */
 
     for (i = 0; i < previous_menu_items_used; i++)
-    if (menu_items_used == i
-	|| (!EQ (previous_items[i], XVECTOR (menu_items)->contents[i])))
-      break;
+      if (menu_items_used == i
+	  || (!Fequal (previous_items[i],
+		       XVECTOR (menu_items)->contents[i])))
+	break;
     if (i == menu_items_used && i == previous_menu_items_used && i != 0)
       {
 	free_menubar_widget_value_tree (first_wv);

Re: [Mac-emacs-users] Font tool for OSX

[Andrew C. <ak...@cs...>]

> I'm tring to make an additional font suitcase from a set of Japanese
> bdf fonts to use on Emacs21.1 for Mac OS X. I found a font tool
> (intlfonts-1.2-mac-src-1.0.smi.bin) in mac-emacs site, but it seems
> not to support Mac OS X.
> 
> Does anyone have information about tools which convert bdf fonts to
> Mac font suitcase on Mac OS X?

Hi Shun,

Sorry for the late reply.  The font tools there run under MPW which
can probably run in the Classic environment of Mac OS X (can you
please try?).  To convert Japanese fonts you need bdf2ttbm rather han
bdf2NFNT.  The former writes the bitmap variant of a Truetype font.
I'm not sure whether OS X is able to use the font it generates
however.  Mac OS Classic was able to.

Andrew.

Re: [Mac-emacs-users] Emacs 21.1 AppleScript and Command Key for OS X

[Immanuel L. <imm...@en...>]

I added two lines to the function do_applescript in src/mac.c
>>>
static long
do_applescript (char *script, char **result)
{
  AEDesc script_desc, result_desc, error_desc;
  OSErr error;
  OSAError osaerror;
  long length;

  *result = 0;
->  if (!as_scripting_component){
->    initialize_applescript();
->  }
>>>
This works fine but it does not call the terminate applescript if
emacs terminates. I have also noticed that if you try to "do
applescript" that is not syntactically correct, emacs may hang or 
crash. I have not investigated the reason for this
Immanuel

***************************************************************************
A day for firm decisions!!!!!  Or is it?
Immanuel Litzroth
Software Development Engineer
Enfocus Software
Kleindokkaai 3-5
B-9000 Gent
Belgium
Voice: +32 9 269 23 90
Fax   : +32 9 269 16 91
Email: Imm...@en...
web  : www.enfocus.be
***************************************************************************

[Mac-emacs-users] Emacs 21.1 AppleScript and Command Key for OS X

[Rodney S. <rsp...@wi...>]

*** open/emacs/emacs-21.1/src/mac.c	Thu Dec 27 11:12:26 2001
--- ./mac.c	Thu Dec 27 10:37:09 2001
***************
*** 2508,2513 ****
--- 2508,2521 ----
  }
  
  
+ DEFUN ("initialize-applescript", Finitialize_applescript, Sinitialize_applescript, 0, 0, 0,
+     "Initialize AppleScript.\n")
+      ()
+ {
+   initialize_applescript ();
+ }
+ 
+ 
  DEFUN ("do-applescript", Fdo_applescript, Sdo_applescript, 1, 1, 0,
      "Compile and execute AppleScript SCRIPT and retrieve and return the\n\
  result.  If compilation and execution are successful, the resulting script\n\
***************
*** 2755,2758 ****
--- 2763,2767 ----
    defsubr (&Sdo_applescript);
    defsubr (&Smac_file_name_to_posix);
    defsubr (&Sposix_file_name_to_mac);
+   defsubr (&Sinitialize_applescript);
  }

[Mac-emacs-users] Installable Emacs 21 for OS X

[Piet v. O. <pi...@cs...>]

I have made an installer package for Andrew's emacs 21. I included the
3 patches that he published on this mailing list. I compiled the stuff
and fabricated a package, which is partly automated and partly
handmade (I don't know how to create packages from the command line).

I have tried to test it as much as possible on my machine, but I don't
have a clean machine to try it out. 

The application is installed by default in /Applications, but you can
change this. The system files are installed in /usr/local, which is
not changeble.

You can download the file from 
http://www.cs.uu.nl/~piet/Emacs21.mpkg.tar.gz (25MB)
Maybe someone can put it on an official site.
If you try it, please let me know how it works.
-- 
Piet van Oostrum <pi...@cs...>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.v...@hc...

[Mac-emacs-users] Font tool for OSX

[Shun I. <kar...@ma...>]

Hi,

I'm tring to make an additional font suitcase from a set of Japanese
bdf fonts to use on Emacs21.1 for Mac OS X. I found a font tool
(intlfonts-1.2-mac-src-1.0.smi.bin) in mac-emacs site, but it seems
not to support Mac OS X.

Does anyone have information about tools which convert bdf fonts to
Mac font suitcase on Mac OS X?


--
Shun

Re: [Mac-emacs-users] Installing emacs 21.1 on OSX

[<seg...@ma...>]

On Monday, December 17, 2001, at 09:10 , Gaurav Suri wrote:

> Hello,
>
> I am trying to install Emacs 21.1 on MacOSX (10.1.1). When I
> execute the ./configure command from the terminal (as per
> instructions in the readme.txt file at
> http://mac-emacs.sourceforge.net/ ) I get the following error
> message:
>
> checking whether the C compiler (cc  ) works... no
> configure: error: installation or configuration problem: C compiler 
> cannot create executables.
>
> I understand I need a C compiler on my computer.  Is it included
> the developer tools CD? Or do I need to get it from someplace else?
>
> Thanks
> -Gaurav

Yes, the compiler is included on the developer tools CD.

Hope this helps.

Dan

--
This email impairs your ability to operate machinery.
<mailto:seg...@ma...>

[Mac-emacs-users] Installing emacs 21.1 on OSX

[Gaurav S. <su...@os...>]

Hello,

I am trying to install Emacs 21.1 on MacOSX (10.1.1). When I execute the 
./configure command from the terminal (as per instructions in the 
readme.txt file at http://mac-emacs.sourceforge.net/ ) I get the 
following error message:

checking whether the C compiler (cc  ) works... no
configure: error: installation or configuration problem: C compiler 
cannot create executables.


I understand I need a C compiler on my computer.  Is it included the 
developer tools CD? Or do I need to get it from someplace else?

Thanks
-Gaurav

[Mac-emacs-users] Slow Redisplay Bug Fix

[Andrew C. <ak...@cs...>]

Hi Everyone,

This change improves the patch emacs-21.1-2-mac.patch.gz for building
Emacs 21.1 on Mac OS X.

Without it, the entire menu tree is rebuilt every time a frame is
redisplayed.  This is unnecessary since Emacs rebuilds the menu tree
when the menu bar is clicked anyway.

This (performance) bug does not cause anything to be displayed
incorrectly (afterall it is doing more than that is necessary).
However it causes input to be very sluggish when each key-press
requires a redisplay, e.g., when one is using a quail input method for
typing Chinese or Japanese.

Please apply the following patch to src/macmenu.c.

Andrew.
-----
--- emacs-21.1.30/src/macmenu.c	Sat Oct 27 10:28:58 2001
+++ emacs/src/macmenu.c	Fri Dec 14 14:33:12 2001
@@ -1318,6 +1318,11 @@
 
   XSETFRAME (Vmenu_updating_frame, f);
 
+  if (! menubar_widget)
+    deep_p = 1;
+  else if (pending_menu_activation && !deep_p)
+    deep_p = 1;
+
   wv = xmalloc_widget_value ();
   wv->name = "menubar";
   wv->value = 0;
@@ -1325,116 +1330,155 @@
   wv->button_type = BUTTON_TYPE_NONE;
   first_wv = wv;
 
-  {
-    /* Make a widget-value tree representing the entire menu trees.  */
-
-    struct buffer *prev = current_buffer;
-    Lisp_Object buffer;
-    int specpdl_count = specpdl_ptr - specpdl;
-    int previous_menu_items_used = f->menu_bar_items_used;
-    Lisp_Object *previous_items
-      = (Lisp_Object *) alloca (previous_menu_items_used
-                                * sizeof (Lisp_Object));
-
-    /* If we are making a new widget, its contents are empty,
-       do always reinitialize them.  */
-    if (! menubar_widget)
-      previous_menu_items_used = 0;
-
-    buffer = XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer;
-    specbind (Qinhibit_quit, Qt);
-    /* Don't let the debugger step into this code
-       because it is not reentrant.  */
-    specbind (Qdebug_on_next_call, Qnil);
-
-    record_unwind_protect (Fset_match_data, Fmatch_data (Qnil, Qnil));
-    if (NILP (Voverriding_local_map_menu_flag))
-      {
-	specbind (Qoverriding_terminal_local_map, Qnil);
-	specbind (Qoverriding_local_map, Qnil);
-      }
-
-    set_buffer_internal_1 (XBUFFER (buffer));
-
-    /* Run the Lucid hook.  */
-    call1 (Vrun_hooks, Qactivate_menubar_hook);
-    /* If it has changed current-menubar from previous value,
-       really recompute the menubar from the value.  */
-    if (! NILP (Vlucid_menu_bar_dirty_flag))
-      call0 (Qrecompute_lucid_menubar);
-    safe_run_hooks (Qmenu_bar_update_hook);
-    FRAME_MENU_BAR_ITEMS (f) = menu_bar_items (FRAME_MENU_BAR_ITEMS (f));
-
-    items = FRAME_MENU_BAR_ITEMS (f);
-
-    inhibit_garbage_collection ();
-
-    /* Save the frame's previous menu bar contents data.  */
-    bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
-	   previous_menu_items_used * sizeof (Lisp_Object));
-
-    /* Fill in the current menu bar contents.  */
-    menu_items = f->menu_bar_vector;
-    menu_items_allocated = XVECTOR (menu_items)->size;
-    init_menu_items ();
-    for (i = 0; i < XVECTOR (items)->size; i += 4)
-      {
-	Lisp_Object key, string, maps;
-
-	key = XVECTOR (items)->contents[i];
-	string = XVECTOR (items)->contents[i + 1];
-	maps = XVECTOR (items)->contents[i + 2];
-	if (NILP (string))
-	  break;
-
-	wv = single_submenu (key, string, maps);
-	if (prev_wv) 
-	  prev_wv->next = wv;
-	else
-	  first_wv->contents = wv;
-	/* Don't set wv->name here; GC during the loop might relocate it.  */
-	wv->enabled = 1;
-	wv->button_type = BUTTON_TYPE_NONE;
-	prev_wv = wv;
-      }
-
-    finish_menu_items ();
-
-    set_buffer_internal_1 (prev);
-    unbind_to (specpdl_count, Qnil);
-
-    /* If there has been no change in the Lisp-level contents
-       of the menu bar, skip redisplaying it.  Just exit.  */
-
-    for (i = 0; i < previous_menu_items_used; i++)
-    if (menu_items_used == i
-	|| (!EQ (previous_items[i], XVECTOR (menu_items)->contents[i])))
-      break;
-    if (i == menu_items_used && i == previous_menu_items_used && i != 0)
-      {
-	free_menubar_widget_value_tree (first_wv);
-	menu_items = Qnil;
-
-	return;
-      }
-
-    /* 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)
-      {
-	Lisp_Object string;
-	string = XVECTOR (items)->contents[i + 1];
-	if (NILP (string))
+  if (deep_p)
+    {
+      /* Make a widget-value tree representing the entire menu trees.  */
+
+      struct buffer *prev = current_buffer;
+      Lisp_Object buffer;
+      int specpdl_count = specpdl_ptr - specpdl;
+      int previous_menu_items_used = f->menu_bar_items_used;
+      Lisp_Object *previous_items
+	= (Lisp_Object *) alloca (previous_menu_items_used
+				  * sizeof (Lisp_Object));
+
+      /* If we are making a new widget, its contents are empty,
+	 do always reinitialize them.  */
+      if (! menubar_widget)
+	previous_menu_items_used = 0;
+      
+      buffer = XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer;
+      specbind (Qinhibit_quit, Qt);
+      /* Don't let the debugger step into this code
+	 because it is not reentrant.  */
+      specbind (Qdebug_on_next_call, Qnil);
+
+      record_unwind_protect (Fset_match_data, Fmatch_data (Qnil, Qnil));
+      if (NILP (Voverriding_local_map_menu_flag))
+	{
+	  specbind (Qoverriding_terminal_local_map, Qnil);
+	  specbind (Qoverriding_local_map, Qnil);
+	}
+
+      set_buffer_internal_1 (XBUFFER (buffer));
+
+      /* Run the Lucid hook.  */
+      call1 (Vrun_hooks, Qactivate_menubar_hook);
+      /* If it has changed current-menubar from previous value,
+	 really recompute the menubar from the value.  */
+      if (! NILP (Vlucid_menu_bar_dirty_flag))
+	call0 (Qrecompute_lucid_menubar);
+      safe_run_hooks (Qmenu_bar_update_hook);
+      FRAME_MENU_BAR_ITEMS (f) = menu_bar_items (FRAME_MENU_BAR_ITEMS (f));
+
+      items = FRAME_MENU_BAR_ITEMS (f);
+
+      inhibit_garbage_collection ();
+
+      /* Save the frame's previous menu bar contents data.  */
+      if (previous_menu_items_used)
+	bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
+	       previous_menu_items_used * sizeof (Lisp_Object));
+
+      /* Fill in the current menu bar contents.  */
+      menu_items = f->menu_bar_vector;
+      menu_items_allocated = VECTORP (menu_items) ? ASIZE (menu_items) : 0;
+      init_menu_items ();
+      for (i = 0; i < XVECTOR (items)->size; i += 4)
+	{
+	  Lisp_Object key, string, maps;
+
+	  key = XVECTOR (items)->contents[i];
+	  string = XVECTOR (items)->contents[i + 1];
+	  maps = XVECTOR (items)->contents[i + 2];
+	  if (NILP (string))
+	    break;
+
+	  wv = single_submenu (key, string, maps);
+	  if (prev_wv) 
+	    prev_wv->next = wv;
+	  else
+	    first_wv->contents = wv;
+	  /* Don't set wv->name here; GC during the loop might relocate it.  */
+	  wv->enabled = 1;
+	  wv->button_type = BUTTON_TYPE_NONE;
+	  prev_wv = wv;
+	}
+
+      finish_menu_items ();
+
+      set_buffer_internal_1 (prev);
+      unbind_to (specpdl_count, Qnil);
+
+      /* If there has been no change in the Lisp-level contents
+	 of the menu bar, skip redisplaying it.  Just exit.  */
+
+      for (i = 0; i < previous_menu_items_used; i++)
+	if (menu_items_used == i
+	    || (!EQ (previous_items[i], XVECTOR (menu_items)->contents[i])))
 	  break;
-	wv->name = (char *) XSTRING (string)->data;
-	wv = wv->next;
-      }
-
-    f->menu_bar_vector = menu_items;
-    f->menu_bar_items_used = menu_items_used;
-    menu_items = Qnil;
-  }
+      if (i == menu_items_used && i == previous_menu_items_used && i != 0)
+	{
+	  free_menubar_widget_value_tree (first_wv);
+	  menu_items = Qnil;
+	  
+	  return;
+	}
+
+      /* 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)
+	{
+	  Lisp_Object string;
+	  string = XVECTOR (items)->contents[i + 1];
+	  if (NILP (string))
+	    break;
+	  wv->name = (char *) XSTRING (string)->data;
+	  wv = wv->next;
+	}
+
+      f->menu_bar_vector = menu_items;
+      f->menu_bar_items_used = menu_items_used;
+      menu_items = Qnil;
+    }
+  else
+    {
+      /* Make a widget-value tree containing
+	 just the top level menu bar strings.  */
+
+      items = FRAME_MENU_BAR_ITEMS (f);
+      for (i = 0; i < XVECTOR (items)->size; i += 4)
+	{
+	  Lisp_Object string;
+
+	  string = XVECTOR (items)->contents[i + 1];
+	  if (NILP (string))
+	    break;
+
+	  wv = xmalloc_widget_value ();
+	  wv->name = (char *) XSTRING (string)->data;
+	  wv->value = 0;
+	  wv->enabled = 1;
+	  wv->button_type = BUTTON_TYPE_NONE;
+	  /* This prevents lwlib from assuming this
+	     menu item is really supposed to be empty.  */
+	  /* The EMACS_INT cast avoids a warning.
+	     This value just has to be different from small integers.  */
+	  wv->call_data = (void *) (EMACS_INT) (-1);
+
+	  if (prev_wv) 
+	    prev_wv->next = wv;
+	  else
+	    first_wv->contents = wv;
+	  prev_wv = wv;
+	}
+
+      /* Forget what we thought we knew about what is in the
+	 detailed contents of the menu bar menus.
+	 Changing the top level always destroys the contents.  */
+      f->menu_bar_items_used = 0;
+    }
 
   /* Create or update the menu bar widget.  */
 

[Mac-emacs-users] command-x (cut), command-c (copy) and command-v (paste)

[Rodney S. <rsp...@mc...>]

mac-emacs-users

I wanted to get command-x (cut), command-c (copy) and command-v (paste) to 
work in 21.1 on OS X.  Of course, Andrew did most of the work.  Here's his 
instructions (I'm attaching macterm.c  since you won't be able to copy and 
paste the code into emacs until after you re-compile):

add the following IF statement just before the line

   bufp->modifiers = the_modifiers;

in macterm.c in function XTread_socket.

   if (NILP (Vmac_command_key_is_meta) && (er.modifiers & cmdKey))
     the_modifiers |= alt_modifier;

Now, do a "make" and a "make install".  And, finally, you need to define 
your keys appropriately in ~/.emacs

(setq mac-command-key-is-meta nil)       ; meta key is option
(global-set-key [?\A-v] 'yank)           ; paste is command-v
(global-set-key [?\A-x] 'kill-region)    ; cut   is command-x
(global-set-key [?\A-c] 'kill-ring-save) ; copy  is command-c

Rodney
<File attached: macterm.c.gz>

Re: [Mac-emacs-users] Emacs.app, german umlaute,solution

[Andrew C. <ak...@cs...>]

Hi Patrick,

Great to hear that it now works!

I've taught for a long time.  I've learned to be very very patient
:-).

Andrew.

[Mac-emacs-users] Emacs.app, german umlaute,solution

[Patrick G. <gun...@ir...>]

Hallo you all!

> > >   M-x set-frame-font RET fontset-mac RET
> > >   M-x set-frame-font RET
> > > -apple-monaco-medium-r-normal--12-120-75-75-m-120-mac-roman
> >
> > no different result.

> Could you please try the first command by itself?  I.e., just do
>   M-x set-frame-font RET fontset-mac RET

Oh no! you are probably (and you are right with it) going to hit me! That 
works! I was absolutely positive that I have tried this! Oh no, so stupid 
Patrick. 

So my solution is a .emacs file with

(set-frame-font "fontset-mac")
(set-keyboard-coding-system 'mac-roman)

wheee!


Thank you soooo much for a) making the patch itself b) being so patient


Viele Grüße,

  Patrick Gundlach

Re: [Mac-emacs-users] (no subject)

[Andrew C. <ak...@cs...>]

> I reported yesterday that your process patch has killed gnuclient. I
> recompiled using unix domain sockets and now it is working again. I
> wonder if it is a good idea to add binaries for this to your site
> and/or add some utility elisp scripts (I also have ps-print working
> nicely) somewhat like the GNU Emacs on win32 site.

Hi Immanuel,

Then I will not investigate any further into problems with
subprocesses for the time being.

I would like to avoid the work of distributing binaries at this time.
If anyone like to do so, they're welcome to.

I have ownership of the mac/emacs directory at ftp.gnu.org so at the
proper time, I can distribute binaries there.  But obviously that's
only for releases.

If patches are small, please post them.  For big files, please write
and let's discuss where best to distribute them.

I'm thinking about gradually moving development support from
SourceForge to GNU servers and starting to use the gnu.emacs.*
newsgroups.  This seems more appropriate to me now that
savannah.gnu.org is available and the Mac ports are part of the
standard Emacs distribution (I'll be adding the Mac OS X code to the
CVS repository).  If it becomes necessary, we can create a project for
the Mac OS X build of Emacs on Savannah.

I'll of course make the proper announcments on these lists when I'm
ready to do this.

Andrew.

Re: [Mac-emacs-users] Emacs.app, german umlaute

[Andrew C. <ak...@cs...>]

> >   M-x set-frame-font RET fontset-mac RET
> >   M-x set-frame-font RET 
> > -apple-monaco-medium-r-normal--12-120-75-75-m-120-mac-roman
> 
> no different result.

Hi Patrick,

Could you please try the first command by itself?  I.e., just do

  M-x set-frame-font RET fontset-mac RET

Please also check that you didn't do anything in the .emacs to prevent
this from working.  Since we can't specify an option when running in
GUI mode, one way to do this now is to temporarily rename the .emacs
file.

> But, I am getting closer!
> with 
> (standard-display-european 1)
> and 
> (standard-display-8bit 0 255) 
> I can display the ö (o with two dots) an other 'special characters'.

Both of these commands turn the buffer into unibyte coding.  The
current recommended way is to use multibyte buffers.  So perhaps it's
better to try to get characters to display correctly using fontsets.

> But now I have an input problem...  I press the key with the ö (o
> with two dots) and emacs beeps (no output in the buffer). Pressing
> C-h l to see the recent key presses, it displays the ö correctly. So
> it seems that the key is recognized correctly.
> 
> Setting the default coding system (C-x RET k) to latin-1 or
> mac-roman did not help:
> 
> with mac-roman, it dispays a ^ (hat) instead of the ö. With latin-1
> there is no output. In both cases the C-h l reports the correct
> keys.
> 
> Copy and paste from the key-caps application works fine.
> 
> Setting mac-keybord-text-encoding to kTextEncodingISOLatin1 did not
> do anything that I noticed.
> 
> With coding system for keybord input set to mac-roman, the ö for
> example is bound to encoded-kbd-self-insert-ccl.
> 
> Any hints for the correct input method?
>
> By the way, I use an iBook with the keybord set to the german
> 'language' on MacOS X

All these "problems" are due to the use of the unibyte buffer.  Again
I recommend first getting characters to display correctly using
fontsets.  If you cannot type them to see if they work, display the
German tutorial by saying

  C-u M-x help-with-tutorial RET German RET

or looking at the HELLO file (C-h h).  Once this works, there are a
number of ways you can edit a file with German characters.

1.  The file is in Mac Roman encoding.  You set the file/buffer
    coding system to mac-roman (for example by typing C-x RET c
    mac-roman before finding the file) and the keyboard coding system
    to mac-roman (by typing C-x RET k mac-roman).  You also set your
    Keyboard control panel to German.

2.  The file is in ISO 8859-1 encoding.  This is the default coding
    for a buffer (unless you change prefer-coding-system) so you
    shouldn't need to do anything special to find/create it.

    2.1.  You can edit it using one of the Emacs input methods, in
          which case you set the language environment to German and
          select an input method such as german-postfix.  With this
          setting Emacs assumes an plain ASCII keyboard so the
          Keyboard control panel should probably be set to US.

    2.2.  To typing German characters as one would in other
          applications with a German Keyboard control panel setting
          and insert them in ISO 8859-1 encoding, set
          mac-keybord-text-encoding to kTextEncodingISOLatin1.

Could you please try these methods?  Could other users share their
experience?

Andrew.

Re: [Mac-emacs-users] (no subject)

[Immanuel L. <imm...@en...>]

>>>>> "Andrew" == Andrew Choi <ak...@cs...> writes:
Andrew,
I reported yesterday that your process patch has killed gnuclient. I
recompiled using unix domain sockets and now it is working again. I
wonder if it is a good idea to add binaries for this to your site
and/or add some utility elisp scripts (I also have ps-print working
nicely) somewhat like the GNU Emacs on win32 site.
Immanuel
***************************************************************************
A day for firm decisions!!!!!  Or is it?
Immanuel Litzroth
Software Development Engineer
Enfocus Software
Kleindokkaai 3-5
B-9000 Gent
Belgium
Voice: +32 9 269 23 90
Fax   : +32 9 269 16 91
Email: Imm...@en...
web  : www.enfocus.be
***************************************************************************

Re: [Mac-emacs-users] Emacs.app, german umlaute

[Patrick G. <gun...@ir...>]

Hello,

> Actually it should display them by default.  Could you use M-x
> describe-font 

m-x describe-font gives me a prompt in the modeline:
"Fontname (default, current choice for ASCII chars): "
perhaps this is already strange (because is says ASCII char)?

after pressing return, it gives me
name (opened by):  (the font you have mentioned below)
        full name:       (the same font)
...
relative-compose : 0

> and M-x describe-fontset to check which font or fontset
"Current frame is using font, not fontset"


>   M-x set-frame-font RET fontset-mac RET
>   M-x set-frame-font RET 
> -apple-monaco-medium-r-normal--12-120-75-75-m-120-mac-roman

no different result.
But, I am getting closer!
with 
(standard-display-european 1)
and 
(standard-display-8bit 0 255) 
I can display the ö (o with two dots) an other 'special characters'. But 
now I have an input problem...
I press the key with the ö (o with two dots) and emacs beeps (no output in 
the buffer). Pressing C-h l to see the recent key presses, it displays the 
ö correctly. So it seems that the key is recognized correctly.

Setting the default coding system (C-x RET k) to latin-1 or mac-roman did 
not help:

with mac-roman, it dispays a ^ (hat) instead of the ö. With latin-1 there 
is no output. In both cases the C-h l reports the correct keys.

Copy and paste from the key-caps application works fine.

Setting mac-keybord-text-encoding to kTextEncodingISOLatin1 did not do 
anything that I noticed.

With coding system for keybord input set to mac-roman, the ö for example is 
bound to encoded-kbd-self-insert-ccl.

Any hints for the correct input method?

By the way, I use an iBook with the keybord set to the german 'language' on 
MacOS X


Viele Grüße,

  Patrick Gundlach

Re: [Mac-emacs-users] Am I missing something here?

[Andrew C. <ak...@cs...>]

> However, attempting to launch the Emacs.app from the Finder, through
> doubble-clicking on the icon, results in a stalled launch of emacs,
> which does nothing and can only be dealt with through explicitly
> forcing it to quit.

Please check that you did a `make install'?  You should have a
/usr/local/share/emacs/ directory.

> I can launch emacs-21 through emacs -nw from the command line [...]
> However, this method of running emacs does not launch new
> frames. Moreover, the function keys f1 through f4 are seen as kp-f1
> through kp-f4, and the functions f5 and above are not seen at
> all. Since f5 through f9 are the emacs recomended function keys
> reserved for local use, this is a most unfortunate situation.

When it is run in terminal mode, Emacs can only get what Terminal.app
passes to it.  Perhaps those keys are all the latter recognizes.  The
GUI mode supports a few more function keys.

Andrew.

[Mac-emacs-users] Am I missing something here?

[Tom W. <tom...@in...>]

Hello there.

I have just used the emacs-21.1-2-mac.patch to compile the source 
distribution of emacs-21.1 for mac-os-x-1. I have read throughly the 
readme, and followed the instructions carefully; my machine has 640 MB, 
and has XDarwin installed.

However, attempting to launch the Emacs.app from the Finder, through 
doubble-clicking on the icon, results in a stalled launch of emacs, 
which does nothing and can only be dealt with through explicitly forcing 
it to quit.

I can launch emacs-21 through emacs -nw from the command line, and with 
the suggested lines to ~/.termcap I see a functioning editor with 
font-lock colours displayed, ispell , tex modes, and shell modes 
working. However, this method of  running emacs does not launch new 
frames. Moreover, the function keys f1 through f4 are seen as kp-f1 
through kp-f4, and the functions f5 and above are not seen at all. Since 
f5 through f9 are the emacs recomended function keys reserved for local 
use, this is a most unfortunate situation.

So, the question is simply: Am I missing something here?

For example, does this patch actually work with os-x-1; is there some 
keyboard parameters I need to set correctly; and so on.

On the whole, good work andrew choi and others. Emacs working in an Aqua 
interface is a much nicer result than maintaining an old technology X11 
interface. The fonts are much more readable!

Thanks in advance

Tom Winchester

[Mac-emacs-users] Mouse Face Failing to Clear Bug Fix

[Andrew C. <ak...@cs...>]

Hi Everyone,

With the patch emacs-21.1-2-mac.patch.gz for building Emacs 21.1 on
Mac OS X, you should be experiencing the following problem.  When the
mouse is moved off any text with a mouse face (highlight property),
the highlight is not cleared automatically.  This problem can be seen
when you use M-x customize or M-x list-faces-display.

Please try the following patch for the file src/macterm.c.

Andrew.
-----

--- emacs-21.1.30/src/macterm.c	Tue Oct 30 21:16:48 2001
+++ emacs/src/macterm.c	Sat Dec  8 15:47:25 2001
@@ -7676,8 +7676,11 @@
 clear_mouse_face (dpyinfo)
      struct mac_display_info *dpyinfo;
 {
+#if 0 /* This prevents redrawing tool bar items when changing from one
+         to another while a tooltip is open, so don't do it.  */
   if (tip_frame)
     return;
+#endif
   
   if (! NILP (dpyinfo->mouse_face_window))
     show_mouse_face (dpyinfo, DRAW_NORMAL_TEXT);