* bug#14829: 24.3; split-window-keep-point breaks shell tab completion
@ 2013-07-08 21:08 Barry Warsaw
2013-07-11 19:37 ` bug#14829: (no subject) Barry Warsaw
2013-07-12 8:20 ` bug#14829: 24.3; split-window-keep-point breaks shell tab completion martin rudalics
0 siblings, 2 replies; 21+ messages in thread
From: Barry Warsaw @ 2013-07-08 21:08 UTC (permalink / raw)
To: 14829
[-- Attachment #1: Type: text/plain, Size: 3236 bytes --]
Start `emacs -Q`
(make the window full screen height, 80 columns wide)
M-x shell RET
(in the shell buffer)
$ cd /tmp
$ mkdir foo
$ cd foo
$ touch aa.txt ab.txt cc.txt dd.txt ee.txt ff.txt gg.txt hh.txt ii.txt jj.txt kk.txt ll.txt mm.txt nn.txt oo.txt pp.txt qq.txt rr.txt ss.txt tt.txt uu.txt vv.txt ww.txt xx.txt yy.txt zz.txt
$ ls -l
$ ls -l
(this is just to fill the buffer with output. now your shell prompt
should be the last line at the bottom of the frame, if not, hit C-l a
few times until it is.)
$ cat a<TAB>
With `(setq split-window-keep-point t)` you will see the window split,
with the top window scrolled to leave point just after the `a` in the
middle of the window. The bottom window will have the completions for
aa.txt and ab.txt
With `(setq split-window-keep-point nil)` you will not get any window
split, but point will jump someplace higher up in the window (e.g. for
me it jumps to just after the gg.txt line).
In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2)
of 2013-06-14 on komainu, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11303000
System Description: Ubuntu Saucy Salamander (development branch)
Configured using:
`configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
'--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
'--localstatedir=/var/lib' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
'--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
'--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'
'CPPFLAGS=-D_FORTIFY_SOURCE=2''
Important settings:
value of $LC_COLLATE: en_US.UTF-8
value of $LC_CTYPE: en_US.UTF-8
value of $LC_MESSAGES: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Shell
Minor modes in effect:
erc-notifications-mode: t
delete-selection-mode: t
icomplete-mode: t
shell-dirtrack-mode: t
erc-spelling-mode: t
erc-services-mode: t
erc-ring-mode: t
erc-networks-mode: t
erc-netsplit-mode: t
erc-menu-mode: t
erc-list-mode: t
erc-pcomplete-mode: t
erc-button-mode: t
erc-fill-mode: t
erc-stamp-mode: t
erc-autojoin-mode: t
show-paren-mode: t
savehist-mode: t
rcirc-track-minor-mode: t
global-whitespace-mode: t
erc-track-mode: t
erc-track-minor-mode: t
erc-match-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
erc-move-to-prompt-mode: t
erc-readonly-mode: t
desktop-save-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: (no subject)
2013-07-08 21:08 bug#14829: 24.3; split-window-keep-point breaks shell tab completion Barry Warsaw
@ 2013-07-11 19:37 ` Barry Warsaw
2013-07-22 17:18 ` Stefan Monnier
2013-07-12 8:20 ` bug#14829: 24.3; split-window-keep-point breaks shell tab completion martin rudalics
1 sibling, 1 reply; 21+ messages in thread
From: Barry Warsaw @ 2013-07-11 19:37 UTC (permalink / raw)
To: 14829
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
This fixes it for me.
;; Work around a bug in split-window-keep-point and completion.
(defadvice completion-at-point (around completion-at-point-around)
"Point safe completion"
(let ((split-window-keep-point t))
ad-do-it))
(ad-activate 'completion-at-point)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#14829: (no subject)
2013-07-11 19:37 ` bug#14829: (no subject) Barry Warsaw
@ 2013-07-22 17:18 ` Stefan Monnier
2013-07-22 17:37 ` martin rudalics
2013-07-22 17:41 ` Barry Warsaw
0 siblings, 2 replies; 21+ messages in thread
From: Stefan Monnier @ 2013-07-22 17:18 UTC (permalink / raw)
To: Barry Warsaw, martin rudalics; +Cc: 14829
> This fixes it for me.
> ;; Work around a bug in split-window-keep-point and completion.
> (defadvice completion-at-point (around completion-at-point-around)
> "Point safe completion"
> (let ((split-window-keep-point t))
> ad-do-it))
> (ad-activate 'completion-at-point)
Hmm... looking at it further I see that:
- split-window-keep-point defaults to t.
- the problem could affect other cases than completion.
Basically, I'm leaning towards forcing split-window-keep-point to t in
display-buffer, since AFAICT a value of nil only makes sense when you
split a window into two so that they both show the same buffer, whereas
in the case of display-buffer, you always want the current buffer's
point to stay put.
Why do you (and other people) set split-window-keep-point to nil?
What is the expected behavior from it?
The docstring seems to indicate it's only meant to affect C-x 2 rather
than all cases where we create a new window. Martin?
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#14829: (no subject)
2013-07-22 17:18 ` Stefan Monnier
@ 2013-07-22 17:37 ` martin rudalics
2013-07-22 17:42 ` Barry Warsaw
2013-07-22 18:56 ` Stefan Monnier
2013-07-22 17:41 ` Barry Warsaw
1 sibling, 2 replies; 21+ messages in thread
From: martin rudalics @ 2013-07-22 17:37 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 14829, Barry Warsaw
> Hmm... looking at it further I see that:
> - split-window-keep-point defaults to t.
> - the problem could affect other cases than completion.
> Basically, I'm leaning towards forcing split-window-keep-point to t in
> display-buffer, since AFAICT a value of nil only makes sense when you
> split a window into two so that they both show the same buffer, whereas
> in the case of display-buffer, you always want the current buffer's
> point to stay put.
With `inhibit-same-window' t one might want to show the same buffer in the
new window.
> The docstring seems to indicate it's only meant to affect C-x 2 rather
> than all cases where we create a new window. Martin?
It happens because \\[split-window-below] gets substituted by C-x 2.
Why not declare `split-window-keep-point' obsolete and always keep
point?
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: (no subject)
2013-07-22 17:37 ` martin rudalics
@ 2013-07-22 17:42 ` Barry Warsaw
2013-07-23 7:10 ` martin rudalics
2013-07-22 18:56 ` Stefan Monnier
1 sibling, 1 reply; 21+ messages in thread
From: Barry Warsaw @ 2013-07-22 17:42 UTC (permalink / raw)
To: martin rudalics; +Cc: 14829
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
On Jul 22, 2013, at 07:37 PM, martin rudalics wrote:
>It happens because \\[split-window-below] gets substituted by C-x 2.
>
>Why not declare `split-window-keep-point' obsolete and always keep
>point?
Please no! C-x 2 with split-window-keep-point nil is a *really* important
feature, to me at least.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: (no subject)
2013-07-22 17:37 ` martin rudalics
2013-07-22 17:42 ` Barry Warsaw
@ 2013-07-22 18:56 ` Stefan Monnier
2013-07-23 7:10 ` martin rudalics
1 sibling, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2013-07-22 18:56 UTC (permalink / raw)
To: martin rudalics; +Cc: 14829, Barry Warsaw
>> Hmm... looking at it further I see that:
>> - split-window-keep-point defaults to t.
>> - the problem could affect other cases than completion.
>> Basically, I'm leaning towards forcing split-window-keep-point to t in
>> display-buffer, since AFAICT a value of nil only makes sense when you
>> split a window into two so that they both show the same buffer, whereas
>> in the case of display-buffer, you always want the current buffer's
>> point to stay put.
> With `inhibit-same-window' t one might want to show the same buffer in the
> new window.
I can live with that "problem".
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#14829: (no subject)
2013-07-22 18:56 ` Stefan Monnier
@ 2013-07-23 7:10 ` martin rudalics
2013-07-23 13:09 ` Stefan Monnier
0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics @ 2013-07-23 7:10 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 14829, Barry Warsaw
> I can live with that "problem".
So what do we prefer? Handle this option in `split-window-sensibly' or
in `split-window-below'?
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: (no subject)
2013-07-23 7:10 ` martin rudalics
@ 2013-07-23 13:09 ` Stefan Monnier
2013-07-23 13:38 ` Barry Warsaw
2013-07-25 10:04 ` martin rudalics
0 siblings, 2 replies; 21+ messages in thread
From: Stefan Monnier @ 2013-07-23 13:09 UTC (permalink / raw)
To: martin rudalics; +Cc: 14829, Barry Warsaw
>> I can live with that "problem".
> So what do we prefer? Handle this option in `split-window-sensibly' or
> in `split-window-below'?
I think we can start by let-binding split-window-keep-point to t in
display-buffer.
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#14829: (no subject)
2013-07-23 13:09 ` Stefan Monnier
@ 2013-07-23 13:38 ` Barry Warsaw
2013-07-25 10:05 ` martin rudalics
2013-07-25 10:04 ` martin rudalics
1 sibling, 1 reply; 21+ messages in thread
From: Barry Warsaw @ 2013-07-23 13:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 14829
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
On Jul 23, 2013, at 09:09 AM, Stefan Monnier wrote:
>>> I can live with that "problem".
>> So what do we prefer? Handle this option in `split-window-sensibly' or
>> in `split-window-below'?
>
>I think we can start by let-binding split-window-keep-point to t in
>display-buffer.
I'm happy to test out a patch if it can be applied to 24.3.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: (no subject)
2013-07-23 13:38 ` Barry Warsaw
@ 2013-07-25 10:05 ` martin rudalics
2013-07-27 2:52 ` Barry Warsaw
0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics @ 2013-07-25 10:05 UTC (permalink / raw)
To: Barry Warsaw; +Cc: 14829
> I'm happy to test out a patch if it can be applied to 24.3.
It's trivial, try the one below.
Thanks, martin
--- lisp/window.el 2013-07-06 14:24:54 +0000
+++ lisp/window.el 2013-07-25 09:32:11 +0000
@@ -5470,6 +5470,9 @@
(let ((buffer (if (bufferp buffer-or-name)
buffer-or-name
(get-buffer buffer-or-name)))
+ ;; Make sure that when we split windows the old window keeps
+ ;; point, bug#14829.
+ (split-window-keep-point t)
;; Handle the old form of the first argument.
(inhibit-same-window (and action (not (listp action)))))
(unless (listp action) (setq action nil))
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#14829: (no subject)
2013-07-25 10:05 ` martin rudalics
@ 2013-07-27 2:52 ` Barry Warsaw
2013-07-27 8:18 ` martin rudalics
2013-07-29 16:56 ` martin rudalics
0 siblings, 2 replies; 21+ messages in thread
From: Barry Warsaw @ 2013-07-27 2:52 UTC (permalink / raw)
To: martin rudalics; +Cc: 14829
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
On Jul 25, 2013, at 12:05 PM, martin rudalics wrote:
>> I'm happy to test out a patch if it can be applied to 24.3.
>
>It's trivial, try the one below.
>
>Thanks, martin
>
>--- lisp/window.el 2013-07-06 14:24:54 +0000
>+++ lisp/window.el 2013-07-25 09:32:11 +0000
>@@ -5470,6 +5470,9 @@
> (let ((buffer (if (bufferp buffer-or-name)
> buffer-or-name
> (get-buffer buffer-or-name)))
>+ ;; Make sure that when we split windows the old window keeps
>+ ;; point, bug#14829.
>+ (split-window-keep-point t)
> ;; Handle the old form of the first argument.
> (inhibit-same-window (and action (not (listp action)))))
> (unless (listp action) (setq action nil))
Works great, thanks. I've applied this to Ubuntu 13.10's version of Emacs
24.3.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: (no subject)
2013-07-23 13:09 ` Stefan Monnier
2013-07-23 13:38 ` Barry Warsaw
@ 2013-07-25 10:04 ` martin rudalics
1 sibling, 0 replies; 21+ messages in thread
From: martin rudalics @ 2013-07-25 10:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 14829, Barry Warsaw
> I think we can start by let-binding split-window-keep-point to t in
> display-buffer.
Done.
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: (no subject)
2013-07-22 17:18 ` Stefan Monnier
2013-07-22 17:37 ` martin rudalics
@ 2013-07-22 17:41 ` Barry Warsaw
1 sibling, 0 replies; 21+ messages in thread
From: Barry Warsaw @ 2013-07-22 17:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 14829
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
On Jul 22, 2013, at 01:18 PM, Stefan Monnier wrote:
>> This fixes it for me.
>> ;; Work around a bug in split-window-keep-point and completion.
>> (defadvice completion-at-point (around completion-at-point-around)
>> "Point safe completion"
>> (let ((split-window-keep-point t))
>> ad-do-it))
>> (ad-activate 'completion-at-point)
>
>Hmm... looking at it further I see that:
>- split-window-keep-point defaults to t.
>- the problem could affect other cases than completion.
>Basically, I'm leaning towards forcing split-window-keep-point to t in
>display-buffer, since AFAICT a value of nil only makes sense when you
>split a window into two so that they both show the same buffer, whereas
>in the case of display-buffer, you always want the current buffer's
>point to stay put.
This seems reasonable to me, as long as it doesn't affect C-x 2.
>Why do you (and other people) set split-window-keep-point to nil?
>What is the expected behavior from it?
>
>The docstring seems to indicate it's only meant to affect C-x 2 rather
>than all cases where we create a new window. Martin?
C-x 2 is the only reason I set it to nil. There used to be an old XEmacs hack
(might have been some of my personal elisp) that did what I think was called
"slow-splitting" although it was not actually slow. It did exactly what C-x 2
with s-w-k-p set to nil does. I love this for tall windows since in most
cases, nothing changes except you get a modeline in the middle of the window
where the split occurs.
So I'm all in favor of keeping the behavior for C-x 2 and inhibiting it for
all other purposes. I have definitely encountered other situations that the
defadvice above does not handle. One example is pdb-track in python-mode.
When you hit the breakpoint, the shell buffer is split with the code shown
below, but the split does not happen correct. Point is left at the same bogus
place as described in the original bug report.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: 24.3; split-window-keep-point breaks shell tab completion
2013-07-08 21:08 bug#14829: 24.3; split-window-keep-point breaks shell tab completion Barry Warsaw
2013-07-11 19:37 ` bug#14829: (no subject) Barry Warsaw
@ 2013-07-12 8:20 ` martin rudalics
2013-07-12 9:26 ` Eli Zaretskii
1 sibling, 1 reply; 21+ messages in thread
From: martin rudalics @ 2013-07-12 8:20 UTC (permalink / raw)
To: Barry Warsaw; +Cc: 14829
> With `(setq split-window-keep-point t)` you will see the window split,
> with the top window scrolled to leave point just after the `a` in the
> middle of the window. The bottom window will have the completions for
> aa.txt and ab.txt
>
> With `(setq split-window-keep-point nil)` you will not get any window
> split, but point will jump someplace higher up in the window (e.g. for
> me it jumps to just after the gg.txt line).
`split-window-below' here does
(setq new-window (split-window nil size))
(unless split-window-keep-point
so I don't understand how setting `split-window-keep-point' can affect
the decisison whether to split the window.
Does anyone know where this behavior comes from?
martin
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#14829: 24.3; split-window-keep-point breaks shell tab completion
2013-07-12 8:20 ` bug#14829: 24.3; split-window-keep-point breaks shell tab completion martin rudalics
@ 2013-07-12 9:26 ` Eli Zaretskii
2013-07-12 10:12 ` martin rudalics
2013-07-12 14:12 ` Barry Warsaw
0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2013-07-12 9:26 UTC (permalink / raw)
To: martin rudalics; +Cc: 14829, barry
> Date: Fri, 12 Jul 2013 10:20:22 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 14829@debbugs.gnu.org
>
> > With `(setq split-window-keep-point t)` you will see the window split,
> > with the top window scrolled to leave point just after the `a` in the
> > middle of the window. The bottom window will have the completions for
> > aa.txt and ab.txt
> >
> > With `(setq split-window-keep-point nil)` you will not get any window
> > split, but point will jump someplace higher up in the window (e.g. for
> > me it jumps to just after the gg.txt line).
>
> `split-window-below' here does
>
> (setq new-window (split-window nil size))
> (unless split-window-keep-point
>
> so I don't understand how setting `split-window-keep-point' can affect
> the decisison whether to split the window.
Maybe it is split, and then deleted, before we have a chance of
displaying it?
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: 24.3; split-window-keep-point breaks shell tab completion
2013-07-12 9:26 ` Eli Zaretskii
@ 2013-07-12 10:12 ` martin rudalics
2013-07-12 14:18 ` Barry Warsaw
2013-07-12 14:12 ` Barry Warsaw
1 sibling, 1 reply; 21+ messages in thread
From: martin rudalics @ 2013-07-12 10:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14829, barry
> Maybe it is split, and then deleted, before we have a chance of
> displaying it?
Maybe it is not split at all for other reasons. But that decision
should never be affected by `split-window-keep-point'. Barry, can you
check whether and/or why not a window splitting occurs?
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: 24.3; split-window-keep-point breaks shell tab completion
2013-07-12 10:12 ` martin rudalics
@ 2013-07-12 14:18 ` Barry Warsaw
0 siblings, 0 replies; 21+ messages in thread
From: Barry Warsaw @ 2013-07-12 14:18 UTC (permalink / raw)
To: martin rudalics; +Cc: 14829
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On Jul 12, 2013, at 12:12 PM, martin rudalics wrote:
> > Maybe it is split, and then deleted, before we have a chance of
> > displaying it?
>
>Maybe it is not split at all for other reasons. But that decision
>should never be affected by `split-window-keep-point'. Barry, can you
>check whether and/or why not a window splitting occurs?
With this workaround:
(defadvice completion-at-point (around completion-at-point-around)
"Point safe completion"
(let ((split-window-keep-point t))
ad-do-it))
(ad-activate 'completion-at-point)
and the setup I mentioned earlier (e.g. shell buffer filled with output,
prompt on bottom line of window)...
If you deactivate the advice, what happens when you hit TAB is that you don't
see the split, but you also don't see the completion buffer. Point just jumps
up to the end-of-line on a line about half-way up the window.
With the advice activated, the window gets split, with the completion buffer
on bottom, and the shell buffer scrolled up so that point remains on the
prompt line which is now approximately in the middle of its buffer (looks to
be a few lines lower, but that's really immaterial).
I notice the exact same behavior in an ERC window, so it's clearly related to
completion-at-point. Hence the advice in the workaround.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14829: 24.3; split-window-keep-point breaks shell tab completion
2013-07-12 9:26 ` Eli Zaretskii
2013-07-12 10:12 ` martin rudalics
@ 2013-07-12 14:12 ` Barry Warsaw
1 sibling, 0 replies; 21+ messages in thread
From: Barry Warsaw @ 2013-07-12 14:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14829
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Jul 12, 2013, at 12:26 PM, Eli Zaretskii wrote:
>Maybe it is split, and then deleted, before we have a chance of
>displaying it?
I think that's exactly what's happening. I did a long session of edebug
tracing and observed that behavior (split, then deleted). I'm sorry that I
don't remember the details - it was quite a long spelunk through the Elisp.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-07-29 16:56 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-08 21:08 bug#14829: 24.3; split-window-keep-point breaks shell tab completion Barry Warsaw
2013-07-11 19:37 ` bug#14829: (no subject) Barry Warsaw
2013-07-22 17:18 ` Stefan Monnier
2013-07-22 17:37 ` martin rudalics
2013-07-22 17:42 ` Barry Warsaw
2013-07-23 7:10 ` martin rudalics
2013-07-22 18:56 ` Stefan Monnier
2013-07-23 7:10 ` martin rudalics
2013-07-23 13:09 ` Stefan Monnier
2013-07-23 13:38 ` Barry Warsaw
2013-07-25 10:05 ` martin rudalics
2013-07-27 2:52 ` Barry Warsaw
2013-07-27 8:18 ` martin rudalics
2013-07-29 16:56 ` martin rudalics
2013-07-25 10:04 ` martin rudalics
2013-07-22 17:41 ` Barry Warsaw
2013-07-12 8:20 ` bug#14829: 24.3; split-window-keep-point breaks shell tab completion martin rudalics
2013-07-12 9:26 ` Eli Zaretskii
2013-07-12 10:12 ` martin rudalics
2013-07-12 14:18 ` Barry Warsaw
2013-07-12 14:12 ` Barry Warsaw
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).