Patch: AREF -vs- ASET

Patch: AREF -vs- ASET

[Tom Tromey]

I noticed that Emacs has both AREF and ASET macros, but they are not
consistently used.  Sometimes ASET is used to set an array element,
but sometimes AREF is used instead.

This patch mostly changes Emacs to use ASET rather than AREF.  I chose
this, rather than removing ASET, because using a settor macro like
ASET allows the future possibility of a write barrier, needed for some
kinds of GC.

Unfortunately it is not possible to change AREF to use
LISP_MAKE_RVALUE, because there is code like:

  XSETBUFFER (AREF (vector, i), current_buffer);

... but, more importantly, macros like LFACE_HEIGHT, which expand to
AREF and for which there is no "SET" equivalent.

These problems are fixable, of course.  But is this the direction the
Emacs maintainers want to go?

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* xselect.c (x_handle_dnd_message): Use ASET.
	* xmenu.c (digest_single_submenu): Use ASET.
	(xmenu_show): Likewise.
	* xfaces.c (Finternal_make_lisp_face): Use ASET.
	* xdisp.c (with_echo_area_buffer_unwind_data): Use ASET.
	(format_mode_line_unwind_data): Likewise.
	(unwind_format_mode_line): Likewise.
	(display_menu_bar): Likewise.
	* macmenu.c (digest_single_submenu): Use ASET.
	(mac_menu_show): Likewise.
	* keyboard.c (add_command_key): Use ASET.
	(parse_menu_item): Likewise.
	* fontset.c (make_fontset): Use ASET.
	(free_face_fontset): Likewise.
	(Ffontset_info): Likewise.
	(syms_of_fontset): Likewise.
	* fns.c (concat): Use ASET.
	(hash_clear): Likewise.
	* eval.c (Ffetch_bytecode): Use ASET.
	* ccl.c (resolve_symbol_ccl_program): Use ASET.
	(ccl_get_compiled_code): Likewise.
	(Fregister_code_conversion_map): Likewise.
	* buffer.c (add_overlay_mod_hooklist): Use ASET.

Index: buffer.c
===================================================================
RCS file: /sources/emacs/emacs/src/buffer.c,v
retrieving revision 1.521
diff -u -r1.521 buffer.c
--- buffer.c 21 Jan 2007 04:18:17 -0000 1.521
+++ buffer.c 2 Feb 2007 04:44:47 -0000
@@ -4185,8 +4185,12 @@
 	     XVECTOR (last_overlay_modification_hooks)->contents,
 	     sizeof (Lisp_Object) * oldsize);
     }
-  AREF (last_overlay_modification_hooks, last_overlay_modification_hooks_used++) = functionlist;
-  AREF (last_overlay_modification_hooks, last_overlay_modification_hooks_used++) = overlay;
+  ASET (last_overlay_modification_hooks,
+	last_overlay_modification_hooks_used++,
+	functionlist);
+  ASET (last_overlay_modification_hooks,
+	last_overlay_modification_hooks_used++,
+	overlay);
 }
 \f
 /* Run the modification-hooks of overlays that include
Index: ccl.c
===================================================================
RCS file: /sources/emacs/emacs/src/ccl.c,v
retrieving revision 1.96
diff -u -r1.96 ccl.c
--- ccl.c 21 Jan 2007 04:18:16 -0000 1.96
+++ ccl.c 2 Feb 2007 04:44:49 -0000
@@ -1988,7 +1988,7 @@
 
 	  val = Fget (XCAR (contents), XCDR (contents));
 	  if (NATNUMP (val))
-	    AREF (result, i) = val;
+	    ASET (result, i, val);
 	  else
 	    unresolved = 1;
 	  continue;
@@ -2003,17 +2003,17 @@
 
 	  val = Fget (contents, Qtranslation_table_id);
 	  if (NATNUMP (val))
-	    AREF (result, i) = val;
+	    ASET (result, i, val);
 	  else
 	    {
 	      val = Fget (contents, Qcode_conversion_map_id);
 	      if (NATNUMP (val))
-		AREF (result, i) = val;
+		ASET (result, i, val);
 	      else
 		{
 		  val = Fget (contents, Qccl_program_idx);
 		  if (NATNUMP (val))
-		    AREF (result, i) = val;
+		    ASET (result, i, val);
 		  else
 		    unresolved = 1;
 		}
@@ -2063,8 +2063,8 @@
       val = resolve_symbol_ccl_program (AREF (slot, 1));
       if (! VECTORP (val))
 	return Qnil;
-      AREF (slot, 1) = val;
-      AREF (slot, 2) = Qt;
+      ASET (slot, 1, val);
+      ASET (slot, 2, Qt);
     }
   return AREF (slot, 1);
 }
@@ -2421,15 +2421,14 @@
       int j;
 
       for (j = 0; j < len; j++)
-	AREF (new_vector, j)
-	  = AREF (Vcode_conversion_map_vector, j);
+	ASET (new_vector, j, AREF (Vcode_conversion_map_vector, j));
       Vcode_conversion_map_vector = new_vector;
     }
 
   index = make_number (i);
   Fput (symbol, Qcode_conversion_map, map);
   Fput (symbol, Qcode_conversion_map_id, index);
-  AREF (Vcode_conversion_map_vector, i) = Fcons (symbol, map);
+  ASET (Vcode_conversion_map_vector, i, Fcons (symbol, map));
   return index;
 }
 
Index: eval.c
===================================================================
RCS file: /sources/emacs/emacs/src/eval.c,v
retrieving revision 1.276
diff -u -r1.276 eval.c
--- eval.c 21 Jan 2007 04:18:16 -0000 1.276
+++ eval.c 2 Feb 2007 04:44:54 -0000
@@ -1238,7 +1238,7 @@
    the handler stack as we go, so that the proper handlers are in
    effect for each unwind-protect clause we run.  At the end, restore
    some static info saved in CATCH, and longjmp to the location
-   specified in the
+   specified there.
 
    This is used for correct unwinding in Fthrow and Fsignal.  */
 
@@ -3208,8 +3208,8 @@
 	  else
 	    error ("Invalid byte code");
 	}
-      AREF (object, COMPILED_BYTECODE) = XCAR (tem);
-      AREF (object, COMPILED_CONSTANTS) = XCDR (tem);
+      ASET (object, COMPILED_BYTECODE, XCAR (tem));
+      ASET (object, COMPILED_CONSTANTS, XCDR (tem));
     }
   return object;
 }
Index: fns.c
===================================================================
RCS file: /sources/emacs/emacs/src/fns.c,v
retrieving revision 1.424
diff -u -r1.424 fns.c
--- fns.c 21 Jan 2007 04:18:16 -0000 1.424
+++ fns.c 2 Feb 2007 04:44:59 -0000
@@ -780,7 +780,7 @@
 		tail = XCDR (tail);
 	      }
 	    else if (VECTORP (val))
-	      AREF (val, toindex++) = elt;
+	      ASET (val, toindex++, elt);
 	    else
 	      {
 		CHECK_NUMBER (elt);
@@ -4863,7 +4863,7 @@
 	}
 
       for (i = 0; i < ASIZE (h->index); ++i)
-	AREF (h->index, i) = Qnil;
+	ASET (h->index, i, Qnil);
 
       h->next_free = make_number (0);
       h->count = make_number (0);
Index: fontset.c
===================================================================
RCS file: /sources/emacs/emacs/src/fontset.c,v
retrieving revision 1.103
diff -u -r1.103 fontset.c
--- fontset.c 21 Jan 2007 20:49:43 -0000 1.103
+++ fontset.c 2 Feb 2007 04:45:00 -0000
@@ -396,7 +396,7 @@
 
       tem = Fmake_vector (make_number (size + 8), Qnil);
       for (i = 0; i < size; i++)
-	AREF (tem, i) = AREF (Vfontset_table, i);
+	ASET (tem, i, AREF (Vfontset_table, i));
       Vfontset_table = tem;
     }
 
@@ -407,7 +407,7 @@
   FONTSET_FRAME (fontset) = frame;
   FONTSET_BASE (fontset) = base;
 
-  AREF (Vfontset_table, id) = fontset;
+  ASET (Vfontset_table, id, fontset);
   next_fontset_id = id + 1;
   return fontset;
 }
@@ -493,7 +493,7 @@
 {
   if (fontset_id_valid_p (face->fontset))
     {
-      AREF (Vfontset_table, face->fontset) = Qnil;
+      ASET (Vfontset_table, face->fontset, Qnil);
       if (face->fontset < next_fontset_id)
 	next_fontset_id = face->fontset;
     }
@@ -1528,8 +1528,8 @@
       fontp = (*query_font_func) (f, SDATA (elt));
     }
   val = Fmake_vector (make_number (3), val);
-  AREF (val, 0) = fontp ? make_number (fontp->size) : make_number (0);
-  AREF (val, 1) = fontp ? make_number (fontp->height) : make_number (0);
+  ASET (val, 0, fontp ? make_number (fontp->size) : make_number (0));
+  ASET (val, 1, fontp ? make_number (fontp->height) : make_number (0));
   return val;
 }
 
@@ -1653,7 +1653,7 @@
   FONTSET_ID (Vdefault_fontset) = make_number (0);
   FONTSET_NAME (Vdefault_fontset)
     = build_string ("-*-*-*-*-*-*-*-*-*-*-*-*-fontset-default");
-  AREF (Vfontset_table, 0) = Vdefault_fontset;
+  ASET (Vfontset_table, 0, Vdefault_fontset);
   next_fontset_id = 1;
 
   Voverriding_fontspec_alist = Qnil;
Index: keyboard.c
===================================================================
RCS file: /sources/emacs/emacs/src/keyboard.c,v
retrieving revision 1.892
diff -u -r1.892 keyboard.c
--- keyboard.c 27 Jan 2007 18:18:31 -0000 1.892
+++ keyboard.c 2 Feb 2007 04:45:20 -0000
@@ -966,7 +966,7 @@
 				       2 * ASIZE (this_command_keys),
 				       Qnil);
 
-  AREF (this_command_keys, this_command_key_count) = key;
+  ASET (this_command_keys, this_command_key_count, key);
   ++this_command_key_count;
 }
 
@@ -7468,11 +7468,11 @@
 
   /* Initialize optional entries.  */
   for (i = ITEM_PROPERTY_DEF; i < ITEM_PROPERTY_ENABLE; i++)
-    AREF (item_properties, i) = Qnil;
-  AREF (item_properties, ITEM_PROPERTY_ENABLE) = Qt;
+    ASET (item_properties, i, Qnil);
+  ASET (item_properties, ITEM_PROPERTY_ENABLE, Qt);
 
   /* Save the item here to protect it from GC.  */
-  AREF (item_properties, ITEM_PROPERTY_ITEM) = item;
+  ASET (item_properties, ITEM_PROPERTY_ITEM, item);
 
   item_string = XCAR (item);
 
@@ -7481,12 +7481,12 @@
   if (STRINGP (item_string))
     {
       /* Old format menu item.  */
-      AREF (item_properties, ITEM_PROPERTY_NAME) = item_string;
+      ASET (item_properties, ITEM_PROPERTY_NAME, item_string);
 
       /* Maybe help string.  */
       if (CONSP (item) && STRINGP (XCAR (item)))
 	{
-	  AREF (item_properties, ITEM_PROPERTY_HELP) = XCAR (item);
+	  ASET (item_properties, ITEM_PROPERTY_HELP, XCAR (item));
 	  start = item;
 	  item = XCDR (item);
 	}
@@ -7501,27 +7501,27 @@
 	}
 
       /* This is the real definition--the function to run.  */
-      AREF (item_properties, ITEM_PROPERTY_DEF) = item;
+      ASET (item_properties, ITEM_PROPERTY_DEF, item);
 
       /* Get enable property, if any.  */
       if (SYMBOLP (item))
 	{
 	  tem = Fget (item, Qmenu_enable);
 	  if (!NILP (Venable_disabled_menus_and_buttons))
-	    AREF (item_properties, ITEM_PROPERTY_ENABLE) = Qt;
+	    ASET (item_properties, ITEM_PROPERTY_ENABLE, Qt);
 	  else if (!NILP (tem))
-	    AREF (item_properties, ITEM_PROPERTY_ENABLE) = tem;
+	    ASET (item_properties, ITEM_PROPERTY_ENABLE, tem);
 	}
     }
   else if (EQ (item_string, Qmenu_item) && CONSP (item))
     {
       /* New format menu item.  */
-      AREF (item_properties, ITEM_PROPERTY_NAME) = XCAR (item);
+      ASET (item_properties, ITEM_PROPERTY_NAME, XCAR (item));
       start = XCDR (item);
       if (CONSP (start))
 	{
 	  /* We have a real binding.  */
-	  AREF (item_properties, ITEM_PROPERTY_DEF) = XCAR (start);
+	  ASET (item_properties, ITEM_PROPERTY_DEF, XCAR (start));
 
 	  item = XCDR (start);
 	  /* Is there a cache list with key equivalences. */
@@ -7540,9 +7540,9 @@
 	      if (EQ (tem, QCenable))
 		{
 		  if (!NILP (Venable_disabled_menus_and_buttons))
-		    AREF (item_properties, ITEM_PROPERTY_ENABLE) = Qt;
+		    ASET (item_properties, ITEM_PROPERTY_ENABLE, Qt);
 		  else
-		    AREF (item_properties, ITEM_PROPERTY_ENABLE) = XCAR (item);
+		    ASET (item_properties, ITEM_PROPERTY_ENABLE, XCAR (item));
 		}
 	      else if (EQ (tem, QCvisible) && !notreal)
 		{
@@ -7553,7 +7553,7 @@
 		    return 0;
 	 	}
 	      else if (EQ (tem, QChelp))
-		AREF (item_properties, ITEM_PROPERTY_HELP) = XCAR (item);
+		ASET (item_properties, ITEM_PROPERTY_HELP, XCAR (item));
 	      else if (EQ (tem, QCfilter))
 		filter = item;
 	      else if (EQ (tem, QCkey_sequence))
@@ -7568,7 +7568,7 @@
 		{
 		  tem = XCAR (item);
 		  if (CONSP (tem) || (STRINGP (tem) && NILP (cachelist)))
-		    AREF (item_properties, ITEM_PROPERTY_KEYEQ) = tem;
+		    ASET (item_properties, ITEM_PROPERTY_KEYEQ, tem);
 		}
 	      else if (EQ (tem, QCbutton) && CONSP (XCAR (item)))
 		{
@@ -7577,10 +7577,10 @@
 		  type = XCAR (tem);
 		  if (EQ (type, QCtoggle) || EQ (type, QCradio))
 		    {
-		      AREF (item_properties, ITEM_PROPERTY_SELECTED)
-			= XCDR (tem);
-		      AREF (item_properties, ITEM_PROPERTY_TYPE)
-			= type;
+		      ASET (item_properties, ITEM_PROPERTY_SELECTED,
+			    XCDR (tem));
+		      ASET (item_properties, ITEM_PROPERTY_TYPE,
+			    type);
 		    }
 		}
 	      item = XCDR (item);
@@ -7600,7 +7600,7 @@
       item_string = menu_item_eval_property (item_string);
       if (!STRINGP (item_string))
 	return 0;
-      AREF (item_properties, ITEM_PROPERTY_NAME) = item_string;
+      ASET (item_properties, ITEM_PROPERTY_NAME, item_string);
     }
 
   /* If got a filter apply it on definition.  */
@@ -7610,7 +7610,7 @@
       def = menu_item_eval_property (list2 (XCAR (filter),
 					    list2 (Qquote, def)));
 
-      AREF (item_properties, ITEM_PROPERTY_DEF) = def;
+      ASET (item_properties, ITEM_PROPERTY_DEF, def);
     }
 
   /* Enable or disable selection of item.  */
@@ -7623,7 +7623,7 @@
 	tem = menu_item_eval_property (tem);
       if (inmenubar && NILP (tem))
 	return 0;		/* Ignore disabled items in menu bar.  */
-      AREF (item_properties, ITEM_PROPERTY_ENABLE) = tem;
+      ASET (item_properties, ITEM_PROPERTY_ENABLE, tem);
     }
 
   /* If we got no definition, this item is just unselectable text which
@@ -7637,8 +7637,8 @@
   /* For a subkeymap, just record its details and exit.  */
   if (CONSP (tem))
     {
-      AREF (item_properties, ITEM_PROPERTY_MAP) = tem;
-      AREF (item_properties, ITEM_PROPERTY_DEF) = tem;
+      ASET (item_properties, ITEM_PROPERTY_MAP, tem);
+      ASET (item_properties, ITEM_PROPERTY_DEF, tem);
       return 1;
     }
 
@@ -7761,7 +7761,7 @@
     return 1;
 
   /* If we have an equivalent key binding, use that.  */
-  AREF (item_properties, ITEM_PROPERTY_KEYEQ) = tem;
+  ASET (item_properties, ITEM_PROPERTY_KEYEQ, tem);
 
   /* Include this when menu help is implemented.
   tem = XVECTOR (item_properties)->contents[ITEM_PROPERTY_HELP];
@@ -7777,8 +7777,8 @@
   /* Handle radio buttons or toggle boxes.  */
   tem = AREF (item_properties, ITEM_PROPERTY_SELECTED);
   if (!NILP (tem))
-    AREF (item_properties, ITEM_PROPERTY_SELECTED)
-      = menu_item_eval_property (tem);
+    ASET (item_properties, ITEM_PROPERTY_SELECTED,
+	  menu_item_eval_property (tem));
 
   return 1;
 }
Index: macmenu.c
===================================================================
RCS file: /sources/emacs/emacs/src/macmenu.c,v
retrieving revision 1.54
diff -u -r1.54 macmenu.c
--- macmenu.c 21 Jan 2007 04:18:15 -0000 1.54
+++ macmenu.c 2 Feb 2007 04:45:29 -0000
@@ -1417,7 +1417,7 @@
 	  if (STRINGP (pane_name) && STRING_MULTIBYTE (pane_name))
 	    {
 	      pane_name = ENCODE_MENU_STRING (pane_name);
-	      AREF (menu_items, i + MENU_ITEMS_PANE_NAME) = pane_name;
+	      ASET (menu_items, i + MENU_ITEMS_PANE_NAME, pane_name);
 	    }
 #endif
 	  pane_string = (NILP (pane_name)
@@ -1473,13 +1473,13 @@
           if (STRING_MULTIBYTE (item_name))
 	    {
 	      item_name = ENCODE_MENU_STRING (item_name);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_NAME) = item_name;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_NAME, item_name);
 	    }
 
           if (STRINGP (descrip) && STRING_MULTIBYTE (descrip))
 	    {
 	      descrip = ENCODE_MENU_STRING (descrip);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY) = descrip;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY, descrip);
 	    }
 #endif /* not HAVE_MULTILINGUAL_MENU */
 
@@ -2085,7 +2085,7 @@
 	  if (STRINGP (pane_name) && STRING_MULTIBYTE (pane_name))
 	    {
 	      pane_name = ENCODE_MENU_STRING (pane_name);
-	      AREF (menu_items, i + MENU_ITEMS_PANE_NAME) = pane_name;
+	      ASET (menu_items, i + MENU_ITEMS_PANE_NAME, pane_name);
 	    }
 #endif
 	  pane_string = (NILP (pane_name)
@@ -2139,13 +2139,13 @@
           if (STRINGP (item_name) && STRING_MULTIBYTE (item_name))
 	    {
 	      item_name = ENCODE_MENU_STRING (item_name);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_NAME) = item_name;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_NAME, item_name);
 	    }
 
           if (STRINGP (descrip) && STRING_MULTIBYTE (descrip))
 	    {
 	      descrip = ENCODE_MENU_STRING (descrip);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY) = descrip;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY, descrip);
 	    }
 #endif /* not HAVE_MULTILINGUAL_MENU */
 
Index: xdisp.c
===================================================================
RCS file: /sources/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1139
diff -u -r1.1139 xdisp.c
--- xdisp.c 21 Jan 2007 23:29:20 -0000 1.1139
+++ xdisp.c 2 Feb 2007 04:46:00 -0000
@@ -7967,21 +7967,21 @@
     vector = Fmake_vector (make_number (7), Qnil);
 
   XSETBUFFER (AREF (vector, i), current_buffer); ++i;
-  AREF (vector, i) = Vdeactivate_mark, ++i;
-  AREF (vector, i) = make_number (windows_or_buffers_changed), ++i;
+  ASET (vector, i, Vdeactivate_mark); ++i;
+  ASET (vector, i, make_number (windows_or_buffers_changed)); ++i;
 
   if (w)
     {
       XSETWINDOW (AREF (vector, i), w); ++i;
-      AREF (vector, i) = w->buffer; ++i;
-      AREF (vector, i) = make_number (XMARKER (w->pointm)->charpos); ++i;
-      AREF (vector, i) = make_number (XMARKER (w->pointm)->bytepos); ++i;
+      ASET (vector, i, w->buffer); ++i;
+      ASET (vector, i, make_number (XMARKER (w->pointm)->charpos)); ++i;
+      ASET (vector, i, make_number (XMARKER (w->pointm)->bytepos)); ++i;
     }
   else
     {
       int end = i + 4;
       for (; i < end; ++i)
-	AREF (vector, i) = Qnil;
+	ASET (vector, i, Qnil);
     }
 
   xassert (i == ASIZE (vector));
@@ -8844,17 +8844,17 @@
   if (NILP (vector))
     vector = Fmake_vector (make_number (7), Qnil);
 
-  AREF (vector, 0) = make_number (mode_line_target);
-  AREF (vector, 1) = make_number (MODE_LINE_NOPROP_LEN (0));
-  AREF (vector, 2) = mode_line_string_list;
-  AREF (vector, 3) = (save_proptrans ? mode_line_proptrans_alist : Qt);
-  AREF (vector, 4) = mode_line_string_face;
-  AREF (vector, 5) = mode_line_string_face_prop;
+  ASET (vector, 0, make_number (mode_line_target));
+  ASET (vector, 1, make_number (MODE_LINE_NOPROP_LEN (0)));
+  ASET (vector, 2, mode_line_string_list);
+  ASET (vector, 3, (save_proptrans ? mode_line_proptrans_alist : Qt));
+  ASET (vector, 4, mode_line_string_face);
+  ASET (vector, 5, mode_line_string_face_prop);
 
   if (obuf)
     XSETBUFFER (AREF (vector, 6), obuf);
   else
-    AREF (vector, 6) = Qnil;
+    ASET (vector, 6, Qnil);
 
   return vector;
 }
@@ -8874,7 +8874,7 @@
   if (!NILP (AREF (vector, 6)))
     {
       set_buffer_internal_1 (XBUFFER (AREF (vector, 6)));
-      AREF (vector, 6) = Qnil;
+      ASET (vector, 6, Qnil);
     }
 
   Vmode_line_unwind_vector = vector;
@@ -16475,7 +16475,7 @@
 	break;
 
       /* Remember where item was displayed.  */
-      AREF (items, i + 3) = make_number (it.hpos);
+      ASET (items, i + 3, make_number (it.hpos));
 
       /* Display the item, pad with one space.  */
       if (it.current_x < it.last_visible_x)
Index: xfaces.c
===================================================================
RCS file: /sources/emacs/emacs/src/xfaces.c,v
retrieving revision 1.358
diff -u -r1.358 xfaces.c
--- xfaces.c 21 Jan 2007 04:18:14 -0000 1.358
+++ xfaces.c 2 Feb 2007 04:46:11 -0000
@@ -3866,7 +3866,7 @@
     {
       global_lface = Fmake_vector (make_number (LFACE_VECTOR_SIZE),
 				   Qunspecified);
-      AREF (global_lface, 0) = Qface;
+      ASET (global_lface, 0, Qface);
       Vface_new_frame_defaults = Fcons (Fcons (face, global_lface),
 					Vface_new_frame_defaults);
 
@@ -3888,7 +3888,7 @@
     }
   else if (f == NULL)
     for (i = 1; i < LFACE_VECTOR_SIZE; ++i)
-      AREF (global_lface, i) = Qunspecified;
+      ASET (global_lface, i, Qunspecified);
 
   /* Add a frame-local definition.  */
   if (f)
@@ -3897,12 +3897,12 @@
 	{
 	  lface = Fmake_vector (make_number (LFACE_VECTOR_SIZE),
 				Qunspecified);
-	  AREF (lface, 0) = Qface;
+	  ASET (lface, 0, Qface);
 	  f->face_alist = Fcons (Fcons (face, lface), f->face_alist);
 	}
       else
 	for (i = 1; i < LFACE_VECTOR_SIZE; ++i)
-	  AREF (lface, i) = Qunspecified;
+	  ASET (lface, i, Qunspecified);
     }
   else
     lface = global_lface;
Index: xmenu.c
===================================================================
RCS file: /sources/emacs/emacs/src/xmenu.c,v
retrieving revision 1.317
diff -u -r1.317 xmenu.c
--- xmenu.c 21 Jan 2007 04:18:14 -0000 1.317
+++ xmenu.c 2 Feb 2007 04:46:15 -0000
@@ -1934,7 +1934,7 @@
 	  if (STRINGP (pane_name) && STRING_MULTIBYTE (pane_name))
 	    {
 	      pane_name = ENCODE_MENU_STRING (pane_name);
-	      AREF (menu_items, i + MENU_ITEMS_PANE_NAME) = pane_name;
+	      ASET (menu_items, i + MENU_ITEMS_PANE_NAME, pane_name);
 	    }
 #endif
 	  pane_string = (NILP (pane_name)
@@ -1990,13 +1990,13 @@
           if (STRING_MULTIBYTE (item_name))
 	    {
 	      item_name = ENCODE_MENU_STRING (item_name);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_NAME) = item_name;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_NAME, item_name);
 	    }
 
           if (STRINGP (descrip) && STRING_MULTIBYTE (descrip))
 	    {
 	      descrip = ENCODE_MENU_STRING (descrip);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY) = descrip;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY, descrip);
 	    }
 #endif /* not HAVE_MULTILINGUAL_MENU */
 
@@ -2898,7 +2898,7 @@
 	  if (STRINGP (pane_name) && STRING_MULTIBYTE (pane_name))
 	    {
 	      pane_name = ENCODE_MENU_STRING (pane_name);
-	      AREF (menu_items, i + MENU_ITEMS_PANE_NAME) = pane_name;
+	      ASET (menu_items, i + MENU_ITEMS_PANE_NAME, pane_name);
 	    }
 #endif
 	  pane_string = (NILP (pane_name)
@@ -2952,13 +2952,13 @@
           if (STRINGP (item_name) && STRING_MULTIBYTE (item_name))
 	    {
 	      item_name = ENCODE_MENU_STRING (item_name);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_NAME) = item_name;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_NAME, item_name);
 	    }
 
           if (STRINGP (descrip) && STRING_MULTIBYTE (descrip))
 	    {
 	      descrip = ENCODE_MENU_STRING (descrip);
-	      AREF (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY) = descrip;
+	      ASET (menu_items, i + MENU_ITEMS_ITEM_EQUIV_KEY, descrip);
 	    }
 #endif /* not HAVE_MULTILINGUAL_MENU */
 
Index: xselect.c
===================================================================
RCS file: /sources/emacs/emacs/src/xselect.c,v
retrieving revision 1.167
diff -u -r1.167 xselect.c
--- xselect.c 21 Jan 2007 04:18:14 -0000 1.167
+++ xselect.c 2 Feb 2007 04:46:19 -0000
@@ -2765,15 +2765,15 @@
     }
 
   vec = Fmake_vector (make_number (4), Qnil);
-  AREF (vec, 0) = SYMBOL_NAME (x_atom_to_symbol (FRAME_X_DISPLAY (f),
-                                                 event->message_type));
-  AREF (vec, 1) = frame;
-  AREF (vec, 2) = make_number (event->format);
-  AREF (vec, 3) = x_property_data_to_lisp (f,
-                                           data,
-                                           event->message_type,
-                                           event->format,
-                                           size);
+  ASET (vec, 0, SYMBOL_NAME (x_atom_to_symbol (FRAME_X_DISPLAY (f),
+					       event->message_type)));
+  ASET (vec, 1, frame);
+  ASET (vec, 2, make_number (event->format));
+  ASET (vec, 3, x_property_data_to_lisp (f,
+					 data,
+					 event->message_type,
+					 event->format,
+					 size));
 
   mouse_position_for_drop (f, &x, &y);
   bufp->kind = DRAG_N_DROP_EVENT;

Re: Patch: AREF -vs- ASET

[Sascha Wilde]

Tom Tromey <tromey@redhat.com> wrote:

> I noticed that Emacs has both AREF and ASET macros, but they are not
> consistently used.  Sometimes ASET is used to set an array element,
> but sometimes AREF is used instead.
>
> This patch mostly changes Emacs to use ASET rather than AREF.  I chose
> this, rather than removing ASET, because using a settor macro like
> ASET allows the future possibility of a write barrier, needed for some
> kinds of GC.

FWIW: I like the AREF macro better, as it has the more "lispy"
semantics.  YMMV

just my 2¢
sascha
-- 
Sascha Wilde
To become a Jedi, use Emacs you have to.

Re: Patch: AREF -vs- ASET

[Miles Bader]

Sascha Wilde <wilde@sha-bang.de> writes:
> FWIW: I like the AREF macro better, as it has the more "lispy"
> semantics.  YMMV

elisp is not common-lisp...

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Patch: AREF -vs- ASET

[Sascha Wilde]

Miles Bader <miles.bader@necel.com> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>> FWIW: I like the AREF macro better, as it has the more "lispy"
>> semantics.  YMMV
>
> elisp is not common-lisp...

I know...  *sigh*

sascha
-- 
Sascha Wilde
Nota bene: wenn Word für Längeres geeignet wäre, würde es schließlich
nicht Word, sondern Sentence, Page oder Article heißen
 	-- Matthias Mühlich in dctt

Re: Patch: AREF -vs- ASET

[Stefan Monnier]

> This patch mostly changes Emacs to use ASET rather than AREF.

Looks good to me.


        Stefan

Re: Patch: AREF -vs- ASET

[Richard Stallman]

I like this cleanup, but please save it for after the release.  I
don't want to even think about such things now.  I am very overloaded
and there are other things we NEED to do to make the release possible.

Re: Patch: AREF -vs- ASET

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 02 Feb 2007 15:37:23 -0500
> Cc: emacs-devel@gnu.org
> 
> there are other things we NEED to do to make the release possible.

Maybe I'm missing something obvious, but is there anything beyond
FOR-RELEASE that NEEDS to be done?

If there are such things, let's please add them to FOR-RELEASE, and
let's then mount a concentrated effort on them.

If FOR-RELEASE lists all there is to it, then I think we can resolve
any issues remaining there in a day or two and make the release
shortly after that.

Re: Patch: AREF -vs- ASET

[Richard Stallman]

    Maybe I'm missing something obvious, but is there anything beyond
    FOR-RELEASE that NEEDS to be done?

The main thing that needs doing is to clear up the copyright and
license situation on a surprisingly large number of files.  I'm
working on it with a lawyer.

Re: Patch: AREF -vs- ASET

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Sat, 03 Feb 2007 17:43:32 -0500
> 
> The main thing that needs doing is to clear up the copyright and
> license situation on a surprisingly large number of files.

Are all of those mentioned in admin/notes/copyright?  Maybe you can
publish the list of problematic files, so I could more easily look
them up in the portion of emacs-hackers correspondence that is now on
fencepost?

Re: Patch: AREF -vs- ASET

[Richard Stallman]

    > The main thing that needs doing is to clear up the copyright and
    > license situation on a surprisingly large number of files.

    Are all of those mentioned in admin/notes/copyright?

I think so.  Glenn, can you make an authoritative statement?

copyrights to be fixed [was Re: Patch: AREF -vs- ASET]

[Glenn Morris]

Richard Stallman wrote:

>     > The main thing that needs doing is to clear up the copyright and
>     > license situation on a surprisingly large number of files.
>
>     Are all of those mentioned in admin/notes/copyright?
>
> I think so.  Glenn, can you make an authoritative statement?

I can authoritatively say that it mentions all the issues I know about
at present. People can ask me if they need more details on any
particular issue.

(with-pessimism Though it's entirely possible other people could find
more such issues than I did. It would be "fun" to cross-reference all
non-tiny changelog entries against copyright.list sometime).

It would be a big help if anyone could assist with the many image
files in etc/images, none of which have any real legal information
that I could see. I still want to ask the lawyer if there is such a
thing as a "trivial" image which does not need a copyright; but
clearly listing the provenance of all the images there would be a good
start, I think.

Re: copyrights to be fixed

[Glenn Morris]

I should have also said: if anyone has any ideas about the legal
status of any of the files without copyright (eg who might have
written them and how we can contact them), please speak up.

Also, for the items marked "fix available", I know what needs to be
done, but don't have time to do it until the weekend, probably. (I
think it's easier for me to do it rather than explain the details to
someone else. I'll put guidelines for the future in the file when I
have time).

Re: copyrights to be fixed

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> It would be a big help if anyone could assist with the many image
> files in etc/images, none of which have any real legal information
> that I could see. I still want to ask the lawyer if there is such a
> thing as a "trivial" image which does not need a copyright; but
> clearly listing the provenance of all the images there would be a good
> start, I think.

emacs.xbm, gnu.xpm

These are very old images not used by anything in the Emacs source
tree.  Let's just delete them.

gnus.pbm

This is an old file that is read by Gnus in case
etc/images/gnus/gnus.xpm is unavailable.  Let's just delete it.

gnus-logo.eps

This is a straightforward conversion of the Gnu Emacs logo to EPS
format, used by a couple of reference cards.  I don't think it counts
as a creative work.

letter.pbm
letter.xpm

These are simple images whose source code consists of three short
lines.  They should not be considered creative works.  (If we want to
worry about them, let's just delete them and make new versions---which
would take about half a minute.)

Re: copyrights to be fixed

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> emacs.xbm, gnu.xpm
>
> These are very old images not used by anything in the Emacs source
> tree.  Let's just delete them.

Those are classic Emacs images, take almost no space, and the chance of
them being a problem is more or less zero.  Let's just leave them there
like they've been for approximately 3 zillion years.

-miles
-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish are
breaking up??!  Shit, white people oughtta understand, their job is to GIVE
people the blues, not to get them!    -- George Carlin

Re: copyrights to be fixed

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>> emacs.xbm, gnu.xpm
>>
>> These are very old images not used by anything in the Emacs source
>> tree.  Let's just delete them.
>
> Those are classic Emacs images, take almost no space, and the chance of
> them being a problem is more or less zero.  Let's just leave them there
> like they've been for approximately 3 zillion years.

These are classic Emacs images with no copyright information, and
tracking down the relevant info might take another 3 zillion years...

Re: copyrights to be fixed

[Richard Stallman]

    These are classic Emacs images with no copyright information, and
    tracking down the relevant info might take another 3 zillion years...

Is there a change log entry for their installation?

Re: copyrights to be fixed

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     These are classic Emacs images with no copyright information, and
>     tracking down the relevant info might take another 3 zillion years...
>
> Is there a change log entry for their installation?

emacs.xbm
Sun Oct 3 12:30:05 1999 UTC (7 years, 4 months ago) by fx

gnu.xpm
Sun Oct 3 12:30:07 1999 UTC (7 years, 4 months ago) by fx

Re: copyrights to be fixed

[Stuart D. Herring]

>> Is there a change log entry for their installation?
>
> emacs.xbm
> Sun Oct 3 12:30:05 1999 UTC (7 years, 4 months ago) by fx
>
> gnu.xpm
> Sun Oct 3 12:30:07 1999 UTC (7 years, 4 months ago) by fx

I'm not sure which are the desired images, but here are the relevant bits
from etc/ChangeLog:

2005-03-29  Reiner Steib  <Reiner.Steib@gmx.de>
* gnus-refcard.tex, gnus-logo.eps: New files.
2003-04-01  Dave Love  <fx@gnu.org>
* letter.pbm: New.
2002-01-27  Pavel Janík  <Pavel@Janik.cz>
* letter.xpm: New file, XPM variant of letter.xbm.
2001-04-03  Gerd Moellmann  <gerd@gnu.org>
* splash8.xpm: New image from Luis Fernandes <elf@ee.ryerson.ca>
2001-03-26  Gerd Moellmann  <gerd@gnu.org>
* splash.pbm: New image from Luis Fernandes <elf@ee.ryerson.ca>.
2001-03-15  Gerd Moellmann  <gerd@gnu.org>
* splash.xpm, splash.pbm: Replaced with new images from Luis Fernandes
<elf@ee.ryerson.ca>.
2000-10-12  Dave Love  <fx@gnu.org>
* gnus.pbm: New file.

Dave Love also modified letter.xpm and deleted letter.xbm when he created
letter.pbm.  Gerd Moellmann added the original versions of splash.*.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: copyrights to be fixed

[Glenn Morris]

"Stuart D. Herring" wrote:

>>> Is there a change log entry for their installation?
>>
>> emacs.xbm
>> Sun Oct 3 12:30:05 1999 UTC (7 years, 4 months ago) by fx
>>
>> gnu.xpm
>> Sun Oct 3 12:30:07 1999 UTC (7 years, 4 months ago) by fx
>
> I'm not sure which are the desired images, but here are the relevant
> bits from etc/ChangeLog:

These Changelog examples illustrate why this whole process is such a
nuisance.

> 2005-03-29  Reiner Steib  <Reiner.Steib@gmx.de>
> * gnus-refcard.tex, gnus-logo.eps: New files.

gnus-refcard.ps says that the copyright holder for the Gnus logo is
Luis Fernandes, whose name is totally absent from this entry.

> 2001-04-03  Gerd Moellmann  <gerd@gnu.org>
> * splash8.xpm: New image from Luis Fernandes <elf@ee.ryerson.ca>

The author entry here is wrong, it should be Fernandes (it's lucky he
is mentioned at all, as we have seen above)...

> 2000-10-12  Dave Love  <fx@gnu.org>
> * gnus.pbm: New file.

... which, coupled with the fact that gnus.pbm is basically the
Gnus/Emacs logo, makes me seriously doubt that Dave Love is the real
contributor...

> Dave Love also modified letter.xpm and deleted letter.xbm when he
> created letter.pbm.

... which suggests he may not have created these either.


So all this exercise really does is show us the people to contact in
the first instance and ask "can you remember who really created this
image that you installed 7 years ago".


We need README files that list all these images, and the 300 more in
etc/images, saying who created them, who holds the copyright, and what
license they are under.

Re: copyrights to be fixed

[Reiner Steib]

On Thu, Feb 08 2007, Glenn Morris wrote:

> These Changelog examples illustrate why this whole process is such a
> nuisance.
>
>> 2005-03-29  Reiner Steib  <Reiner.Steib@gmx.de>
>> * gnus-refcard.tex, gnus-logo.eps: New files.
>
> gnus-refcard.ps says that the copyright holder for the Gnus logo is
> Luis Fernandes, whose name is totally absent from this entry.

I'm sorry for the insufficient entry.  I copied the file from Gnus.
Would "New files imported from Gnus." be sufficient?

Here are the relevant cvs log entries (cvs log gnus-logo.eps
gnuslogo-booklet.eps)...

--8<---------------cut here---------------start------------->8---

RCS file: /usr/local/cvsroot/gnus/texi/gnus-logo.eps,v
Working file: gnus-logo.eps
head: 7.1
branch:
[...]
----------------------------
revision 7.1
date: 2005/03/30 02:00:30;  author: miles;  state: Exp;  lines: +1055 -0
Revision: miles@gnu.org--gnu-2005/gnus--devo--0--patch-82

[...]

2005-03-29  Reiner Steib  <Reiner.Steib@gmx.de>

[...]

   * texi/gnus-logo.eps: Renamed from gnuslogo-booklet.eps.
   gnuslogo-refcard.eps: Removed.

[...]
----------------------------
revision 1.1
date: 2005/03/29 17:21:12;  author: rsteib;  state: dead;
branches:  1.1.2;
file gnus-logo.eps was initially added on branch v5-10.
----------------------------
revision 1.1.2.1
date: 2005/03/29 17:21:12;  author: rsteib;  state: Exp;  lines: +1055 -0
Renamed from gnuslogo-booklet.eps.
gnuslogo-refcard.eps: Removed.
=============================================================================

RCS file: /usr/local/cvsroot/gnus/texi/Attic/gnuslogo-booklet.eps,v
Working file: gnuslogo-booklet.eps
head: 7.2
[...]
----------------------------
revision 7.2
date: 2005/03/30 02:00:30;  author: miles;  state: dead;  lines: +0 -0
Revision: miles@gnu.org--gnu-2005/gnus--devo--0--patch-82

Merge from gnus--rel--5.10

[...]

2005-03-29  Reiner Steib  <Reiner.Steib@gmx.de>

[...]
   * texi/gnus-logo.eps: Renamed from gnuslogo-booklet.eps.
   gnuslogo-refcard.eps: Removed.

   * texi/Makefile.in (gnus-faq.texi): Depend on xml2texi.*. Fix sed
   command.
----------------------------
revision 7.1
date: 2004/01/04 21:42:02;  author: larsi;  state: Exp;  lines: +0 -0
New version.
----------------------------
revision 6.1
date: 2002/03/24 22:54:53;  author: zsh;  state: Exp;
branches:  6.1.2;
[...]
2002-03-24  Felix Natter <fnatter@gmx.net>

	* booklet.tex, bk-at.tex, bk-lt.tex, gnuslog-booklet.eps: New file.
	* gnusref.tex, refcard.tex: Support booklet.

[...]
----------------------------
revision 6.1.2.1
date: 2005/03/29 17:22:59;  author: rsteib;  state: dead;  lines: +0 -0
	* gnus-logo.eps: Renamed from gnuslogo-booklet.eps.
	gnuslogo-refcard.eps: Removed.
=============================================================================
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: copyrights to be fixed

[Richard Stallman]

    I'm sorry for the insufficient entry.  I copied the file from Gnus.
    Would "New files imported from Gnus." be sufficient?

In the case of Gnus, we usually treat it as part of Emacs.

When a new file is installed in Gnus, the change log entry in Gnus
should be in the name of the author.

200X-MM-DD  AUTHOR OF FILE  <email address>

Don't put your name there just because you're checking the file in.
Who checked in the file is not important.  All that matters is who
wrote it.

When that file is copied into the Emacs repository, copy the change
log entry with the author's name!  Don't put your own name in that
change log entry.  Who copied the file into Emacs is not important.
All that matters is who wrote it.

Re: copyrights to be fixed

[Richard Stallman]

    emacs.xbm
    Sun Oct 3 12:30:05 1999 UTC (7 years, 4 months ago) by fx

    gnu.xpm
    Sun Oct 3 12:30:07 1999 UTC (7 years, 4 months ago) by fx

Let's ask Dave Love who wrote them.

Re: copyrights to be fixed

[Chong Yidong]

The smiley images are from Gnus.  From looking at the Gnus ChangeLog,
it seems that the smilies are authored by various people, who have FSF
copyright assignments in place:

Reiner Steib
Simon Josefsson
Kai Grossjohann
Alex Schroeder
Oliver Scholz
Per Abrahamsen
Kim F. Storm

I will create a README file crediting these folks and stating (C) FSF.
Let's then treat the etc/images/smilies issue as resolved.  After all,
it takes about half a minute to create each of these little images;
let's not lose any sleep over them.

Re: copyrights to be fixed

[Richard Stallman]

    I will create a README file crediting these folks and stating (C) FSF.
    Let's then treat the etc/images/smilies issue as resolved.

That will do the job for the group od smilies that were made by those
people.

I'm not sure whether that deals with _all_ of the "etc/images/smilies
issue", because I'm not sure what else is included in that issue
and which other parts have been handled.

Re: copyrights to be fixed

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     I will create a README file crediting these folks and stating (C) FSF.
>     Let's then treat the etc/images/smilies issue as resolved.
>
> That will do the job for the group od smilies that were made by those
> people.
>
> I'm not sure whether that deals with _all_ of the "etc/images/smilies
> issue", because I'm not sure what else is included in that issue
> and which other parts have been handled.

If you like, I can delete the smilies, make new ones, and check them
in.  It will take about five minutes to recreate the 16 images; that's
how trivial they are.

Re: copyrights to be fixed

[Richard Stallman]

    If you like, I can delete the smilies, make new ones, and check them
    in.  It will take about five minutes to recreate the 16 images; that's
    how trivial they are.

There is no need to delete and regenerate the files for which we have
papers.  I didn't ask for that.  Perhaps there is a misunderstanding.

Re: copyrights to be fixed

[Reiner Steib]

On Mon, Feb 12 2007, Chong Yidong wrote:

> The smiley images are from Gnus.  From looking at the Gnus ChangeLog,
> it seems that the smilies are authored by various people, who have FSF
> copyright assignments in place:
>
> Reiner Steib
[...]

FWIW, I didn't modify any of the smiley icons.  Maybe you counted the
following make.bat change?

2006-04-19  Reiner Steib  <Reiner.Steib@gmx.de>

        * make.bat: Use "echo *" to clarify the output.
        (:lisp, :infotest): Avoid "not found" errors
        (:etc): Remove etc\gnus.  Be more verbose.  Add new smilies.
        Simplify.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: copyrights to be fixed

[Richard Stallman]

    gnus-logo.eps

    This is a straightforward conversion of the Gnu Emacs logo to EPS
    format, used by a couple of reference cards.  I don't think it counts
    as a creative work.

More precisely, if your description is accurate, no extra creativity
went into deriving it from the other form of the Emacs logo, and we do
have papers for that.

Is this all the "gnus logo" refers to?  So there really is no separate
logo for Gnus?  If so, that term "gnus logo" is misleading: this is
the Emacs logo.  We should stop using the term "gnus logo" if there
isn't actually a different logo for Gnus.

    letter.pbm
    letter.xpm

    These are simple images whose source code consists of three short
    lines.  They should not be considered creative works.

We can keep them.

Re: copyrights to be fixed

[Jesper Harder]

Richard Stallman <rms@gnu.org> writes:

>     gnus-logo.eps
>
>     This is a straightforward conversion of the Gnu Emacs logo to EPS
>     format, used by a couple of reference cards.  I don't think it counts
>     as a creative work.
>
> More precisely, if your description is accurate, no extra creativity
> went into deriving it from the other form of the Emacs logo, and we do
> have papers for that.

It's actually the other way around: The current Emacs logo is derived
from the original Gnus logo (both designed by Luis Fernandes),
cf. <http://www.ee.ryerson.ca/~elf/emacs/logo/logo.html>

Re: copyrights to be fixed

[Richard Stallman]

    It's actually the other way around: The current Emacs logo is derived
    from the original Gnus logo (both designed by Luis Fernandes),

"Derived" as used that statement has two possible meanings.  Does it
mean "automatically converted", or does it mean "produced by hand-made
changes from"?

Re: copyrights to be fixed

[Jesper Harder]

Richard Stallman <rms@gnu.org> writes:

>     It's actually the other way around: The current Emacs logo is derived
>     from the original Gnus logo (both designed by Luis Fernandes),
>
> "Derived" as used that statement has two possible meanings.  Does it
> mean "automatically converted", or does it mean "produced by hand-made
> changes from"?

The Emacs logo is the same as the Gnus logo except that it includes
the word "Emacs" in a custom style of lettering.  This addition is
clearly a hand-made change.

But the file gnus-logo.eps is a straigh-forward conversion from the
Gnus logo.

Re: copyrights to be fixed

[Richard Stallman]

    The Emacs logo is the same as the Gnus logo except that it includes
    the word "Emacs" in a custom style of lettering.  This addition is
    clearly a hand-made change.

In that case, it is just as well that we are getting papers for both.

Re: copyrights to be fixed [was Re: Patch: AREF -vs- ASET]

[Richard Stallman]

    clearly listing the provenance of all the images there would be a good
    start, I think.

Yes, this is important.

Can you find this by searching for items in copyright.list that
assign images for Emacs?  I think those will quickly account
for most of the images.

Re: copyrights to be fixed [was Re: Patch: AREF -vs- ASET]

[Nick Roberts]

 >     clearly listing the provenance of all the images there would be a good
 >     start, I think.
 > 
 > Yes, this is important.
 > 
 > Can you find this by searching for items in copyright.list that
 > assign images for Emacs?  I think those will quickly account
 > for most of the images.

I can vouch for the ones in the emacs/etc/images/gud directory.  Most are from
RedHat's Insight debugger.  You obtained copyright assignment for these shortly
before I committed them in November 2002 (I can dig out our correspondence if
you want, but clearly not yours with RedHat).  The other images were created by
me since we were unsuccessful in obtaining suitable ones from a graphical
designer.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: copyrights to be fixed

[Glenn Morris]

Nick Roberts wrote:

> I can vouch for the ones in the emacs/etc/images/gud directory. Most
> are from RedHat's Insight debugger. You obtained copyright
> assignment for these shortly before I committed them in November
> 2002 (I can dig out our correspondence if you want, but clearly not
> yours with RedHat). The other images were created by me since we
> were unsuccessful in obtaining suitable ones from a graphical
> designer.

Can you add a README file to the images/gud directory that says which
image came from where, please?

Re: copyrights to be fixed

[Nick Roberts]

 > Can you add a README file to the images/gud directory that says which
 > image came from where, please?

I've done this.  You might want to reformat it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: copyrights to be fixed

[Glenn Morris]

Nick Roberts wrote:

>  > Can you add a README file to the images/gud directory that says which
>  > image came from where, please?
>
> I've done this.  You might want to reformat it.

Thanks! Can either you or RMS add the copyright and license info for
the files that came from Red Hat?

Re: copyrights to be fixed

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> It would be a big help if anyone could assist with the many image
> files in etc/images, none of which have any real legal information
> that I could see. I still want to ask the lawyer if there is such a
> thing as a "trivial" image which does not need a copyright; but
> clearly listing the provenance of all the images there would be a good
> start, I think.

The files in etc/images are taken from GTK 2.x and Gnome 2.x, as
explained in the README file.  The Debian copyrights file said to
refer to the Changelogs for copyright information, so I did that.  The
result is

Copyright 2002 through 2006

Copyright owners (not FSF assigned as far as I can tell):
  Tuomas Kuosmanen, Rodney Dawes, Jakub Steiner, Alexander Larsson,
  Tor Lillqvist, Garrett LeSage, Dennis Cranston, Jody Goldberg, Luca
  Ferretti, Mark Finlay, and Marco Pesenti Gritti

Released under the GNU General Public License, version 2.

Re: copyrights to be fixed

[Glenn Morris]

Chong Yidong wrote:

> The files in etc/images are taken from GTK 2.x and Gnome 2.x, as
> explained in the README file.

Except:

1) it doesn't mention all the files: cancel.xpm, info.xpm,
   mh-logo.xpm, next-node.xpm, prev-node.xpm, redo.xpm,
   search-replace.xpm, show.xpm, up-node.xpm are missing.

2) it mentions find-replace.xpm, which isn't there.

3) it lists sort-ascending.xpm and sort-descending.xpm as being taken
   from _both_ GTK and Gnome, so which is it?


[OT, but also annoys me, why do some files get a pbm version (eg
zoom-out) while some do not (eg zoom-in)...]

Re: copyrights to be fixed

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
> 
> > The files in etc/images are taken from GTK 2.x and Gnome 2.x, as
> > explained in the README file.
> 
> Except:
> 
> 1) it doesn't mention all the files: cancel.xpm, info.xpm,
>    mh-logo.xpm, next-node.xpm, prev-node.xpm, redo.xpm,
>    search-replace.xpm, show.xpm, up-node.xpm are missing.

All of these, except for mh-logo, are derived from the stock GTK icons
with no additional creative effort (for example, by reflecting the
original image or rotating these by 90 degrees).  So they can be added
to the list.

I don't know about mh-logo.xpm.
 
> 2) it mentions find-replace.xpm, which isn't there.

Probably an oversight; just delete that entry.
 
> 3) it lists sort-ascending.xpm and sort-descending.xpm as being taken
>    from _both_ GTK and Gnome, so which is it?

The same group of artists make the GTK and Gnome icons; I believe in
this case there is no difference between the icons taken from either
source.  So let's not worry about it.

Re: copyrights to be fixed

[Richard Stallman]

    The files in etc/images are taken from GTK 2.x and Gnome 2.x, as
    explained in the README file.  The Debian copyrights file said to
    refer to the Changelogs for copyright information, so I did that.  The
    result is

    Copyright 2002 through 2006

    Copyright owners (not FSF assigned as far as I can tell):
      Tuomas Kuosmanen, Rodney Dawes, Jakub Steiner, Alexander Larsson,
      Tor Lillqvist, Garrett LeSage, Dennis Cranston, Jody Goldberg, Luca
      Ferretti, Mark Finlay, and Marco Pesenti Gritti

    Released under the GNU General Public License, version 2.

Is it really only version 2?  If so, we may have to replace them in
order to move Emacs to GPL version 3.

Can you tell me how to contact these people so I can ask them to
relicense to GPL version 3 or later?

Re: copyrights to be fixed

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     The files in etc/images are taken from GTK 2.x and Gnome 2.x, as
>     explained in the README file.  The Debian copyrights file said to
>     refer to the Changelogs for copyright information, so I did that.  The
>     result is
>
>     Copyright 2002 through 2006
>
>     Copyright owners (not FSF assigned as far as I can tell):
>       Tuomas Kuosmanen, Rodney Dawes, Jakub Steiner, Alexander Larsson,
>       Tor Lillqvist, Garrett LeSage, Dennis Cranston, Jody Goldberg, Luca
>       Ferretti, Mark Finlay, and Marco Pesenti Gritti
>
>     Released under the GNU General Public License, version 2.
>
> Is it really only version 2?

Not sure.  The .c and .h files in the same tarballs contain the string
"or (at your option) any later version".  But these comments
(obviously) do not appear in the image files themselves.

>  If so, we may have to replace them in
> order to move Emacs to GPL version 3.

If we wait long enough, we can move Emacs to GPL version 4.

> Can you tell me how to contact these people so I can ask them to
> relicense to GPL version 3 or later?

Tuomas Kuosmanen  <tigert@novell.com>
Rodney Dawes  <dobey@novell.com>
Jakub Steiner <jimmac@ximian.com>
Alexander Larsson  <alexl@redhat.com>

Re: copyrights to be fixed

[Richard Stallman]

    > Is it really only version 2?

    Not sure.  The .c and .h files in the same tarballs contain the string
    "or (at your option) any later version".

Hmm.  Perhaps that notice for the images is a mistake.
I will write to them.

Re: copyrights to be fixed

[Richard Stallman]

    Not sure.  The .c and .h files in the same tarballs contain the string
    "or (at your option) any later version".

Can you tell me the names of these tarballs?  When I write to them, I
want to identify precisely what I'm talking about.  Also, what are the
names of the image files in question?

Re: copyrights to be fixed

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     Not sure.  The .c and .h files in the same tarballs contain the string
>     "or (at your option) any later version".
>
> Can you tell me the names of these tarballs?  When I write to them, I
> want to identify precisely what I'm talking about.  Also, what are the
> names of the image files in question?

gtk+-2.10.0.tar.bz2
gnome-icon-theme-2.16.0.tar.gz

Re: copyrights to be fixed

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Is it really only version 2?  If so, we may have to replace them in
> order to move Emacs to GPL version 3.

Are we going to do that before the release?
If not, why does it matter at this time?

We can just note it in the copyright file, and deal with it in 2010
when 23.x is ready for release...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: copyrights to be fixed

[Paul Pogonyshev]

Kim F. Storm wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> > Is it really only version 2?  If so, we may have to replace them in
> > order to move Emacs to GPL version 3.
> 
> Are we going to do that before the release?
> If not, why does it matter at this time?
> 
> We can just note it in the copyright file, and deal with it in 2010
> when 23.x is ready for release...

Yeah, and make it 2015 at least.

Paul

Re: copyrights to be fixed

[David Kastrup]

Paul Pogonyshev <pogonyshev@gmx.net> writes:

> Kim F. Storm wrote:
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> > Is it really only version 2?  If so, we may have to replace them in
>> > order to move Emacs to GPL version 3.
>> 
>> Are we going to do that before the release?
>> If not, why does it matter at this time?
>> 
>> We can just note it in the copyright file, and deal with it in 2010
>> when 23.x is ready for release...
>
> Yeah, and make it 2015 at least.

The tentative sketches of what we want to have in version 23.x call
for merging the unicode-2 branch, multi-tty and minor pending changes.

Copyright situation, manual status and proof reading and major missing
functionality will be still reasonably fresh from the impending 22.x
release (with the possible exception of GPL 3 worries, but I don't see
them posing a major showstopper).

In the mean time, no particular problems are addressed by snapping,
sarcasm and bitterness.

-- 
David Kastrup

Re: copyrights to be fixed

[Romain Francoise]

David Kastrup <dak@gnu.org> writes:

> The tentative sketches of what we want to have in version 23.x
> call for merging the unicode-2 branch, multi-tty and minor pending
> changes.

By the way, last I heard the multi-tty branch was in need of a new
maintainer:

  http://article.gmane.org/gmane.emacs.multi-tty/630

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: copyrights to be fixed

[Stefan Monnier]

>> The tentative sketches of what we want to have in version 23.x
>> call for merging the unicode-2 branch, multi-tty and minor pending
>> changes.

> By the way, last I heard the multi-tty branch was in need of a new
> maintainer:

>   http://article.gmane.org/gmane.emacs.multi-tty/630

Then I think it's urgent to merge the multi-tty branch into the unicode
branch, before the two diverge too much.


        Stefan

Re: copyrights to be fixed

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The tentative sketches of what we want to have in version 23.x
>>> call for merging the unicode-2 branch, multi-tty and minor pending
>>> changes.
>
>> By the way, last I heard the multi-tty branch was in need of a new
>> maintainer:
>
>>   http://article.gmane.org/gmane.emacs.multi-tty/630
>
> Then I think it's urgent to merge the multi-tty branch into the unicode
> branch, before the two diverge too much.

I'm interested in this and will do my best to help test this merged version.

>
>         Stefan

-- 
Joakim Verona

Re: copyrights to be fixed

[Richard Stallman]

How well does the multi-tty branch actually work?
Are there major gaps in the features?

Re: copyrights to be fixed

[Robert J. Chassell]

    How well does the multi-tty branch actually work?

For a month or so I have been using the multi-tty branch for two
instances of Emacs that are secondary to my prime instance -- in one
of the secondary instances, I get mail and update Emacs; in the other
secondary instance, which is in a different screen, or `desktop' as
some say, I do a variety of things.  That is the instance I start with
`emacsclient.emacs-multi-tty &' in a small shell window.

Both instances are stable.

    Are there major gaps in the features?

No, not that I have seen.  I am not doing anything strange or doing
stress testing.  Mostly I am doing ordinary stuff, such as evaluating
expressions like

   (progn
    (cd "/usr/local/src/emacs/") 
    (cvs-update "/usr/local/src/emacs/" '("-dP")))

and writing files.  As far as I am concerned, the two instances are
behaving like a normal, up to date Emacs.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: copyrights to be fixed

[Richard Stallman]

	Are there major gaps in the features?

    No, not that I have seen.

A small number of people can't tell the answer to this question by
running the program.

We need the people who implemented the multi-tty code to tell us
whether there are cases they have not handled yet that need to be
handled to avoid loss of functionality.

Re: copyrights to be fixed

[joakim]

Richard Stallman <rms@gnu.org> writes:

> 	Are there major gaps in the features?
>
>     No, not that I have seen.
>
> A small number of people can't tell the answer to this question by
> running the program.
>
> We need the people who implemented the multi-tty code to tell us
> whether there are cases they have not handled yet that need to be
> handled to avoid loss of functionality.

This readme contains a list of known issues:

http://lorentey.hu/downloads/emacs/multi-tty/README.multi-tty

For convenience I paste the Known Problems list here:

Known problems:

        * GTK support.  If you compile your Emacs with the GTK
          toolkit, some functionality of multi-tty will be lost.  In
          particular, you will not be able to work on multiple X
          displays at once.  Current releases of GTK have limitations
          and bugs that prevent full-blown multi-display support in
          Emacs.  (GTK crashes when Emacs tries to disconnect from an
          X server.)  Use the Lucid toolkit if you want to see a
          complete feature set.

        * The single-kboard mode.

	  If your multi-tty Emacs session seems to be frozen, you
	  probably have a recursive editing session or a pending
	  minibuffer prompt (which is a kind of recursive editing) on
	  another display.  To unfreeze your session, switch to that
	  display and complete the recursive edit, for example by
	  pressing C-] (`abort-recursive-edit').

	  I am sorry to say that currently there is no way to break
	  out of this "single-kboard mode" from a frozen display.  If
	  you are unable to switch to the display that locks the
	  others (for example because it is on a remote computer),
	  then you can use emacsclient to break out of all recursive
	  editing sessions:

		emacsclient -e '(top-level)'

	  Note that this (perhaps) unintuitive behaviour is by design.
	  Single-kboard mode is required because of an intrinsic Emacs
	  limitation that is very hard to eliminate.  (This limitation
	  is related to the single-threaded nature of Emacs.)

	  I plan to implement better user notification and support for
	  breaking out of single-kboard mode from locked displays.

	* Mac, Windows and DOS support is broken, doesn't even
  	  compile.  Multiple display support will probably not provide
  	  new Emacs features on these systems, but the multi-tty
  	  branch changed a few low-level interfaces, and the
  	  system-dependent source files need to be adapted
  	  accordingly.  The changes are mostly trivial, so almost
  	  anyone can help, if only by compiling the branch and
  	  reporting the compiler errors.



--
Joakim Verona
http://www.verona.se

Re: copyrights to be fixed

[David Kastrup]

joakim@verona.se writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> 	Are there major gaps in the features?
>>
>>     No, not that I have seen.
>>
>> A small number of people can't tell the answer to this question by
>> running the program.
>>
>> We need the people who implemented the multi-tty code to tell us
>> whether there are cases they have not handled yet that need to be
>> handled to avoid loss of functionality.
>
> This readme contains a list of known issues:
>
> http://lorentey.hu/downloads/emacs/multi-tty/README.multi-tty
>
> For convenience I paste the Known Problems list here:
>
> Known problems:
>
>         * GTK support.  If you compile your Emacs with the GTK
>           toolkit, some functionality of multi-tty will be lost.  In
>           particular, you will not be able to work on multiple X
>           displays at once.  Current releases of GTK have limitations
>           and bugs that prevent full-blown multi-display support in
>           Emacs.  (GTK crashes when Emacs tries to disconnect from an
>           X server.)  Use the Lucid toolkit if you want to see a
>           complete feature set.

Ok, perhaps people will call me a lunatic for that, but I think this
would be a rather compelling reason to merge multi-tty support rather
sooner than later after releasing Emacs 22: there are rather few
applications for which multi-tty support and disconnecting from an X
server would be relevant.  GTK and/or Gnome are supposed to be GNU
desktop components, and we want to get problems with them ironed out.
Merging multi-tty early in the Emacs 23 process gives appropriate GTK
bug fixes a chance to make it out into the real world before Emacs 23
follows.  In contrast, I don't think that we have similar
"sympathetic" software releases to take into consideration in
connection with unicode2.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: copyrights to be fixed

[Jan Djärv]

David Kastrup skrev:
> joakim@verona.se writes:
> 
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> 	Are there major gaps in the features?
>>>
>>>     No, not that I have seen.
>>>
>>> A small number of people can't tell the answer to this question by
>>> running the program.
>>>
>>> We need the people who implemented the multi-tty code to tell us
>>> whether there are cases they have not handled yet that need to be
>>> handled to avoid loss of functionality.
>> This readme contains a list of known issues:
>>
>> http://lorentey.hu/downloads/emacs/multi-tty/README.multi-tty
>>
>> For convenience I paste the Known Problems list here:
>>
>> Known problems:
>>
>>         * GTK support.  If you compile your Emacs with the GTK
>>           toolkit, some functionality of multi-tty will be lost.  In
>>           particular, you will not be able to work on multiple X
>>           displays at once.  Current releases of GTK have limitations
>>           and bugs that prevent full-blown multi-display support in
>>           Emacs.  (GTK crashes when Emacs tries to disconnect from an
>>           X server.)  Use the Lucid toolkit if you want to see a
>>           complete feature set.
> 
> Ok, perhaps people will call me a lunatic for that, but I think this
> would be a rather compelling reason to merge multi-tty support rather
> sooner than later after releasing Emacs 22: there are rather few
> applications for which multi-tty support and disconnecting from an X
> server would be relevant.  GTK and/or Gnome are supposed to be GNU
> desktop components, and we want to get problems with them ironed out.
> Merging multi-tty early in the Emacs 23 process gives appropriate GTK
> bug fixes a chance to make it out into the real world before Emacs 23
> follows.  In contrast, I don't think that we have similar
> "sympathetic" software releases to take into consideration in
> connection with unicode2.

The Gtk guys are aware of the problem, see 
http://bugzilla.gnome.org/show_bug.cgi?id=85715.

The issue is still not fixed as far as I can tell.

	Jan D.

> 

Re: copyrights to be fixed

[Richard Stallman]

      (GTK crashes when Emacs tries to disconnect from an
    >>           X server.)

    The Gtk guys are aware of the problem, see 
    http://bugzilla.gnome.org/show_bug.cgi?id=85715.

    The issue is still not fixed as far as I can tell.

Does the current version work properly with multiple terminals
when built with GTK?

multi-tty branch + GTK (Re: copyrights to be fixed)

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 1176 bytes --]

Richard Stallman wrote:
>       (GTK crashes when Emacs tries to disconnect from an
>     >>           X server.)
> 
>     The Gtk guys are aware of the problem, see 
>     http://bugzilla.gnome.org/show_bug.cgi?id=85715.
> 
>     The issue is still not fixed as far as I can tell.
> 
> Does the current version work properly with multiple terminals
> when built with GTK?

Multiple X server support is disabled in the GTK build of the multi-tty
branch due to the GTK bug cited above.  On the other hand, multiple tty
device support is fully supported and functional on all builds of
multi-tty, including GTK.  Multiple ttys work, multiple X servers don't.

Incidentally, most of the multiple X display support comes from the
trunk, so the bug is reproducible there as well.  It is unlikely to
occur in normal usage, though: the trunk does not normally disconnect
from an X server, while the multi-tty branch disconnects immediately
when the last frame is deleted. It is the act of disconnection that
triggers the GTK crash.  (Connections must be closed sooner to support
using emacsclient in an SSH session with X forwarding better.)

-- 
Károly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch + GTK (Re: copyrights to be fixed)

[Richard Stallman]

    > Does the current version work properly with multiple terminals
    > when built with GTK?

    Multiple X server support is disabled in the GTK build of the multi-tty
    branch due to the GTK bug cited above.

My question is what the _current_ version of Emacs does with multiple
terminals (X terminals, that is), when it is built with GTK.

However, that answer is important, because it shows we cannot merge in
the multi-tty support under present circumstances.  It would imply a
significant loss of functionality for users of X.

    Incidentally, most of the multiple X display support comes from the
    trunk, so the bug is reproducible there as well.  It is unlikely to
    occur in normal usage, though: the trunk does not normally disconnect
    from an X server, while the multi-tty branch disconnects immediately
    when the last frame is deleted. It is the act of disconnection that
    triggers the GTK crash.

That answers my question.

One possible work-around would be not to disconnect from an X server.

Can someone change the multi-tty branch so that, when built with GTK,
it does not try to disconnect?  Then it could support multiple X
terminals with GTK as well as the current version does.  This obstacle
to merging in the multi-tty branch would be gone.

Re: multi-tty branch + GTK (Re: copyrights to be fixed)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 1312 bytes --]

Richard Stallman wrote:
>     Incidentally, most of the multiple X display support comes from the
>     trunk, so the bug is reproducible there as well.  It is unlikely to
>     occur in normal usage, though: the trunk does not normally disconnect
>     from an X server, while the multi-tty branch disconnects immediately
>     when the last frame is deleted. It is the act of disconnection that
>     triggers the GTK crash.
> 
> That answers my question.
> 
> One possible work-around would be not to disconnect from an X server.
> 
> Can someone change the multi-tty branch so that, when built with GTK,
> it does not try to disconnect?  Then it could support multiple X
> terminals with GTK as well as the current version does.  This obstacle
> to merging in the multi-tty branch would be gone.

I will do that.

(Disconnections can not be prevented entirely, though: Emacs/GTK crashes
on both branches if a server connection is cut or a server crashes.  In
some use cases, this happens regularly, by design: e.g., if the user
runs emacsclient to create a frame on an ssh-forwarded remote X server,
then later logs out from the ssh session, the server connection is
closed, unintentionally SEGVing the Emacs process.  I think we should
document this in PROBLEMS.)

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: multi-tty branch + GTK (Re: copyrights to be fixed)

[Jan Djärv]

Karoly Lorentey skrev:

> (Disconnections can not be prevented entirely, though: Emacs/GTK crashes
> on both branches if a server connection is cut or a server crashes.  In
> some use cases, this happens regularly, by design: e.g., if the user
> runs emacsclient to create a frame on an ssh-forwarded remote X server,
> then later logs out from the ssh session, the server connection is
> closed, unintentionally SEGVing the Emacs process.  I think we should
> document this in PROBLEMS.)
> 

We do:

** Emacs compiled with Gtk+ crashes when closing a display (x-close-connection).

This happens because of bugs in Gtk+.  Gtk+ 2.10 seems to be OK.  See bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715.

	Jan D.

Re: multi-tty branch + GTK (Re: copyrights to be fixed)

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> ** Emacs compiled with Gtk+ crashes when closing a display
> (x-close-connection).
>
> This happens because of bugs in Gtk+.  Gtk+ 2.10 seems to be OK.
> See bug http://bugzilla.gnome.org/show_bug.cgi?id=85715.

The bug is still open and I don't see anything that would lead to a
conclusion in the bottom of the comments that this would be fixed
and/or checked in.

While I think it probable that by the time Emacs 23 will be released,
Gtk+ 2.10 will be out long enough, did you perform any tests yourself
that would point to 2.10 working in this regard?

-- 
David Kastrup

Re: multi-tty branch + GTK (Re: copyrights to be fixed)

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> ** Emacs compiled with Gtk+ crashes when closing a display
>> (x-close-connection).
>>
>> This happens because of bugs in Gtk+.  Gtk+ 2.10 seems to be OK.
>> See bug http://bugzilla.gnome.org/show_bug.cgi?id=85715.
> 
> The bug is still open and I don't see anything that would lead to a
> conclusion in the bottom of the comments that this would be fixed
> and/or checked in.
> 
> While I think it probable that by the time Emacs 23 will be released,
> Gtk+ 2.10 will be out long enough, did you perform any tests yourself
> that would point to 2.10 working in this regard?
> 

Not more than open up a second display and then closed it with 
x-close-conection, and confirm that Emacs does not crash.

It may leak memory though.  It is hard to tell what goes on inside Gtk+.

	Jan D.

Re: multi-tty branch + GTK (Re: copyrights to be fixed)

[Richard Stallman]

    (Disconnections can not be prevented entirely, though: Emacs/GTK crashes
    on both branches if a server connection is cut or a server crashes.  In
    some use cases, this happens regularly, by design: e.g., if the user
    runs emacsclient to create a frame on an ssh-forwarded remote X server,
    then later logs out from the ssh session, the server connection is
    closed, unintentionally SEGVing the Emacs process.  I think we should
    document this in PROBLEMS.)

Yes, would someone please do so?

However, once the multi-tty branch handles this just as well as
the current version, this issue is no longer an obstacle to merging in
the multi-tty branch.

Re: multi-tty branch + GTK (Re: copyrights to be fixed)

[Jan Djärv]

Richard Stallman skrev:
>     (Disconnections can not be prevented entirely, though: Emacs/GTK crashes
>     on both branches if a server connection is cut or a server crashes.  In
>     some use cases, this happens regularly, by design: e.g., if the user
>     runs emacsclient to create a frame on an ssh-forwarded remote X server,
>     then later logs out from the ssh session, the server connection is
>     closed, unintentionally SEGVing the Emacs process.  I think we should
>     document this in PROBLEMS.)
> 
> Yes, would someone please do so?
> 
> However, once the multi-tty branch handles this just as well as
> the current version, this issue is no longer an obstacle to merging in
> the multi-tty branch.

We alredy have a workaround in place (gtkutil.c):

   /* GTK 2.2-2.8 has a bug that makes gdk_display_close crash (bug
      http://bugzilla.gnome.org/show_bug.cgi?id=85715).  This way
      we can continue running, but there will be memory leaks.  */

#if GTK_MAJOR_VERSION == 2 && GTK_MINOR_VERSION < 10
   g_object_run_dispose (G_OBJECT (gdpy));
#else
   /* This seems to be fixed in GTK 2.10. */
   gdk_display_close (gdpy);
#endif


But I don't have all versions of Gtk+ in place, so if anybody can confirm that 
this does not work on some Gtk+ version, we can skip the g_object_run_dispose 
call also.

	Jan D.

Re: copyrights to be fixed

[Stefan Monnier]

> Known problems:
>         * GTK support.  If you compile your Emacs with the GTK

IIUC, this is a bug in GTK rather than in Emacs (or even in multi-tty).
Probably the bug can already be reproduced without the multi-tty code.

>         * The single-kboard mode.

This is a fundamental restriction in Emacs and is not new to multi-tty
(the same can already be seen when you use make-frame-on-display).

> 	* Mac, Windows and DOS support is broken, doesn't even compile.

So that's the only real open issue w.r.t. multi-tty.


        Stefan

Re: copyrights to be fixed

[Mark Plaksin]

Richard Stallman <rms@gnu.org> writes:

> How well does the multi-tty branch actually work?

multi-tty is awesome!  I've been using it for at least a year and can't
imagine life before it.  I have had essentially no problems with multi-tty
that did not also exist in CVS Emacs.

> Are there major gaps in the features?

As far as I can tell it only adds functionality.

Re: copyrights to be fixed

[Manoj Srivastava]

On Sat, 10 Feb 2007 12:40:15 -0500, Richard Stallman <rms@gnu.org> said: 

> How well does the multi-tty branch actually work?  Are there major
> gaps in the features?

        I have been using the multi-tty branch as my primary emacs for
 about 6 months now. It is routinely updated to the latest Emacs CVS.
 I often have long running IRC and Gnus sessions, and I have started
 to run emacs in a detached mode on my machine using screen; and then
 I use the gnuclient interface to open a local X frame, or a remote
 ssh tty frame, without losing context.

        I have not found anything I would consider major gaps in this
 feature. I would be very happy to test the merged unicode/multi-tty
 branch.

        manoj
-- 
Saint: A dead sinner revised and edited. Ambrose Bierce
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: copyrights to be fixed

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > How well does the multi-tty branch actually work?

I have used emacs from the multi-tty branch for at least 2 years
almost exclusively. I connect/disconnect X11 and tty frames to the
same emacs instance all the time. 

  > Are there major gaps in the features?

AFAIK the main missing thing is that the Windows and Mac ports
probably don't even compile, they have not been kept up to date with
the rest of the changes. It shouldn't be too hard for someone that
knows those platforms to fix this.

Re: copyrights to be fixed

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>   > How well does the multi-tty branch actually work?
>
> I have used emacs from the multi-tty branch for at least 2 years
> almost exclusively. I connect/disconnect X11 and tty frames to the
> same emacs instance all the time. 
>
>   > Are there major gaps in the features?
>
> AFAIK the main missing thing is that the Windows and Mac ports
> probably don't even compile, they have not been kept up to date with
> the rest of the changes. It shouldn't be too hard for someone that
> knows those platforms to fix this.

Well, from what Lőrentey wrote, it would seem like these architecture
problems are pretty much constrained to "simple changes" and most
likely constrained to few files.

Since the multi-tty branch currently has no really active maintainer
but is considered robust, it would probably be the safest strategy to
merge it first to HEAD, iron out the platform specific problems, only
_then_ merge the unicode branch.  In that way, the multi-tty branch
merge requires less work and its success can be estimated better on
the various platforms.  While this shifts a good part of the merge
load to the unicode branch merge, we have more expertise available
there.

Since the overlap between the branches should also be not too high, I
think that should be doable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Multi-tty merge plan (Re: copyrights to be fixed)

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 916 bytes --]

David Kastrup wrote:
> Since the multi-tty branch currently has no really active maintainer
> but is considered robust, it would probably be the safest strategy to
> merge it first to HEAD, iron out the platform specific problems, only
> _then_ merge the unicode branch.  In that way, the multi-tty branch
> merge requires less work and its success can be estimated better on
> the various platforms.  While this shifts a good part of the merge
> load to the unicode branch merge, we have more expertise available
> there.

I would be glad to help with whatever merge plan you come up with.
While I can't afford to actively maintain the multi-tty branch on a
daily basis, I would happily invest time and effort in the preparation
and execution of the merge.  After the merge, I am willing to help
fixing multi-tty bugs and to provide developer support for as long as
necessary.

-- 
Károly




[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: copyrights to be fixed

[Richard Stallman]

      > Are there major gaps in the features?

    AFAIK the main missing thing is that the Windows and Mac ports
    probably don't even compile, they have not been kept up to date with
    the rest of the changes. It shouldn't be too hard for someone that
    knows those platforms to fix this.

This is the sort of issue I was hoping to find out about.  There may
be other such gaps in places that the current users won't run across.
To install the multi-tty feature, we need to fill in the gaps.

Can someone please enter this in a special TODO in the multi-tty branch?

Multi-tty vs. non-Un*x ports (Re: copyrights to be fixed)

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 659 bytes --]

Richard Stallman wrote:
>     AFAIK the main missing thing is that the Windows and Mac ports
>     probably don't even compile, they have not been kept up to date with
>     the rest of the changes. It shouldn't be too hard for someone that
>     knows those platforms to fix this.
> 
> This is the sort of issue I was hoping to find out about.  There may
> be other such gaps in places that the current users won't run across.
> To install the multi-tty feature, we need to fill in the gaps.
> 
> Can someone please enter this in a special TODO in the multi-tty branch?

The porting issue is already explained in its TODO list.

-- 
Károly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty vs. non-Un*x ports (Re: copyrights to be fixed)

[Richard Stallman]

    > Can someone please enter this in a special TODO in the multi-tty branch=
    ?

    The porting issue is already explained in its TODO list.

I am glad that this has already been done.

Re: copyrights to be fixed

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 09 Feb 2007 08:13:51 +0100
> Cc: emacs-devel@gnu.org
> 
> In the mean time, no particular problems are addressed by snapping,
> sarcasm and bitterness.

Especially when those come from people who are not actively
participating in Emacs maintenance.