* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
@ 2009-05-29 19:03 Leo
2009-05-29 23:46 ` Jay Belanger
2012-10-04 13:18 ` martin rudalics
0 siblings, 2 replies; 43+ messages in thread
From: Leo @ 2009-05-29 19:03 UTC (permalink / raw)
To: emacs-pretest-bug
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
Packages such as calc or calendar that use a small window does not play
well with temp-buffer-resize-mode. i.e. their windows get enlarged by
temp-buffer-resize-mode. In the case of calc, the size change is
permanent.
1. Emacs -Q
2. (temp-buffer-resize-mode t)
3. M-x calc
4. h h
You will notice that calc-window-height is changed to a much larger
value. Calendar also has this similar problem but it can restore to its
default height after restarting itself.
GNU Emacs 23.0.94.1 (i386-apple-darwin9.7.0, NS apple-appkit-949.46) of
2009-05-23 on 200.sub-75-216-116.myvzw.com
Best wishes,
Leo
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-29 19:03 bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode Leo
@ 2009-05-29 23:46 ` Jay Belanger
2009-05-30 1:43 ` Leo
2012-10-04 13:18 ` martin rudalics
1 sibling, 1 reply; 43+ messages in thread
From: Jay Belanger @ 2009-05-29 23:46 UTC (permalink / raw)
To: emacs-pretest-bug
> Packages such as calc or calendar that use a small window does not play
> well with temp-buffer-resize-mode. i.e. their windows get enlarged by
> temp-buffer-resize-mode. In the case of calc, the size change is
> permanent.
Calc keeps track of changes to its size, and restarts it in the last
size that it had. Why is that a problem?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-29 23:46 ` Jay Belanger
@ 2009-05-30 1:43 ` Leo
2009-05-30 2:15 ` Jay Belanger
0 siblings, 1 reply; 43+ messages in thread
From: Leo @ 2009-05-30 1:43 UTC (permalink / raw)
To: emacs-pretest-bug; +Cc: bug-gnu-emacs
On 2009-05-30 00:46 +0100, Jay Belanger wrote:
>> Packages such as calc or calendar that use a small window does not play
>> well with temp-buffer-resize-mode. i.e. their windows get enlarged by
>> temp-buffer-resize-mode. In the case of calc, the size change is
>> permanent.
>
> Calc keeps track of changes to its size, and restarts it in the last
> size that it had. Why is that a problem?
When temp-buffer-resize-mode is enabled, `C-h v' on a variable that has
2 or 3 lines of documentation will make the calc window takes up 70-80%
of the frame. See this screen shot http://imagebin.org/50896
It might be good to track the size, but when the size change is caused
by a program instead of the user, it can be annoying.
For example, when I'm editing some file and need some calculations, I'd
like calc to take up as little screen estate as possible so that the
file is visible to help me with the calculations.
But I'm not sure whether this is a bug in calc or temp-buffer-resize-mode.
--
.: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 1:43 ` Leo
@ 2009-05-30 2:15 ` Jay Belanger
2009-05-30 9:51 ` martin rudalics
2009-06-02 15:57 ` Leo
0 siblings, 2 replies; 43+ messages in thread
From: Jay Belanger @ 2009-05-30 2:15 UTC (permalink / raw)
To: emacs-pretest-bug, bug-gnu-emacs
Leo <sdl.web@gmail.com> writes:
...
> But I'm not sure whether this is a bug in calc or temp-buffer-resize-mode.
Or neither, and simply unexpected behavior.
I've never used temp-buffer-resize-mode before, but if it's supposed to
make a window a better size for displaying a temporary buffer, I'm
surprised it doesn't change anything back when the buffer is killed or
hidden. In this case, I'm not sure it's Calc's job to keep track of why
it changed its window size. Perhaps an option "Always start Calc with
the initial window height" might be helpful.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 2:15 ` Jay Belanger
@ 2009-05-30 9:51 ` martin rudalics
2009-05-30 10:58 ` Leo
2011-10-24 11:07 ` Leo
2009-06-02 15:57 ` Leo
1 sibling, 2 replies; 43+ messages in thread
From: martin rudalics @ 2009-05-30 9:51 UTC (permalink / raw)
To: jay.p.belanger, 3419
>> But I'm not sure whether this is a bug in calc or temp-buffer-resize-mode.
>
> Or neither, and simply unexpected behavior.
> I've never used temp-buffer-resize-mode before, but if it's supposed to
> make a window a better size for displaying a temporary buffer, I'm
> surprised it doesn't change anything back when the buffer is killed or
> hidden.
Changing window sizes when `temp-buffer-resize-mode' exits is tricky.
That is, we could restore the window configuration that existed when
`temp-buffer-resize-mode' was started but that has the often unwanted
side-effect that other windows created (deleted) in the meantime get
deleted (resurrected).
> In this case, I'm not sure it's Calc's job to keep track of why
> it changed its window size. Perhaps an option "Always start Calc with
> the initial window height" might be helpful.
Calc could make its windows fixed-size but that's hardly reasonable with
the current handling of fixed-size windows. Any option affecting only
the initial size of Calc windows won't help in the present case either.
We could give Calc window parameters, say ideal-height and ideal-width,
and try to use these when exiting `temp-buffer-resize-mode' but writing
the corresponding code won't be trivial.
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 9:51 ` martin rudalics
@ 2009-05-30 10:58 ` Leo
2009-05-30 12:19 ` martin rudalics
2011-10-24 11:07 ` Leo
1 sibling, 1 reply; 43+ messages in thread
From: Leo @ 2009-05-30 10:58 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
On 2009-05-30 10:51 +0100, martin rudalics wrote:
>>> But I'm not sure whether this is a bug in calc or temp-buffer-resize-mode.
>>
>> Or neither, and simply unexpected behavior.
>> I've never used temp-buffer-resize-mode before, but if it's supposed to
>> make a window a better size for displaying a temporary buffer, I'm
>> surprised it doesn't change anything back when the buffer is killed or
>> hidden.
>
> Changing window sizes when `temp-buffer-resize-mode' exits is tricky.
> That is, we could restore the window configuration that existed when
> `temp-buffer-resize-mode' was started but that has the often unwanted
> side-effect that other windows created (deleted) in the meantime get
> deleted (resurrected).
>
>> In this case, I'm not sure it's Calc's job to keep track of why
>> it changed its window size. Perhaps an option "Always start Calc with
>> the initial window height" might be helpful.
>
> Calc could make its windows fixed-size but that's hardly reasonable with
> the current handling of fixed-size windows. Any option affecting only
> the initial size of Calc windows won't help in the present case either.
> We could give Calc window parameters, say ideal-height and ideal-width,
> and try to use these when exiting `temp-buffer-resize-mode' but writing
> the corresponding code won't be trivial.
>
> martin
I wonder if it may be possible to distinguish program or human changing
the size. In most cases, when a program (in this case:
temp-buffer-resize-mode) changes the size, it is hardly ideal to keep
that change. But I agree that for example, if a user drags the calc
window to be bigger, it is desirable to keep that change permanent.
At the moment I have to have (setq calc-window-height 7) at my finger
tip to get rid of the size change sometimes accidentally happens.
Leo
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 10:58 ` Leo
@ 2009-05-30 12:19 ` martin rudalics
2009-05-30 18:21 ` Glenn Morris
0 siblings, 1 reply; 43+ messages in thread
From: martin rudalics @ 2009-05-30 12:19 UTC (permalink / raw)
To: Leo; +Cc: 3419
> I wonder if it may be possible to distinguish program or human changing
> the size. In most cases, when a program (in this case:
> temp-buffer-resize-mode) changes the size, it is hardly ideal to keep
> that change. But I agree that for example, if a user drags the calc
> window to be bigger, it is desirable to keep that change permanent.
It can be done but it's not trivial.
> At the moment I have to have (setq calc-window-height 7) at my finger
> tip to get rid of the size change sometimes accidentally happens.
In your use case it might make sense to set `split-height-threshold' to
a smaller value so the "other" window gets split instead of reused.
Alternatively we could allow `temp-buffer-resize-mode' to resize a
window iff it was obtained by splitting a window before.
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 12:19 ` martin rudalics
@ 2009-05-30 18:21 ` Glenn Morris
2009-05-30 22:37 ` Leo
0 siblings, 1 reply; 43+ messages in thread
From: Glenn Morris @ 2009-05-30 18:21 UTC (permalink / raw)
To: 3419
I winder if temp-buffer-resize-mode should only do its thing if the
window displaying the temp-buffer was created specifically to show
said buffer. If it was a pre-existing window, it should leave it
alone. ?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 18:21 ` Glenn Morris
@ 2009-05-30 22:37 ` Leo
0 siblings, 0 replies; 43+ messages in thread
From: Leo @ 2009-05-30 22:37 UTC (permalink / raw)
To: Glenn Morris; +Cc: 3419
On 2009-05-30 19:21 +0100, Glenn Morris wrote:
> I winder if temp-buffer-resize-mode should only do its thing if the
> window displaying the temp-buffer was created specifically to show
> said buffer. If it was a pre-existing window, it should leave it
> alone. ?
This seems to imply that if before displaying the temp-buffer there's
only one window do the resize otherwise do nothing. This is better than
the default behaviour because temp-buffer-resize-mode is only useful in
very limited cases.
--
.: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 9:51 ` martin rudalics
2009-05-30 10:58 ` Leo
@ 2011-10-24 11:07 ` Leo
2011-10-24 16:15 ` martin rudalics
1 sibling, 1 reply; 43+ messages in thread
From: Leo @ 2011-10-24 11:07 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
On 2009-05-30 17:51 +0800, martin rudalics wrote:
[snipped 18 lines]
> Calc could make its windows fixed-size but that's hardly reasonable with
> the current handling of fixed-size windows. Any option affecting only
> the initial size of Calc windows won't help in the present case either.
> We could give Calc window parameters, say ideal-height and ideal-width,
> and try to use these when exiting `temp-buffer-resize-mode' but writing
> the corresponding code won't be trivial.
>
> martin
Is there a satisfactory solution in light of the new windowing features?
Leo
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-10-24 11:07 ` Leo
@ 2011-10-24 16:15 ` martin rudalics
2011-10-25 2:17 ` Leo
2011-10-31 10:34 ` Juri Linkov
0 siblings, 2 replies; 43+ messages in thread
From: martin rudalics @ 2011-10-24 16:15 UTC (permalink / raw)
To: Leo; +Cc: 3419
>> Calc could make its windows fixed-size but that's hardly reasonable with
>> the current handling of fixed-size windows. Any option affecting only
>> the initial size of Calc windows won't help in the present case either.
>> We could give Calc window parameters, say ideal-height and ideal-width,
>> and try to use these when exiting `temp-buffer-resize-mode' but writing
>> the corresponding code won't be trivial.
>>
>> martin
>
> Is there a satisfactory solution in light of the new windowing features?
It depends on what you want. You can resove the example in your
original posting
> 1. Emacs -Q
> 2. (temp-buffer-resize-mode t)
> 3. M-x calc
> 4. h h
by doing
(setq temp-buffer-max-height
(lambda (buffer)
(max
(window-total-size)
(/ (- (frame-height) 2) 2))))
in your .emacs (personally I think that this should be the default
value). If you refer to Jay's remark
> I've never used temp-buffer-resize-mode before, but if it's supposed to
> make a window a better size for displaying a temporary buffer, I'm
> surprised it doesn't change anything back when the buffer is killed or
> hidden.
that is you want to get the *scratch* window back in its original size,
then typing "q" in the help window should do what you want.
martin
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-10-24 16:15 ` martin rudalics
@ 2011-10-25 2:17 ` Leo
2011-10-25 2:47 ` Jay Belanger
2011-10-31 10:34 ` Juri Linkov
1 sibling, 1 reply; 43+ messages in thread
From: Leo @ 2011-10-25 2:17 UTC (permalink / raw)
To: 3419
On 2011-10-25 00:15 +0800, martin rudalics wrote:
>> 1. Emacs -Q
>> 2. (temp-buffer-resize-mode t)
>> 3. M-x calc
>> 4. h h
>
> by doing
>
> (setq temp-buffer-max-height
> (lambda (buffer)
> (max
> (window-total-size)
> (/ (- (frame-height) 2) 2))))
>
> in your .emacs (personally I think that this should be the default
> value). If you refer to Jay's remark
Thanks, this seems to work well. But I am using a build from 2011-09-04.
Also I have noticed that `q' in calc no longer deletes all its windows.
So after hitting `q', I am left with three windows on the frame as shown
here: http://i.imgur.com/jFKG5.jpg.
Leo
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-10-25 2:17 ` Leo
@ 2011-10-25 2:47 ` Jay Belanger
2011-10-25 15:20 ` Leo
0 siblings, 1 reply; 43+ messages in thread
From: Jay Belanger @ 2011-10-25 2:47 UTC (permalink / raw)
To: Leo; +Cc: 3419
Leo <sdl.web@gmail.com> writes:
...
> Thanks, this seems to work well. But I am using a build from 2011-09-04.
> Also I have noticed that `q' in calc no longer deletes all its windows.
> So after hitting `q', I am left with three windows on the frame as shown
> here: http://i.imgur.com/jFKG5.jpg.
I haven't been able to recreate this with a current build.
I tried it from a gnus buffer, as you did, and from the scratch
buffer. I tried it with and without the temp-buffer adjustments that
martin mentioned. Nothing in calc.el has changed since 2011-09-04,
either.
Is there anything special you did before you started and quit Calc?
Jay
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-10-25 2:47 ` Jay Belanger
@ 2011-10-25 15:20 ` Leo
0 siblings, 0 replies; 43+ messages in thread
From: Leo @ 2011-10-25 15:20 UTC (permalink / raw)
To: jay.p.belanger; +Cc: 3419
On 2011-10-25 10:47 +0800, Jay Belanger wrote:
> I haven't been able to recreate this with a current build. I tried it
> from a gnus buffer, as you did, and from the scratch buffer. I tried
> it with and without the temp-buffer adjustments that martin mentioned.
> Nothing in calc.el has changed since 2011-09-04, either. Is there
> anything special you did before you started and quit Calc?
I have just tried it with the latest build and the problem is gone.
Leo
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-10-24 16:15 ` martin rudalics
2011-10-25 2:17 ` Leo
@ 2011-10-31 10:34 ` Juri Linkov
2011-10-31 18:56 ` Jay Belanger
1 sibling, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2011-10-31 10:34 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
>> Is there a satisfactory solution in light of the new windowing features?
>
> It depends on what you want. You can resove the example in your
> original posting
>
>> 1. Emacs -Q
>> 2. (temp-buffer-resize-mode t)
>> 3. M-x calc
>> 4. h h
When I type `M-x calc RET h h', it displays the *Help* window in the
Calc window that is too small to read comfortably the Help buffer.
That's because I have in .emacs:
(add-to-list 'same-window-buffer-names "*Help*")
Is it possible to display the Help buffer in another window in this case
when `h h' is typed in the Calc window?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-10-31 10:34 ` Juri Linkov
@ 2011-10-31 18:56 ` Jay Belanger
2011-11-01 9:27 ` Juri Linkov
0 siblings, 1 reply; 43+ messages in thread
From: Jay Belanger @ 2011-10-31 18:56 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
Juri Linkov <juri@jurta.org> writes:
...
> When I type `M-x calc RET h h', it displays the *Help* window in the
> Calc window that is too small to read comfortably the Help buffer.
>
> That's because I have in .emacs:
> (add-to-list 'same-window-buffer-names "*Help*")
>
> Is it possible to display the Help buffer in another window in this case
> when `h h' is typed in the Calc window?
I'm not sure what you want, since you are explicitly telling Emacs to
display Help in the same window. Is that line from your .emacs for some
other *Help* buffer, and you never want the Calc help to appear in the
same window? Perhaps if the Calc help were named "*Calc Help*" (or
better, perhaps, using a variable to determine the name,
`calc-help-buffer-name' or somesuch). That wouldn't be hard, but
perhaps should wait until after 24.1.
Jay
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-10-31 18:56 ` Jay Belanger
@ 2011-11-01 9:27 ` Juri Linkov
2011-11-01 14:38 ` martin rudalics
0 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2011-11-01 9:27 UTC (permalink / raw)
To: jay.p.belanger; +Cc: 3419
>> When I type `M-x calc RET h h', it displays the *Help* window in the
>> Calc window that is too small to read comfortably the Help buffer.
>>
>> That's because I have in .emacs:
>> (add-to-list 'same-window-buffer-names "*Help*")
>>
>> Is it possible to display the Help buffer in another window in this case
>> when `h h' is typed in the Calc window?
>
> I'm not sure what you want, since you are explicitly telling Emacs to
> display Help in the same window. Is that line from your .emacs for some
> other *Help* buffer, and you never want the Calc help to appear in the
> same window? Perhaps if the Calc help were named "*Calc Help*" (or
> better, perhaps, using a variable to determine the name,
> `calc-help-buffer-name' or somesuch). That wouldn't be hard, but
> perhaps should wait until after 24.1.
Some modes bind `same-window-buffer-names' to nil when it makes no sense
to display the *Help* or *Info* buffer in the same window when it is
too small, thus overridding the user's settings.
IIUC, with the new window rules, the right way to do this is to bind
`display-buffer-overriding-action' to `display-buffer-pop-up-window'.
But this doesn't work as expected:
(let ((display-buffer-overriding-action '(display-buffer-pop-up-window)))
(with-output-to-temp-buffer "*Help*"
(princ "GNU Emacs Calculator.\n")))
It still displays the *Help* buffer in the same window when
(add-to-list 'same-window-buffer-names "*Help*") is presented in .emacs.
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-01 9:27 ` Juri Linkov
@ 2011-11-01 14:38 ` martin rudalics
2011-11-01 20:00 ` Stefan Monnier
2011-11-01 21:54 ` Juri Linkov
0 siblings, 2 replies; 43+ messages in thread
From: martin rudalics @ 2011-11-01 14:38 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
> Some modes bind `same-window-buffer-names' to nil when it makes no sense
> to display the *Help* or *Info* buffer in the same window when it is
> too small, thus overridding the user's settings.
>
> IIUC, with the new window rules, the right way to do this is to bind
> `display-buffer-overriding-action' to `display-buffer-pop-up-window'.
> But this doesn't work as expected:
>
> (let ((display-buffer-overriding-action '(display-buffer-pop-up-window)))
> (with-output-to-temp-buffer "*Help*"
> (princ "GNU Emacs Calculator.\n")))
>
> It still displays the *Help* buffer in the same window when
> (add-to-list 'same-window-buffer-names "*Help*") is presented in .emacs.
I suppose because `display-buffer-pop-up-window' cannot split the window
due to `split-height-threshold' being too large. You really just wanted
to add (inhibit-same-window . t) somewhere.
A related problem: With emacs -Q insert and evaluate in *scratch* the
form
(customize-set-variable
'display-buffer-alist
'(("\\*.*\\*" . (display-buffer-pop-up-frame . nil))))
move point to "alist" and type M-$. Gets me
ispell-highlight-spelling-error-overlay: Marker points into wrong buffer
martin
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-01 14:38 ` martin rudalics
@ 2011-11-01 20:00 ` Stefan Monnier
2011-11-01 21:54 ` Juri Linkov
1 sibling, 0 replies; 43+ messages in thread
From: Stefan Monnier @ 2011-11-01 20:00 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
> You really just wanted to add (inhibit-same-window . t) somewhere.
That's my impression as well.
Stefan
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-01 14:38 ` martin rudalics
2011-11-01 20:00 ` Stefan Monnier
@ 2011-11-01 21:54 ` Juri Linkov
2011-11-02 1:21 ` Stefan Monnier
1 sibling, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2011-11-01 21:54 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
> I suppose because `display-buffer-pop-up-window' cannot split the window
> due to `split-height-threshold' being too large. You really just wanted
> to add (inhibit-same-window . t) somewhere.
Thanks, this works as expected:
(let ((display-buffer-overriding-action '(display-buffer-reuse-window
(inhibit-same-window . t))))
(with-output-to-temp-buffer "*Help*"
(princ "GNU Emacs Calculator.\n")))
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-01 21:54 ` Juri Linkov
@ 2011-11-02 1:21 ` Stefan Monnier
2011-11-02 9:35 ` Juri Linkov
0 siblings, 1 reply; 43+ messages in thread
From: Stefan Monnier @ 2011-11-02 1:21 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
> (let ((display-buffer-overriding-action '(display-buffer-reuse-window
> (inhibit-same-window . t))))
Better would be
> (let ((display-buffer-overriding-action '(nil (inhibit-same-window . t))))
-- Stefan
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-02 1:21 ` Stefan Monnier
@ 2011-11-02 9:35 ` Juri Linkov
2011-11-02 10:04 ` martin rudalics
2011-11-02 12:37 ` Stefan Monnier
0 siblings, 2 replies; 43+ messages in thread
From: Juri Linkov @ 2011-11-02 9:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 3419
>> (let ((display-buffer-overriding-action '(display-buffer-reuse-window
>> (inhibit-same-window . t))))
>
> Better would be
>
>> (let ((display-buffer-overriding-action '(nil (inhibit-same-window . t))))
Yes, this works too.
Looking at the available display actions in window.el, I found that
there are `display-buffer--other-frame-action' and the command
`display-buffer-other-frame' that uses it, but their counterpart
window functions are missing.
Copying these frame-related functions and replacing "frame" with "window"
in their names, produces two new functions:
(defvar display-buffer--other-window-action
'((display-buffer-reuse-window
display-buffer--special
display-buffer-pop-up-window)
(inhibit-same-window . t)))
(defun display-buffer-other-window (buffer)
(interactive "BDisplay buffer in other window: ")
(display-buffer buffer display-buffer--other-window-action))
I don't know why these window functions are omitted from window.el,
but the `display-buffer--other-window-action' would be useful for this case:
(let ((display-buffer-overriding-action display-buffer--other-window-action))
(with-output-to-temp-buffer "*Help*"
(princ "GNU Emacs Calculator.\n")))
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-02 9:35 ` Juri Linkov
@ 2011-11-02 10:04 ` martin rudalics
2011-11-03 9:05 ` Juri Linkov
2011-11-02 12:37 ` Stefan Monnier
1 sibling, 1 reply; 43+ messages in thread
From: martin rudalics @ 2011-11-02 10:04 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
> (defvar display-buffer--other-window-action
> '((display-buffer-reuse-window
> display-buffer--special
> display-buffer-pop-up-window)
> (inhibit-same-window . t)))
Isn't this the default behavior? Try reusing a window showing the
buffer, try the special stuff, try popping up a new window, try reusing
another window?
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-02 10:04 ` martin rudalics
@ 2011-11-03 9:05 ` Juri Linkov
2011-11-03 10:07 ` martin rudalics
0 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2011-11-03 9:05 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
>> (defvar display-buffer--other-window-action
>> '((display-buffer-reuse-window
>> display-buffer--special
>> display-buffer-pop-up-window)
>> (inhibit-same-window . t)))
>
> Isn't this the default behavior? Try reusing a window showing the
> buffer, try the special stuff, try popping up a new window, try reusing
> another window?
As I understand from window.el, the default behavior in
`display-buffer-fallback-action' is to try first
`display-buffer--maybe-same-window', that uses
`display-buffer-same-window' where a non-nil `inhibit-same-window'
prohibits it from using the same window.
BTW, do you think it's possible for `calc' to use a single
`display-buffer' call with a display action so that users could easily
override its default *Calc* window displaying behavior?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 9:05 ` Juri Linkov
@ 2011-11-03 10:07 ` martin rudalics
2011-11-03 10:17 ` Juri Linkov
0 siblings, 1 reply; 43+ messages in thread
From: martin rudalics @ 2011-11-03 10:07 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
> BTW, do you think it's possible for `calc' to use a single
> `display-buffer' call with a display action so that users could easily
> override its default *Calc* window displaying behavior?
Do you mean that `calc' should call `display-buffer' with an appropriate
ACTION argument? Here `calc' pops up two windows. So even if this were
possible, it would constitute an abuse of `display-buffer'.
Or do you mean the display of calc's *Help* buffer?
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 10:07 ` martin rudalics
@ 2011-11-03 10:17 ` Juri Linkov
2011-11-03 12:26 ` Stefan Monnier
2011-11-03 13:59 ` martin rudalics
0 siblings, 2 replies; 43+ messages in thread
From: Juri Linkov @ 2011-11-03 10:17 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
>> BTW, do you think it's possible for `calc' to use a single
>> `display-buffer' call with a display action so that users could easily
>> override its default *Calc* window displaying behavior?
>
> Do you mean that `calc' should call `display-buffer' with an appropriate
> ACTION argument? Here `calc' pops up two windows. So even if this were
> possible, it would constitute an abuse of `display-buffer'.
>
> Or do you mean the display of calc's *Help* buffer?
With the calc's *Help* buffer it's clear now that
(inhibit-same-window . t) is available for users
that have (add-to-list 'same-window-buffer-names "*Help*")
in .emacs.
But I meant that *Calculator* and *Calc Trail* windows could be
displayed with `display-buffer' and an appropriate ACTION argument.
Then users will be able to customize its default behavior.
Isn't it the goal of window related improvements to allow
customizing easily of how windows are displayed?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 10:17 ` Juri Linkov
@ 2011-11-03 12:26 ` Stefan Monnier
2011-11-03 19:44 ` Juri Linkov
2011-11-03 13:59 ` martin rudalics
1 sibling, 1 reply; 43+ messages in thread
From: Stefan Monnier @ 2011-11-03 12:26 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
> But I meant that *Calculator* and *Calc Trail* windows could be
> displayed with `display-buffer' and an appropriate ACTION argument.
> Then users will be able to customize its default behavior.
Can't they already do that with display-buffer-alist?
> Isn't it the goal of window related improvements to allow
> customizing easily of how windows are displayed?
Yes, but not only that: it should be possible without having to do
special gymnastics in the Elisp code.
Stefan
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 12:26 ` Stefan Monnier
@ 2011-11-03 19:44 ` Juri Linkov
2011-11-03 21:07 ` Stefan Monnier
2011-11-04 9:39 ` martin rudalics
0 siblings, 2 replies; 43+ messages in thread
From: Juri Linkov @ 2011-11-03 19:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 3419
>> But I meant that *Calculator* and *Calc Trail* windows could be
>> displayed with `display-buffer' and an appropriate ACTION argument.
>> Then users will be able to customize its default behavior.
>
> Can't they already do that with display-buffer-alist?
`display-buffer-alist' can't undo splitting done outside of the
`display-buffer' call. When splitting is done in a display action,
user can easily override it. For instance, a new action
`display-buffer-pop-up-window-below' I posted in bug#9873
does splitting that users can override. This action
can be used in `calendar-generate-window', and when I tested it,
I observe finally the ideal behavior of `M-x calendar RET'
in many different window configurations with this very small patch:
=== modified file 'lisp/calendar/calendar.el'
--- lisp/calendar/calendar.el 2011-10-30 08:29:56 +0000
+++ lisp/calendar/calendar.el 2011-11-03 19:36:29 +0000
@@ -1331,7 +1331,7 @@ (defun calendar-basic-setup (&optional a
;;
;; Is this a wide frame? If so, split it horizontally.
(if (window-splittable-p t) (split-window-right))
- (pop-to-buffer calendar-buffer)
+ (pop-to-buffer calendar-buffer '(display-buffer-pop-up-window-below))
;; Has the window already been split vertically?
(when (and (not (window-dedicated-p))
(window-full-height-p))
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 19:44 ` Juri Linkov
@ 2011-11-03 21:07 ` Stefan Monnier
2011-11-04 9:38 ` Juri Linkov
2011-11-04 9:39 ` martin rudalics
1 sibling, 1 reply; 43+ messages in thread
From: Stefan Monnier @ 2011-11-03 21:07 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
>>> But I meant that *Calculator* and *Calc Trail* windows could be
>>> displayed with `display-buffer' and an appropriate ACTION argument.
>>> Then users will be able to customize its default behavior.
>> Can't they already do that with display-buffer-alist?
> `display-buffer-alist' can't undo splitting done outside of the
> `display-buffer' call.
I think I'm completely lost here. What splitting are you talking about?
Stefan
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 21:07 ` Stefan Monnier
@ 2011-11-04 9:38 ` Juri Linkov
0 siblings, 0 replies; 43+ messages in thread
From: Juri Linkov @ 2011-11-04 9:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 3419
>>>> But I meant that *Calculator* and *Calc Trail* windows could be
>>>> displayed with `display-buffer' and an appropriate ACTION argument.
>>>> Then users will be able to customize its default behavior.
>>> Can't they already do that with display-buffer-alist?
>> `display-buffer-alist' can't undo splitting done outside of the
>> `display-buffer' call.
>
> I think I'm completely lost here. What splitting are you talking about?
There is an explicit call to `split-window' in `calc'.
So users can't override it with `display-buffer-alist'.
With `split-window' implemented in a special action, users will be able
to override it with another action, e.g. an action that displays the
*Calc* buffer above the minibuffer, or below the selected window, etc.
(Currently *Calc* is displayed only in the largest window,
and this is not customizable yet).
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 19:44 ` Juri Linkov
2011-11-03 21:07 ` Stefan Monnier
@ 2011-11-04 9:39 ` martin rudalics
2011-11-04 10:12 ` Juri Linkov
1 sibling, 1 reply; 43+ messages in thread
From: martin rudalics @ 2011-11-04 9:39 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
> `display-buffer-alist' can't undo splitting done outside of the
> `display-buffer' call.
We have to identify all cases where this happens and replace them
appropriately.
> When splitting is done in a display action,
> user can easily override it. For instance, a new action
> `display-buffer-pop-up-window-below' I posted in bug#9873
> does splitting that users can override.
We have to make sure that it doesn't create too small windows. Binding
`split-height-threshold' to zero might be too strong in some cases and
ignores user preferences.
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-04 9:39 ` martin rudalics
@ 2011-11-04 10:12 ` Juri Linkov
2011-11-04 13:55 ` martin rudalics
0 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2011-11-04 10:12 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
>> `display-buffer-alist' can't undo splitting done outside of the
>> `display-buffer' call.
>
> We have to identify all cases where this happens and replace them
> appropriately.
I agree.
>> When splitting is done in a display action,
>> user can easily override it. For instance, a new action
>> `display-buffer-pop-up-window-below' I posted in bug#9873
>> does splitting that users can override.
>
> We have to make sure that it doesn't create too small windows. Binding
> `split-height-threshold' to zero might be too strong in some cases and
> ignores user preferences.
In this case users can express preferences by customizing
`display-buffer-alist' to a different action.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-04 10:12 ` Juri Linkov
@ 2011-11-04 13:55 ` martin rudalics
0 siblings, 0 replies; 43+ messages in thread
From: martin rudalics @ 2011-11-04 13:55 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
>> We have to make sure that it doesn't create too small windows. Binding
>> `split-height-threshold' to zero might be too strong in some cases and
>> ignores user preferences.
>
> In this case users can express preferences by customizing
> `display-buffer-alist' to a different action.
Sure. But we should also make sure that the standard behavior remains
unchanged. Going through those "used to work for years" complaints is
no fun.
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 10:17 ` Juri Linkov
2011-11-03 12:26 ` Stefan Monnier
@ 2011-11-03 13:59 ` martin rudalics
2011-11-03 19:45 ` Juri Linkov
2011-11-06 21:09 ` Jay Belanger
1 sibling, 2 replies; 43+ messages in thread
From: martin rudalics @ 2011-11-03 13:59 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
>>> BTW, do you think it's possible for `calc' to use a single
>>> `display-buffer' call with a display action so that users could easily
>>> override its default *Calc* window displaying behavior?
[...]
> But I meant that *Calculator* and *Calc Trail* windows could be
> displayed with `display-buffer' and an appropriate ACTION argument.
> Then users will be able to customize its default behavior.
We'd have to change the calling convention if we were to allow a "single
`display-buffer' call" to display both *Calculator* and *Calc Trail*.
> Isn't it the goal of window related improvements to allow
> customizing easily of how windows are displayed?
Yes. But it's already quite tedious to achieve this goal for the one
buffer case (as in ispell, ibuffer, buff-menu or calendar).
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 13:59 ` martin rudalics
@ 2011-11-03 19:45 ` Juri Linkov
2011-11-04 9:39 ` martin rudalics
2011-11-06 21:09 ` Jay Belanger
1 sibling, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2011-11-03 19:45 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
>> Isn't it the goal of window related improvements to allow
>> customizing easily of how windows are displayed?
>
> Yes. But it's already quite tedious to achieve this goal for the one
> buffer case (as in ispell, ibuffer, buff-menu or calendar).
The goal can be achieved for calendar with the patch I sent in another
message. For ibuffer and buff-menu I see no problem. For ispell
I guess you mean your test case with `display-buffer-pop-up-frame'?
IIUC, ispell already supports displaying the choices in another frame
when `ispell-use-framepop-p' is non-nil, but it does this with
an unknown function `framepop-display-buffer'.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 19:45 ` Juri Linkov
@ 2011-11-04 9:39 ` martin rudalics
2011-11-04 13:12 ` Stefan Monnier
0 siblings, 1 reply; 43+ messages in thread
From: martin rudalics @ 2011-11-04 9:39 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
> The goal can be achieved for calendar with the patch I sent in another
> message. For ibuffer and buff-menu I see no problem.
You mean doing the same as in calendar? Things like
(lambda (buf)
(split-window nil height (eq type 'horizontally))
(other-window 1)
(switch-to-buffer buf)))
look suspicious because `switch-to-buffer' without FORCE-SAME-WINDOW set
can now make the behavior differently wrt Emacs 23.
> For ispell
> I guess you mean your test case with `display-buffer-pop-up-frame'?
No. I mean the same as above. More precisely
(let ((choices-window (get-buffer-window ispell-choices-buffer)))
...
;; Overlay *Choices* window when it isn't showing
(ispell-overlay-window (max line ispell-choices-win-default-height)))
(switch-to-buffer ispell-choices-buffer)
(goto-char (point-min)))))
does strange things when `switch-to-buffer' does _not_ use the window
selected by `ispell-overlay-window'. You can, for example, get an extra
window showing the initial buffer.
> IIUC, ispell already supports displaying the choices in another frame
> when `ispell-use-framepop-p' is non-nil, but it does this with
> an unknown function `framepop-display-buffer'.
We have to rewrite ispell's window handling from scratch.
martin
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-03 13:59 ` martin rudalics
2011-11-03 19:45 ` Juri Linkov
@ 2011-11-06 21:09 ` Jay Belanger
1 sibling, 0 replies; 43+ messages in thread
From: Jay Belanger @ 2011-11-06 21:09 UTC (permalink / raw)
To: martin rudalics; +Cc: 3419
>>>> BTW, do you think it's possible for `calc' to use a single
>>>> `display-buffer' call with a display action so that users could easily
>>>> override its default *Calc* window displaying behavior?
> [...]
>> But I meant that *Calculator* and *Calc Trail* windows could be
>> displayed with `display-buffer' and an appropriate ACTION argument.
>> Then users will be able to customize its default behavior.
>
> We'd have to change the calling convention if we were to allow a "single
> `display-buffer' call" to display both *Calculator* and *Calc Trail*.
Is that what Juri meant, or did he mean a single `display-buffer' for
each display action? Currently, Calc uses `split-window' to set up
*Calculator* and then a separate `split-window' to split the
*Calculator* window and use the new window for *Calc Trail* (or the
keypad). Is the suggestion to replace both of these with a single
`display-buffer' or each `split-window' with a `display-buffer'?
Jay
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2011-11-02 9:35 ` Juri Linkov
2011-11-02 10:04 ` martin rudalics
@ 2011-11-02 12:37 ` Stefan Monnier
1 sibling, 0 replies; 43+ messages in thread
From: Stefan Monnier @ 2011-11-02 12:37 UTC (permalink / raw)
To: Juri Linkov; +Cc: 3419
>>> (let ((display-buffer-overriding-action '(display-buffer-reuse-window
>>> (inhibit-same-window . t))))
>> Better would be
>>> (let ((display-buffer-overriding-action '(nil (inhibit-same-window . t))))
> Looking at the available display actions in window.el, I found that
> there are `display-buffer--other-frame-action' and the command
> `display-buffer-other-frame' that uses it, but their counterpart
> window functions are missing.
We don't need them: inhibit-same-window works as well.
Stefan
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-30 2:15 ` Jay Belanger
2009-05-30 9:51 ` martin rudalics
@ 2009-06-02 15:57 ` Leo
2009-06-02 19:20 ` Jay Belanger
1 sibling, 1 reply; 43+ messages in thread
From: Leo @ 2009-06-02 15:57 UTC (permalink / raw)
To: jay.p.belanger; +Cc: emacs-pretest-bug, bug-gnu-emacs, 3419
On 2009-05-30 03:15 +0100, Jay Belanger wrote:
> I've never used temp-buffer-resize-mode before, but if it's supposed to
> make a window a better size for displaying a temporary buffer, I'm
> surprised it doesn't change anything back when the buffer is killed or
> hidden. In this case, I'm not sure it's Calc's job to keep track of why
> it changed its window size. Perhaps an option "Always start Calc with
> the initial window height" might be helpful.
I have started looking for a workaround to save me doing (setq
calc-window-height 7) all the time. I am thinking of using
calc-end-hook, however it is located right in the middle of calc-quit.
So I cannot use the following:
(add-hook 'calc-end-hook
(lambda ()
(setq calc-window-height 7)))
But it seems to me that moving the hook to the very end of calc-quit is
better than putting it in the middle. Do you recall any reason why this
is not the case? Thank you.
--
.: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :.
^ permalink raw reply [flat|nested] 43+ messages in thread* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-06-02 15:57 ` Leo
@ 2009-06-02 19:20 ` Jay Belanger
2009-06-02 21:28 ` Leo
0 siblings, 1 reply; 43+ messages in thread
From: Jay Belanger @ 2009-06-02 19:20 UTC (permalink / raw)
To: Leo; +Cc: emacs-pretest-bug, bug-gnu-emacs
Leo <sdl.web@gmail.com> writes:
> I have started looking for a workaround to save me doing (setq
> calc-window-height 7) all the time. I am thinking of using
> calc-end-hook, however it is located right in the middle of calc-quit.
> So I cannot use the following:
>
> (add-hook 'calc-end-hook
> (lambda ()
> (setq calc-window-height 7)))
>
> But it seems to me that moving the hook to the very end of calc-quit is
> better than putting it in the middle. Do you recall any reason why this
> is not the case? Thank you.
It is mentioned in the documentation that the hook is called early, so I
guess it was done on purpose. I don't know why, though.
A workaround for now might be to define `my-calc' or `my-calc-dispatch'
with
(defun my-calc ()
(interactive)
(setq calc-window-heigth)
(calc....))
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-06-02 19:20 ` Jay Belanger
@ 2009-06-02 21:28 ` Leo
0 siblings, 0 replies; 43+ messages in thread
From: Leo @ 2009-06-02 21:28 UTC (permalink / raw)
To: bug-gnu-emacs; +Cc: emacs-pretest-bug
On 2009-06-02 20:20 +0100, Jay Belanger wrote:
> It is mentioned in the documentation that the hook is called early, so I
> guess it was done on purpose. I don't know why, though.
>
> A workaround for now might be to define `my-calc' or `my-calc-dispatch'
> with
> (defun my-calc ()
> (interactive)
> (setq calc-window-heigth)
> (calc....))
I have disabled temp-buffer-resize-mode until it is properly
implemented. Thanks.
--
.: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
2009-05-29 19:03 bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode Leo
2009-05-29 23:46 ` Jay Belanger
@ 2012-10-04 13:18 ` martin rudalics
1 sibling, 0 replies; 43+ messages in thread
From: martin rudalics @ 2012-10-04 13:18 UTC (permalink / raw)
To: 3419-done
> 1. Emacs -Q
> 2. (temp-buffer-resize-mode t)
> 3. M-x calc
> 4. h h
>
> You will notice that calc-window-height is changed to a much larger
> value. Calendar also has this similar problem but it can restore to its
> default height after restarting itself.
>
> GNU Emacs 23.0.94.1 (i386-apple-darwin9.7.0, NS apple-appkit-949.46) of
> 2009-05-23 on 200.sub-75-216-116.myvzw.com
With Emacs 24.3 `temp-buffer-resize-mode' should no longer resizes a window
that formerly showed another buffer. Bug closed.
For any related problems that have been discussed in the thread of this
bug please make a new report.
Thanks, martin
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2012-10-04 13:18 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-29 19:03 bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode Leo
2009-05-29 23:46 ` Jay Belanger
2009-05-30 1:43 ` Leo
2009-05-30 2:15 ` Jay Belanger
2009-05-30 9:51 ` martin rudalics
2009-05-30 10:58 ` Leo
2009-05-30 12:19 ` martin rudalics
2009-05-30 18:21 ` Glenn Morris
2009-05-30 22:37 ` Leo
2011-10-24 11:07 ` Leo
2011-10-24 16:15 ` martin rudalics
2011-10-25 2:17 ` Leo
2011-10-25 2:47 ` Jay Belanger
2011-10-25 15:20 ` Leo
2011-10-31 10:34 ` Juri Linkov
2011-10-31 18:56 ` Jay Belanger
2011-11-01 9:27 ` Juri Linkov
2011-11-01 14:38 ` martin rudalics
2011-11-01 20:00 ` Stefan Monnier
2011-11-01 21:54 ` Juri Linkov
2011-11-02 1:21 ` Stefan Monnier
2011-11-02 9:35 ` Juri Linkov
2011-11-02 10:04 ` martin rudalics
2011-11-03 9:05 ` Juri Linkov
2011-11-03 10:07 ` martin rudalics
2011-11-03 10:17 ` Juri Linkov
2011-11-03 12:26 ` Stefan Monnier
2011-11-03 19:44 ` Juri Linkov
2011-11-03 21:07 ` Stefan Monnier
2011-11-04 9:38 ` Juri Linkov
2011-11-04 9:39 ` martin rudalics
2011-11-04 10:12 ` Juri Linkov
2011-11-04 13:55 ` martin rudalics
2011-11-03 13:59 ` martin rudalics
2011-11-03 19:45 ` Juri Linkov
2011-11-04 9:39 ` martin rudalics
2011-11-04 13:12 ` Stefan Monnier
2011-11-06 21:09 ` Jay Belanger
2011-11-02 12:37 ` Stefan Monnier
2009-06-02 15:57 ` Leo
2009-06-02 19:20 ` Jay Belanger
2009-06-02 21:28 ` Leo
2012-10-04 13:18 ` martin rudalics
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).
