latest git sources badly broken on OS X

latest git sources badly broken on OS X

[Perry E. Metzger]

Just built a fresh pull from git on OS X Yosemite, and things are in
a bad way -- no cursor appears (though the mode line seems to
indicate one is moving around), no text appears when I type, if I
open files the display gets very screwed up. This is a bad enough
situation that I thought I'd mention it here. No idea if things are
equally bad under X11.

-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Paul Eggert]

Perry E. Metzger wrote:
> No idea if things are equally bad under X11.

For what it's worth, I'm not observing a problem under X11 with GNU/Linux.  I 
built commit fec9b792f543c35b1a635b3a3326d496e3ca9012 (dated 19:11:50 -0800 
today) on Fedora 21 x86-64.

Re: latest git sources badly broken on OS X

[Jan D.]

Hello.

I don't see this in trunk, compiled from:

commit 1ac42bca8886267dac029a2f19df1a43313e0d95
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sun Jan 4 00:50:35 2015 -0800

    * doc/lispref/files.texi: Fix xref typo.

Can you submit a bug report with your configure line and compiler specifics?

	Jan D.

> 4 jan 2015 kl. 04:03 skrev Perry E. Metzger <perry@piermont.com>:
> 
> Just built a fresh pull from git on OS X Yosemite, and things are in
> a bad way -- no cursor appears (though the mode line seems to
> indicate one is moving around), no text appears when I type, if I
> open files the display gets very screwed up. This is a bad enough
> situation that I thought I'd mention it here. No idea if things are
> equally bad under X11.
> 
> -- 
> Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Sun, 4 Jan 2015 10:46:08 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
> Hello.
> 
> I don't see this in trunk, compiled from:
> 
> commit 1ac42bca8886267dac029a2f19df1a43313e0d95
> Author: Paul Eggert <eggert@cs.ucla.edu>
> Date:   Sun Jan 4 00:50:35 2015 -0800
> 
>     * doc/lispref/files.texi: Fix xref typo.
> 
> Can you submit a bug report with your configure line and compiler
> specifics?

I can't run the internal bug report function inside Emacs compiled
this way (for obvious reasons), but the build was off of

commit d20f82e6f1ab902469723ebd530ca21bea9cc41b
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Jan 3 17:48:23 2015 -0800

the config lines were:

./configure --with-ns --without-dbus --without-compress-install

And the compile is the one available with the latest xcode in
Yosemite, i.e. cc --version says:

Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

The problem seems consistent for me. Unsure how to debug further.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Harald Hanche-Olsen]

Perry E. Metzger wrote:
> The problem seems consistent for me. Unsure how to debug further.

Um, git bisect?

– Harald

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Sun, 04 Jan 2015 19:32:15 +0100 Harald Hanche-Olsen
<hanche@math.ntnu.no> wrote:
> Perry E. Metzger wrote:
> > The problem seems consistent for me. Unsure how to debug further.
> 
> Um, git bisect?

That would indeed work. If no one has an obvious candidate for the
change that might have broken this I'll go in and do it.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Jan D.]

Perry E. Metzger skrev 2015-01-04 19:50:
> On Sun, 04 Jan 2015 19:32:15 +0100 Harald Hanche-Olsen
> <hanche@math.ntnu.no> wrote:
>> Perry E. Metzger wrote:
>>> The problem seems consistent for me. Unsure how to debug further.
>>
>> Um, git bisect?
>
> That would indeed work. If no one has an obvious candidate for the
> change that might have broken this I'll go in and do it.
>
> Perry
>

Update to the latest checkin first.

	Jan D.

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Sun, 04 Jan 2015 20:23:08 +0100 "Jan D." <jan.h.d@swipnet.se>
wrote:
> >> Um, git bisect?
> >
> > That would indeed work. If no one has an obvious candidate for the
> > change that might have broken this I'll go in and do it.
> 
> Update to the latest checkin first.

Done, and the problem persists. My guess is that some of the
renovation to the frame handling stuff inadvertently broke it, I'm
starting a git bisect now.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Sun, 04 Jan 2015 20:23:08 +0100 "Jan D." <jan.h.d@swipnet.se>
wrote:
> >> Um, git bisect?
> >
> > That would indeed work. If no one has an obvious candidate for the
> > change that might have broken this I'll go in and do it.

BTW, as an aside: it would be nice if emacs-version included the git
repo version it was built off of (if and only if that information is
available, of course).

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Óscar Fuentes]

"Perry E. Metzger" <perry@piermont.com> writes:

> BTW, as an aside: it would be nice if emacs-version included the git
> repo version it was built off of (if and only if that information is
> available, of course).

It is readily available here:

C-h v emacs-repository-version

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Sun, 04 Jan 2015 20:42:46 +0100 Óscar Fuentes <ofv@wanadoo.es>
wrote:
> "Perry E. Metzger" <perry@piermont.com> writes:
> 
> > BTW, as an aside: it would be nice if emacs-version included the
> > git repo version it was built off of (if and only if that
> > information is available, of course).
> 
> It is readily available here:
> 
> C-h v emacs-repository-version
> 
> 

When I try that, I get something that doesn't look like a sha-1 hex
string.

-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Eli Zaretskii]

> Date: Sun, 4 Jan 2015 14:47:32 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: emacs-devel@gnu.org
> 
> On Sun, 04 Jan 2015 20:42:46 +0100 Óscar Fuentes <ofv@wanadoo.es>
> wrote:
> > "Perry E. Metzger" <perry@piermont.com> writes:
> > 
> > > BTW, as an aside: it would be nice if emacs-version included the
> > > git repo version it was built off of (if and only if that
> > > information is available, of course).
> > 
> > It is readily available here:
> > 
> > C-h v emacs-repository-version
> > 
> > 
> 
> When I try that, I get something that doesn't look like a sha-1 hex
> string.

What does it look like?

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Sun, 04 Jan 2015 22:09:46 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sun, 4 Jan 2015 14:47:32 -0500
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: emacs-devel@gnu.org
> > 
> > On Sun, 04 Jan 2015 20:42:46 +0100 Óscar Fuentes <ofv@wanadoo.es>
> > wrote:
> > > "Perry E. Metzger" <perry@piermont.com> writes:
> > > 
> > > > BTW, as an aside: it would be nice if emacs-version included
> > > > the git repo version it was built off of (if and only if that
> > > > information is available, of course).
> > > 
> > > It is readily available here:
> > > 
> > > C-h v emacs-repository-version
> > > 
> > > 
> > 
> > When I try that, I get something that doesn't look like a sha-1
> > hex string.
> 
> What does it look like?

"118224 ulf.jasper@web.de-20141028203312-opt122s97xqkhdst"

(This was in my known last good version in October. Haven't tried it
on a newer emacs as that's what I'm trying to build right now. About
halfway through the git bisect btw.)

-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Óscar Fuentes]

"Perry E. Metzger" <perry@piermont.com> writes:

>> What does it look like?
>
> "118224 ulf.jasper@web.de-20141028203312-opt122s97xqkhdst"
>
> (This was in my known last good version in October. Haven't tried it
> on a newer emacs as that's what I'm trying to build right now. About
> halfway through the git bisect btw.)

That's a bzr revno + revid. I think that embedding the git revid in
`emacs-repository-version' only works since the git transition (~ 2
months ago.)

Re: latest git sources badly broken on OS X

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 04 Jan 2015 21:27:09 +0100
> 
> "Perry E. Metzger" <perry@piermont.com> writes:
> 
> >> What does it look like?
> >
> > "118224 ulf.jasper@web.de-20141028203312-opt122s97xqkhdst"
> >
> > (This was in my known last good version in October. Haven't tried it
> > on a newer emacs as that's what I'm trying to build right now. About
> > halfway through the git bisect btw.)
> 
> That's a bzr revno + revid. I think that embedding the git revid in
> `emacs-repository-version' only works since the git transition (~ 2
> months ago.)

Obviously, we cannot show a git sha1 in a bzr repository, can we?

Re: latest git sources badly broken on OS X

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> That's a bzr revno + revid. I think that embedding the git revid in
>> `emacs-repository-version' only works since the git transition (~ 2
>> months ago.)
>
> Obviously, we cannot show a git sha1 in a bzr repository, can we?

No for a bzr repo. Yes for a git repo (there was a git mirror of the bzr
repo since long time ago.)

I mean, the machinery for embedding the git revid was a recent addition.

For the OP: the bzr revid contains the timestamp of the commit:
2014/10/28 20:33.

Re: latest git sources badly broken on OS X

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 04 Jan 2015 21:45:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> That's a bzr revno + revid. I think that embedding the git revid in
> >> `emacs-repository-version' only works since the git transition (~ 2
> >> months ago.)
> >
> > Obviously, we cannot show a git sha1 in a bzr repository, can we?
> 
> No for a bzr repo. Yes for a git repo (there was a git mirror of the bzr
> repo since long time ago.)

Then this repo's sha1 values are all different, so of no use with the
current repo.

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Sun, 04 Jan 2015 22:31:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> Obviously, we cannot show a git sha1 in a bzr repository, can we?

Clearly my mistake. The git transition was 11/11 and this was a build
from a few days before.

-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

I wrote:
>>> The problem seems consistent for me. Unsure how to debug
>>> further.
>>
>> Um, git bisect?
>
> That would indeed work. If no one has an obvious candidate for the
> change that might have broken this I'll go in and do it.

Spending a few hours on this, this popped up as the bad rev. This
explains why it is OS X only. Unsure what the exact problem is still
but that should be easy from here.

$ git bisect bad
d29658759a1343995f0d8b163d7fe445dd904b81 is the first bad commit
commit d29658759a1343995f0d8b163d7fe445dd904b81
Author: Jan Dj__rv <jan.h.d@swipnet.se>
Date:   Sun Nov 9 14:47:02 2014 +0100

    * nsterm.h (EmacsScroller): judge returns bool.
    
    * nsterm.m (ns_set_vertical_scroll_bar): Release bar.
    (ns_judge_scroll_bars): Only set removed if judge returns true.
    (judge): Returns bool == condemned.  Remove self from window.
    (setPosition:portion:whole:): Remove raise SIGIO.
    
    Fixes: debbugs:18757

:040000 040000 fdc45d21babe0914c2de8dbea838a97689cdbada 5914794e0b431ca729338a27df419244d5903c8e M	src


-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Jan D.]

Perry E. Metzger skrev den 2015-01-05 03:41:

Hello.

> Spending a few hours on this, this popped up as the bad rev. This
> explains why it is OS X only. Unsure what the exact problem is still
> but that should be easy from here.
>
> $ git bisect bad
> d29658759a1343995f0d8b163d7fe445dd904b81 is the first bad commit
> commit d29658759a1343995f0d8b163d7fe445dd904b81
> Author: Jan Dj__rv <jan.h.d@swipnet.se>
> Date:   Sun Nov 9 14:47:02 2014 +0100
>
>      * nsterm.h (EmacsScroller): judge returns bool.
>
>      * nsterm.m (ns_set_vertical_scroll_bar): Release bar.
>      (ns_judge_scroll_bars): Only set removed if judge returns true.
>      (judge): Returns bool == condemned.  Remove self from window.
>      (setPosition:portion:whole:): Remove raise SIGIO.
>
>      Fixes: debbugs:18757
>
> :040000 040000 fdc45d21babe0914c2de8dbea838a97689cdbada 5914794e0b431ca729338a27df419244d5903c8e M	src
>
>

Not easy at all.  I have run with this change since it was made on two 
separate machines, and I don't see the errors you do.

Does your tree have any local modifications?  Do you see this in the 
Emacs-24 branch also?

	Jan D.

Re: latest git sources badly broken on OS X

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

For what it's worth, I updated to the latest git release a few days ago on
my Mavericks Macbook and I also do not see this issue.

Regards,
Elias

On 5 January 2015 at 14:40, Jan D. <jan.h.d@swipnet.se> wrote:

> Perry E. Metzger skrev den 2015-01-05 03:41:
>
> Hello.
>
>  Spending a few hours on this, this popped up as the bad rev. This
>> explains why it is OS X only. Unsure what the exact problem is still
>> but that should be easy from here.
>>
>> $ git bisect bad
>> d29658759a1343995f0d8b163d7fe445dd904b81 is the first bad commit
>> commit d29658759a1343995f0d8b163d7fe445dd904b81
>> Author: Jan Dj__rv <jan.h.d@swipnet.se>
>> Date:   Sun Nov 9 14:47:02 2014 +0100
>>
>>      * nsterm.h (EmacsScroller): judge returns bool.
>>
>>      * nsterm.m (ns_set_vertical_scroll_bar): Release bar.
>>      (ns_judge_scroll_bars): Only set removed if judge returns true.
>>      (judge): Returns bool == condemned.  Remove self from window.
>>      (setPosition:portion:whole:): Remove raise SIGIO.
>>
>>      Fixes: debbugs:18757
>>
>> :040000 040000 fdc45d21babe0914c2de8dbea838a97689cdbada
>> 5914794e0b431ca729338a27df419244d5903c8e M      src
>>
>>
>>
> Not easy at all.  I have run with this change since it was made on two
> separate machines, and I don't see the errors you do.
>
> Does your tree have any local modifications?  Do you see this in the
> Emacs-24 branch also?
>
>         Jan D.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2146 bytes --]

Re: latest git sources badly broken on OS X

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

Sorry and I apologise for the spam. I meant Yosemite.

Regards,
Elias

On 5 January 2015 at 21:12, Elias Mårtenson <lokedhs@gmail.com> wrote:

> For what it's worth, I updated to the latest git release a few days ago on
> my Mavericks Macbook and I also do not see this issue.
>
> Regards,
> Elias
>
> On 5 January 2015 at 14:40, Jan D. <jan.h.d@swipnet.se> wrote:
>
>> Perry E. Metzger skrev den 2015-01-05 03:41:
>>
>> Hello.
>>
>>  Spending a few hours on this, this popped up as the bad rev. This
>>> explains why it is OS X only. Unsure what the exact problem is still
>>> but that should be easy from here.
>>>
>>> $ git bisect bad
>>> d29658759a1343995f0d8b163d7fe445dd904b81 is the first bad commit
>>> commit d29658759a1343995f0d8b163d7fe445dd904b81
>>> Author: Jan Dj__rv <jan.h.d@swipnet.se>
>>> Date:   Sun Nov 9 14:47:02 2014 +0100
>>>
>>>      * nsterm.h (EmacsScroller): judge returns bool.
>>>
>>>      * nsterm.m (ns_set_vertical_scroll_bar): Release bar.
>>>      (ns_judge_scroll_bars): Only set removed if judge returns true.
>>>      (judge): Returns bool == condemned.  Remove self from window.
>>>      (setPosition:portion:whole:): Remove raise SIGIO.
>>>
>>>      Fixes: debbugs:18757
>>>
>>> :040000 040000 fdc45d21babe0914c2de8dbea838a97689cdbada
>>> 5914794e0b431ca729338a27df419244d5903c8e M      src
>>>
>>>
>>>
>> Not easy at all.  I have run with this change since it was made on two
>> separate machines, and I don't see the errors you do.
>>
>> Does your tree have any local modifications?  Do you see this in the
>> Emacs-24 branch also?
>>
>>         Jan D.
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2655 bytes --]

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Mon, 05 Jan 2015 07:40:56 +0100 "Jan D." <jan.h.d@swipnet.se>
wrote:
> Perry E. Metzger skrev den 2015-01-05 03:41:
> 
> Hello.
> 
> > Spending a few hours on this, this popped up as the bad rev. This
> > explains why it is OS X only. Unsure what the exact problem is
> > still but that should be easy from here.
> >
> > $ git bisect bad
> > d29658759a1343995f0d8b163d7fe445dd904b81 is the first bad commit
> > commit d29658759a1343995f0d8b163d7fe445dd904b81
> > Author: Jan Dj__rv <jan.h.d@swipnet.se>
> > Date:   Sun Nov 9 14:47:02 2014 +0100
> >
> >      * nsterm.h (EmacsScroller): judge returns bool.
> >
> >      * nsterm.m (ns_set_vertical_scroll_bar): Release bar.
> >      (ns_judge_scroll_bars): Only set removed if judge returns
> > true. (judge): Returns bool == condemned.  Remove self from
> > window. (setPosition:portion:whole:): Remove raise SIGIO.
> >
> >      Fixes: debbugs:18757
> >
> > :040000 040000 fdc45d21babe0914c2de8dbea838a97689cdbada
> > 5914794e0b431ca729338a27df419244d5903c8e M	src
> >
> >
> 
> Not easy at all.  I have run with this change since it was made on
> two separate machines, and I don't see the errors you do.
> 
> Does your tree have any local modifications?

Nope. I'm running the pure branch.

I've played with the issue for a while now trying to figure out how
you could not be seeing this.

.My suspicion is now that the issue only shows up if the emacs screen
is vertically maximized. My .emacs vertically maximizes the frame on
startup. If I bypass that or shrink it to less than maximum the
problem seems to go away.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Mon, 5 Jan 2015 21:13:35 +0800 Elias Mårtenson <lokedhs@gmail.com>
wrote:
> > For what it's worth, I updated to the latest git release a few
> > days ago on my Mavericks Macbook and I also do not see this issue.
>
> Sorry and I apologise for the spam. I meant Yosemite.

Try to set your Emacs frame to open up occupying the entire available
vertical space. The problem is entirely consistent if I do that.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Jan D.]

Please post your corresponding .emacs.
There are many ways to do this.

	Jan D.

> 5 jan 2015 kl. 17:18 skrev Perry E. Metzger <perry@piermont.com>:
> 
> On Mon, 05 Jan 2015 07:40:56 +0100 "Jan D." <jan.h.d@swipnet.se>
> wrote:
>> Perry E. Metzger skrev den 2015-01-05 03:41:
>> 
>> Hello.
>> 
>>> Spending a few hours on this, this popped up as the bad rev. This
>>> explains why it is OS X only. Unsure what the exact problem is
>>> still but that should be easy from here.
>>> 
>>> $ git bisect bad
>>> d29658759a1343995f0d8b163d7fe445dd904b81 is the first bad commit
>>> commit d29658759a1343995f0d8b163d7fe445dd904b81
>>> Author: Jan Dj__rv <jan.h.d@swipnet.se>
>>> Date:   Sun Nov 9 14:47:02 2014 +0100
>>> 
>>>     * nsterm.h (EmacsScroller): judge returns bool.
>>> 
>>>     * nsterm.m (ns_set_vertical_scroll_bar): Release bar.
>>>     (ns_judge_scroll_bars): Only set removed if judge returns
>>> true. (judge): Returns bool == condemned.  Remove self from
>>> window. (setPosition:portion:whole:): Remove raise SIGIO.
>>> 
>>>     Fixes: debbugs:18757
>>> 
>>> :040000 040000 fdc45d21babe0914c2de8dbea838a97689cdbada
>>> 5914794e0b431ca729338a27df419244d5903c8e M	src
>>> 
>>> 
>> 
>> Not easy at all.  I have run with this change since it was made on
>> two separate machines, and I don't see the errors you do.
>> 
>> Does your tree have any local modifications?
> 
> Nope. I'm running the pure branch.
> 
> I've played with the issue for a while now trying to figure out how
> you could not be seeing this.
> 
> .My suspicion is now that the issue only shows up if the emacs screen
> is vertically maximized. My .emacs vertically maximizes the frame on
> startup. If I bypass that or shrink it to less than maximum the
> problem seems to go away.
> 
> Perry
> -- 
> Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Mon, 5 Jan 2015 18:29:21 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
> Please post your corresponding .emacs.
> There are many ways to do this.

I'm trying to minimize my .emacs to the fewest lines that will
accomplish this. Is there a good set of startup flags to say "use
this file instead of .emacs when starting"?

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Jan D.]

> 5 jan 2015 kl. 18:40 skrev Perry E. Metzger <perry@piermont.com>:
> 
> On Mon, 5 Jan 2015 18:29:21 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
>> Please post your corresponding .emacs.
>> There are many ways to do this.
> 
> I'm trying to minimize my .emacs to the fewest lines that will
> accomplish this. Is there a good set of startup flags to say "use
> this file instead of .emacs when starting"?

You can set HOME to point to another dir with your .emacs.
Or just move your normal .emacs out of the way.

	Jan D.

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Mon, 5 Jan 2015 18:29:21 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
> Please post your corresponding .emacs.
> There are many ways to do this.

Figured it out, -q and -l made minimizing easy.

Manifestation with this .emacs will be that the top of the *scratch*
buffer is above the top of the screen and inaccessible. You may have
to adjust the height from 60 to whatever will fully fill your screen,
and you may need to uncomment the line that sets the top above. It
will work with a different font but you then have to adjust the
height yet again -- "menlo" and 60 rows does it for me.

Technically, you don't need to inhibit the startup message, but the
manifestation is then that part of the buffer is "differently" above
the top of the screen and inaccessible.

Also in an attached file.

(tool-bar-mode -1)
(setq inhibit-startup-message t)

(if (eq window-system 'ns)
    (progn
      (set-face-attribute 'default nil
                          :family "menlo" :height 140)
;      (add-to-list 'default-frame-alist '(top . 0))
      )
  )

(if window-system
    (add-to-list 'default-frame-alist
		 (cons 'height 60)))


-- 
Perry E. Metzger		perry@piermont.com

[-- Attachment #2: dot-emacs --]
[-- Type: application/octet-stream, Size: 330 bytes --]

(tool-bar-mode -1)
(setq inhibit-startup-message t)

(if (eq window-system 'ns)
    (progn
      (set-face-attribute 'default nil
                          :family "menlo" :height 140)
;      (add-to-list 'default-frame-alist '(top . 0))
      )
  )

(if window-system
    (add-to-list 'default-frame-alist
		 (cons 'height 60)))

Re: latest git sources badly broken on OS X

[Michael Welsh Duggan]

"Perry E. Metzger" <perry@piermont.com> writes:

> On Mon, 5 Jan 2015 18:29:21 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
>> Please post your corresponding .emacs.
>> There are many ways to do this.
>
> I'm trying to minimize my .emacs to the fewest lines that will
> accomplish this. Is there a good set of startup flags to say "use
> this file instead of .emacs when starting"?

emacs -q -l file.el

Though for debugging purposes using -Q instead of -q is better, since -Q
doesn't attempt to load the site startup file.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Mon, 05 Jan 2015 13:05:40 -0500 Michael Welsh Duggan
<mwd@md5i.com> wrote:
> "Perry E. Metzger" <perry@piermont.com> writes:
> 
> > On Mon, 5 Jan 2015 18:29:21 +0100 "Jan D." <jan.h.d@swipnet.se>
> > wrote:
> >> Please post your corresponding .emacs.
> >> There are many ways to do this.
> >
> > I'm trying to minimize my .emacs to the fewest lines that will
> > accomplish this. Is there a good set of startup flags to say "use
> > this file instead of .emacs when starting"?
> 
> emacs -q -l file.el
> 
> Though for debugging purposes using -Q instead of -q is better,
> since -Q doesn't attempt to load the site startup file.

Thanks! I figured that out already but it is good to hear I used the
right method.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Jan D.]

Still can't see any error, except frame size being wrong at startup.
Fonts are still fine.

	Jan D.

> 5 jan 2015 kl. 18:59 skrev Perry E. Metzger <perry@piermont.com>:
> 
> On Mon, 5 Jan 2015 18:29:21 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
>> Please post your corresponding .emacs.
>> There are many ways to do this.
> 
> Figured it out, -q and -l made minimizing easy.
> 
> Manifestation with this .emacs will be that the top of the *scratch*
> buffer is above the top of the screen and inaccessible. You may have
> to adjust the height from 60 to whatever will fully fill your screen,
> and you may need to uncomment the line that sets the top above. It
> will work with a different font but you then have to adjust the
> height yet again -- "menlo" and 60 rows does it for me.
> 
> Technically, you don't need to inhibit the startup message, but the
> manifestation is then that part of the buffer is "differently" above
> the top of the screen and inaccessible.
> 
> Also in an attached file.
> 
> (tool-bar-mode -1)
> (setq inhibit-startup-message t)
> 
> (if (eq window-system 'ns)
>    (progn
>      (set-face-attribute 'default nil
>                          :family "menlo" :height 140)
> ;      (add-to-list 'default-frame-alist '(top . 0))
>      )
>  )
> 
> (if window-system
>    (add-to-list 'default-frame-alist
> 		 (cons 'height 60)))
> 
> 
> -- 
> Perry E. Metzger		perry@piermont.com
> <dot-emacs>

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Tue, 6 Jan 2015 20:31:33 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
> Still can't see any error, except frame size being wrong at startup.
> Fonts are still fine.

See the attached screen shot. This is what happens to me right at the
start -- cursor is easily put "off screen" above, and the top of
the display cannot be scrolled to -- the normal stuff in the
"scratch" buffer at the start is off the top of the display.

If I try working with the thing, I get terrible artifacts that get
worse as I work.

Perry
-- 
Perry E. Metzger		perry@piermont.com

[-- Attachment #2: Screen Shot 2015-01-06 at 14.42.57.png --]
[-- Type: application/octet-stream, Size: 118399 bytes --]

Re: latest git sources badly broken on OS X

[Jan D.]

This is not a font problem at all, it it just the frame that is sized wrong.
Please try an updated trunk.

	Jan D.

> 6 jan 2015 kl. 20:45 skrev Perry E. Metzger <perry@piermont.com>:
> 
> On Tue, 6 Jan 2015 20:31:33 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
>> Still can't see any error, except frame size being wrong at startup.
>> Fonts are still fine.
> 
> See the attached screen shot. This is what happens to me right at the
> start -- cursor is easily put "off screen" above, and the top of
> the display cannot be scrolled to -- the normal stuff in the
> "scratch" buffer at the start is off the top of the display.
> 
> If I try working with the thing, I get terrible artifacts that get
> worse as I work.
> 
> Perry
> -- 
> Perry E. Metzger		perry@piermont.com
> <Screen Shot 2015-01-06 at 14.42.57.png>

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Wed, 7 Jan 2015 06:56:41 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
> This is not a font problem at all, it it just the frame that is
> sized wrong. Please try an updated trunk.

I never believed it was a font problem, sorry if that was
somehow conveyed.

Anyway, rebuilding the trunk on Yosemite right now dies with this:

Loading /Users/perry/src/emacs/emacs/lisp/international/characters.el
(source)...
make[1]: *** [bootstrap-emacs] Illegal instruction: 4 (core dumped)
make: *** [src] Error 2

I've tried it twice, unsure what is going wrong.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Wed, 7 Jan 2015 17:01:40 -0500 "Perry E. Metzger"
<perry@piermont.com> wrote:
> On Wed, 7 Jan 2015 06:56:41 +0100 "Jan D." <jan.h.d@swipnet.se>
> wrote:
> > This is not a font problem at all, it it just the frame that is
> > sized wrong. Please try an updated trunk.
> 
> I never believed it was a font problem, sorry if that was
> somehow conveyed.
> 
> Anyway, rebuilding the trunk on Yosemite right now dies with this:
> 
> Loading /Users/perry/src/emacs/emacs/lisp/international/characters.el
> (source)...
> make[1]: *** [bootstrap-emacs] Illegal instruction: 4 (core dumped)
> make: *** [src] Error 2
> 
> I've tried it twice, unsure what is going wrong.

git bisect finds this as the commit that breaks the build (at least
on OS X):

bc78ff2603b8c062dbd8f93f421c3412e36e343f is the first bad commit
commit bc78ff2603b8c062dbd8f93f421c3412e36e343f
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Mon Jan 5 09:07:45 2015 -0800

    Use 0 for Qnil
[...]

One wonders if it might not be nice for there to be an automated QA
machine to try builds after, or even before, commits...

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Perry E. Metzger]

On Wed, 7 Jan 2015 06:56:41 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
> Please try an updated trunk.

Now that I can compile again, I can verify that the problem was
indeed fixed. Thank you so much! 

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: latest git sources badly broken on OS X

[Jan D.]

Good, thanks for testing.

	Jan D.

> 8 jan 2015 kl. 19:03 skrev Perry E. Metzger <perry@piermont.com>:
> 
> On Wed, 7 Jan 2015 06:56:41 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
>> Please try an updated trunk.
> 
> Now that I can compile again, I can verify that the problem was
> indeed fixed. Thank you so much! 
> 
> Perry
> -- 
> Perry E. Metzger		perry@piermont.com