Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stefan Monnier]

>     * packages/other-frame-window/other-frame-window.el: New single-file package.

Thanks Stephen.  The auto-build of the package failed because it didn't
follow the ";;; name --- desc" convention, so I fixed it.  And while
I was there I made a bunch of other changes.  Please take a look at them.


        Stefan

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stephen Leake]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>     * packages/other-frame-window/other-frame-window.el: New single-file package.
>
> Thanks Stephen.  The auto-build of the package failed because it didn't
> follow the ";;; name --- desc" convention, so I fixed it.  

Sorry about that.

> And while
> I was there I made a bunch of other changes.  Please take a look at
> them.

Thanks, looks good.

I have a couple questions:

In `ofw-transient-map', you wrote:

    ;; FIXME: This is basically the union of the default C-x 4 and C-x 5
    ;; keymaps in Emacs-25.

Is the point of this FIXME: that eventually this could replace the C-x 4
and C-x 5 keymaps?

In ofw-display-buffer-other-window, you added a FIXME about being
careful with display-buffer-overriding-action; that was an oversite,
I'll fix it.

In `other-frame-window-mode':

- I agree :lighter can be removed.

- Why is (remove-hook 'pre-command-hook #'ofw--reset-prefix) before the
  'if', instead of in the else branch?

-- 
-- Stephe

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stefan Monnier]

>     ;; FIXME: This is basically the union of the default C-x 4 and C-x 5
>     ;; keymaps in Emacs-25.
> Is the point of this FIXME: that eventually this could replace the C-x 4
> and C-x 5 keymaps?

Good question.  I think it was a mistake.  I probably started to write
"FIXME:" because I wanted to document the problem of the "dwim"
commands, which are somewhat ugly, but then I went ahead and wrote
those dwim commands and decided it wasn't that bad.  So the end result
is a doc that isn't really a FIXME but which starts with "FIXME:".

> - Why is (remove-hook 'pre-command-hook #'ofw--reset-prefix) before the
>   'if', instead of in the else branch?

I like to write minor modes such that they always begin by cleaning up
first and then, if requested, adding what needs to be added.
I think in the case of global hooks it makes no difference, but for
a few other cases it avoids adding stuff twice or having to check
whether the mode was already enabled or something.


        Stefan

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Kaushal]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

If I do C-x 5 f, a new frame opens if needed (if I have only one frame to
begin with).
But if I do C-x 9 f, the buffer opens in a second frame only if I have 2
frames to begin with. If I had just one frame open, C-x 9 f seems to do
nothing. Is that by design? If not, I can debug my config.

On Sat, Aug 15, 2015 at 5:50 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >     ;; FIXME: This is basically the union of the default C-x 4 and C-x 5
> >     ;; keymaps in Emacs-25.
> > Is the point of this FIXME: that eventually this could replace the C-x 4
> > and C-x 5 keymaps?
>
> Good question.  I think it was a mistake.  I probably started to write
> "FIXME:" because I wanted to document the problem of the "dwim"
> commands, which are somewhat ugly, but then I went ahead and wrote
> those dwim commands and decided it wasn't that bad.  So the end result
> is a doc that isn't really a FIXME but which starts with "FIXME:".
>
> > - Why is (remove-hook 'pre-command-hook #'ofw--reset-prefix) before the
> >   'if', instead of in the else branch?
>
> I like to write minor modes such that they always begin by cleaning up
> first and then, if requested, adding what needs to be added.
> I think in the case of global hooks it makes no difference, but for
> a few other cases it avoids adding stuff twice or having to check
> whether the mode was already enabled or something.
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1826 bytes --]

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stefan Monnier]

> If I do C-x 5 f, a new frame opens if needed (if I have only one frame to
> begin with).
> But if I do C-x 9 f, the buffer opens in a second frame only if I have 2
> frames to begin with. If I had just one frame open, C-x 9 f seems to do
> nothing. Is that by design?

No.  The design is for C-x 9 f to behave pretty much exactly like C-x 5 f.
But indeed, I can reproduce here (with -Q) the problem you describe, so
the problem is not in your config.


        Stefan

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If I do C-x 5 f, a new frame opens if needed (if I have only one frame to
>> begin with).
>> But if I do C-x 9 f, the buffer opens in a second frame only if I have 2
>> frames to begin with. If I had just one frame open, C-x 9 f seems to do
>> nothing. Is that by design?
>
> No.  The design is for C-x 9 f to behave pretty much exactly like C-x 5 f.
> But indeed, I can reproduce here (with -Q) the problem you describe, so
> the problem is not in your config.

Hmm. It works here:

emacs -Q

In *scratch*:

(package-initialize)
(require 'other-frame-window)
(other-frame-window-mode 1)

C-x 9 f ~/.emacs.d/elpa/other-frame-window-1.0.1/other-frame-widow.el

Opens in a new frame.

I'm on Windows 8, Emacs built with Mingw 64 bit.


The require step should not be needed; it's missing an autoload cookie.



-- 
-- Stephe

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stefan Monnier]

> No.  The design is for C-x 9 f to behave pretty much exactly like C-x 5 f.
> But indeed, I can reproduce here (with -Q) the problem you describe, so
> the problem is not in your config.

Actually, I'm not sure I can reproduce it: the problem I see is that if
the find-file commands prompts me with a y-or-n-p (to follow the symlink
to the VCS controlled file), then I don't get a new frame, but if the
file is found without prompting then I do get a new frame.


        Stefan

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> No.  The design is for C-x 9 f to behave pretty much exactly like C-x 5 f.
>> But indeed, I can reproduce here (with -Q) the problem you describe, so
>> the problem is not in your config.
>
> Actually, I'm not sure I can reproduce it: the problem I see is that if
> the find-file commands prompts me with a y-or-n-p (to follow the symlink
> to the VCS controlled file), then I don't get a new frame, but if the
> file is found without prompting then I do get a new frame.

I can get that effect when opening a modified file:

$ emacs -Q
(progn
 (package-initialize)
 (require 'other-frame-window)
 (other-frame-window-mode 1))

C-x f /Projects/elpa/packages/other-frame-window/other-frame-window.el

# back in shell:
$ touch /Projects/elpa/packages/other-frame-window/other-frame-window.el

# in Emacs:
C-x 9 f /Projects/elpa/packages/other-frame-window/other-frame-window.el
# get prompt; answer yes

opens in same frame. Without the prompt, it opens a new frame.

So the prompt is consuming the other-frame prefix, despite the advice
around read-from-minibuffer.


-- 
-- Stephe

Re: [elpa] master b843370: * packages/other-frame-window/other-frame-window.el: New single-file package.

[Stefan Monnier]

> So the prompt is consuming the other-frame prefix, despite the advice
> around read-from-minibuffer.

Ah, right, I think the issue is simply that the yes-or-no-p code doesn't
go through read-from-minibuffer (e.g. it calls directly the C function,
thus circumventing the advice).


        Stefan