* Negative positions in frame parameters
@ 2010-04-13 13:24 Stefan Monnier
2010-04-13 13:33 ` Lennart Borgman
2010-04-13 15:18 ` Jan Djärv
0 siblings, 2 replies; 17+ messages in thread
From: Stefan Monnier @ 2010-04-13 13:24 UTC (permalink / raw
To: emacs-devel
Recently
(make-frame '((left . -10) (top . -10)))
stopped placing the frame in the bottom-right corner of the screen (at
least in the Gtk build).
Could someone fix it?
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 13:24 Negative positions in frame parameters Stefan Monnier
@ 2010-04-13 13:33 ` Lennart Borgman
2010-04-13 14:12 ` Stephen J. Turnbull
2010-04-13 14:41 ` Jan Djärv
2010-04-13 15:18 ` Jan Djärv
1 sibling, 2 replies; 17+ messages in thread
From: Lennart Borgman @ 2010-04-13 13:33 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Recently
>
> (make-frame '((left . -10) (top . -10)))
>
> stopped placing the frame in the bottom-right corner of the screen (at
> least in the Gtk build).
>
> Could someone fix it?
Why should it go to the bottom-right corner? At least on w32 you can
have the upper left corner outside of the screen.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 13:33 ` Lennart Borgman
@ 2010-04-13 14:12 ` Stephen J. Turnbull
2010-04-13 16:17 ` Jason Rumney
2010-04-13 14:41 ` Jan Djärv
1 sibling, 1 reply; 17+ messages in thread
From: Stephen J. Turnbull @ 2010-04-13 14:12 UTC (permalink / raw
To: Lennart Borgman; +Cc: Stefan Monnier, emacs-devel
Lennart Borgman writes:
> On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
> > Recently
> >
> > (make-frame '((left . -10) (top . -10)))
> >
> > stopped placing the frame in the bottom-right corner of the screen (at
> > least in the Gtk build).
> >
> > Could someone fix it?
>
> Why should it go to the bottom-right corner?
This is just the traditional behavior on X11 displays. Negative
position coordinates are relative to the bottom-right corner, positive
ones to the top-left.
> At least on w32 you can have the upper left corner outside of the
> screen.
You can in X, too, but it's rarely useful for top-level windows. The
ability to place the window on the right or bottom of the screen is
often useful. IME YMMV, of course; I'm just explaining where the
tradition comes from, not advocating it.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 13:33 ` Lennart Borgman
2010-04-13 14:12 ` Stephen J. Turnbull
@ 2010-04-13 14:41 ` Jan Djärv
2010-04-13 15:26 ` David Kastrup
2010-04-13 16:09 ` Stefan Monnier
1 sibling, 2 replies; 17+ messages in thread
From: Jan Djärv @ 2010-04-13 14:41 UTC (permalink / raw
To: Lennart Borgman; +Cc: Stefan Monnier, emacs-devel
Lennart Borgman skrev 2010-04-13 15.33:
> On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>> Recently
>>
>> (make-frame '((left . -10) (top . -10)))
>>
>> stopped placing the frame in the bottom-right corner of the screen (at
>> least in the Gtk build).
>>
>> Could someone fix it?
>
> Why should it go to the bottom-right corner? At least on w32 you can
> have the upper left corner outside of the screen.
>
http://www.xfree86.org/current/X.7.html#sect6
The problem in Emacs is how do you say the equivalent to
-geometry --10--10, -geometry +-10+-10
in frame parameters?
Jan D.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 13:24 Negative positions in frame parameters Stefan Monnier
2010-04-13 13:33 ` Lennart Borgman
@ 2010-04-13 15:18 ` Jan Djärv
2010-04-13 16:10 ` Stefan Monnier
1 sibling, 1 reply; 17+ messages in thread
From: Jan Djärv @ 2010-04-13 15:18 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier skrev:
> Recently
>
> (make-frame '((left . -10) (top . -10)))
>
> stopped placing the frame in the bottom-right corner of the screen (at
> least in the Gtk build).
>
> Could someone fix it?
>
Done. AFAIK, the Gtk-port has never handled negative positions in frame
parameters correctly.
Jan D.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 14:41 ` Jan Djärv
@ 2010-04-13 15:26 ` David Kastrup
2010-04-13 16:31 ` Jan Djärv
2010-04-13 16:09 ` Stefan Monnier
1 sibling, 1 reply; 17+ messages in thread
From: David Kastrup @ 2010-04-13 15:26 UTC (permalink / raw
To: emacs-devel
Jan Djärv <jan.h.d@swipnet.se> writes:
> Lennart Borgman skrev 2010-04-13 15.33:
>> On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
>> <monnier@iro.umontreal.ca> wrote:
>>> Recently
>>>
>>> (make-frame '((left . -10) (top . -10)))
>>>
>>> stopped placing the frame in the bottom-right corner of the screen (at
>>> least in the Gtk build).
>>>
>>> Could someone fix it?
>>
>> Why should it go to the bottom-right corner? At least on w32 you can
>> have the upper left corner outside of the screen.
>>
>
> http://www.xfree86.org/current/X.7.html#sect6
>
> The problem in Emacs is how do you say the equivalent to
>
> -geometry --10--10, -geometry +-10+-10
>
> in frame parameters?
(make-frame '((right . -10) (bottom . -10)))
(make-frame '((left . -10) (top . -10)))
would seem like a reasonably obvious way.
--
David Kastrup
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 14:41 ` Jan Djärv
2010-04-13 15:26 ` David Kastrup
@ 2010-04-13 16:09 ` Stefan Monnier
2010-04-13 17:07 ` Jan Djärv
1 sibling, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2010-04-13 16:09 UTC (permalink / raw
To: Jan Djärv; +Cc: Lennart Borgman, emacs-devel
>>> Recently
>>> (make-frame '((left . -10) (top . -10)))
>>> stopped placing the frame in the bottom-right corner of the screen (at
>>> least in the Gtk build).
>>> Could someone fix it?
>> Why should it go to the bottom-right corner? At least on w32 you can
>> have the upper left corner outside of the screen.
> http://www.xfree86.org/current/X.7.html#sect6
So where was the change made that caused this new behavior?
In Emacs's code or in some external library?
> The problem in Emacs is how do you say the equivalent to
> -geometry --10--10, -geometry +-10+-10
> in frame parameters?
David was quicker than I, so I'll just +1 on his suggestion, except that
it's incompatible with previous behavior.
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 15:18 ` Jan Djärv
@ 2010-04-13 16:10 ` Stefan Monnier
2010-04-13 17:08 ` Jan Djärv
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2010-04-13 16:10 UTC (permalink / raw
To: Jan Djärv; +Cc: emacs-devel
> Done. AFAIK, the Gtk-port has never handled negative positions in frame
> parameters correctly.
I've been using them forever on several of my special-display frames, so
at least it made a good enough impression to fool me,
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 14:12 ` Stephen J. Turnbull
@ 2010-04-13 16:17 ` Jason Rumney
2010-04-13 17:14 ` Jan Djärv
0 siblings, 1 reply; 17+ messages in thread
From: Jason Rumney @ 2010-04-13 16:17 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: Lennart Borgman, Stefan Monnier, emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> > At least on w32 you can have the upper left corner outside of the
> > screen.
>
> You can in X, too, but it's rarely useful for top-level windows.
I'm not sure if Xinerama or RandR works like this, but with multiple monitor
setups on Windows, you can choose to put the secondary montitor to the
left and/or above the primary monitor, in which case all coordinates on
that monitor become negative. So its not as useless as it might
initially seem.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 15:26 ` David Kastrup
@ 2010-04-13 16:31 ` Jan Djärv
2010-04-13 17:02 ` Drew Adams
2010-04-13 23:41 ` YAMAMOTO Mitsuharu
0 siblings, 2 replies; 17+ messages in thread
From: Jan Djärv @ 2010-04-13 16:31 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
David Kastrup skrev 2010-04-13 17.26:
> Jan Djärv<jan.h.d@swipnet.se> writes:
>
>> The problem in Emacs is how do you say the equivalent to
>>
>> -geometry --10--10, -geometry +-10+-10
>>
>> in frame parameters?
>
> (make-frame '((right . -10) (bottom . -10)))
>
> (make-frame '((left . -10) (top . -10)))
>
> would seem like a reasonably obvious way.
>
You would think that, but I found out that is actually:
(make-frame '((right . (- -10)) (left . (- -10)))
and
(make-frame '((right . (+ -10)) (left . (+ -10)))
Jan D.
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Negative positions in frame parameters
2010-04-13 16:31 ` Jan Djärv
@ 2010-04-13 17:02 ` Drew Adams
2010-04-13 23:41 ` YAMAMOTO Mitsuharu
1 sibling, 0 replies; 17+ messages in thread
From: Drew Adams @ 2010-04-13 17:02 UTC (permalink / raw
To: emacs-devel
FWIW, I've been using the following functions forever, to make life simpler when
trying to deal with the different possible representations that Emacs functions
might return.
I use this, for example, to move frames around incrementally. (To increment a
value it needs to be in numeric form.)
The functions are also here, in case mail wraparound makes them difficult to
read:
http://www.emacswiki.org/emacs/frame-fns.el
----
(defun frame-geom-value-numeric (type value &optional frame)
"Return equivalent geometry value for FRAME in numeric terms.
A geometry value equivalent to VALUE for FRAME is returned,
where the value is numeric, not a consp.
TYPE is the car of the original geometry spec (TYPE . VALUE).
It is `top' or `left', depending on which edge VALUE is related to.
VALUE is the cdr of a frame geometry spec: (left/top . VALUE).
If VALUE is a consp, then it is converted to a numeric value, perhaps
relative to the opposite frame edge from that in the original spec.
FRAME defaults to the selected frame.
Examples (measures in pixels) -
Assuming display height/width=1024, frame height/width=600:
300 inside display edge: 300 => 300
(+ 300) => 300
300 inside opposite display edge: (- 300) => -300
-300 => -300
300 beyond display edge
(= 724 inside opposite display edge): (+ -300) => -724
300 beyond display edge
(= 724 inside opposite display edge): (- -300) => 724
In the last two examples, the returned value is relative to the
opposite frame edge from the edge indicated in the input spec."
(if (consp value)
(if (natnump (cadr value))
;; e.g. (+ 300) or (- 300) => 300 or -300
(funcall (car value) (cadr value))
;; e.g. (+ -300) or (- -300)
(let ((oppval (- (if (eq 'left type)
(x-display-pixel-width)
(x-display-pixel-height))
(cadr value)
(if (eq 'left type)
(frame-pixel-width frame)
(frame-pixel-height frame)))))
(if (eq '+ (car value))
(- oppval) ; e.g. (+ -300) => -724
oppval))) ; e.g. (- -300) => 724
;; e.g. 300 or -300
value))
(defun frame-geom-spec-numeric (spec &optional frame)
"Return equivalent geometry specification for FRAME in numeric terms.
A geometry specification equivalent to SPEC for FRAME is returned,
where the value is numeric, not a consp.
SPEC is a frame geometry spec: (left . VALUE) or (top . VALUE).
If VALUE is a consp, then it is converted to a numeric value, perhaps
relative to the opposite frame edge from that in the original SPEC.
FRAME defaults to the selected frame.
Examples (measures in pixels) -
Assuming display height=1024, frame height=600:
top 300 below display top: (top . 300) => (top . 300)
(top + 300) => (top . 300)
bottom 300 above display bottom: (top - 300) => (top . -300)
(top . -300) => (top . -300)
top 300 above display top
(= bottom 724 above display bottom): (top + -300) => (top . -724)
bottom 300 below display bottom
(= top 724 below display top): (top - -300) => (top . 724)
In the last two examples, the returned value is relative to the
opposite frame edge from the edge indicated in the input SPEC."
(cons (car spec) (frame-geom-value-numeric (car spec) (cdr spec))))
(defun frame-geom-value-cons (type value &optional frame)
"Return equivalent geometry value for FRAME as a cons with car `+'.
A geometry value equivalent to VALUE for FRAME is returned,
where the value is a cons with car `+', not numeric.
TYPE is the car of the original geometry spec (TYPE . VALUE).
It is `top' or `left', depending on which edge VALUE is related to.
VALUE is the cdr of a frame geometry spec: (left/top . VALUE).
If VALUE is a number, then it is converted to a cons value, perhaps
relative to the opposite frame edge from that in the original spec.
FRAME defaults to the selected frame.
Examples (measures in pixels) -
Assuming display height/width=1024, frame height/width=600:
300 inside display edge: 300 => (+ 300)
(+ 300) => (+ 300)
300 inside opposite display edge: (- 300) => (+ 124)
-300 => (+ 124)
300 beyond display edge
(= 724 inside opposite display edge): (+ -300) => (+ -300)
300 beyond display edge
(= 724 inside opposite display edge): (- -300) => (+ 724)
In the 3rd, 4th, and 6th examples, the returned value is relative to
the opposite frame edge from the edge indicated in the input spec."
(cond ((and (consp value) (eq '+ (car value))) ; e.g. (+ 300), (+ -300)
value)
((natnump value) (list '+ value)) ; e.g. 300 => (+ 300)
(t ; e.g. -300, (- 300), (- -300)
(list '+ (- (if (eq 'left type) ; => (+ 124), (+ 124), (+ 724)
(x-display-pixel-width)
(x-display-pixel-height))
(if (integerp value) (- value) (cadr value))
(if (eq 'left type)
(frame-pixel-width frame)
(frame-pixel-height frame)))))))
(defun frame-geom-spec-cons (spec &optional frame)
"Return equivalent geometry spec for FRAME as a cons with car `+'.
A geometry specification equivalent to SPEC for FRAME is returned,
where the value is a cons with car `+', not numeric.
SPEC is a frame geometry spec: (left . VALUE) or (top . VALUE).
If VALUE is a number, then it is converted to a cons value, perhaps
relative to the opposite frame edge from that in the original spec.
FRAME defaults to the selected frame.
Examples (measures in pixels) -
Assuming display height=1024, frame height=600:
top 300 below display top: (top . 300) => (top + 300)
(top + 300) => (top + 300)
bottom 300 above display bottom: (top - 300) => (top + 124)
(top . -300) => (top + 124)
top 300 above display top
(= bottom 724 above display bottom): (top + -300) => (top + -300)
bottom 300 below display bottom
(= top 724 below display top): (top - -300) => (top + 724)
In the 3rd, 4th, and 6th examples, the returned value is relative to
the opposite frame edge from the edge indicated in the input spec."
(cons (car spec) (frame-geom-value-cons (car spec) (cdr spec))))
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 16:09 ` Stefan Monnier
@ 2010-04-13 17:07 ` Jan Djärv
0 siblings, 0 replies; 17+ messages in thread
From: Jan Djärv @ 2010-04-13 17:07 UTC (permalink / raw
To: Stefan Monnier; +Cc: Lennart Borgman, emacs-devel
Stefan Monnier skrev:
>>>> Recently
>>>> (make-frame '((left . -10) (top . -10)))
>>>> stopped placing the frame in the bottom-right corner of the screen (at
>>>> least in the Gtk build).
>>>> Could someone fix it?
>>> Why should it go to the bottom-right corner? At least on w32 you can
>>> have the upper left corner outside of the screen.
>
>> http://www.xfree86.org/current/X.7.html#sect6
>
> So where was the change made that caused this new behavior?
> In Emacs's code or in some external library?
What new behaviour? The bug was in Emacs code.
>
>> The problem in Emacs is how do you say the equivalent to
>> -geometry --10--10, -geometry +-10+-10
>> in frame parameters?
>
> David was quicker than I, so I'll just +1 on his suggestion, except that
> it's incompatible with previous behavior.
>
And there already is a way.
Jan D.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 16:10 ` Stefan Monnier
@ 2010-04-13 17:08 ` Jan Djärv
0 siblings, 0 replies; 17+ messages in thread
From: Jan Djärv @ 2010-04-13 17:08 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier skrev:
>> Done. AFAIK, the Gtk-port has never handled negative positions in frame
>> parameters correctly.
>
> I've been using them forever on several of my special-display frames, so
> at least it made a good enough impression to fool me,
>
If you also set user-position, then it worked as it should.
Jan D.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 16:17 ` Jason Rumney
@ 2010-04-13 17:14 ` Jan Djärv
2010-04-13 17:33 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: Jan Djärv @ 2010-04-13 17:14 UTC (permalink / raw
To: Jason Rumney
Cc: Stephen J. Turnbull, Lennart Borgman, Stefan Monnier, emacs-devel
Jason Rumney skrev:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>> > At least on w32 you can have the upper left corner outside of the
>> > screen.
>>
>> You can in X, too, but it's rarely useful for top-level windows.
>
> I'm not sure if Xinerama or RandR works like this, but with multiple monitor
> setups on Windows, you can choose to put the secondary montitor to the
> left and/or above the primary monitor, in which case all coordinates on
> that monitor become negative. So its not as useless as it might
> initially seem.
>
AFAIK, in X the top left corner is always at 0, 0. There is no concept of
primary or secondary monitor, there are just monitors. There is a primary
screen though.
Jan D.
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Negative positions in frame parameters
2010-04-13 17:14 ` Jan Djärv
@ 2010-04-13 17:33 ` Drew Adams
0 siblings, 0 replies; 17+ messages in thread
From: Drew Adams @ 2010-04-13 17:33 UTC (permalink / raw
To: emacs-devel
BTW, apparently the `invisible' `display' property affects frame positioning.
I use dired-details.el, which puts an overlay on all of the Dired fields except
the file name. The overlay has `evaporate' = t, `invisible' = t, and
`before-string' = "".
As a result, if I do (make-frame '((left . -10) (top . -10))) with such a Dired
frame current, it positions the new frame as if its right edge were the same as
the original frame before hiding the details.
That is, the narrow frame (because no permissions, time etc. are shown) appears
in the middle of the screen - it does not have its right edge 10 pixels past the
screen right edge. It is not the right edge of the actual frame that is
positioned correctly, but the right edge of the frame as it would have appeared
without hiding anything.
Dunno if this should be considered a bug or not, but it's interesting. ;-)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 16:31 ` Jan Djärv
2010-04-13 17:02 ` Drew Adams
@ 2010-04-13 23:41 ` YAMAMOTO Mitsuharu
2010-04-14 4:51 ` Jan Djärv
1 sibling, 1 reply; 17+ messages in thread
From: YAMAMOTO Mitsuharu @ 2010-04-13 23:41 UTC (permalink / raw
To: Jan Djärv; +Cc: David Kastrup, emacs-devel
>>>>> On Tue, 13 Apr 2010 18:31:20 +0200, Jan Djärv <jan.h.d@swipnet.se> said:
> David Kastrup skrev 2010-04-13 17.26:
>> Jan Djärv<jan.h.d@swipnet.se> writes:
>>
>>> The problem in Emacs is how do you say the equivalent to
>>>
>>> -geometry --10--10, -geometry +-10+-10
>>>
>>> in frame parameters?
>>
>> (make-frame '((right . -10) (bottom . -10)))
>>
>> (make-frame '((left . -10) (top . -10)))
>>
>> would seem like a reasonably obvious way.
>>
> You would think that, but I found out that is actually:
> (make-frame '((right . (- -10)) (left . (- -10)))
> and
> (make-frame '((right . (+ -10)) (left . (+ -10)))
Apparently you meant
(make-frame '((top . (- -10)) (left . (- -10))))
and
(make-frame '((top . (+ -10)) (left . (+ -10))))
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Negative positions in frame parameters
2010-04-13 23:41 ` YAMAMOTO Mitsuharu
@ 2010-04-14 4:51 ` Jan Djärv
0 siblings, 0 replies; 17+ messages in thread
From: Jan Djärv @ 2010-04-14 4:51 UTC (permalink / raw
To: YAMAMOTO Mitsuharu; +Cc: David Kastrup, emacs-devel@gnu.org
14 apr 2010 kl. 01.41 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp
>:
>>>>>> On Tue, 13 Apr 2010 18:31:20 +0200, Jan Djärv <jan.h.d@swi
>>>>>> pnet.se> said:
>
>> You would think that, but I found out that is actually:
>
>> (make-frame '((right . (- -10)) (left . (- -10)))
>> and
>> (make-frame '((right . (+ -10)) (left . (+ -10)))
>
> Apparently you meant
>
> (make-frame '((top . (- -10)) (left . (- -10))))
> and
> (make-frame '((top . (+ -10)) (left . (+ -10))))
>
Apparently :-)
Jan D.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-04-14 4:51 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-13 13:24 Negative positions in frame parameters Stefan Monnier
2010-04-13 13:33 ` Lennart Borgman
2010-04-13 14:12 ` Stephen J. Turnbull
2010-04-13 16:17 ` Jason Rumney
2010-04-13 17:14 ` Jan Djärv
2010-04-13 17:33 ` Drew Adams
2010-04-13 14:41 ` Jan Djärv
2010-04-13 15:26 ` David Kastrup
2010-04-13 16:31 ` Jan Djärv
2010-04-13 17:02 ` Drew Adams
2010-04-13 23:41 ` YAMAMOTO Mitsuharu
2010-04-14 4:51 ` Jan Djärv
2010-04-13 16:09 ` Stefan Monnier
2010-04-13 17:07 ` Jan Djärv
2010-04-13 15:18 ` Jan Djärv
2010-04-13 16:10 ` Stefan Monnier
2010-04-13 17:08 ` Jan Djärv
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).