Re: multi-tty breakage on MS-Windows

Re: multi-tty breakage on MS-Windows

[Angelo Graziosi]

A stange coincidence.

I flag this for the sake of completeness.


Eli Zaretskii wrote:

> "emacs -nw" crashes on startup;

After these changes:

---------------------------------------------------------------------
2007-09-08  Fredrik Axelsson  <f.axelsson@gmail.com>

	* window.c (prefer_window_split_horizontally): New variable.
	(display_buffer): Consider splitting window horizontally depending
	on prefer_window_split_horizontally.

2007-09-08  Eli Zaretskii  <eliz@gnu.org>

	* sysdep.c [WINDOWSNT]: Don't include sysselect.h
--------------------------------------------------------------

this happens also on Cygwin BUT ONLY IF "emacs -nw" is started from the
DOS-like shell (cygwin.bat).

If it is started from an X shell it works fine ("emacs &" and "emacs
-nw").

The build I did after these changes (CVS cheched out less than 24 hours
ago):
------------------------------------------
2007-09-07  Stefan Monnier  <monnier@iro.umontreal.ca>

	* s/cygwin.h (GC_MARK_STACK): Enable conservative stack marking.

	* frame.c (x_set_frame_parameters): Check number is positive
before
	using XFASTINT.

	* window.c (freeze_window_start): Don't presume selected_window
holds
	a window object.
	(Fdisplay_buffer): Remove `register' since `buffer' needs to be
gcpro'd.
------------------------------------------

works fine from all shells (X, Dos-like).


Cheers,

   Angelo.

Re: multi-tty breakage on MS-Windows

[Angelo Graziosi]

As I described here

http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg00756.html

the changes to emacs/src/window.c and to emacs/lisp/cus-start.el
-------------------------------------
2007-09-08  Fredrik Axelsson  <f.axelsson@gmail.com>

	* cus-start.el (all): Add prefer-window-split-horizontally from
	window.c.
-------------------------------------

make Emacs-CVS to crash when started as "emacs -nw" from the Cygwin
Dos-like shell (cygwin.bat) but not from an X shell.

If one, after a fresh CVS check out, substitutes window.c and cus-start.el
with the previous version, Emacs works fine when started from all shells
(Dos-like, rxvt, urxvt, xterm). Also emacsclient works fine.

Since I read this

http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg00773.html,

should the changes to window.c and cus-start.el be reverted?

If not, we have to file an Emacs bug on Cygwin.


   Angelo.

multi-tty breakage on MS-Windows

[Eli Zaretskii]

I've just built the current CVS HEAD on MS-Windows, and immediately
saw two problems:

  . emacsclient is incompatible with Emacs 22.1's server: it causes
    Emacs 22.1 to spew all kinds of weirdo error messages; here are a
    few examples:

     File no longer exists: -env, write buffer to file? (y or n) 
     File no longer exists: -file, write buffer to file? (y or n) 
     File no longer exists: -dir, write buffer to file? (y or n) 
     Use M-x make-directory RET RET to create the directory and its parents [3 times]
     error in process filter: basic-save-buffer-2: d:/gnu/emacs/windir=C:/USERPROFILE=C:/Documents and Settings/TMPDIR=D:/usr/TMP=C:/DOCUME~1/Zaretzky/LOCALS~1/TEMP=C:/DOCUME~1/Zaretzky/LOCALS~1/SystemRoot=C:/: no such directory

    Is this incompatibility an absolute must?

  . "emacs -nw" crashes on startup; backtrace attached below.

 emacs.exe caused an Access Violation at location 01095c7c in module emacs.exe Reading from location 00000148.

 Registers:
 eax=00000000 ebx=00000003 ecx=01717a00 edx=00000001 esi=00000052 edi=00000000
 eip=01095c7c esp=0082e6d0 ebp=0082e798 iopl=0         nv up ei pl nz na pe nc
 cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

 Call stack:
 01095C7C  emacs.exe:01095C7C  update_frame_line  dispnew.c:5781
	 ...

	   tem = (nlen - nsp) - (olen - osp);
 >	  if (endmatch && tem
	       && (!FRAME_CHAR_INS_DEL_OK (f)
		   || endmatch <= char_ins_del_cost (f)[tem]))
	 ...

 010969DF  emacs.exe:010969DF  update_frame  dispnew.c:5286
	 ...
	   /* Update the individual lines as needed.  Do bottom line first.  */
	   if (MATRIX_ROW_ENABLED_P (desired_matrix, desired_matrix->nrows - 1))
 >	    update_frame_line (f, desired_matrix->nrows - 1);

	   /* Now update the rest of the lines.  */
	 ...

 0102F2BE  emacs.exe:0102F2BE  echo_area_display  xdisp.c:8770
	 ...
	     }
	   else
 >	    update_frame (f, 1, 1);

	   /* If cursor is in the echo area, make sure that the next
	 ...

 0102FAF1  emacs.exe:0102FAF1  message2_nolog  xdisp.c:7517
	 ...
	       do_pending_window_change (0);
	       echo_area_display (1);
 >	      do_pending_window_change (0);
	       if (FRAME_TERMINAL (f)->frame_up_to_date_hook != 0 && ! gc_in_progress)
	 (*FRAME_TERMINAL (f)->frame_up_to_date_hook) (f);
	 ...

 0102FBE0  emacs.exe:0102FBE0  message1_nolog  xdisp.c:7650
	 ...
	      char *m;
	 {
 >	  message2_nolog (m, (m ? strlen (m) : 0), 0);
	 }

	 ...

 01066102  emacs.exe:01066102  Fgarbage_collect  alloc.c:5156
	 ...

	   if (garbage_collection_messages)
 >	    message1_nolog ("Garbage collecting...");

	   BLOCK_INPUT;
	 ...

 0100B496  emacs.exe:0100B496  Feval  eval.c:2259
	 ...
	     {
	       GCPRO1 (form);
 >	      Fgarbage_collect ();
	       UNGCPRO;
	     }
	 ...

 010763C3  emacs.exe:010763C3  readevalloop  lread.c:1562
	 ...

	       /* Now eval what we just read.  */
 >	      val = (*evalfun) (val);

	       if (printflag)
	 ...

 01077090  emacs.exe:01077090  Fload  lread.c:1031
	 ...
	   readevalloop (Qget_file_char, stream, hist_file_name,
	 Feval, 0, Qnil, Qnil, Qnil, Qnil);
 >	  unbind_to (count, Qnil);

	   /* Run any eval-after-load forms for this file */
	 ...

 0100CC22  emacs.exe:0100CC22  do_autoload  eval.c:2208
	 ...

	   /* Save the old autoloads, in case we ever do an unload.  */
 >	  queue = Vautoload_queue;
	   while (CONSP (queue))
	     {
	 ...

 0100B3D7  emacs.exe:0100B3D7  Feval  eval.c:2290
	 ...

	   /* Optimize for no indirection.  */
 >	  fun = original_fun;
	   if (SYMBOLP (fun) && !EQ (fun, Qunbound)
	       && (fun = XSYMBOL (fun)->function, SYMBOLP (fun)))
	 ...

 010763C3  emacs.exe:010763C3  readevalloop  lread.c:1562
	 ...

	       /* Now eval what we just read.  */
 >	      val = (*evalfun) (val);

	       if (printflag)
	 ...

 01076A75  emacs.exe:01076A75  Feval_buffer  lread.c:1627
	 ...
	   readevalloop (buf, 0, filename, Feval,
	 !NILP (printflag), unibyte, Qnil, Qnil, Qnil);
 >	  unbind_to (count, Qnil);

	   return Qnil;
	 ...

 0100C233  emacs.exe:0100C233  Ffuncall  eval.c:3050
	 ...
	   goto done;
	 case 5:
 >	  val = (*XSUBR (fun)->function) (internal_args[0], internal_args[1],
	   internal_args[2], internal_args[3],
	   internal_args[4]);
	 ...

 01110643  emacs.exe:01110643  Fbyte_code  bytecode.c:679
	 ...
	       }
	 #endif
 >	    TOP = Ffuncall (op + 1, &TOP);
	     AFTER_POTENTIAL_GC ();
	     break;
	 ...

 0100BB87  emacs.exe:0100BB87  funcall_lambda  eval.c:3228
	 ...
	     }

 >	  return unbind_to (count, val);
	 }

	 ...

 0100C07C  emacs.exe:0100C07C  Ffuncall  eval.c:3105
	 ...
	  done:
	   CHECK_CONS_LIST ();
 >	  lisp_eval_depth--;
	   if (backtrace.debug_on_exit)
	     val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
	 ...

 0100C414  emacs.exe:0100C414  call4  eval.c:2892
	 ...
	   RETURN_UNGCPRO (Ffuncall (5, &fn));
	 #endif /* not NO_ARG_ARRAY */
 >	}

	 /* Call function fn with 5 arguments arg1, arg2, arg3, arg4, arg5 */
	 ...

 01077358  emacs.exe:01077358  Fload  lread.c:986
	 ...
		NILP (noerror) ? Qnil : Qt,
		NILP (nomessage) ? Qnil : Qt);
 >	  return unbind_to (count, val);
	 }
	     }
	 ...

 0100C233  emacs.exe:0100C233  Ffuncall  eval.c:3050
	 ...
	   goto done;
	 case 5:
 >	  val = (*XSUBR (fun)->function) (internal_args[0], internal_args[1],
	   internal_args[2], internal_args[3],
	   internal_args[4]);
	 ...

 01110643  emacs.exe:01110643  Fbyte_code  bytecode.c:679
	 ...
	       }
	 #endif
 >	    TOP = Ffuncall (op + 1, &TOP);
	     AFTER_POTENTIAL_GC ();
	     break;
	 ...

 0100BB87  emacs.exe:0100BB87  funcall_lambda  eval.c:3228
	 ...
	     }

 >	  return unbind_to (count, val);
	 }

	 ...

 0100C07C  emacs.exe:0100C07C  Ffuncall  eval.c:3105
	 ...
	  done:
	   CHECK_CONS_LIST ();
 >	  lisp_eval_depth--;
	   if (backtrace.debug_on_exit)
	     val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
	 ...

 01110643  emacs.exe:01110643  Fbyte_code  bytecode.c:679
	 ...
	       }
	 #endif
 >	    TOP = Ffuncall (op + 1, &TOP);
	     AFTER_POTENTIAL_GC ();
	     break;
	 ...

 0100B7AB  emacs.exe:0100B7AB  Feval  eval.c:2373
	 ...
	   goto done;
	 case 3:
 >	  val = (*XSUBR (fun)->function) (argvals[0], argvals[1],
	   argvals[2]);
	   goto done;
	 ...

 0100DAF4  emacs.exe:0100DAF4  internal_lisp_condition_case  eval.c:1437
	 ...
	   handlerlist = &h;

 >	  val = Feval (bodyform);
	   catchlist = c.next;
	   handlerlist = h.next;
	 ...

 01110C23  emacs.exe:01110C23  Fbyte_code  bytecode.c:869
	 ...
	     body = POP;
	     BEFORE_POTENTIAL_GC ();
 >	    TOP = internal_lisp_condition_case (TOP, body, handlers);
	     AFTER_POTENTIAL_GC ();
	     break;
	 ...

 0100BB87  emacs.exe:0100BB87  funcall_lambda  eval.c:3228
	 ...
	     }

 >	  return unbind_to (count, val);
	 }

	 ...

 0100C07C  emacs.exe:0100C07C  Ffuncall  eval.c:3105
	 ...
	  done:
	   CHECK_CONS_LIST ();
 >	  lisp_eval_depth--;
	   if (backtrace.debug_on_exit)
	     val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
	 ...

 01110643  emacs.exe:01110643  Fbyte_code  bytecode.c:679
	 ...
	       }
	 #endif
 >	    TOP = Ffuncall (op + 1, &TOP);
	     AFTER_POTENTIAL_GC ();
	     break;
	 ...

 0100BB87  emacs.exe:0100BB87  funcall_lambda  eval.c:3228
	 ...
	     }

 >	  return unbind_to (count, val);
	 }

	 ...

 0100BE04  emacs.exe:0100BE04  apply_lambda  eval.c:3147
	 ...
	     }
	   backtrace_list->evalargs = 0;
 >	  tem = funcall_lambda (fun, XINT (numargs), arg_vector);

	   /* Do the debug-on-exit now, while arg_vector still exists.  */
	 ...

 0100B4CC  emacs.exe:0100B4CC  Feval  eval.c:2434
	 ...
	   CHECK_CONS_LIST ();

 >	  lisp_eval_depth--;
	   if (backtrace.debug_on_exit)
	     val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
	 ...

 010512C1  emacs.exe:010512C1  top_level_2  keyboard.c:1415
	 ...
	 {
	   return Feval (Vtop_level);
 >	}

	 Lisp_Object
	 ...

 0100A3E5  emacs.exe:0100A3E5  internal_condition_case  eval.c:1495
	 ...

	   val = (*bfun) ();
 >	  catchlist = c.next;
	   handlerlist = h.next;
	   return val;
	 ...

 010512F3  emacs.exe:010512F3  top_level_1  keyboard.c:1427
	 ...
	   else
	     message ("Bare Emacs (standard Lisp code not loaded)");
 >	  return Qnil;
	 }

	 ...

 0100A31A  emacs.exe:0100A31A  internal_catch  eval.c:1229
	 ...
	   /* Call FUNC.  */
	   if (! _setjmp (c.jmp))
 >	    c.val = (*func) (arg);

	   /* Throw works by a longjmp that comes right here.  */
	 ...

 01051098  emacs.exe:01051098  command_loop  keyboard.c:1384
	 ...
		 any_kboard_state ();
	 #endif
 >	internal_catch (Qtop_level, command_loop_2, Qnil);
	 executing_kbd_macro = Qnil;

	 ...

 0105114A  emacs.exe:0105114A  recursive_edit_1  keyboard.c:994
	 ...

	   val = command_loop ();
 >	  if (EQ (val, Qt))
	     Fsignal (Qquit, Qnil);
	   /* Handle throw from read_minibuf when using minibuffer
	 ...

 0105126B  emacs.exe:0105126B  Frecursive_edit  keyboard.c:1056
	 ...

	   recursive_edit_1 ();
 >	  return unbind_to (count, Qnil);
	 }

	 ...

 010029C6  emacs.exe:010029C6  main  emacs.c:1781
	 ...
	   /* NOTREACHED */
	   return 0;
 >	}

	 /* Sort the args so we can find the most important ones
	 ...

 010011E7  emacs.exe:010011E7
 01001238  emacs.exe:01001238
 7C816D4F  kernel32.dll:7C816D4F  RegisterWaitForInputIdle

Re: multi-tty breakage on MS-Windows

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > I've just built the current CVS HEAD on MS-Windows, and immediately
  > saw two problems:
  > 
  >   . emacsclient is incompatible with Emacs 22.1's server: it causes
  >     Emacs 22.1 to spew all kinds of weirdo error messages; here are a
  >     few examples:
  > 
  >      File no longer exists: -env, write buffer to file? (y or n) 
  >      File no longer exists: -file, write buffer to file? (y or n) 
  >      File no longer exists: -dir, write buffer to file? (y or n) 
  >      Use M-x make-directory RET RET to create the directory and its parents [3 times]
  >      error in process filter: basic-save-buffer-2: d:/gnu/emacs/windir=C:/USERPROFILE=C:/Documents and Settings/TMPDIR=D:/usr/TMP=C:/DOCUME~1/Zaretzky/LOCALS~1/TEMP=C:/DOCUME~1/Zaretzky/LOCALS~1/SystemRoot=C:/: no such directory
  > 
  >     Is this incompatibility an absolute must?

I think so, the communication between the emacsclient and emacs is
more complex now, more stuff is sent over the wire.

  >   . "emacs -nw" crashes on startup; backtrace attached below.

This is a known problem, Jason Rumney stated that this does not work
in his message announcing that multi-tty was ported to Windows. 
Can you please help fixing it? 

Re: multi-tty breakage on MS-Windows

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sat, 08 Sep 2007 08:32:38 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   >     Is this incompatibility an absolute must?
> 
> I think so, the communication between the emacsclient and emacs is
> more complex now, more stuff is sent over the wire.

Too bad.  This will make life harder for those who, like me, routinely
run several different versions of Emacs (to test each one of them at
least to some extent).

>   >   . "emacs -nw" crashes on startup; backtrace attached below.
> 
> This is a known problem, Jason Rumney stated that this does not work
> in his message announcing that multi-tty was ported to Windows. 
> Can you please help fixing it? 

I will, if I find enough time.  This is made harder by almost complete
lack of documentation of how multi-tty works.  Can someone please make
an effort of explaining it in plain English?  The changes installed as
result of the merge are extensive and very invasive, and it's hard to
figure them out without some guidance.  Judging by the amount of
problems we had lately on any platform but GNU/Linux, I think we will
need much more working knowledge of this feature before we can go on
with merging unicode-2 etc.

Also, how come Karoly is suddenly silent or unavailable for help when
his work is being installed and used on platforms he obviously didn't
try?  It's annoying, to say the least: such a significant change
becomes almost completely unsupported the moment it's merged into the
trunk.

Re: multi-tty breakage on MS-Windows

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: emacs-devel@gnu.org
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Sat, 08 Sep 2007 08:32:38 -0700
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > 
  > >   >   . "emacs -nw" crashes on startup; backtrace attached below.
  > > 
  > > This is a known problem, Jason Rumney stated that this does not work
  > > in his message announcing that multi-tty was ported to Windows. 
  > > Can you please help fixing it? 
  > 
  > I will, if I find enough time.  This is made harder by almost complete
  > lack of documentation of how multi-tty works.  Can someone please make
  > an effort of explaining it in plain English?  

IHMO there's nobody beside the multi-tty author that understands the
design well enough to be able to write correct documentation... 

  > The changes installed as result of the merge are extensive and
  > very invasive, and it's hard to figure them out without some
  > guidance.  Judging by the amount of problems we had lately on any
  > platform but GNU/Linux, 

I have a different impression, things have not been bad at all. It
might be misleading that the same problems were reported over and over
followed by very long discussions.

Here's a summary of what I can remember right now:
Cygwin: 
 - 1 problem that was solved with a 2 line patch by people that (from
 the sound of it) didn't have much experience hacking  either emacs or
 cygwin. Pretty good in my book.

Mac:
  - 2 problems: 
    - bootstrap problem because of requiring 'url from
      term/mac-win.el. The fix is simple, but nobody has done it.
    - input is very slow
    Unfortunately nobody is willing to do any work on this platform,
    the plan seems to be to abandon this port and switch to a
    different toolkit (or whatever is called on a mac).
    Nobody has done any testing on this platform since multi-tty has
    been in CVS and until after the merge. 
    I am inclined to say that we should disable/or print a big warning
    when configuring this platform.

Windows: 
  - 2 problems:
    - -nw not working
    - Some issue with setting the invisible property in default-frame-alist
  Those were both known at the time the Windows port first worked on
  the multi-tty branch.

  > Also, how come Karoly is suddenly silent or unavailable for help when
  > his work is being installed 

Don't know, last I heard from him was about 2 months ago...

  > and used on platforms he obviously didn't try?

To his defense, this was documented as such.

Re: multi-tty breakage on MS-Windows

[martin rudalics]

 > I have a different impression, things have not been bad at all. It
 > might be misleading that the same problems were reported over and over
 > followed by very long discussions.

I think time has come to praise Dan for devoting so much of his time to
fix these problems.  This was and is a non-trivial endeavour.

Re: multi-tty breakage on MS-Windows

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > The really bad problem is that lots of functions (in xterm.c, for
  > instance) have no comments.  I don't know what they are supposed to
  > do.

There must be some confusion here that it would be good if you could
clarify: multi-tty only added 2 new functions to xterm.c. Only one of
which does not have comments: x_create_terminal. But I doubt there can
be any misunderstanding of what that function does. I added some
comments to it, I'll commit it soon.

Looking that the multi-tty diff for that file, most of the changes are
because of adding another level of indirection, and using some new
macros, not much new code added, and for the added code the comments
added seem on par with what was there before.

Or maybe you are referring to term.c, not xterm.c?
2 new functions there don't have much comments: set_tty_hooks and
clear_tty_hooks, but they are pretty simple: what used to be global
variables in term.c are now fields in struct terminal, those 2
functions set/reset those fields. I'll add some comments.

There's a boatload of functions in term.c that don't have much
comments, most of them are called tty_*. Maybe that is what you are
referring to? 
The multi-tty patch renamed a lot of those functions, to start with
"tty_", but it did not introduce them. Some of these functions have
been around for at least 16 years, so I don't think you'd want
multi-tty to document them. Anyway reverting the multi-tty patch as
you said in another message will not help with that.

Re: multi-tty breakage on MS-Windows

[dhruva]

Hi,

On 9/10/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> multi-tty to document them. Anyway reverting the multi-tty patch as
> you said in another message will not help with that.

IMHO, the best way forward is that someone with best knowledge of
multi-tty as on today actively involved (maybe Dan) make a short write
up on the files modified and some top level functions that need to be
explored in depth. If possible, platform specific functions that need
special attention or porting. This document could be just a seed at
first cut and can evolve as more developers find out during exploring
the code.
 Though I do not have any GUI/rendering related programming, I can
start exploring as a learning experience. What do people say for this
approach?
From a programmer's ego (I know should not be there), reverting the
multi-tty patch will send wrong signals about the abilities. It is
just a temporary phase of turbulence, we just need to sail past. I am
sure more complex issues were fixed. If nothing else, we will try to
disable parts which break the features on some platforms (ex: M$)
inside some MACRO and add the same in TODO. We can take a second sweep
and fix them. We will know the code better in the process.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: multi-tty breakage on MS-Windows

[Richard Stallman]

    There must be some confusion here that it would be good if you could
    clarify: multi-tty only added 2 new functions to xterm.c. Only one of
    which does not have comments: x_create_terminal. But I doubt there can
    be any misunderstanding of what that function does. I added some
    comments to it, I'll commit it soon.

There are a number of functions there which lack comments.  I came
across that one and others.  Maybe they are not new, but they are
problems.

Adding comments to these functions is a very important thing to do, so
thanks for working on it.

I wrote comments for two of these functions, a couple of days ago.
I installed them just now.

Re: multi-tty breakage on MS-Windows

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Also, how come Karoly is suddenly silent or unavailable for help when
 > his work is being installed and used on platforms he obviously didn't
 > try?

He did say he had a window when he would be available.  IIRC, it was
about 4-6 weeks long.  It appears the merge occurred after his window
ended, and obviously he is no longer readily available.

Re: multi-tty breakage on MS-Windows

[Richard Stallman]

Karoly should have documented the functions and features when he was
available.  Also, people should not have said that this branch was
ready for installation while its doc was incomplete.  However, that's
the past.

For now, we either have to revert those changes or figure them out and
document them.  It would be a shame to revert them, but it is simply
impossible to go ahead with them undocumented.

So if you don't want the multi-tty code taken out, start studying the code
and commenting all the new functions, and writing up the new features
for etc/NEWS.

Re: multi-tty breakage on MS-Windows

[Eli Zaretskii]

> Date: Sat, 08 Sep 2007 19:29:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> >   >   . "emacs -nw" crashes on startup; backtrace attached below.
> > 
> > This is a known problem, Jason Rumney stated that this does not work
> > in his message announcing that multi-tty was ported to Windows. 
> > Can you please help fixing it? 
> 
> I will, if I find enough time.

I fixed a few problems, and now "emacs -nw" starts on Windows.  Please
test.

Some problems that are still to be fixed, before "emacs -nw" can be
considered operable on Windows:

  o Colors don't work.  Details:

     . Emacs knows it has 16 colors, but draws only white on black and
       reverse video.  (Try "M-x list-colors-display".)

     . Mode line and menu bar are not in reverse video, as they should
       be.

     . Under a debugger, each face returns the value 7 (white on
       black) as character attribute from w32_face_attributes.

  o Ctrl-C keystrokes are swallowed and don't get to Emacs input
    queue.  For example, "C-x C-c" will not kill Emacs.

  o The screen buffer dimensions are not restored by Emacs when it
    exits.  You will see that the scroll bar of the DOS box is not
    restored, for example.  (Use the Properties of the DOS box to
    restore manually.)

After these problems are solved, I think we need to decide whether it
makes sense to use several tty's on Windows.  I know that one use case
for the multi-tty Emacs on Posix platforms is to connect to the same
Emacs session remotely; I think this use case doesn't make much sense
on MS-Windows (but if I'm wrong, please correct me).  Are there other
use cases? if so, what are they?

If we find legitimate use cases for multi-tty on MS-Windows, more
coding will be needed to provide the Windows equivalents of opening
a non-default tty device, emulate suspension, etc.

Re: multi-tty breakage on MS-Windows

[Jason Rumney]

Eli Zaretskii wrote:
> After these problems are solved, I think we need to decide whether it
> makes sense to use several tty's on Windows.
If that is even possible, I don't think it is.

Re: multi-tty breakage on MS-Windows

[Eli Zaretskii]

> Date: Sat, 22 Sep 2007 22:16:27 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > After these problems are solved, I think we need to decide whether it
> > makes sense to use several tty's on Windows.
> If that is even possible, I don't think it is.

Well, we could allocate several consoles and switch between them, I
think.

But as I wrote, I don't think this will be useful.

Re: multi-tty breakage on MS-Windows

[Jason Rumney]

Eli Zaretskii wrote:
>> Date: Sat, 22 Sep 2007 22:16:27 +0100
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> Eli Zaretskii wrote:
>>     
>>> After these problems are solved, I think we need to decide whether it
>>> makes sense to use several tty's on Windows.
>>>       
>> If that is even possible, I don't think it is.
>>     
>
> Well, we could allocate several consoles and switch between them, I
> think.
>   
I looked into this, and only one console can be opened at a time. We
might be able to close and reopen consoles, which might be a good
implementation of suspend/resume, but if the user can see both consoles,
they might not expect that.

Re: multi-tty breakage on MS-Windows

[dhruva]

Hi,

On 9/23/07, Jason Rumney <jasonr@gnu.org> wrote:
> might be able to close and reopen consoles, which might be a good
> implementation of suspend/resume, but if the user can see both consoles,

Another (not tried out) approach for suspend/resume:

For suspend: Walk through all the threads in the running emacs process
and suspend each thread.
For resume: Need a separate process to create a remote thread in emacs
process (CreateRemoteThread API) and that thread can resume all other
threads in Emacs.

Is it feasible or useful?

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: multi-tty breakage on MS-Windows

[Jason Rumney]

dhruva wrote:
> Another (not tried out) approach for suspend/resume:
>
> For suspend: Walk through all the threads in the running emacs process
> and suspend each thread.
>   
We are talking about C-z functionality here, which is not the same as
suspending threads. The main purpose is to use the console for something
else, so Emacs must reliquish the console.

Re: multi-tty breakage on MS-Windows

[Jason Rumney]

Eli Zaretskii wrote:
> Some problems that are still to be fixed, before "emacs -nw" can be
> considered operable on Windows:
>   
>   o Ctrl-C keystrokes are swallowed and don't get to Emacs input
>     queue.  For example, "C-x C-c" will not kill Emacs.
>   
This was due to terminal->set_terminal_modes_hook not being called.

>   o The screen buffer dimensions are not restored by Emacs when it
>     exits.  You will see that the scroll bar of the DOS box is not
>     restored, for example.  (Use the Properties of the DOS box to
>     restore manually.)
>   
I think this was due to terminal->reset_terminal_modes_hook not being
called, but my scrollbars do not change when Emacs starts, so I don't
know know for sure.

Re: multi-tty breakage on MS-Windows

[Eli Zaretskii]

> Date: Tue, 25 Sep 2007 10:01:05 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > Some problems that are still to be fixed, before "emacs -nw" can be
> > considered operable on Windows:
> >   
> >   o Ctrl-C keystrokes are swallowed and don't get to Emacs input
> >     queue.  For example, "C-x C-c" will not kill Emacs.
> >   
> This was due to terminal->set_terminal_modes_hook not being called.
> 
> >   o The screen buffer dimensions are not restored by Emacs when it
> >     exits.  You will see that the scroll bar of the DOS box is not
> >     restored, for example.  (Use the Properties of the DOS box to
> >     restore manually.)
> >   
> I think this was due to terminal->reset_terminal_modes_hook not being
> called, but my scrollbars do not change when Emacs starts, so I don't
> know know for sure.

Yes, these two problems are now fixed, thanks.

The problem with colors is still there.

Re: multi-tty breakage on MS-Windows

[Stefan Monnier]

> I think so, the communication between the emacsclient and emacs is
> more complex now, more stuff is sent over the wire.

AFAICT we could very well make it backward compatible.
The first thing to do for that is to change the "-c" argument of emacsclient
so that by default it "behaves as before".  Then we can make sure that when
it "behaves as before" it sends the same data to the server.


        Stefan

Re: multi-tty breakage on MS-Windows

[David Kastrup]

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

>> I think so, the communication between the emacsclient and emacs is
>> more complex now, more stuff is sent over the wire.
>
> AFAICT we could very well make it backward compatible.
> The first thing to do for that is to change the "-c" argument of emacsclient
> so that by default it "behaves as before".  Then we can make sure that when
> it "behaves as before" it sends the same data to the server.

Where is the point of having an emacsclient not matching the emacs
version one is using?  At least as long as we are only talking about
local connections.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: multi-tty breakage on MS-Windows

[Eli Zaretskii]

> Cc: Dan Nicolaescu <dann@ics.uci.edu>,  Eli Zaretskii <eliz@gnu.org>,
> 	  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sun, 09 Sep 2007 22:03:59 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> I think so, the communication between the emacsclient and emacs is
> >> more complex now, more stuff is sent over the wire.
> >
> > AFAICT we could very well make it backward compatible.
> > The first thing to do for that is to change the "-c" argument of emacsclient
> > so that by default it "behaves as before".  Then we can make sure that when
> > it "behaves as before" it sends the same data to the server.
> 
> Where is the point of having an emacsclient not matching the emacs
> version one is using?

I explained when this is incompatibility is an annoyance: when you
use several different versions of Emacs at once.  In that case, it
might well happen that the Emacs that is running the server is
incompatible with emacsclient that's invoked by some application that
calls $EDITOR.