get rid of the MULTI_KBOARD #ifdefs

get rid of the MULTI_KBOARD #ifdefs

[Dan Nicolaescu]

src/config.in contains an unconditional #define for MULTI_KBOARD. 
The Windows port also defines it unconditionally in s/ms-w32.h
The Mac Carbon port is not functional anyway, but it ought to define
it too.

So I think we should get rid of all the #ifdef MULTI_KBOARD
conditionals and just leave the code for when MULTI_KBOARD is
defined, this will help reduce the cruft in the code base. 

RMS OKed this provided there no objections here...

Comments?

Re: get rid of the MULTI_KBOARD #ifdefs

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Tue, 25 Sep 2007 09:40:36 -0700
> 
> So I think we should get rid of all the #ifdef MULTI_KBOARD
> conditionals and just leave the code for when MULTI_KBOARD is
> defined, this will help reduce the cruft in the code base. 
> 
> RMS OKed this provided there no objections here...
> 
> Comments?

The MSDOS port doesn't support MULTI_KBOARD (and never will).

So if there's an alternative way of fixing this ugliness without
gratuitously breaking the DOS port, please use that alternative.

Re: get rid of the MULTI_KBOARD #ifdefs

[Jason Rumney]

Eli Zaretskii wrote:
> The MSDOS port doesn't support MULTI_KBOARD (and never will).
>   

It doesn't need to support multiple keyboards to use the MULTI_KBOARD
code path. The changes are fairly minor, and on DOS probably fairly
similar to the changes made on 2007-09-04 to support the MULTI_KBOARD
code path on Windows.

Re: get rid of the MULTI_KBOARD #ifdefs

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Tue, 25 Sep 2007 09:40:36 -0700
  > > 
  > > So I think we should get rid of all the #ifdef MULTI_KBOARD
  > > conditionals and just leave the code for when MULTI_KBOARD is
  > > defined, this will help reduce the cruft in the code base. 
  > > 
  > > RMS OKed this provided there no objections here...
  > > 
  > > Comments?
  > 
  > The MSDOS port doesn't support MULTI_KBOARD (and never will).

Have you made a decision yet if you still want to maintain the MSDOS
port?

  > So if there's an alternative way of fixing this ugliness without
  > gratuitously breaking the DOS port, please use that alternative.

AFAIK, now, the only big difference between MULTI_KBOARD and non
MULTI_KBOARD is that in one case there a global variable of type
struct kboard, and in the other case is malloced. So it seems to me
that even if the MSDOS is kept alive, it might be possible to make it
work in MULTI_KBOARD mode. But I don't have a good understanding about
this, so take this with a big grain of salt...

Re: get rid of the MULTI_KBOARD #ifdefs

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Tue, 25 Sep 2007 15:03:04 -0700
> 
>   > The MSDOS port doesn't support MULTI_KBOARD (and never will).
> 
> Have you made a decision yet if you still want to maintain the MSDOS
> port?

No matter what is my decision, I'm asking not to make my life harder
by adding more required work, if a reasonably simple and good
alternative exists.

Re: get rid of the MULTI_KBOARD #ifdefs

[Eli Zaretskii]

> Date: Tue, 25 Sep 2007 22:49:42 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Dan Nicolaescu <dann@ics.uci.edu>, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > The MSDOS port doesn't support MULTI_KBOARD (and never will).
> >   
> 
> It doesn't need to support multiple keyboards to use the MULTI_KBOARD
> code path. The changes are fairly minor, and on DOS probably fairly
> similar to the changes made on 2007-09-04 to support the MULTI_KBOARD
> code path on Windows.

If someone volunteers to make those changes and see that the result
builds and starts up, I don't mind.

Re: get rid of the MULTI_KBOARD #ifdefs

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: emacs-devel@gnu.org
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Tue, 25 Sep 2007 15:03:04 -0700
  > > 
  > >   > The MSDOS port doesn't support MULTI_KBOARD (and never will).
  > > 
  > > Have you made a decision yet if you still want to maintain the MSDOS
  > > port?
  > 
  > No matter what is my decision, I'm asking not to make my life harder
  > by adding more required work, if a reasonably simple and good
  > alternative exists.

This was intended to be simple minded cleanup, strictly deleting
code. Alternatives would just be busy work... 
So consider this issue dropped.

(BTW, I doubt the MSDOS port even compiles now, so trying to test it
after such a change implies getting it to work)