[multi-tty] Emacs port status

[multi-tty] Emacs port status

[Jason Rumney]

Thanks to some help from Dan Nicolaescu, I think we have reached a point
with the Windows port where I would be comfortable merging into the
trunk. There is still much to do - none of the extra functionality is
working, and -nw support is broken, but I don't think that is a
showstopper for Windows users. Some more testing while it is still on
the branch will be most welcome.

Maintainers of other ports may find it useful to look at the changelogs,
as the changes for other platforms will probably be similar.

Re: [multi-tty] Emacs port status

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Thanks to some help from Dan Nicolaescu, I think we have reached a
> point with the Windows port where I would be comfortable merging
> into the trunk.

That was pleasantly fast.  Of the other ports, probably the MSDOS port
will provide the most puzzlers.  Carbon hopefully would be simpler.

> There is still much to do - none of the extra functionality is
> working, and -nw support is broken, but I don't think that is a
> showstopper for Windows users. Some more testing while it is still
> on the branch will be most welcome.
>
> Maintainers of other ports may find it useful to look at the
> changelogs, as the changes for other platforms will probably be
> similar.

Personally, I'd find it best if we merged once we have more or less
agreed on the model we want to use: having the trunk as a reference
for less invasive variants (where changes in callers can be reverted
to their old state) might be more convenient than searching the branch
line.  However, this is not cast in stone.

One thing that I personally am concerned about is that it might be
difficult to reach a consensus about what kind of environment model we
should be using and documenting.  There have not actually been many
people involved in the discussion, but it is clear that there are
quite different standpoints from the user experience and the system
architecture point of view.

Resolving them will require either a long test phase with both options
available and people being able to try what fits them best, or a
decision by a responsible maintainer.  Or both: a decision after a
sufficient number of people have tested the behaviors.

Personally, I would prefer the least invasive solution people can come
up with (I tried sketching one myself) for the start of a test phase.
And then one has to see if people actually complain about it when
using them, or if people can feel at home with it well enough.  We
should really aim for the simplest and most logical solution that
still offers tolerable behavior and works with most existing code
(probably in that order of priorities).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [multi-tty] Emacs port status

[Károly Lo"rentey]

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

Jason Rumney wrote:
> Thanks to some help from Dan Nicolaescu, I think we have reached a point
> with the Windows port where I would be comfortable merging into the
> trunk. There is still much to do - none of the extra functionality is
> working, and -nw support is broken, but I don't think that is a
> showstopper for Windows users. Some more testing while it is still on
> the branch will be most welcome.

Thank you very much indeed!  That was incredibly fast work.

-- 
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] Emacs port status

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Thu, 17 May 2007 23:14:18 +0200
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> Jason Rumney <jasonr@gnu.org> writes:
> 
> > Thanks to some help from Dan Nicolaescu, I think we have reached a
> > point with the Windows port where I would be comfortable merging
> > into the trunk.
> 
> That was pleasantly fast.  Of the other ports, probably the MSDOS port
> will provide the most puzzlers.

I'm not sure I will continue the MSDOS support in Emacs 23.  It sounds
like Emacs 23 will be Unicode-based; if that is indeed so, it will be
most probably well beyond my resources to make all the Unicode-related
features work on MSDOS.

> One thing that I personally am concerned about is that it might be
> difficult to reach a consensus about what kind of environment model we
> should be using and documenting.  There have not actually been many
> people involved in the discussion, but it is clear that there are
> quite different standpoints from the user experience and the system
> architecture point of view.

One reason why _I_ wasn't part of the discussion is that I couldn't
find any place where the design principles of multi-tty are described
in sufficient detail for me to make up my mind about it.  Is there
such a document out there?  If not, could someone ``in the know'',
preferably Karoly himself, please describe the feature and its main
design principles?

Re: [multi-tty] Emacs port status

[Károly Lőrentey]

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

Eli Zaretskii wrote:
>> One thing that I personally am concerned about is that it might be
>> difficult to reach a consensus about what kind of environment model we
>> should be using and documenting.  There have not actually been many
>> people involved in the discussion, but it is clear that there are
>> quite different standpoints from the user experience and the system
>> architecture point of view.
> 
> One reason why _I_ wasn't part of the discussion is that I couldn't
> find any place where the design principles of multi-tty are described
> in sufficient detail for me to make up my mind about it.  Is there
> such a document out there?  If not, could someone ``in the know'',
> preferably Karoly himself, please describe the feature and its main
> design principles?

In terms of core Emacs features, the multi-tty branch adds the
capability to create frames on multiple tty devices at once (hence the
name).  It also adds support to simultaneously have X and tty frames in
the same Emacs session.

The tty support is such that different terminals may have different TERM
settings, character encodings, color depths and function key maps
applied to them.

X support is basically similar to what we have in the trunk; i.e., Emacs
can open frames on multiple X servers at once, and this works pretty
reliably.  One area of difference is that on the multi-tty branch, an X
server problem (such as an X server crash) will not necessarily bring
down the entire Emacs process: it will simply delete the broken
terminal. If other terminals remain, then Emacs will continue to work
after such a disconnect.

The original goal of the multi-tty project was to improve how
emacsclient works: I always felt it should open a new frame on
emacsclient's terminal by default.  This wasn't possible before when X
was not available on the emacsclient side, but in this case now Emacs
can simply open a frame on the local tty device.  Some things that
deserve mention about the new Emacsclient:

   1. Emacsclient opens a new frame by default.  It prefers X, but
      falls back to tty when necessary or when forced, just like Emacs
      itself.

   2. Frames are associated with the emacsclient session they were
      created in.  C-x 5 2 makes the new frame inherit the association
      as well.  When the user closes the last frame associated with a
      particular emacsclient session, emacsclient exits automatically,
      and vice versa.  C-x C-c is rebound to exit the client, not Emacs
      itself.

   3. When there is a tty frame open on emacsclient's controlling tty,
      you can send emacsclient into the background by pressing C-z.
      Emacs then suspends input/output to the tty device, and the
      emacsclient process stops itself, returning you to the shell
      prompt.   This works just like any standalone UNIX application
      would.  As a little no-cost extra feature, you can even create
      multiple emacsclient sessions running at the same time on the same
      terminal, and transparently switch between them by C-z and fg.

      More on the tty suspend feature: tty terminals can be suspended
      and resumed from Elisp.  Output is never sent to and input is
      never read from suspended terminals, but otherwise they keep their
      set of frames and windows configurations.  To resume output,
      suspended terminals must be explicitly resumed by another elisp
      call.  (This was something like a low-cost bonus feature that
      was very little work to implement, but considerably improves user
      experience.)

   4. Environment variable handling is currently in a state of flux;
      see the separate thread for that.

I think the best way to get a handle on the multi-tty branch is to
compile it and try out the new emacsclient.  It should be a convincing
emulation of a superfast little standalone editor, but with Emacs's
power, and built-in sharing of state between session.  Achieving this
was my primary goal, and I like how the results turned out very much.

-- 
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

[multi-tty] X or tty (was Re: Emacs port status)

[csant]

Some feedback as a *user* of this feature.  Please disregard if I am  
talking rubbish.

On Fri, 18 May 2007 21:09:12 +0200, Károly Lőrentey <karoly@lorentey.hu>  
wrote:

>    1. Emacsclient opens a new frame by default.  It prefers X, but
>       falls back to tty when necessary or when forced, just like Emacs
>       itself.

The simplest case is running server and client both in X, and expected  
behaviour would be for the client to prefer X.  Equally obvious would be  
the case where no X is available, and both the server and the client run  
in console.  I can easily see use cases for running the emacs server  
without X (in screen, or in console) and expect emacsclients to draw their  
frame on the X display they are invoked on.  I can a bit less easily  
imagine cases where you'd run the server in X, and clients on a display  
but wanting them to open the frame in terminal.  In my personal workflow I  
am running both the server and the clients on an X display *in terminal*  
(-nw and -t respectively).  It gets tedious to add a -t to each  
emacsclient call, and I'd wish for it to be `smarter' in understanding  
`what I mean'.

Ideally, I'd like the client to inherit by default any `forced' flags set  
to the server, i.e. to start by default with -t when the server was  
deliberately started -nw in an environment that does have $DISPLAY set.   
This could be overwritten in the client with -d .

Would that break more expected behaviours than fix some?
/c

Re: [multi-tty] X or tty

[David Kastrup]

csant <csant@csant.info> writes:

> On Fri, 18 May 2007 21:09:12 +0200, Károly Lőrentey
> <karoly@lorentey.hu>  wrote:
>
>>    1. Emacsclient opens a new frame by default.  It prefers X, but
>>       falls back to tty when necessary or when forced, just like Emacs
>>       itself.
>
> The simplest case is running server and client both in X, and
> expected behaviour would be for the client to prefer X.  Equally
> obvious would be the case where no X is available, and both the
> server and the client run in console.  I can easily see use cases
> for running the emacs server without X (in screen, or in console)
> and expect emacsclients to draw their frame on the X display they
> are invoked on.  I can a bit less easily imagine cases where you'd
> run the server in X, and clients on a display but wanting them to
> open the frame in terminal.

Funny.  For me it is just the other way round.  The normal case for me
is to run my emacs server in an X session.  Now if I am somewhere on
the road and want to access my Emacs session at home via a modem
connection or similar, I have quite limited bandwidth.  Even though
the ssh session I'll be using into my home computer forwards X
connections, I would not want to make use of it: it would be dead
slow.

> Ideally, I'd like the client to inherit by default any `forced'
> flags set to the server, i.e. to start by default with -t when the
> server was deliberately started -nw in an environment that does have
> $DISPLAY set.  This could be overwritten in the client with -d .
>
> Would that break more expected behaviours than fix some?

I think it would be unexpected.  If you have frequent particular uses,
I think it reasonable to use a shell script wrapper or shell alias or
environment variables for starting your favorite programs with your
favorite options.

Maybe emacsclient could read options from an environment variable
EMACSCLIENT_FLAGS (is that environment name acceptable under Windows?)
on startup, then you could set it there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [multi-tty] X or tty

[csant]

> Funny.  For me it is just the other way round.  The normal case for me
> is to run my emacs server in an X session.  Now if I am somewhere on
> the road and want to access my Emacs session at home via a modem
> connection or similar, I have quite limited bandwidth.  Even though
> the ssh session I'll be using into my home computer forwards X
> connections, I would not want to make use of it: it would be dead
> slow.

I am not completely sure that this is what you'd really have to expect.   
If you'd be ssh-ing without X forwarding, then this would be a no-brainer,  
but if you ssh with X forwarding, you probably are doing that... because  
you want to forward X?  Not wanting X to be forwarded for one application  
(the emacsclient) sounds more like a the exception that you could  
overwrite with an explicit -t .

>> Ideally, I'd like the client to inherit by default any `forced'
>> flags set to the server, i.e. to start by default with -t when the
>> server was deliberately started -nw in an environment that does have
>> $DISPLAY set.  This could be overwritten in the client with -d .

> I think it would be unexpected.

I am currently solving it with wrappers.  But I am not convinced that if I  
am forcing the `main' emacs instance (the server) into deliberately  
ignoring X, I do not want this to be `inherited' by the clients.  Right  
now it feels more, from the `dumb user's perspective, as  `hrmph - didn't  
I say --no-window-system?' each time the emacsclient starts with X.

/c

Re: [multi-tty] X or tty

[David Kastrup]

csant <csant@csant.info> writes:

>> Funny.  For me it is just the other way round.  The normal case for me
>> is to run my emacs server in an X session.  Now if I am somewhere on
>> the road and want to access my Emacs session at home via a modem
>> connection or similar, I have quite limited bandwidth.  Even though
>> the ssh session I'll be using into my home computer forwards X
>> connections, I would not want to make use of it: it would be dead
>> slow.
>
> I am not completely sure that this is what you'd really have to
> expect.  If you'd be ssh-ing without X forwarding, then this would
> be a no-brainer, but if you ssh with X forwarding, you probably are
> doing that... because you want to forward X?  Not wanting X to be
> forwarded for one application (the emacsclient) sounds more like a
> the exception that you could overwrite with an explicit -t .

No, there are applications like xdvi (started from within Emacs) which
just don't work without using X.  But Emacs still is useful without X.

>>> Ideally, I'd like the client to inherit by default any `forced'
>>> flags set to the server, i.e. to start by default with -t when the
>>> server was deliberately started -nw in an environment that does
>>> have $DISPLAY set.  This could be overwritten in the client with
>>> -d .
>
>> I think it would be unexpected.
>
> I am currently solving it with wrappers.  But I am not convinced
> that if I am forcing the `main' emacs instance (the server) into
> deliberately ignoring X, I do not want this to be `inherited' by the
> clients.  Right now it feels more, from the `dumb user's
> perspective, as `hrmph - didn't I say --no-window-system?' each time
> the emacsclient starts with X.

Maybe we should have emacs -nw still notice that it is running on an X
display and associate the -nw setting with _this_ display.  After all,
when we are running emacs -nw or emacsclient -t, we still may want to
have subprocesses inherit the original DISPLAY variable (which is
supposedly conjured from the actual terminal Emacs is running on).

But this would mean that a terminal was _both_ associated with a text
tty _and_ an X terminal screen.  I am not sure the complication would
be worth the win.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [multi-tty] Emacs port status

[Richard Stallman]

    I'm not sure I will continue the MSDOS support in Emacs 23.  It sounds
    like Emacs 23 will be Unicode-based; if that is indeed so, it will be
    most probably well beyond my resources to make all the Unicode-related
    features work on MSDOS.

Emacs 23 is probably at least a year away.  Is MSDOS still used
sufficiently to make it worth continuing to support?

Re: [multi-tty] Emacs port status

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: dak@gnu.org, emacs-devel@gnu.org
> Date: Sat, 19 May 2007 06:55:14 -0400
> 
>     I'm not sure I will continue the MSDOS support in Emacs 23.  It sounds
>     like Emacs 23 will be Unicode-based; if that is indeed so, it will be
>     most probably well beyond my resources to make all the Unicode-related
>     features work on MSDOS.
> 
> Emacs 23 is probably at least a year away.

My estimate is 3 years away, but I'd love to be wrong.

> Is MSDOS still used sufficiently to make it worth continuing to
> support?

I don't think it is used enough for people to want the latest and
greatest Emacs (which is why the prospect of letting it slowly bit-rot
doesn't bother me), but a year is enough time for people to holler if
I'm wrong.  I myself don't use the MSDOS port for at least 2 years,
except occasionally for a few minutes when I build a pretest of 22.1
and try a few commands, just to see that it doesn't crash.  And I
didn't see a bug report or a question about it for a long time.

Re: [multi-tty] Emacs port status

[Eli Zaretskii]

> Date: Fri, 18 May 2007 21:09:12 +0200
> From: =?UTF-8?B?S8Ohcm9seSBMxZFyZW50ZXk=?= <karoly@lorentey.hu>
> CC: David Kastrup <dak@gnu.org>,  emacs-devel@gnu.org
> 
> > One reason why _I_ wasn't part of the discussion is that I couldn't
> > find any place where the design principles of multi-tty are described
> > in sufficient detail for me to make up my mind about it.  Is there
> > such a document out there?  If not, could someone ``in the know'',
> > preferably Karoly himself, please describe the feature and its main
> > design principles?
> 
> In terms of core Emacs features, the multi-tty branch adds the
> capability to create frames on multiple tty devices at once (hence the
> name).  It also adds support to simultaneously have X and tty frames in
> the same Emacs session.
> [...]

Thanks for the explanations.

Now maybe a similarly concise description of the issues that were so
extensively argued about would help more people to speak their minds.
Judging by what you wrote, the issue doesn't sound like a very
important one, but I'm sure that I'm missing something.

Re: [multi-tty] Emacs port status

[Juanma Barranquero]

On 5/19/07, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Richard Stallman <rms@gnu.org>
> > Emacs 23 is probably at least a year away.
>
> My estimate is 3 years away, but I'd love to be wrong.

FWIW, we've crossed the half-year line just for the pretest of 22.1.

             Juanma

MacOS port functional too (was Re: [multi-tty] Emacs port status)

[Dan Nicolaescu]

The MacOS port is functional now. 
When compiling for X11 all the multi-tty functionality that is
available on other platform works as well. 

When compiling for the native Carbon toolkit it is possible to use
both terminal and Carbon frames simultaneously. 

Everything was only very lightly test as I run out of time, I have
done this work on a borrowed machine that I had to return. I am not
sure that I am going to have access to such a machine any time soon. 
(This is the first time ever that I compiled _any_ code on a Mac...)

Please take multi-tty for a spin on a Mac.

Re: [multi-tty] Emacs port status

[Richard Stallman]

I propose we announce, after the Emacs 22 release, the tentative plan
to desupport MSDOS.  Then we can see if anyone cares enough about it to
volunteer to maintain it.

Re: [multi-tty] Emacs port status

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I propose we announce, after the Emacs 22 release, the tentative
> plan to desupport MSDOS.  Then we can see if anyone cares enough
> about it to volunteer to maintain it.

Perhaps we should do it in the release announcement?  When listing the
supported operating systems, one could mention that MSDOS is
deprecated and this is the last version for it?

That way the announcement is pretty certain to catch the eye of
concerned people.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: MacOS port functional too

[David Kastrup]

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

> The MacOS port is functional now. 
> When compiling for X11 all the multi-tty functionality that is
> available on other platform works as well. 
>
> When compiling for the native Carbon toolkit it is possible to use
> both terminal and Carbon frames simultaneously. 
>
> Everything was only very lightly test as I run out of time, I have
> done this work on a borrowed machine that I had to return. I am not
> sure that I am going to have access to such a machine any time soon. 
> (This is the first time ever that I compiled _any_ code on a Mac...)
>
> Please take multi-tty for a spin on a Mac.

Are there other platforms we would need to get a basic hold on before
merging?  From what Eli has said, there seems to be little point in
going overboard keeping MSDOS functional in the trunk for now.  If
there is no sufficient impetus to keep it in our portfolio, it should
not prevent a merger.  While it is still not clear to me that it would
be a good idea to tackle the remaining architectural and usage issues
from the trunk, having the platform support showstopper out of the way
would at least be a good start.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [multi-tty] Emacs port status

[Kenichi Handa]

In article <uabw2uqnj.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure I will continue the MSDOS support in Emacs 23.  It sounds
> like Emacs 23 will be Unicode-based; if that is indeed so, it will be
> most probably well beyond my resources to make all the Unicode-related
> features work on MSDOS.

I don't think changing internal representation of characters
afects that much to MSDOS port.

---
Kenichi Handa
handa@m17n.org

Re: [multi-tty] X or tty (was Re: Emacs port status)

[Karoly Lorentey]

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

csant wrote:
> Ideally, I'd like the client to inherit by default any `forced' flags
> set to the server, i.e. to start by default with -t when the server was
> deliberately started -nw in an environment that does have $DISPLAY set. 
> This could be overwritten in the client with -d .

I can see your point, although I would personally find this behaviour a
little surprising.  For you, constantly typing "-t" clearly is a hassle.

A simple solution would be to implement an EMACSCLIENT_OPTIONS
environment variable, the value of which would be added to the
emacsclient command line automatically.  You would then be able to set
it to "-t", and get what you want.  "Old-school" emacsclient users would
set it to "-c".

EMACSCLIENT_OPTIONS would make the "--alternate-editor" option usable
without a wrapper script as well.

-- 
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] X or tty

[Károly Lőrentey]

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

David Kastrup wrote:
> Maybe emacsclient could read options from an environment variable
> EMACSCLIENT_FLAGS (is that environment name acceptable under Windows?)
> on startup, then you could set it there.

Ah, we think alike.   I don't see any drawback to having such a feature,
so I say we implement it.

-- 
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] Emacs port status

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: David Kastrup <dak@gnu.org>
  > > Date: Thu, 17 May 2007 23:14:18 +0200
  > > Cc: Emacs Devel <emacs-devel@gnu.org>
  > > 
  > > Jason Rumney <jasonr@gnu.org> writes:
  > > 
  > > > Thanks to some help from Dan Nicolaescu, I think we have reached a
  > > > point with the Windows port where I would be comfortable merging
  > > > into the trunk.
  > > 
  > > That was pleasantly fast.  Of the other ports, probably the MSDOS port
  > > will provide the most puzzlers.
  > 
  > I'm not sure I will continue the MSDOS support in Emacs 23.  It sounds
  > like Emacs 23 will be Unicode-based; if that is indeed so, it will be
  > most probably well beyond my resources to make all the Unicode-related
  > features work on MSDOS.

If you decide you want to still keep the MSDOS port, don't let
multi-tty deter you, a port is not hard to do.

Re: MacOS port functional too (was Re: [multi-tty] Emacs port status)

[Karoly Lorentey]

Dan Nicolaescu wrote:
> The MacOS port is functional now. 
> When compiling for X11 all the multi-tty functionality that is
> available on other platform works as well. 
> 
> When compiling for the native Carbon toolkit it is possible to use
> both terminal and Carbon frames simultaneously. 

Once again that was amazingly fast.  Great work, thank you!

-- 
Karoly

Re: [multi-tty] Emacs port status

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Sun, 20 May 2007 02:50:51 -0400
> 
> I propose we announce, after the Emacs 22 release, the tentative plan
> to desupport MSDOS.

Will do.

Re: [multi-tty] Emacs port status

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sun, 20 May 2007 09:35:21 +0200
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > I propose we announce, after the Emacs 22 release, the tentative
> > plan to desupport MSDOS.  Then we can see if anyone cares enough
> > about it to volunteer to maintain it.
> 
> Perhaps we should do it in the release announcement?

That too, but it isn't enough, I think: MSDOS users rarely read
info-gnu-emacs.

Re: MacOS port functional too

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 20 May 2007 11:26:23 +0200
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> From what Eli has said, there seems to be little point in
> going overboard keeping MSDOS functional in the trunk for now.

Yes, the MSDOS port should not be considered as a factor for this
decision.

Re: [multi-tty] Emacs port status

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: dak@gnu.org, emacs-devel@gnu.org
> Date: Sun, 20 May 2007 20:32:23 +0900
> 
> I don't think changing internal representation of characters
> afects that much to MSDOS port.

Maybe I'm just confused, but shouldn't the entire codepage.el
machinery be reworked from scratch (or else codepages.el should be
augmented with what they currently lack to support MSDOS)?

Also, the stuff in lisp/term/internal.el that deals with the DOS
display setup should be rewritten, right?

And the support in msdos.c for non-US keyboards should be revised,
shouldn't it?

And then, AFAIR, there are many files in the Unicode branch whose
names clash in the DOS 8+3 namespace (try doschk to see how many).
Fixing this is not rocket science, of course, but it's a lot of
nuisance, to say nothing of the uphill battle I sometimes need to
fight with people who don't want the original file names to be
changed.  Etc., etc. ...

Re: [multi-tty] Emacs port status

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sun, 20 May 2007 08:49:06 -0700
> 
> If you decide you want to still keep the MSDOS port, don't let
> multi-tty deter you, a port is not hard to do.

I'll certainly try when I have time, so if this is indeed easy, it
will be done.

Re: MacOS port functional too

[Jason Rumney]

David Kastrup wrote:
> Are there other platforms we would need to get a basic hold on before
> merging?

Did we drop vms support for Emacs 22, or did someone come forward to
support it?

That is the only other I can think of.

Re: [multi-tty] Emacs port status

[Richard Stallman]

    Perhaps we should do it in the release announcement?  When listing the
    supported operating systems, one could mention that MSDOS is
    deprecated and this is the last version for it?

Good idea.

vms for emacs [was: MacOS port functional too]

[Thien-Thi Nguyen]

() Jason Rumney <jasonr@gnu.org>
() Sun, 20 May 2007 21:38:01 +0100

   Did we drop vms support for Emacs 22, or did someone come forward to
   support it?

there was no official support for Emacs 21, and that situation has not
changed since then.  thus "drop" is not entirely correct although the
result is the same from user point of view.

personally, i'm currently talking w/ someone to set up a remote account
where i can do some work on vms support.  things move slowly, though.

ideally, i could install changes directly into cvs (on a branch), but
iirc from discussion w/ rms and the FSF copyright clerk, Richard Levitte
disclaimed changes only up through 1992 (and not "future changes").

so, either we separate post-1992 stuff and rewrite it (not fun), or we
ask him for assignment (i did a couple years back but the process has
stalled -- perhaps i missed something due to losing glug.org and other
misadventures).  i will ask him again.

to sum up, things may float side by side for a while (more) and drift
together in the future, but in the meantime i don't think we should
worry about vms support for Emacs (any version).

(cc trimmed.)

thi

Re: vms for emacs

[David Kastrup]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Jason Rumney <jasonr@gnu.org>
> () Sun, 20 May 2007 21:38:01 +0100
>
>    Did we drop vms support for Emacs 22, or did someone come forward to
>    support it?
>
> there was no official support for Emacs 21, and that situation has
> not changed since then.  thus "drop" is not entirely correct
> although the result is the same from user point of view.

So we basically have the situation where basically working code for
all platforms we want to see supported exists.

For merging, I think we would want to have the code in a state where
people have a clue about how to work on it in order to iron out
problems they are having.  So we need some sort of design description
fit for inclusion into the Elisp manual.

We can partly come up with it by diffing current branch and trunk, but
if Károly could give us a head start by writing out the principles,
APIs and details, this would certainly help.

In unitty Emacs, terminals and terminal-locality are very much hidden
away: you have to actually switch terminals (using select-frame?) in
order to access local variables from other terminals and similar.

Multitty Emacs makes those entities all accessible.  A description of
all the details of the API would certainly be desirable.  If we have a
good overview over who uses what when, it might be possible to make
some of the stuff more automatic and thus provide less user-visible
complexity.  It might also be infeasible to hide away any of the
existing accessors.

Having a good overview over the mechanisms will help deciding this in
the one or other way and will at the very least (even if we still
change things) make a good start for the final Elisp manual
documentation.  Some of the articles Károly posted could already make
material suitable for the Emacs user manual.

-- 
David Kastrup

Re: MacOS port functional too

[Richard Stallman]

The VMS code in Emacs has not really worked for a long time.  Someone
(Richard Levitte?) has done work on updating it, but it has not been
installed.

Re: vms for emacs

[jasonr]

Quoting David Kastrup <dak@gnu.org>:

> So we basically have the situation where basically working code for
> all platforms we want to see supported exists.

One important task left before merging is to extract the ChangeLogs from arch,
and somehow resolve RMS's desire to have full and accurate CVS logs.

Re: vms for emacs

[David Kastrup]

jasonr@f2s.com writes:

> Quoting David Kastrup <dak@gnu.org>:
>
>> So we basically have the situation where basically working code for
>> all platforms we want to see supported exists.
>
> One important task left before merging is to extract the ChangeLogs
> from arch, and somehow resolve RMS's desire to have full and
> accurate CVS logs.

Yes.  I was at the moment more concerned about the quality of the code
that people have to work with once it is in the trunk.

-- 
David Kastrup

Re: vms for emacs

[Miles Bader]

jasonr@f2s.com writes:
> One important task left before merging is to extract the ChangeLogs from arch,
> and somehow resolve RMS's desire to have full and accurate CVS logs.

Good luck with that...

-miles
-- 
97% of everything is grunge

Re: vms for emacs [was: MacOS port functional too]

[Chip Coldwell]

On Mon, 21 May 2007, Thien-Thi Nguyen wrote:

> () Jason Rumney <jasonr@gnu.org>
> () Sun, 20 May 2007 21:38:01 +0100
> 
>    Did we drop vms support for Emacs 22, or did someone come forward to
>    support it?
> 
> there was no official support for Emacs 21, and that situation has not
> changed since then.  thus "drop" is not entirely correct although the
> result is the same from user point of view.
> 
> personally, i'm currently talking w/ someone to set up a remote account
> where i can do some work on vms support.  things move slowly, though.

I'm currently maintaining the Xpdf port for VMS (OpenVMS/Alpha to be
precise):

http://frank.harvard.edu/~coldwell/vms/xpdf.html

I could have a crack at compiling Emacs-22.  It requires a lot of
infrastructure that isn't normally available on VMS, though (e.g. GNU
make, gcc, etc.).

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426

Re: vms for emacs [was: MacOS port functional too]

[dhruva]

Hi,

On 5/21/07, Chip Coldwell <coldwell@redhat.com> wrote:
> I could have a crack at compiling Emacs-22.  It requires a lot of
> infrastructure that isn't normally available on VMS, though (e.g. GNU
> make, gcc, etc.).

 The GNV kit has quite a good collection (look for the not yet
released bash which fixes some issues with '|'). I would not say that
it is close to make it build and run out of the box. I have personally
tried to build Samba and was quite close in getting a running binary,
As part of HP OpenVMS developer group (I am no longer working on
VMS/HP), we put in a whole lot of POSIX support complementing VMS CRTL
library. The current version of CRTL+ Hacks in Samba code + Some ports
of GNU tools by John Malmberg
(http://eisner.encompasserve.org/~malmberg/) could give a good base.

with best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: vms for emacs

[Richard Stallman]

    One important task left before merging is to extract the ChangeLogs from arch,
    and somehow resolve RMS's desire to have full and accurate CVS logs.

We decided that the way to do this was (1) simplify the change log
entries by hand, and (2) use a program to extract the relevant parts
for each one file at a time.

I think Karoly said he would do (1).  Would someone like to write that
program?