* today's git does not run on Ubuntu
@ 2013-12-15 13:56 Susan Cragin
2013-12-15 15:20 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Susan Cragin @ 2013-12-15 13:56 UTC (permalink / raw)
To: EMACS development team
Hello,
I updated my emacs git today, which compiled seemingly without errors, but does not run. The program opens and freezes immediately.
I have an unmodified Ubuntu Trusty 64-bit system, and have been compiling emacs for a couple of years without problems. I have all dependencies.
Nothing pops up in the terminal window.
Susan Cragin
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: today's git does not run on Ubuntu
2013-12-15 13:56 today's git does not run on Ubuntu Susan Cragin
@ 2013-12-15 15:20 ` Juanma Barranquero
2013-12-15 16:36 ` Eli Zaretskii
2013-12-15 19:48 ` Desktop tty frames (was: today's git does not run on Ubuntu) Juri Linkov
0 siblings, 2 replies; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-15 15:20 UTC (permalink / raw)
To: Susan Cragin; +Cc: Paul Eggert, EMACS development team
On Sun, Dec 15, 2013 at 2:56 PM, Susan Cragin <susancragin@earthlink.net> wrote:
> I updated my emacs git today, which compiled seemingly without errors, but does not run. The program opens and freezes immediately.
I see the same thing on Windows: "emacs -Q" freezes, "emacs -Q -nw" does not.
It seems a consequence of Paul's latest patches (revno:115529, revno:115532).
Breaking with Ctrl-C gives this backtrace:
Quit (expect signal SIGINT when the program is resumed)
(gdb) thread 1
[Switching to thread 1 (Thread 10728.0x16b8)]
#0 0x01204269 in w32_frame_up_to_date (f=0x3a9d360
<__register_frame_info+61461344>) at w32term.c:730
730 FRAME_MOUSE_UPDATE (f);
(gdb) bt
#0 0x01204269 in w32_frame_up_to_date (f=0x3a9d360
<__register_frame_info+61461344>) at w32term.c:730
#1 0x0103b3a2 in message3_nolog (m=61864465) at xdisp.c:9992
#2 0x0103b08c in message3 (m=61864465) at xdisp.c:9931
#3 0x01172af6 in Fmessage (nargs=2, args=0x88eb08) at editfns.c:3452
#4 0x0117f07f in Ffuncall (nargs=3, args=0x88eb04) at eval.c:2786
#5 0x011bf97c in exec_byte_code (bytestr=19642409, vector=19642429,
maxdepth=24, args_template=0, nargs=0, args=0x88ee3c) at
bytecode.c:919
#6 0x0117f971 in funcall_lambda (fun=19642389, nargs=0,
arg_vector=0x88ee3c) at eval.c:2973
#7 0x0117f3cb in Ffuncall (nargs=1, args=0x88ee38) at eval.c:2854
#8 0x011bf97c in exec_byte_code (bytestr=19642961, vector=19642981,
maxdepth=92, args_template=1028, nargs=1, args=0x88f1ac) at
bytecode.c:919
#9 0x0117f971 in funcall_lambda (fun=19642941, nargs=1,
arg_vector=0x88f1a8) at eval.c:2973
#10 0x0117f3cb in Ffuncall (nargs=2, args=0x88f1a4) at eval.c:2854
#11 0x011bf97c in exec_byte_code (bytestr=19630113, vector=19630133,
maxdepth=68, args_template=0, nargs=0, args=0x88f50c) at
bytecode.c:919
#12 0x0117f971 in funcall_lambda (fun=19630093, nargs=0,
arg_vector=0x88f50c) at eval.c:2973
#13 0x0117f3cb in Ffuncall (nargs=1, args=0x88f508) at eval.c:2854
#14 0x011bf97c in exec_byte_code (bytestr=19628321, vector=19628341,
maxdepth=48, args_template=0, nargs=0, args=0x88f7c0) at
bytecode.c:919
#15 0x0117f971 in funcall_lambda (fun=19628301, nargs=0,
arg_vector=0x88f7c0) at eval.c:2973
#16 0x0117f690 in apply_lambda (fun=19628301, args=58132514) at eval.c:2914
#17 0x0117e06e in eval_sub (form=59864350) at eval.c:2220
#18 0x0117d68e in Feval (form=59864350, lexical=58132514) at eval.c:1993
#19 0x010f262d in top_level_2 () at keyboard.c:1179
#20 0x0117c075 in internal_condition_case (bfun=0x10f2610
<top_level_2>, handlers=58183970, hfun=0x10f21ab <cmd_error>) at
eval.c:1344
#21 0x010f2661 in top_level_1 (ignore=58132514) at keyboard.c:1187
#22 0x0117b622 in internal_catch (tag=58179330, func=0x10f262f
<top_level_1>, arg=58132514) at eval.c:1108
#23 0x010f2593 in command_loop () at keyboard.c:1148
#24 0x010f1d48 in recursive_edit_1 () at keyboard.c:777
#25 0x010f1f04 in Frecursive_edit () at keyboard.c:841
#26 0x010f0108 in main (argc=2, argv=0xab1b50) at emacs.c:1634
Lisp Backtrace:
"message" (0x88eb08)
warning: SuspendThread failed. (winerr 5)
warning: SuspendThread failed. (winerr 5)
PC register is not available
(gdb)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: today's git does not run on Ubuntu
2013-12-15 15:20 ` Juanma Barranquero
@ 2013-12-15 16:36 ` Eli Zaretskii
2013-12-15 17:02 ` Paul Eggert
2013-12-15 19:48 ` Desktop tty frames (was: today's git does not run on Ubuntu) Juri Linkov
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-12-15 16:36 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: eggert, susancragin, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 15 Dec 2013 16:20:18 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>,
> EMACS development team <emacs-devel@gnu.org>
>
> On Sun, Dec 15, 2013 at 2:56 PM, Susan Cragin <susancragin@earthlink.net> wrote:
>
> > I updated my emacs git today, which compiled seemingly without errors, but does not run. The program opens and freezes immediately.
>
> I see the same thing on Windows: "emacs -Q" freezes, "emacs -Q -nw" does not.
>
> It seems a consequence of Paul's latest patches (revno:115529, revno:115532).
Please try again. It's amazing what one incorrect "true" can do.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: today's git does not run on Ubuntu
@ 2013-12-15 16:44 Susan Cragin
0 siblings, 0 replies; 21+ messages in thread
From: Susan Cragin @ 2013-12-15 16:44 UTC (permalink / raw)
To: Eli Zaretskii, Juanma Barranquero; +Cc: eggert, susancragin, emacs-devel
>Please try again. It's amazing what one incorrect "true" can do.
Works for me!
Thanks!
Susan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: today's git does not run on Ubuntu
2013-12-15 16:36 ` Eli Zaretskii
@ 2013-12-15 17:02 ` Paul Eggert
0 siblings, 0 replies; 21+ messages in thread
From: Paul Eggert @ 2013-12-15 17:02 UTC (permalink / raw)
To: Eli Zaretskii, Juanma Barranquero; +Cc: susancragin, emacs-devel
Eli Zaretskii wrote:
> It's amazing what one incorrect "true" can do.
Yeowch. Thanks for fixing that. I looked for further
errors of that form, and didn't find any.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Desktop tty frames (was: today's git does not run on Ubuntu)
2013-12-15 15:20 ` Juanma Barranquero
2013-12-15 16:36 ` Eli Zaretskii
@ 2013-12-15 19:48 ` Juri Linkov
2013-12-15 20:13 ` Juanma Barranquero
1 sibling, 1 reply; 21+ messages in thread
From: Juri Linkov @ 2013-12-15 19:48 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: EMACS development team
> I see the same thing on Windows: "emacs -Q" freezes, "emacs -Q -nw" does not.
When I tried "emacs -nw" in this revision, it loads the saved desktop,
creates a new graphical frame and freezes. This raises the question:
shouldn't the desktop open the saved frame as a tty frame when the desktop
is restored by "emacs -nw"?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames (was: today's git does not run on Ubuntu)
2013-12-15 19:48 ` Desktop tty frames (was: today's git does not run on Ubuntu) Juri Linkov
@ 2013-12-15 20:13 ` Juanma Barranquero
2013-12-15 20:52 ` Juanma Barranquero
2013-12-15 21:47 ` Desktop tty frames (was: today's git does not run on Ubuntu) Drew Adams
0 siblings, 2 replies; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-15 20:13 UTC (permalink / raw)
To: Juri Linkov; +Cc: EMACS development team
On Sun, Dec 15, 2013 at 8:48 PM, Juri Linkov <juri@jurta.org> wrote:
> This raises the question:
> shouldn't the desktop open the saved frame as a tty frame when the desktop
> is restored by "emacs -nw"?
That is a good question. In general, the frameset stuff tries to
restore the frames as they were (though there are options to tweak
this) because on POSIX systems Emacs can have tty and GUI frames at
once.
So I suppose the answer is:
- do we want to default to non-GUI frames on POSIX -nw runs? If so, do
we force them to tty frames or ignore them?
- do we want to select this behavior through and option?
- some other idea?
J
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames (was: today's git does not run on Ubuntu)
2013-12-15 20:13 ` Juanma Barranquero
@ 2013-12-15 20:52 ` Juanma Barranquero
2013-12-15 21:14 ` Desktop tty frames Juri Linkov
2013-12-15 21:47 ` Desktop tty frames (was: today's git does not run on Ubuntu) Drew Adams
1 sibling, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-15 20:52 UTC (permalink / raw)
To: Juri Linkov; +Cc: EMACS development team
On Sun, Dec 15, 2013 at 9:13 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> This raises the question:
>> shouldn't the desktop open the saved frame as a tty frame when the desktop
>> is restored by "emacs -nw"?
Anyway, note that the desktop only loads in non -q/Q runs, in which
case the user can set desktop-restore-in-current-display to t or
`delete' according to the window-system or whatever they want. So not
sure that something needs to be fixed; but I'm open to be told
otherwise.
J
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-15 20:52 ` Juanma Barranquero
@ 2013-12-15 21:14 ` Juri Linkov
2013-12-15 21:52 ` Drew Adams
0 siblings, 1 reply; 21+ messages in thread
From: Juri Linkov @ 2013-12-15 21:14 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: EMACS development team
> Anyway, note that the desktop only loads in non -q/Q runs, in which
> case the user can set desktop-restore-in-current-display to t or
> `delete' according to the window-system or whatever they want. So not
> sure that something needs to be fixed; but I'm open to be told
> otherwise.
Thanks, desktop-restore-in-current-display=t indeed helps in this situation.
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Desktop tty frames (was: today's git does not run on Ubuntu)
2013-12-15 20:13 ` Juanma Barranquero
2013-12-15 20:52 ` Juanma Barranquero
@ 2013-12-15 21:47 ` Drew Adams
2013-12-15 21:52 ` Juanma Barranquero
1 sibling, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-12-15 21:47 UTC (permalink / raw)
To: Juanma Barranquero, Juri Linkov; +Cc: EMACS development team
> So I suppose the answer is:
> - do we want to default to non-GUI frames on POSIX -nw runs? If so, do
> we force them to tty frames or ignore them?
> - do we want to select this behavior through and option?
> - some other idea?
It sounds to me like a user might prefer either respecting what was
recorded or limiting to non-GUI (on -nw). So I'd guess that the
choice should be up to users, as an option.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames (was: today's git does not run on Ubuntu)
2013-12-15 21:47 ` Desktop tty frames (was: today's git does not run on Ubuntu) Drew Adams
@ 2013-12-15 21:52 ` Juanma Barranquero
0 siblings, 0 replies; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-15 21:52 UTC (permalink / raw)
To: Drew Adams; +Cc: Juri Linkov, EMACS development team
On Sun, Dec 15, 2013 at 10:47 PM, Drew Adams <drew.adams@oracle.com> wrote:
> It sounds to me like a user might prefer either respecting what was
> recorded or limiting to non-GUI (on -nw). So I'd guess that the
> choice should be up to users, as an option.
It already is, through desktop-restore-in-current-display. The
question is whether the default should be changed. I suppose testing
will tell us.
J
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Desktop tty frames
2013-12-15 21:14 ` Desktop tty frames Juri Linkov
@ 2013-12-15 21:52 ` Drew Adams
2013-12-15 21:56 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-12-15 21:52 UTC (permalink / raw)
To: Juri Linkov, Juanma Barranquero; +Cc: EMACS development team
> > Anyway, note that the desktop only loads in non -q/Q runs, in which
> > case the user can set desktop-restore-in-current-display to t or
> > `delete' according to the window-system or whatever they want. So not
> > sure that something needs to be fixed; but I'm open to be told
> > otherwise.
>
> Thanks, desktop-restore-in-current-display=t indeed helps in this situation.
I see. So we already have the relevant option. In that case, I'm
confused why the question was raised as to whether we need an option
for this.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-15 21:52 ` Drew Adams
@ 2013-12-15 21:56 ` Juanma Barranquero
2013-12-15 22:27 ` Drew Adams
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-15 21:56 UTC (permalink / raw)
To: Drew Adams; +Cc: Juri Linkov, EMACS development team
On Sun, Dec 15, 2013 at 10:52 PM, Drew Adams <drew.adams@oracle.com> wrote:
> I see. So we already have the relevant option. In that case, I'm
> confused why the question was raised as to whether we need an option
> for this.
Neither Juri nor I remembered the option existed ;-)
J
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Desktop tty frames
2013-12-15 21:56 ` Juanma Barranquero
@ 2013-12-15 22:27 ` Drew Adams
2013-12-15 22:31 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-12-15 22:27 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Juri Linkov, EMACS development team
> > I see. So we already have the relevant option. In that case, I'm
> > confused why the question was raised as to whether we need an option
> > for this.
>
> Neither Juri nor I remembered the option existed ;-)
;-) I wondered about that, and can certainly relate to it.
If this -nw vs GUI thing is an important use case for the option,
perhaps its doc should mention it. As in, "In particular,..." or
"For example,..." (Not sure what the default value should be, BTW.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-15 22:27 ` Drew Adams
@ 2013-12-15 22:31 ` Juanma Barranquero
2013-12-16 0:27 ` Stephen J. Turnbull
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-15 22:31 UTC (permalink / raw)
To: Drew Adams; +Cc: Juri Linkov, EMACS development team
On Sun, Dec 15, 2013 at 11:27 PM, Drew Adams <drew.adams@oracle.com> wrote:
> If this -nw vs GUI thing is an important use case for the option,
> perhaps its doc should mention it. As in, "In particular,..." or
> "For example,..."
I don't think it is a more important use case than restoring in
multiple X displays or all in one, which was the original use case (as
suggested by Stefan, IIRC).
But if you propose a way to make the docstring clearer, I'll commit
it, no-questions-asked'ly fast.
> (Not sure what the default value should be, BTW.)
The current default is to restore every frame in its original display,
which seems pretty sane to me.
J
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-15 22:31 ` Juanma Barranquero
@ 2013-12-16 0:27 ` Stephen J. Turnbull
2013-12-16 12:37 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Stephen J. Turnbull @ 2013-12-16 0:27 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Juri Linkov, Drew Adams, EMACS development team
Juanma Barranquero writes:
> On Sun, Dec 15, 2013 at 11:27 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> > If this -nw vs GUI thing is an important use case for the option,
> > perhaps its doc should mention it. As in, "In particular,..." or
> > "For example,..."
>
> But if you propose a way to make the docstring clearer, I'll commit
> it, no-questions-asked'ly fast.
Huh, I think you answered the question Drew asked. But I think the
place to mention this is in the doc for "-nw"!
> > (Not sure what the default value should be, BTW.)
>
> The current default is to restore every frame in its original display,
> which seems pretty sane to me.
To me, that does make sense for local Xinerama (multimonitor) setups.
But I don't see how this can be done reliably for remote X frames,
where the names of displays can change in arbitrary ways in different
runs, and typically do. Inquiring minds want to know: Did you find a
way?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-16 0:27 ` Stephen J. Turnbull
@ 2013-12-16 12:37 ` Juanma Barranquero
2013-12-16 14:55 ` Stephen J. Turnbull
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-16 12:37 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: Juri Linkov, Drew Adams, EMACS development team
On Mon, Dec 16, 2013 at 1:27 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> But I don't see how this can be done reliably for remote X frames,
> where the names of displays can change in arbitrary ways in different
> runs, and typically do. Inquiring minds want to know: Did you find a
> way?
How could I? When saving the frames, the only data connecting them
with their display is a string, the contents of the `display'
property. When restoring, I have to trust that it still makes sense.
If it doesn't, the user can customize desktop not to do that. I'm not
sure we can do anything else.
J
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-16 12:37 ` Juanma Barranquero
@ 2013-12-16 14:55 ` Stephen J. Turnbull
2013-12-16 16:27 ` Juanma Barranquero
2013-12-16 16:36 ` chad
0 siblings, 2 replies; 21+ messages in thread
From: Stephen J. Turnbull @ 2013-12-16 14:55 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Juri Linkov, Drew Adams, EMACS development team
Juanma Barranquero writes:
> How could I?
Perhaps you're a magician!
> When saving the frames, the only data connecting them
> with their display is a string, the contents of the `display'
> property.
That's how I would have done it 10years ago, but lots of things have
changed since then. Linux has found ways to ensure that devices have
stable names, maybe the X.org guys figured out how to do it be X
servers.
too bad they didn't, eh?
Steve
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-16 14:55 ` Stephen J. Turnbull
@ 2013-12-16 16:27 ` Juanma Barranquero
2013-12-16 16:36 ` chad
1 sibling, 0 replies; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-16 16:27 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: Juri Linkov, Drew Adams, EMACS development team
On Mon, Dec 16, 2013 at 3:55 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> That's how I would have done it 10years ago, but lots of things have
> changed since then. Linux has found ways to ensure that devices have
> stable names, maybe the X.org guys figured out how to do it be X
> servers.
>
> too bad they didn't, eh?
frameset.el has been mostly tested on Windows, which is what I use; I
have received some feedback, but not much (other than Drew's), which
presumably means that it hasn't caused any major trouble ;-) But
perhaps POSIX people can suggest ways to make it better.
I suppose we'll know once the pretest starts.
J
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-16 14:55 ` Stephen J. Turnbull
2013-12-16 16:27 ` Juanma Barranquero
@ 2013-12-16 16:36 ` chad
2013-12-16 16:38 ` Juanma Barranquero
1 sibling, 1 reply; 21+ messages in thread
From: chad @ 2013-12-16 16:36 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Juri Linkov, EMACS development team
FWIW, I have been confused by the emacs -nw behavior (opening a tty
frame, then closing it and opening a GUI frame) before, but not
enough to complain or change the behavior. I still find it a little
odd that I effectively can't use 'emacs -nw'. I'm trying out
desktop-restore-in-current-display 't now, and it seems like a
better default in my use cases.
Hope that helps,
~Chad
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Desktop tty frames
2013-12-16 16:36 ` chad
@ 2013-12-16 16:38 ` Juanma Barranquero
0 siblings, 0 replies; 21+ messages in thread
From: Juanma Barranquero @ 2013-12-16 16:38 UTC (permalink / raw)
To: chad; +Cc: Juri Linkov, EMACS development team
On Mon, Dec 16, 2013 at 5:36 PM, chad <chadpbrown@gmail.com> wrote:
> FWIW, I have been confused by the emacs -nw behavior (opening a tty
> frame, then closing it and opening a GUI frame) before, but not
> enough to complain or change the behavior. I still find it a little
> odd that I effectively can't use 'emacs -nw'. I'm trying out
> desktop-restore-in-current-display 't now, and it seems like a
> better default in my use cases.
We could change the default, or we could make the default be t or nil
depending on -nw.
WDOT?
> Hope that helps,
Yes, it does. Thanks.
J
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-12-16 16:38 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-15 13:56 today's git does not run on Ubuntu Susan Cragin
2013-12-15 15:20 ` Juanma Barranquero
2013-12-15 16:36 ` Eli Zaretskii
2013-12-15 17:02 ` Paul Eggert
2013-12-15 19:48 ` Desktop tty frames (was: today's git does not run on Ubuntu) Juri Linkov
2013-12-15 20:13 ` Juanma Barranquero
2013-12-15 20:52 ` Juanma Barranquero
2013-12-15 21:14 ` Desktop tty frames Juri Linkov
2013-12-15 21:52 ` Drew Adams
2013-12-15 21:56 ` Juanma Barranquero
2013-12-15 22:27 ` Drew Adams
2013-12-15 22:31 ` Juanma Barranquero
2013-12-16 0:27 ` Stephen J. Turnbull
2013-12-16 12:37 ` Juanma Barranquero
2013-12-16 14:55 ` Stephen J. Turnbull
2013-12-16 16:27 ` Juanma Barranquero
2013-12-16 16:36 ` chad
2013-12-16 16:38 ` Juanma Barranquero
2013-12-15 21:47 ` Desktop tty frames (was: today's git does not run on Ubuntu) Drew Adams
2013-12-15 21:52 ` Juanma Barranquero
-- strict thread matches above, loose matches on Subject: below --
2013-12-15 16:44 today's git does not run on Ubuntu Susan Cragin
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.