* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
@ 2011-01-11 0:21 Drew Adams
2011-01-11 4:40 ` Lennart Borgman
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2011-01-11 0:21 UTC (permalink / raw)
To: 7822
Enhancement request.
See emacs-devel thread "`fit-window-to-buffer-as-displayed'?",
2011-01-10:
http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html
`fit-window-to-buffer' does not take any display artefacts into account,
except for visual (screen) lines. The enhancement would be to have it
do so.
How much it tries to do so should be under programmer control, so that,
e.g., one could tell it (e.g. via a new optional parameter) not to take
any display stuff into account (i.e., to treat the buffer content as
just plain text with a fixed-width font of the current char size).
See the emacs-devel thread for more info about this.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-01-03 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-11 0:21 bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account Drew Adams
@ 2011-01-11 4:40 ` Lennart Borgman
2011-01-12 2:14 ` Lennart Borgman
0 siblings, 1 reply; 17+ messages in thread
From: Lennart Borgman @ 2011-01-11 4:40 UTC (permalink / raw)
To: Drew Adams; +Cc: 7822
On Tue, Jan 11, 2011 at 1:21 AM, Drew Adams <drew.adams@oracle.com> wrote:
> Enhancement request.
>
> See emacs-devel thread "`fit-window-to-buffer-as-displayed'?",
> 2011-01-10:
> http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html
>
> `fit-window-to-buffer' does not take any display artefacts into account,
> except for visual (screen) lines. The enhancement would be to have it
> do so.
>
> How much it tries to do so should be under programmer control, so that,
> e.g., one could tell it (e.g. via a new optional parameter) not to take
> any display stuff into account (i.e., to treat the buffer content as
> just plain text with a fixed-width font of the current char size).
>
> See the emacs-devel thread for more info about this.
I think this would be a bit easier if adjust_window_trailing_edge gave
different error messages for different problems, i.e. "too small",
"too big" etc.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-11 4:40 ` Lennart Borgman
@ 2011-01-12 2:14 ` Lennart Borgman
2011-01-12 3:16 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: Lennart Borgman @ 2011-01-12 2:14 UTC (permalink / raw)
To: Drew Adams, Stefan Monnier; +Cc: 7822
I started writing a solution for this (could we please move the
discussion here?). It is not ready, but I paste it here for comments.
The part currently fails because window-line-height returns nil -
which I think is another Emacs bug.
Anyway here is what I have written so far:
(defun winsize-fit-window-to-buffer (&optional window max-height min-height)
"A more complete `fit-window-to-buffer'. Fix-me: not ready, bug# 7822.
Find through an iterative search minimal height to display whole
buffer \(narrowed part if narrowed) and set window height to that
height. Or, if that can not be done then set the height to the
best possible height for fit.
Try first to adjust window below and if that is not enough window
above.
"
(let* ((window (or window (selected-window)))
(frm (window-frame window))
(frm-height (frame-height frm))
here
(above (windmove-find-other-window 'up nil window))
(below (windmove-find-other-window 'down nil window))
;;(wcfg (current-window-configuration frm))
window-configuration-change-hook
(eob-in-win (= (window-end window t) (point-max)))
(curh (window-height window))
(minh (if (not eob-in-win)
curh
(or min-height window-min-height)))
(orig-minh minh)
(maxh (if eob-in-win
curh
(or max-height frm-height)))
(orig-maxh maxh)
midh
done)
(when (window-minibuffer-p below)
(setq below nil))
(when (or above below)
(with-current-buffer (window-buffer window)
(setq here (point))
;; First try resizing window below.
(when below
(while (and (not done) (> maxh minh))
(setq midh (+ minh (/ (- maxh minh) 2)))
(let* ((winh (window-height window))
(delta (- midh winh))
did-it)
(condition-case err
(progn
(adjust-window-trailing-edge window delta nil)
(setq did-it t))
(error
(message "%S" err)))
(if did-it
(progn
(goto-char (point-min))
;; Fix-me: This unfortunately returns t even if
;; the last line is partly hidden (test example
;; help for posn-at-x-y):
(setq eob-in-win (= (window-end window t) (point-max)))
;; So let us try another way to check if eob is in window:
(let* ((edges (window-inside-pixel-edges))
(left (1+ (nth 0 edges)))
(bottom (1- (nth 3 edges))))
(setq eob-in-win
(= (point-max)
(posn-point (posn-at-x-y left bottom frm)))))
(if eob-in-win
;; Fix-me: This assumes that posn-at-point is
;; relative to window text area.
(let* ((loc (event-end (posn-at-point
(point-max) window)))
(loc-bottom (cdr loc))
(edges (window-inside-pixel-edges window))
(win-top (nth 1 edges))
(win-bottom (nth 3 edges))
(win-rel-bottom (- win-bottom win-top))
;; Fix-me: This returns nil even though
;; we have updated above with
;; (window-end window t) and also after
;; (redisplay t) or (sit-for 0).
(dummy (redisplay t))
(dummy2 (sit-for 0))
(bottom-line-height (window-line-height
(line-number-at-pos (1- (point-max)))
window)))
;; Make a guess if we are ready.
(when (> bottom-line-height
(- win-rel-bottom loc-bottom))
(setq done t))
(setq maxh midh))
(setq minh midh)))
(if (< 0 delta)
(setq maxh (1- maxh))
(setq minh (1+ minh))))
)))
;; If we are not done try window above.
(when above
(while (and (not done) (> maxh minh))
(setq midh (+ minh (/ (- maxh minh) 2)))
(let* ((winh (window-height window))
(delta (- winh midh))
did-it)
;; (when (> 0 delta) ;; Check window above min height
;; (setq delta (max delta
;; (- window-min-height
;; (window-height above))))
;; (setq midh (- delta winh)))
(condition-case err
(progn
(adjust-window-trailing-edge above delta nil)
(setq did-it t))
(error
(message "%S" err)))
(if did-it
(progn
(goto-char (point-min))
(setq eob-in-win (= (window-end window t) (point-max)))
(if eob-in-win
(setq maxh midh)
(setq minh midh)))
(if (> 0 delta)
(setq maxh (1- maxh))
(setq minh (1+ minh))))
)))
(goto-char here))
)))
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-12 2:14 ` Lennart Borgman
@ 2011-01-12 3:16 ` Drew Adams
2011-01-12 10:40 ` Lennart Borgman
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2011-01-12 3:16 UTC (permalink / raw)
To: 'Lennart Borgman', 'Stefan Monnier'; +Cc: 7822
> Try first to adjust window below and if that is not enough window
> above.
I looked only at the doc string. Whatever we do for `fit-window-to-buffer', it
should _not_ take any other windows into account or have any effect on any other
windows. This is only about fitting a window to its buffer as displayed.
Whatever effects that might have on other windows are derivative, and not to be
taken into account in this function.
It sounds like you are doing something different from what this bug is about.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-12 3:16 ` Drew Adams
@ 2011-01-12 10:40 ` Lennart Borgman
2011-01-12 11:33 ` Lennart Borgman
0 siblings, 1 reply; 17+ messages in thread
From: Lennart Borgman @ 2011-01-12 10:40 UTC (permalink / raw)
To: Drew Adams; +Cc: 7822
On Wed, Jan 12, 2011 at 4:16 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> Try first to adjust window below and if that is not enough window
>> above.
>
> I looked only at the doc string. Whatever we do for `fit-window-to-buffer', it
> should _not_ take any other windows into account or have any effect on any other
> windows. This is only about fitting a window to its buffer as displayed.
> Whatever effects that might have on other windows are derivative, and not to be
> taken into account in this function.
>
> It sounds like you are doing something different from what this bug is about.
Not really, but your answer makes me realize that my solution above is
not enough.
And I actually have a better solution in winsize.el, but it is quite a
bit more elaborate and probably not what we want.
Instead I believe we want a variant of enlarge-window that is not
allowed to delete-windows. Building on that we can make a more simple
solution.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-12 10:40 ` Lennart Borgman
@ 2011-01-12 11:33 ` Lennart Borgman
2011-01-12 15:11 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: Lennart Borgman @ 2011-01-12 11:33 UTC (permalink / raw)
To: Drew Adams; +Cc: 7822
On Wed, Jan 12, 2011 at 11:40 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Wed, Jan 12, 2011 at 4:16 AM, Drew Adams <drew.adams@oracle.com> wrote:
>>> Try first to adjust window below and if that is not enough window
>>> above.
>>
>> I looked only at the doc string. Whatever we do for `fit-window-to-buffer', it
>> should _not_ take any other windows into account or have any effect on any other
>> windows. This is only about fitting a window to its buffer as displayed.
>> Whatever effects that might have on other windows are derivative, and not to be
>> taken into account in this function.
>>
>> It sounds like you are doing something different from what this bug is about.
>
> Not really, but your answer makes me realize that my solution above is
> not enough.
>
> And I actually have a better solution in winsize.el, but it is quite a
> bit more elaborate and probably not what we want.
To be more clear: I was taking into account to few windows. All
windows below and above must be taken into account.
And I somehow forgot to implement this in resize-windows (which is in
winsize.el). It is a little bit complicated so I can't do it that
quickly.
> Instead I believe we want a variant of enlarge-window that is not
> allowed to delete-windows. Building on that we can make a more simple
> solution.
Perhaps that is wrong. That would only mean pushing the logic above to
the C level.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-12 11:33 ` Lennart Borgman
@ 2011-01-12 15:11 ` Drew Adams
2011-01-12 17:55 ` Lennart Borgman
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2011-01-12 15:11 UTC (permalink / raw)
To: 'Lennart Borgman'; +Cc: 7822
> To be more clear: I was taking into account to few windows. All
> windows below and above must be taken into account.
I don't see why _any_ windows should be taken into account. The window for the
buffer should be resized to fit the displayed buffer, period. If that is not
possible for some reason, then we decide what to do.
For that decision, I would imagine that we decide the same way we decide now
when you try to resize a window to size S and that is not possible. Why is this
case any different from other resizing cases?
AFAICT, all that's involved here is to determine the desired window size.
Beyond that, there should be nothing new.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-12 15:11 ` Drew Adams
@ 2011-01-12 17:55 ` Lennart Borgman
2011-01-12 18:24 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: Lennart Borgman @ 2011-01-12 17:55 UTC (permalink / raw)
To: Drew Adams; +Cc: 7822
On Wed, Jan 12, 2011 at 4:11 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> To be more clear: I was taking into account to few windows. All
>> windows below and above must be taken into account.
>
> I don't see why _any_ windows should be taken into account. The window for the
> buffer should be resized to fit the displayed buffer, period. If that is not
> possible for some reason, then we decide what to do.
Hm. Just because you have to actually do the resizing and that affects
other windows and a decision has to be made how?
> For that decision, I would imagine that we decide the same way we decide now
> when you try to resize a window to size S and that is not possible. Why is this
> case any different from other resizing cases?
Do we really have good ways to easily solve this? Maybe I am missing
something? Perhaps you have some specific suggestion for how to do
this? Which functions do you think supply the needed features?
> AFAICT, all that's involved here is to determine the desired window size.
> Beyond that, there should be nothing new.
One little detail of course: It should not delete other windows. (If
you allow it do delete other windows there are much simpler
implementations than the one I am suggesting. Much simpler.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2011-01-12 17:55 ` Lennart Borgman
@ 2011-01-12 18:24 ` Drew Adams
0 siblings, 0 replies; 17+ messages in thread
From: Drew Adams @ 2011-01-12 18:24 UTC (permalink / raw)
To: 'Lennart Borgman'; +Cc: 7822
> > I don't see why _any_ windows should be taken into account.
> > The window for the buffer should be resized to fit the
> > displayed buffer, period. If that is not possible for some
> > reason, then we decide what to do.
>
> Hm. Just because you have to actually do the resizing and that affects
> other windows and a decision has to be made how?
Yes, but that's the last part of what I wrote: "then we decide what to do".
And, a priori at least, that decision is the same anytime a window is resized.
IOW, a priori there is nothing special in that regard about fitting a window to
a buffer.
> > For that decision, I would imagine that we decide the same
> > way we decide now when you try to resize a window to size
> > S and that is not possible. Why is this
> > case any different from other resizing cases?
>
> Do we really have good ways to easily solve this?
I don't know, but that question is a general one and independent of _this_
bug/feature, which is fitting a window to its displayed buffer.
You are bringing in extraneous stuff. Interesting stuff no doubt, but not
specific to fitting a window to its buffer.
> Maybe I am missing something? Perhaps you have some
> specific suggestion for how to do
> this? Which functions do you think supply the needed features?
No I don't. No doubt window experts such as Martin have some ideas and have
already considered the question. My point is that it is outside the scope of
this thread. _Any_ time a window is resized the questions you raise are
pertinent - they have nothing in particular to do with _this_ resizing of a
window.
> > AFAICT, all that's involved here is to determine the
> > desired window size. Beyond that, there should be nothing new.
>
> One little detail of course: It should not delete other windows. (If
> you allow it do delete other windows there are much simpler
> implementations than the one I am suggesting. Much simpler.)
I repeat. I don't see why this resizing is any different from any other window
resizing.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-21 18:02 ` martin rudalics
@ 2014-09-22 9:02 ` martin rudalics
2014-09-22 14:02 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-09-22 9:02 UTC (permalink / raw)
To: 7822-done
> `fit-window-to-buffer' does not take any display artefacts into account,
> except for visual (screen) lines. The enhancement would be to have it
> do so.
As with emacs-24 `fit-window-to-buffer' does so. Bug closed.
Thanks, martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 9:02 ` bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account martin rudalics
@ 2014-09-22 14:02 ` Drew Adams
2014-09-22 17:42 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2014-09-22 14:02 UTC (permalink / raw)
To: martin rudalics, 7822-done
> > `fit-window-to-buffer' does not take any display artefacts into
> > account, except for visual (screen) lines. The enhancement would
> > be to have it do so.
>
> As with emacs-24 `fit-window-to-buffer' does so. Bug closed.
Thanks.
But is this enhancement request really fulfilled? The paragraph
after the intro one that you quote from the ER specifically
states the requirement:
How much it tries to do so should be under programmer
control, so that, e.g., one could tell it (e.g. via a new
optional parameter) not to take any display stuff into account
(i.e., to treat the buffer content as just plain text with a
fixed-width font of the current char size).
And the ER explicitly refers to this emacs-devel thread for
details: "`fit-window-to-buffer-as-displayed'?", 2011-01-10:
http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html
And of course, how users can control the behavior needs to be
well documented.
Is this ER really addressed? I don't have a Windows binary
more recent than 2014-08-15 to test (they are no longer being
built, it seems). If so, then yes this should be closed.
If not then it should not be closed, even if it is good that
some progress has apparently been made. Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 14:02 ` Drew Adams
@ 2014-09-22 17:42 ` martin rudalics
2014-09-22 18:24 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-09-22 17:42 UTC (permalink / raw)
To: Drew Adams, 7822-done
> But is this enhancement request really fulfilled? The paragraph
> after the intro one that you quote from the ER specifically
> states the requirement:
>
> How much it tries to do so should be under programmer
> control, so that, e.g., one could tell it (e.g. via a new
> optional parameter) not to take any display stuff into account
> (i.e., to treat the buffer content as just plain text with a
> fixed-width font of the current char size).
>
> And the ER explicitly refers to this emacs-devel thread for
> details: "`fit-window-to-buffer-as-displayed'?", 2011-01-10:
> http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html
The current behavior is, in fact, based on Stefan's remark that
There's no point trying to add support for some properties but not all:
adding support for all properties is likely to be easier because it'd
rely on (re)using the existing display code.
in that thread.
> And of course, how users can control the behavior needs to be
> well documented.
>
> Is this ER really addressed? I don't have a Windows binary
> more recent than 2014-08-15 to test (they are no longer being
> built, it seems).
The changes are from 2013 so the binaries you have should include them.
> If so, then yes this should be closed.
>
> If not then it should not be closed, even if it is good that
> some progress has apparently been made. Thanks.
If you can give a practical example where the present code fails to do
what you want, feel free to reopen the bug.
Thanks, martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 17:42 ` martin rudalics
@ 2014-09-22 18:24 ` Drew Adams
2014-09-22 19:31 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2014-09-22 18:24 UTC (permalink / raw)
To: martin rudalics, 7822-done
> If you can give a practical example where the present code fails to
> do what you want, feel free to reopen the bug.
I think I understand your reply, but I don't see anything in it that
directly answers the question:
Does a user have a way to "tell it *not* to take any display stuff
into account (i.e., to treat the buffer content as just plain text
with a fixed-width font of the current char size)"? IOW, optional
simple fit, disregarding/ignoring display artefacts.
The ER is for that and more. It asks that a user be able to control
"how much" it "takes display artefacts into account". But just
being able to tell it not to take any into account would probably
be acceptable.
If there is no way to even do that then the ER is not satisfied,
and it should be left open until a user has the option of turning
off this taking-display-artefacts-into-account.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 18:24 ` Drew Adams
@ 2014-09-22 19:31 ` Stefan Monnier
2014-09-22 20:24 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2014-09-22 19:31 UTC (permalink / raw)
To: Drew Adams; +Cc: 7822, 7822-done
> The ER is for that and more. It asks that a user be able to control
> "how much" it "takes display artefacts into account". But just
> being able to tell it not to take any into account would probably
> be acceptable.
Could we have at least some kind of motivating example for why one might
want that kind of control?
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 19:31 ` Stefan Monnier
@ 2014-09-22 20:24 ` Drew Adams
2014-09-22 20:54 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2014-09-22 20:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7822, 7822-done
> > The ER is for that and more. It asks that a user be able to
> > control "how much" it "takes display artefacts into account".
> > But just being able to tell it not to take any into account
> > would probably be acceptable.
>
> Could we have at least some kind of motivating example for why one
> might want that kind of control?
1. He who can do more can do less.
2. That is what the function did before the ER. Some users might
prefer that longstanding behavior generally.
3. Code might want to handle things differently than the current
automatic handling. In particular, it might want to not take into
account some display artefacts, or to deal with them differently.
It is likely to be harder for code to compensate for automatic,
fancy fitting than it would be to add custom fitting behavior to
rudimentary-fit behavior. Best would be as the ER suggested: be
able to choose just which display artefacts are to be taken into
account.
4. Providing also a simple, no-bells-and-whistles behavior lets
users roll their own fitting behavior (#3). Providing only a
one-size-fits-all-do-everything behavior does not. Keep our
options open.
5. What extra cost is there, to provide this flexibility? (See
#1.)
6. Finally, that is what the ER explicitly requested (!). It did
not ask for only do-it-all behavior. It asked to allow users to
be able to obtain that behavior and to do without it - au choix.
The request stands, unless it has been realized. Has it?
I might have had additional things explicitly in mind when I filed
the ER almost 4 years ago, but at least these simple motivations
come to mind immediately now.
I haven't seen where the code for this is (where is it?). If this
was "fixed" in Lisp code then presumably it will be possible for
users to tease apart the various parts, in order to, in the end,
put together whatever behavior they need. But if this was "fixed"
in C code then there is all the more need for explicit provision
for users to turn parts of it off.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 20:24 ` Drew Adams
@ 2014-09-22 20:54 ` Stefan Monnier
2014-09-22 21:04 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2014-09-22 20:54 UTC (permalink / raw)
To: Drew Adams; +Cc: 7822-done
> 1. He who can do more can do less.
[..etc...]
None of these are motivating examples. If a need ever comes up, we can
open a new bug.
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 20:54 ` Stefan Monnier
@ 2014-09-22 21:04 ` Drew Adams
0 siblings, 0 replies; 17+ messages in thread
From: Drew Adams @ 2014-09-22 21:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7822-done
> > 1. He who can do more can do less.
> [..etc...]
>
> None of these are motivating examples. If a need ever comes up, we
> can open a new bug.
The enhancement request is not fulfilled, and you have decided that
it should not be. So be it. The proper way to close it in that
case is to classify it as "won't fix", not as "done".
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-09-22 21:04 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-11 0:21 bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account Drew Adams
2011-01-11 4:40 ` Lennart Borgman
2011-01-12 2:14 ` Lennart Borgman
2011-01-12 3:16 ` Drew Adams
2011-01-12 10:40 ` Lennart Borgman
2011-01-12 11:33 ` Lennart Borgman
2011-01-12 15:11 ` Drew Adams
2011-01-12 17:55 ` Lennart Borgman
2011-01-12 18:24 ` Drew Adams
-- strict thread matches above, loose matches on Subject: below --
2008-11-14 22:46 bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Themba Fletcher
2014-09-21 18:02 ` martin rudalics
2014-09-22 9:02 ` bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account martin rudalics
2014-09-22 14:02 ` Drew Adams
2014-09-22 17:42 ` martin rudalics
2014-09-22 18:24 ` Drew Adams
2014-09-22 19:31 ` Stefan Monnier
2014-09-22 20:24 ` Drew Adams
2014-09-22 20:54 ` Stefan Monnier
2014-09-22 21:04 ` Drew Adams
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).