* bug#14627: 24.2; Vertical frame size shrinking
@ 2013-06-15 14:22 Karl Brodowsky
2013-08-19 18:56 ` Jan Djärv
0 siblings, 1 reply; 33+ messages in thread
From: Karl Brodowsky @ 2013-06-15 14:22 UTC (permalink / raw)
To: 14627
In GNU Emacs 24.2.1 (x86_64-suse-linux-gnu, GTK+ Version 3.6.4)
of 2013-02-21 on build16
Windowing system distributor `The X.Org Foundation', version 11.0.11302000
Configured using:
`configure '--with-pop' '--without-hesiod' '--with-kerberos'
'--with-kerberos5' '--with-xim' '--with-wide-int' '--enable-autodepend'
'--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--localstatedir=/var'
'--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x'
'--with-sound' '--with-sync-input' '--with-xpm' '--with-jpeg'
'--with-tiff' '--with-gif' '--with-png' '--with-rsvg' '--with-dbus'
'--without-gpm' '--with-x-toolkit=gtk3' '--x-includes=/usr/include'
'--x-libraries=/usr/lib64:/usr/share/X11' '--with-xft' '--with-libotf'
'--with-m17n-flt' '--build=x86_64-suse-linux'
'build_alias=x86_64-suse-linux' 'CFLAGS=-fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -D_GNU_SOURCE -std=gnu89 -pipe
-Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
-Wno-unprototyped-calls -fno-optimize-sibling-calls
-DSYSTEM_PURESIZE_EXTRA=55000 -DSITELOAD_PURESIZE_EXTRA=10000 '
'LDFLAGS=-Wl,-O2 -Wl,--hash-size=65521''
uname -a
Linux <hostname> 3.7.10-1.11-desktop #1 SMP PREEMPT Thu May 16 20:27:27
UTC 2013 (adf31bb) x86_64 x86_64 x86_64 GNU/Linux
lsb-release -a
LSB Version: n/a
Distributor ID: openSUSE project
Description: openSUSE 12.3 (x86_64)
Release: 12.3
Codename: Dartmouth
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: POSIX
value of $LC_TIME: nil
value of $LANG: C
value of $XMODIFIERS: @im=local
locale-coding-system: nil
default enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
shell-dirtrack-mode: t
show-paren-mode: t
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
~bk1/etc/emacs/scala-mode-auto hides ~bk1/etc/emacs/scala/scala-mode-auto
~bk1/etc/emacs/scala-mode-indent hides
~bk1/etc/emacs/scala/scala-mode-indent
~bk1/etc/emacs/scala-mode-ui hides ~bk1/etc/emacs/scala/scala-mode-ui
~bk1/etc/emacs/scala-mode-feature-tags hides
~bk1/etc/emacs/scala/scala-mode-feature-tags
~bk1/etc/emacs/scala-mode hides ~bk1/etc/emacs/scala/scala-mode
~bk1/etc/emacs/scala-mode-feature-speedbar hides
~bk1/etc/emacs/scala/scala-mode-feature-speedbar
~bk1/etc/emacs/scala-mode-feature-electric hides
~bk1/etc/emacs/scala/scala-mode-feature-electric
~bk1/etc/emacs/scala-mode-navigation hides
~bk1/etc/emacs/scala/scala-mode-navigation
~bk1/etc/emacs/scala-mode-constants hides
~bk1/etc/emacs/scala/scala-mode-constants
~bk1/etc/emacs/scala-mode-lib hides ~bk1/etc/emacs/scala/scala-mode-lib
~bk1/etc/emacs/scala-mode-variables hides
~bk1/etc/emacs/scala/scala-mode-variables
~bk1/etc/emacs/scala-mode-fontlock hides
~bk1/etc/emacs/scala/scala-mode-fontlock
~bk1/etc/emacs/scala-mode-feature hides
~bk1/etc/emacs/scala/scala-mode-feature
~bk1/etc/emacs/scala-mode-inf hides ~bk1/etc/emacs/scala/scala-mode-inf
~bk1/etc/emacs/maple hides /usr/share/emacs/site-lisp/maple
~bk1/etc/emacs/psvn hides /usr/share/emacs/site-lisp/psvn
~bk1/etc/emacs/finder-inf hides /usr/share/emacs/24.2/lisp/finder-inf
~bk1/etc/emacs/comint hides /usr/share/emacs/24.2/lisp/comint
~bk1/etc/emacs/cyrillic hides /usr/share/emacs/24.2/lisp/language/cyrillic
Features:
(shadow sort gnus-util mail-extr warnings emacsbug message format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs tabify nxml-uchnm rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok dired-aux sql
thingatpt mule-util grep compile dabbrev rect shell pcomplete comint
ring locate dired regexp-opt help-mode easymenu view misearch
multi-isearch vc-git server k-iso-insert iso-insert extra-konvers
asc2iso konvers xxx-konvers iso-konvers ws-minor ws-markerfun
ws-searchfun latin-1 cmode-extra hilit19 meta-arrow shift-arrow paren
preview-latex tex-site auto-loads ispell time-date delsel lpr disp-table
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
What I do:
start emacs
maximize the window
split with C-x 3
open a directory with C-x C-f /tmp
click on left and right half of emacs
The height of my emacs frame shrinks a little bit every time I do so, so
I am loosing about one line of text when clicking to the left half and
back to the right half.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-06-15 14:22 bug#14627: 24.2; Vertical frame size shrinking Karl Brodowsky
@ 2013-08-19 18:56 ` Jan Djärv
2013-08-19 19:15 ` Jan Djärv
2013-08-22 11:32 ` Stephen Berman
0 siblings, 2 replies; 33+ messages in thread
From: Jan Djärv @ 2013-08-19 18:56 UTC (permalink / raw)
To: Karl Brodowsky; +Cc: 14627
Hello.
15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1@gmx.net>:
>
> What I do:
> start emacs
> maximize the window
> split with C-x 3
> open a directory with C-x C-f /tmp
> click on left and right half of emacs
> The height of my emacs frame shrinks a little bit every time I do so, so
> I am loosing about one line of text when clicking to the left half and
> back to the right half.
I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
What dont do you use, and what is your screen size?
You did not mention what window manager you run, I used kwin.
Jan D.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-19 18:56 ` Jan Djärv
@ 2013-08-19 19:15 ` Jan Djärv
2013-08-22 11:32 ` Stephen Berman
1 sibling, 0 replies; 33+ messages in thread
From: Jan Djärv @ 2013-08-19 19:15 UTC (permalink / raw)
To: Karl Brodowsky; +Cc: 14627@debbugs.gnu.org
Aargh...
19 aug 2013 kl. 20:56 skrev Jan Djärv <jan.h.d@swipnet.se>:
> Hello.
>
> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1@gmx.net>:
>
>>
>> What I do:
>> start emacs
>> maximize the window
>> split with C-x 3
>> open a directory with C-x C-f /tmp
>> click on left and right half of emacs
>> The height of my emacs frame shrinks a little bit every time I do so, so
>> I am loosing about one line of text when clicking to the left half and
>> back to the right half.
>
> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
> What dont do you use, and what is
dont -> font
> your screen size?
> You did not mention what window manager you run, I used kwin.
>
> Jan D.
>
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-19 18:56 ` Jan Djärv
2013-08-19 19:15 ` Jan Djärv
@ 2013-08-22 11:32 ` Stephen Berman
2013-08-22 11:51 ` Stephen Berman
2013-08-22 12:15 ` martin rudalics
1 sibling, 2 replies; 33+ messages in thread
From: Stephen Berman @ 2013-08-22 11:32 UTC (permalink / raw)
To: Jan Djärv; +Cc: 14627, Karl Brodowsky
On Mon, 19 Aug 2013 20:56:14 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1@gmx.net>:
>
>>
>> What I do:
>> start emacs
>> maximize the window
>> split with C-x 3
>> open a directory with C-x C-f /tmp
>> click on left and right half of emacs
>> The height of my emacs frame shrinks a little bit every time I do so, so
>> I am loosing about one line of text when clicking to the left half and
>> back to the right half.
>
> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
> What dont do you use, and what is your screen size?
> You did not mention what window manager you run, I used kwin.
I don't see the shrinking with the OP's recipe, but I do see it if,
instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
between the Info and scratch windows shrinks the maximized frame
vertically.
In GNU Emacs 24.3.50.3 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
of 2013-08-07 on rosalinde
Bzr revision: 113738 eliz@gnu.org-20130807151423-mhw4d72032gg0eho
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
System Description: openSUSE 12.2 (x86_64)
Qt: 4.8.4
KDE Development Platform: 4.9.5 "release 4"
KWin: 4.9.5 "release 4"
Configured using:
`configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Steve Berman
(I may not be able to follow up for a week or so.)
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-22 11:32 ` Stephen Berman
@ 2013-08-22 11:51 ` Stephen Berman
2013-08-22 11:59 ` Stephen Berman
2013-08-22 12:15 ` martin rudalics
1 sibling, 1 reply; 33+ messages in thread
From: Stephen Berman @ 2013-08-22 11:51 UTC (permalink / raw)
To: Jan Djärv; +Cc: 14627, Karl Brodowsky
On Thu, 22 Aug 2013 13:32:30 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
> On Mon, 19 Aug 2013 20:56:14 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>> Hello.
>>
>> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1@gmx.net>:
>>
>>>
>>> What I do:
>>> start emacs
>>> maximize the window
>>> split with C-x 3
>>> open a directory with C-x C-f /tmp
>>> click on left and right half of emacs
>>> The height of my emacs frame shrinks a little bit every time I do so, so
>>> I am loosing about one line of text when clicking to the left half and
>>> back to the right half.
>>
>> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
>> What dont do you use, and what is your screen size?
>> You did not mention what window manager you run, I used kwin.
>
> I don't see the shrinking with the OP's recipe, but I do see it if,
> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
> between the Info and scratch windows shrinks the maximized frame
> vertically.
>
> In GNU Emacs 24.3.50.3 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
> of 2013-08-07 on rosalinde
> Bzr revision: 113738 eliz@gnu.org-20130807151423-mhw4d72032gg0eho
> Windowing system distributor `The X.Org Foundation', version 11.0.11203000
> System Description: openSUSE 12.2 (x86_64)
>
> Qt: 4.8.4
> KDE Development Platform: 4.9.5 "release 4"
> KWin: 4.9.5 "release 4"
>
> Configured using:
> `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'
>
> Important settings:
> value of $LANG: en_US.UTF-8
> value of $XMODIFIERS: @im=local
> locale-coding-system: utf-8-unix
> default enable-multibyte-characters: t
>
> Steve Berman
> (I may not be able to follow up for a week or so.)
One quick followup: the shrinking happens with (at least) this font:
xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-22 11:51 ` Stephen Berman
@ 2013-08-22 11:59 ` Stephen Berman
0 siblings, 0 replies; 33+ messages in thread
From: Stephen Berman @ 2013-08-22 11:59 UTC (permalink / raw)
To: Jan Djärv; +Cc: 14627, Karl Brodowsky
On Thu, 22 Aug 2013 13:51:33 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
> On Thu, 22 Aug 2013 13:32:30 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> On Mon, 19 Aug 2013 20:56:14 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>>> Hello.
>>>
>>> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1@gmx.net>:
>>>
>>>>
>>>> What I do:
>>>> start emacs
>>>> maximize the window
>>>> split with C-x 3
>>>> open a directory with C-x C-f /tmp
>>>> click on left and right half of emacs
>>>> The height of my emacs frame shrinks a little bit every time I do so, so
>>>> I am loosing about one line of text when clicking to the left half and
>>>> back to the right half.
>>>
>>> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
>>> What dont do you use, and what is your screen size?
>>> You did not mention what window manager you run, I used kwin.
>>
>> I don't see the shrinking with the OP's recipe, but I do see it if,
>> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
>> between the Info and scratch windows shrinks the maximized frame
>> vertically.
>>
>> In GNU Emacs 24.3.50.3 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
>> of 2013-08-07 on rosalinde
>> Bzr revision: 113738 eliz@gnu.org-20130807151423-mhw4d72032gg0eho
>> Windowing system distributor `The X.Org Foundation', version 11.0.11203000
>> System Description: openSUSE 12.2 (x86_64)
>>
>> Qt: 4.8.4
>> KDE Development Platform: 4.9.5 "release 4"
>> KWin: 4.9.5 "release 4"
>>
>> Configured using:
>> `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'
>>
>> Important settings:
>> value of $LANG: en_US.UTF-8
>> value of $XMODIFIERS: @im=local
>> locale-coding-system: utf-8-unix
>> default enable-multibyte-characters: t
>>
>> Steve Berman
>> (I may not be able to follow up for a week or so.)
>
> One quick followup: the shrinking happens with (at least) this font:
>
> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
And another quick followup:
The shrinking does not happen when the tool bar is detached or
tool-bar-mode is turned off.
Steve Berman
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-22 11:32 ` Stephen Berman
2013-08-22 11:51 ` Stephen Berman
@ 2013-08-22 12:15 ` martin rudalics
2013-08-22 12:25 ` Stephen Berman
1 sibling, 1 reply; 33+ messages in thread
From: martin rudalics @ 2013-08-22 12:15 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14627, Karl Brodowsky
> I don't see the shrinking with the OP's recipe, but I do see it if,
> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
> between the Info and scratch windows shrinks the maximized frame
> vertically.
Does the frame shrink more and more when you repeatedly switch to info?
Or does it shrink just once and stick to that size afterwards?
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-22 12:15 ` martin rudalics
@ 2013-08-22 12:25 ` Stephen Berman
2013-08-23 7:10 ` martin rudalics
0 siblings, 1 reply; 33+ messages in thread
From: Stephen Berman @ 2013-08-22 12:25 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, Karl Brodowsky
On Thu, 22 Aug 2013 14:15:55 +0200 martin rudalics <rudalics@gmx.at> wrote:
>> I don't see the shrinking with the OP's recipe, but I do see it if,
>> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
>> between the Info and scratch windows shrinks the maximized frame
>> vertically.
>
> Does the frame shrink more and more when you repeatedly switch to info?
> Or does it shrink just once and stick to that size afterwards?
>
> martin
It keeps shrinking (window-height decreases by one each time), until the
minibuffer is no longer displayable, then it stops shrinking.
Steve Berman
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-22 12:25 ` Stephen Berman
@ 2013-08-23 7:10 ` martin rudalics
2013-08-23 8:20 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: martin rudalics @ 2013-08-23 7:10 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14627, Karl Brodowsky
> It keeps shrinking (window-height decreases by one each time), until the
> minibuffer is no longer displayable, then it stops shrinking.
I think we have two bugs here:
(1) A maximized frame should never shrink due to a font change.
(2) There seems to be a rounding error present which always chooses to
shrink the frame when changing the toolbar size.
If Jan does not find the cause of these, maybe someone who can reproduce
the problem could step in so we can debug it?
martin
^ permalink raw reply [flat|nested] 33+ messages in thread* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 7:10 ` martin rudalics
@ 2013-08-23 8:20 ` Eli Zaretskii
2013-08-23 8:55 ` martin rudalics
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2013-08-23 8:20 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, bk1, stephen.berman
> Date: Fri, 23 Aug 2013 09:10:16 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 14627@debbugs.gnu.org, Karl Brodowsky <bk1@gmx.net>
>
> I think we have two bugs here:
I think we have three.
> (1) A maximized frame should never shrink due to a font change.
>
> (2) There seems to be a rounding error present which always chooses to
> shrink the frame when changing the toolbar size.
(3) Why does a frame change its size when one clicks on it?
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 8:20 ` Eli Zaretskii
@ 2013-08-23 8:55 ` martin rudalics
2013-08-23 9:25 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: martin rudalics @ 2013-08-23 8:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14627, bk1, stephen.berman
> (3) Why does a frame change its size when one clicks on it?
The OP says that he clicks "to the left half and back to the right half"
which here translates to switches from one window to the other.
Together with Stephen's observations this seems to indicate that the
toolbar contents change, probably with a different default font. And
since Emacs can change the frame size when changing a font size ...
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 8:55 ` martin rudalics
@ 2013-08-23 9:25 ` Eli Zaretskii
2013-08-23 10:21 ` martin rudalics
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2013-08-23 9:25 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, bk1, stephen.berman
> Date: Fri, 23 Aug 2013 10:55:38 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stephen.berman@gmx.net, 14627@debbugs.gnu.org, bk1@gmx.net
>
> > (3) Why does a frame change its size when one clicks on it?
>
> The OP says that he clicks "to the left half and back to the right half"
> which here translates to switches from one window to the other.
> Together with Stephen's observations this seems to indicate that the
> toolbar contents change, probably with a different default font. And
> since Emacs can change the frame size when changing a font size ...
The toolbar displays no text (at least on my system), only images, so
font size should have no significance, only the sizes of the images
should matter. And why would the _default_ font size in two windows
of the same frame be different, anyway, when the recipe includes no
commands that should have any effect on the font?
Anyway, does the toolbar really change its size in this recipe? It
doesn't on my system.
So sorry, but I still think there's some mystery here. Putting a
breakpoint in the relevant primitives and showing the C and Lisp
backtraces when those break might show what am I missing.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 9:25 ` Eli Zaretskii
@ 2013-08-23 10:21 ` martin rudalics
2013-08-23 10:33 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: martin rudalics @ 2013-08-23 10:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14627, bk1, stephen.berman
> The toolbar displays no text (at least on my system), only images, so
> font size should have no significance, only the sizes of the images
> should matter.
IIUC when I change the default font size on Windows, the frame's line
height changes and the pixel size of the toolbar changes too. On
Windows this won't matter, but when an external toolbar changes size it
might and trigger the rounding effect I mentioned earlier. But maybe
you're right and it's the images that change size.
> And why would the _default_ font size in two windows
> of the same frame be different, anyway, when the recipe includes no
> commands that should have any effect on the font?
More so because windows don't have a default face. The OP uses cyrillic
and Stephen invokes Info, could these give a clue? Can face remapping
or buffer local faces have any impact?
> Anyway, does the toolbar really change its size in this recipe? It
> doesn't on my system.
According to Stephen the toolbar matters. I don't know about the OP but
at least he has `tool-bar-mode' turned on.
> So sorry, but I still think there's some mystery here. Putting a
> breakpoint in the relevant primitives and showing the C and Lisp
> backtraces when those break might show what am I missing.
Right.
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 10:21 ` martin rudalics
@ 2013-08-23 10:33 ` Eli Zaretskii
2013-08-23 10:46 ` martin rudalics
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2013-08-23 10:33 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, bk1, stephen.berman
> Date: Fri, 23 Aug 2013 12:21:25 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stephen.berman@gmx.net, 14627@debbugs.gnu.org, bk1@gmx.net
>
> > The toolbar displays no text (at least on my system), only images, so
> > font size should have no significance, only the sizes of the images
> > should matter.
>
> IIUC when I change the default font size on Windows, the frame's line
> height changes and the pixel size of the toolbar changes too. On
> Windows this won't matter, but when an external toolbar changes size it
> might and trigger the rounding effect I mentioned earlier. But maybe
> you're right and it's the images that change size.
If the toolbar is not drawn by Emacs (a.k.a. "external toolbar"), how
can any changes in Emacs's default font change the size of the
toolbar? I'd need to see a recipe for that, and also some explanation
from someone who understands how that external toolbar works and what,
if anything, does its size have to do with the Emacs fonts.
> > And why would the _default_ font size in two windows
> > of the same frame be different, anyway, when the recipe includes no
> > commands that should have any effect on the font?
>
> More so because windows don't have a default face.
??? Of course, they do: they start with the frame's defaults.
> The OP uses cyrillic and Stephen invokes Info, could these give a
> clue?
I don't think so, certainly not with Info.
> Can face remapping or buffer local faces have any impact?
Yes, they can. But the recipe didn't include any face remapping.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 10:33 ` Eli Zaretskii
@ 2013-08-23 10:46 ` martin rudalics
2013-08-23 11:10 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: martin rudalics @ 2013-08-23 10:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14627, bk1, stephen.berman
>> More so because windows don't have a default face.
>
> ??? Of course, they do: they start with the frame's defaults.
What I wanted to state here is that two windows on the same frame can't
have different default faces.
>> The OP uses cyrillic and Stephen invokes Info, could these give a
>> clue?
>
> I don't think so, certainly not with Info.
Info has a special toolbar.
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 10:46 ` martin rudalics
@ 2013-08-23 11:10 ` Eli Zaretskii
2013-08-23 16:22 ` Jan Djärv
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2013-08-23 11:10 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, bk1, stephen.berman
> Date: Fri, 23 Aug 2013 12:46:01 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stephen.berman@gmx.net, 14627@debbugs.gnu.org, bk1@gmx.net
>
> >> The OP uses cyrillic and Stephen invokes Info, could these give a
> >> clue?
> >
> > I don't think so, certainly not with Info.
>
> Info has a special toolbar.
Right, but we already talked about that: only image sizes can change
the toolbar's size.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 11:10 ` Eli Zaretskii
@ 2013-08-23 16:22 ` Jan Djärv
2013-08-23 17:39 ` Eli Zaretskii
2013-08-23 17:55 ` Karl Brodowsky
0 siblings, 2 replies; 33+ messages in thread
From: Jan Djärv @ 2013-08-23 16:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bk1, stephen.berman, 14627
Hello.
23 aug 2013 kl. 13:10 skrev Eli Zaretskii <eliz@gnu.org>:
>> Date: Fri, 23 Aug 2013 12:46:01 +0200
>> From: martin rudalics <rudalics@gmx.at>
>> CC: stephen.berman@gmx.net, 14627@debbugs.gnu.org, bk1@gmx.net
>>
>>>> The OP uses cyrillic and Stephen invokes Info, could these give a
>>>> clue?
>>>
>>> I don't think so, certainly not with Info.
>>
>> Info has a special toolbar.
>
> Right, but we already talked about that: only image sizes can change
> the toolbar's size.
In 99 cases out of 100 these cases are due to either the inherent race in wm_size_hints or bugs in the window manager. In this case it is probably the latter.
I suspect the tool bar changes for the OP. That makes Emacs send new wm_size_hints to the window manager, telling it what the base- and increment sizes are. If the tool bar changes, the base size changes (the size not counted against resize increments, i.e. font size). Normally a window manager shall then make sure Emacs frame has the appropriate size, i.e.
height = base_y + inc_y * n
where n is an integer.
But in this case the frame is maximized, so the window manager should do nothing, like all other window managers.
A possible workaround is not to update size hints when Emacs is maximized or fullscreen.
Jan D.
^ permalink raw reply [flat|nested] 33+ messages in thread* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 16:22 ` Jan Djärv
@ 2013-08-23 17:39 ` Eli Zaretskii
2013-08-23 17:55 ` martin rudalics
2013-08-23 17:55 ` Karl Brodowsky
1 sibling, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2013-08-23 17:39 UTC (permalink / raw)
To: Jan Djärv; +Cc: bk1, stephen.berman, 14627
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Fri, 23 Aug 2013 18:22:16 +0200
> Cc: martin rudalics <rudalics@gmx.at>,
> 14627@debbugs.gnu.org,
> bk1@gmx.net,
> stephen.berman@gmx.net
>
> A possible workaround is not to update size hints when Emacs is maximized or fullscreen.
I think we should take that workaround.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 17:39 ` Eli Zaretskii
@ 2013-08-23 17:55 ` martin rudalics
2013-08-23 17:58 ` Jan Djärv
2013-08-23 18:02 ` Karl Brodowsky
0 siblings, 2 replies; 33+ messages in thread
From: martin rudalics @ 2013-08-23 17:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14627, bk1, stephen.berman
>> A possible workaround is not to update size hints when Emacs is maximized or fullscreen.
>
> I think we should take that workaround.
I'm afraid this won't help always. According to Stephen the frame
"keeps shrinking (window-height decreases by one each time), until the
minibuffer is no longer displayable, then it stops shrinking". So in
his case the frame has ceased to be maximized for quite some time.
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 17:55 ` martin rudalics
@ 2013-08-23 17:58 ` Jan Djärv
2013-08-23 18:06 ` martin rudalics
2013-08-23 18:02 ` Karl Brodowsky
1 sibling, 1 reply; 33+ messages in thread
From: Jan Djärv @ 2013-08-23 17:58 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, stephen.berman, bk1
Hello.
23 aug 2013 kl. 19:55 skrev martin rudalics <rudalics@gmx.at>:
> >> A possible workaround is not to update size hints when Emacs is maximized or fullscreen.
> >
> > I think we should take that workaround.
>
> I'm afraid this won't help always. According to Stephen the frame
> "keeps shrinking (window-height decreases by one each time), until the
> minibuffer is no longer displayable, then it stops shrinking". So in
> his case the frame has ceased to be maximized for quite some time.
I don't understand your reasoning. If we prevent the shrinking from maximized, how is that not solving the problem?
Jan D.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 17:58 ` Jan Djärv
@ 2013-08-23 18:06 ` martin rudalics
0 siblings, 0 replies; 33+ messages in thread
From: martin rudalics @ 2013-08-23 18:06 UTC (permalink / raw)
To: Jan Djärv; +Cc: 14627, stephen.berman, bk1
> I don't understand your reasoning. If we prevent the shrinking from maximized, how is that not solving the problem?
Because apparently a frame may shrink in a non-maximized state too
(maybe maximization is always needed to trigger the process but I
wouldn't be sure).
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 17:55 ` martin rudalics
2013-08-23 17:58 ` Jan Djärv
@ 2013-08-23 18:02 ` Karl Brodowsky
2013-08-23 18:06 ` martin rudalics
1 sibling, 1 reply; 33+ messages in thread
From: Karl Brodowsky @ 2013-08-23 18:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, stephen.berman
On 08/23/13 19:55, martin rudalics wrote:
> >> A possible workaround is not to update size hints when Emacs is
> maximized or fullscreen.
> >
> > I think we should take that workaround.
>
> I'm afraid this won't help always. According to Stephen the frame
> "keeps shrinking (window-height decreases by one each time), until the
> minibuffer is no longer displayable, then it stops shrinking". So in
> his case the frame has ceased to be maximized for quite some time.
But if the first shrink moves Emacs out of the "maximized" state, then
this should
help, because the first shrink would not happen.
But for non-maximized-emacs-frames the issue remains.
Karl
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 18:02 ` Karl Brodowsky
@ 2013-08-23 18:06 ` martin rudalics
2013-08-23 18:14 ` Karl Brodowsky
0 siblings, 1 reply; 33+ messages in thread
From: martin rudalics @ 2013-08-23 18:06 UTC (permalink / raw)
To: Karl Brodowsky; +Cc: 14627, stephen.berman
> But for non-maximized-emacs-frames the issue remains.
Can you produce the shrinking in a non-maximized state?
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 18:06 ` martin rudalics
@ 2013-08-23 18:14 ` Karl Brodowsky
2013-08-24 8:55 ` martin rudalics
0 siblings, 1 reply; 33+ messages in thread
From: Karl Brodowsky @ 2013-08-23 18:14 UTC (permalink / raw)
To: martin rudalics, Jan Djärv; +Cc: 14627, stephen.berman
On 08/23/13 20:06, martin rudalics wrote:
>> But for non-maximized-emacs-frames the issue remains.
>
> Can you produce the shrinking in a non-maximized state?
No, in non-maximized state it behaves well.
If it is no maximized, but using up the whole height (or as much as I
can use up), I see a shrinking by one line and then it remains stable,
with some flickering, or let's say shrinking and growing by a few
pixels, but in the end when I click back and forth many times there is
no major change in size observable.
Karl
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 18:14 ` Karl Brodowsky
@ 2013-08-24 8:55 ` martin rudalics
0 siblings, 0 replies; 33+ messages in thread
From: martin rudalics @ 2013-08-24 8:55 UTC (permalink / raw)
To: Karl Brodowsky; +Cc: 14627, stephen.berman
> If it is no maximized, but using up the whole height (or as much as I
> can use up), I see a shrinking by one line and then it remains stable,
> with some flickering, or let's say shrinking and growing by a few
> pixels, but in the end when I click back and forth many times there is
> no major change in size observable.
Do the behaviors you describe (maximized/non-maximized) occur when you
turn off `tool-bar-mode'? If so, does the toolbar change its contents
and/or height when you switch windows? Does it occur when you use C-x o
instead of clicking with the mouse? Does the toolbar change when both
windows display the same buffer? Can you reproduce the behavior with
emacs -Q? Can you see the behavior described by Stephen in this thread?
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 16:22 ` Jan Djärv
2013-08-23 17:39 ` Eli Zaretskii
@ 2013-08-23 17:55 ` Karl Brodowsky
2013-08-24 8:45 ` Jan Djärv
1 sibling, 1 reply; 33+ messages in thread
From: Karl Brodowsky @ 2013-08-23 17:55 UTC (permalink / raw)
To: Jan Djärv; +Cc: stephen.berman, 14627
| A possible workaround is not to update size hints when Emacs is
maximized or fullscreen. Jan D.
Since this seems to be an issue with KDE4, which is not so uncommon as
window manager, I would agree.
Karl
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-23 17:55 ` Karl Brodowsky
@ 2013-08-24 8:45 ` Jan Djärv
2013-09-08 21:09 ` Stephen Berman
0 siblings, 1 reply; 33+ messages in thread
From: Jan Djärv @ 2013-08-24 8:45 UTC (permalink / raw)
To: Karl Brodowsky; +Cc: stephen.berman, 14627
Hello.
23 aug 2013 kl. 19:55 skrev Karl Brodowsky <bk1@gmx.net>:
> | A possible workaround is not to update size hints when Emacs is
> maximized or fullscreen. Jan D.
> Since this seems to be an issue with KDE4, which is not so uncommon as
> window manager, I would agree.
>
I've checked in the workaround. As I haven't seen the problem I don't know if it does anything, so please test it.
Thanks,
Jan D.
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-08-24 8:45 ` Jan Djärv
@ 2013-09-08 21:09 ` Stephen Berman
2013-09-09 12:00 ` martin rudalics
2015-02-13 18:23 ` martin rudalics
0 siblings, 2 replies; 33+ messages in thread
From: Stephen Berman @ 2013-09-08 21:09 UTC (permalink / raw)
To: Jan Djärv; +Cc: 14627, Karl Brodowsky
On Sat, 24 Aug 2013 10:45:09 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 23 aug 2013 kl. 19:55 skrev Karl Brodowsky <bk1@gmx.net>:
>
>> | A possible workaround is not to update size hints when Emacs is
>> maximized or fullscreen. Jan D.
>> Since this seems to be an issue with KDE4, which is not so uncommon as
>> window manager, I would agree.
>>
>
> I've checked in the workaround. As I haven't seen the problem I don't know if
> it does anything, so please test it.
I've now updated and confirm that with the recipe I gave -- frame
maximized with side by side windows, one containing an Info buffer --
switching between the windows no longer causes the frame to shrink
vertically. The only oddity is that when the Info buffer is selected
there is an empty space the width of the frame one line high below the
minibuffer.
However, there is still a shrinking problem. In KDE clicking the
frame's (i.e. WM window's) maximize button with mouse-2 instead of
mouse-1 maximizes the frame vertically but not horizontally. When I do
this, then split windows (either vertically or horizontally), open an
Info buffer in one window and switch between the windows, then the frame
still (i.e. even with your patch) shrinks vertically by one line for
each switch back to the Info buffer. If I drag the border of an
unmaximized frame to make it vertically fill the desktop and repeat the
recipe, no shrinking occurs. And if I maximize the frame horizontally
by clicking the maximize button with mouse-3 and repeat the recipe,
there is also no shrinking.
Steve Berman
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-09-08 21:09 ` Stephen Berman
@ 2013-09-09 12:00 ` martin rudalics
2013-09-09 12:23 ` Stephen Berman
2015-02-13 18:23 ` martin rudalics
1 sibling, 1 reply; 33+ messages in thread
From: martin rudalics @ 2013-09-09 12:00 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14627, Karl Brodowsky
> The only oddity is that when the Info buffer is selected
> there is an empty space the width of the frame one line high below the
> minibuffer.
Which disappears when you demaximize the frame, I suppose.
> However, there is still a shrinking problem. In KDE clicking the
> frame's (i.e. WM window's) maximize button with mouse-2 instead of
> mouse-1 maximizes the frame vertically but not horizontally. When I do
> this, then split windows (either vertically or horizontally), open an
> Info buffer in one window and switch between the windows, then the frame
> still (i.e. even with your patch) shrinks vertically by one line for
> each switch back to the Info buffer. If I drag the border of an
> unmaximized frame to make it vertically fill the desktop and repeat the
> recipe, no shrinking occurs. And if I maximize the frame horizontally
> by clicking the maximize button with mouse-3 and repeat the recipe,
> there is also no shrinking.
IIUC in his patch Jan fixed only the fully maximized and the fullscreen
cases. So what you see is the old behavior for the partially maximized
case.
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-09-09 12:00 ` martin rudalics
@ 2013-09-09 12:23 ` Stephen Berman
0 siblings, 0 replies; 33+ messages in thread
From: Stephen Berman @ 2013-09-09 12:23 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, Karl Brodowsky
On Mon, 09 Sep 2013 14:00:33 +0200 martin rudalics <rudalics@gmx.at> wrote:
>> The only oddity is that when the Info buffer is selected
>> there is an empty space the width of the frame one line high below the
>> minibuffer.
>
> Which disappears when you demaximize the frame, I suppose.
If I demaximize the frame while the Info buffer is selected and the
empty line is displayed, then the latter remains visible. But it
disappears after switching to the other buffer, and, with the frame
demaximized, when I switch back to the Info buffer again, it now no
longer reappears. Moreover, if I now maximize the frame again, with the
same window configuration, the empty line still doesn't reappear. In
fact, it turns out that it only appears if I maximize the frame before
opening Info the first time; if I then kill the Info buffer with the
frame still maximized and then open Info again, the empty line no longer
appears.
>> However, there is still a shrinking problem. In KDE clicking the
>> frame's (i.e. WM window's) maximize button with mouse-2 instead of
>> mouse-1 maximizes the frame vertically but not horizontally. When I do
>> this, then split windows (either vertically or horizontally), open an
>> Info buffer in one window and switch between the windows, then the frame
>> still (i.e. even with your patch) shrinks vertically by one line for
>> each switch back to the Info buffer. If I drag the border of an
>> unmaximized frame to make it vertically fill the desktop and repeat the
>> recipe, no shrinking occurs. And if I maximize the frame horizontally
>> by clicking the maximize button with mouse-3 and repeat the recipe,
>> there is also no shrinking.
>
> IIUC in his patch Jan fixed only the fully maximized and the fullscreen
> cases. So what you see is the old behavior for the partially maximized
> case.
That's also what I assumed.
Steve Berman
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2013-09-08 21:09 ` Stephen Berman
2013-09-09 12:00 ` martin rudalics
@ 2015-02-13 18:23 ` martin rudalics
2015-02-15 13:38 ` Stephen Berman
1 sibling, 1 reply; 33+ messages in thread
From: martin rudalics @ 2015-02-13 18:23 UTC (permalink / raw)
To: Stephen Berman, Jan Djärv; +Cc: 14627, Karl Brodowsky
> I've now updated and confirm that with the recipe I gave -- frame
> maximized with side by side windows, one containing an Info buffer --
> switching between the windows no longer causes the frame to shrink
> vertically. The only oddity is that when the Info buffer is selected
> there is an empty space the width of the frame one line high below the
> minibuffer.
Does this still happen with current trunk/master?
> However, there is still a shrinking problem. In KDE clicking the
> frame's (i.e. WM window's) maximize button with mouse-2 instead of
> mouse-1 maximizes the frame vertically but not horizontally. When I do
> this, then split windows (either vertically or horizontally), open an
> Info buffer in one window and switch between the windows, then the frame
> still (i.e. even with your patch) shrinks vertically by one line for
> each switch back to the Info buffer. If I drag the border of an
> unmaximized frame to make it vertically fill the desktop and repeat the
> recipe, no shrinking occurs. And if I maximize the frame horizontally
> by clicking the maximize button with mouse-3 and repeat the recipe,
> there is also no shrinking.
And this?
martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#14627: 24.2; Vertical frame size shrinking
2015-02-13 18:23 ` martin rudalics
@ 2015-02-15 13:38 ` Stephen Berman
2015-02-16 18:35 ` martin rudalics
0 siblings, 1 reply; 33+ messages in thread
From: Stephen Berman @ 2015-02-15 13:38 UTC (permalink / raw)
To: martin rudalics; +Cc: 14627, Karl Brodowsky
On Fri, 13 Feb 2015 19:23:43 +0100 martin rudalics <rudalics@gmx.at> wrote:
>> I've now updated and confirm that with the recipe I gave -- frame
>> maximized with side by side windows, one containing an Info buffer --
>> switching between the windows no longer causes the frame to shrink
>> vertically. The only oddity is that when the Info buffer is selected
>> there is an empty space the width of the frame one line high below the
>> minibuffer.
>
> Does this still happen with current trunk/master?
No, I don't see this now.
>> However, there is still a shrinking problem. In KDE clicking the
>> frame's (i.e. WM window's) maximize button with mouse-2 instead of
>> mouse-1 maximizes the frame vertically but not horizontally. When I do
>> this, then split windows (either vertically or horizontally), open an
>> Info buffer in one window and switch between the windows, then the frame
>> still (i.e. even with your patch) shrinks vertically by one line for
>> each switch back to the Info buffer. If I drag the border of an
>> unmaximized frame to make it vertically fill the desktop and repeat the
>> recipe, no shrinking occurs. And if I maximize the frame horizontally
>> by clicking the maximize button with mouse-3 and repeat the recipe,
>> there is also no shrinking.
>
> And this?
No, I also see no shrinking problem anymore.
Steve Berman
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2015-02-16 18:35 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-15 14:22 bug#14627: 24.2; Vertical frame size shrinking Karl Brodowsky
2013-08-19 18:56 ` Jan Djärv
2013-08-19 19:15 ` Jan Djärv
2013-08-22 11:32 ` Stephen Berman
2013-08-22 11:51 ` Stephen Berman
2013-08-22 11:59 ` Stephen Berman
2013-08-22 12:15 ` martin rudalics
2013-08-22 12:25 ` Stephen Berman
2013-08-23 7:10 ` martin rudalics
2013-08-23 8:20 ` Eli Zaretskii
2013-08-23 8:55 ` martin rudalics
2013-08-23 9:25 ` Eli Zaretskii
2013-08-23 10:21 ` martin rudalics
2013-08-23 10:33 ` Eli Zaretskii
2013-08-23 10:46 ` martin rudalics
2013-08-23 11:10 ` Eli Zaretskii
2013-08-23 16:22 ` Jan Djärv
2013-08-23 17:39 ` Eli Zaretskii
2013-08-23 17:55 ` martin rudalics
2013-08-23 17:58 ` Jan Djärv
2013-08-23 18:06 ` martin rudalics
2013-08-23 18:02 ` Karl Brodowsky
2013-08-23 18:06 ` martin rudalics
2013-08-23 18:14 ` Karl Brodowsky
2013-08-24 8:55 ` martin rudalics
2013-08-23 17:55 ` Karl Brodowsky
2013-08-24 8:45 ` Jan Djärv
2013-09-08 21:09 ` Stephen Berman
2013-09-09 12:00 ` martin rudalics
2013-09-09 12:23 ` Stephen Berman
2015-02-13 18:23 ` martin rudalics
2015-02-15 13:38 ` Stephen Berman
2015-02-16 18:35 ` 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).