On Monday, 18 Oct 2021 at 23:53, Max Nikulin wrote:
> I was trying to say that even with such *user* setup, behavior of Org
> should be reasonable.
Ah, okay. I agree. I also do not know what should be the default
behaviour but I do know that I don't like the current default behaviour!
I would,
On 18/10/2021 16:25, Eric S Fraga wrote:
On Sunday, 17 Oct 2021 at 23:35, Max Nikulin wrote:
So
(setq display-buffer-base-action
'((display-buffer-reuse-window display-buffer-pop-up-frame)
(reusable-frames . 0)))
should not be considered as shooting a foot.
I am not
On Sunday, 17 Oct 2021 at 23:35, Max Nikulin wrote:
> So
>
>(setq display-buffer-base-action
> '((display-buffer-reuse-window display-buffer-pop-up-frame)
> (reusable-frames . 0)))
>
> should not be considered as shooting a foot.
I am not sure I understand what you are or
On 16/10/2021 13:52, Ihor Radchenko wrote:
Max Nikulin writes:
It seems, each case of `org-no-popups' may require specific code. I have
tried to take some code related to completion. It overrides
display-buffer-base-action, but something more is required for
pop-up-frames.
I think you went
Max Nikulin writes:
> It seems, each case of `org-no-popups' may require specific code. I have
> tried to take some code related to completion. It overrides
> display-buffer-base-action, but something more is required for
> pop-up-frames.
I think you went too far. display-buffer-base-action
On 14/10/2021 22:44, Max Nikulin wrote:
I think, something should be done with `org-no-popups'. Assume a user
who has (I have no idea concerning the goal though)
(setq pop-up-frames t)
(setq display-buffer-base-action
'((display-buffer-reuse-window display-buffer-pop-up-frame)
On 14/10/2021 17:16, Ihor Radchenko wrote:
Marco Wahl writes:
Since org-goto in main is still broken I'll commit the fix for org-goto
which kicks out the use of the macro org-no-popups (but not the macro
itself since it's used elsewhere AFAICS.)
Max, Ihor! If you see the necessity of
Marco Wahl writes:
> Since org-goto in main is still broken I'll commit the fix for org-goto
> which kicks out the use of the macro org-no-popups (but not the macro
> itself since it's used elsewhere AFAICS.)
>
> Max, Ihor! If you see the necessity of refinement please keep going!
I am
Thanks Eric and Max!
> On Wednesday, 13 Oct 2021 at 19:23, Max Nikulin wrote:
>> Does someone have settings that pins help buffer to particular
>> window/frame of location in a frame (e.g. bottom of "sidebar")?
>
> This is what I use, which is slightly more complex because I have a wide
>
On Wednesday, 13 Oct 2021 at 19:23, Max Nikulin wrote:
> Does someone have settings that pins help buffer to particular
> window/frame of location in a frame (e.g. bottom of "sidebar")?
This is what I use, which is slightly more complex because I have a wide
landscape monitor and a tall portrait
On 13/10/2021 16:44, Marco Wahl wrote:
Clearly I'm for kicking out org-no-popups completely. Many details have
been mentioned already. The big argument for that change for me is that
the code gets simpler.
I have no strong opinion. Second patch locally restoring
`pop-up-windows' is more
Thanks Ihor!
> Marco Wahl writes:
>
>> My feeling is that the "protection" is good intention but brings more
>> harm than good. I think it's not a good idea to enforce a certain
>> window setting. I guess the knowing user has an easier path to fine
>> tune the org-goto user interface when
Marco Wahl writes:
> My feeling is that the "protection" is good intention but brings more
> harm than good. I think it's not a good idea to enforce a certain
> window setting. I guess the knowing user has an easier path to fine
> tune the org-goto user interface when there is less
Hi Max and all!
> On 08/10/2021 17:22, Marco Wahl wrote:
>> Max Nikulin writes:
>>> On 05/10/2021 23:32, Ihor Radchenko wrote:
Max Nikulin writes:
I tried come up with the reason why org-no-popup was used in the
initial
implementation. I think, the reason is avoiding situation
On 08/10/2021 17:22, Marco Wahl wrote:
Max Nikulin writes:
On 05/10/2021 23:32, Ihor Radchenko wrote:
Max Nikulin writes:
I tried come up with the reason why org-no-popup was used in the
initial
implementation. I think, the reason is avoiding situation like what you
may see after running
(let
Max Nikulin writes:
> On 05/10/2021 23:32, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> I tried come up with the reason why org-no-popup was used in the
>> initial
>> implementation. I think, the reason is avoiding situation like what you
>> may see after running
>> (let ((pop-up-frames t))
On 05/10/2021 23:32, Ihor Radchenko wrote:
Max Nikulin writes:
I tried come up with the reason why org-no-popup was used in the initial
implementation. I think, the reason is avoiding situation like what you
may see after running
(let ((pop-up-frames t)) (funcall-interactively #'org-goto))
So,
Max Nikulin writes:
> Thank you, Ihor. I am a user of alternative `org-goto' interface. I have
> tried default one having a couple of windows in the frame (indirect
> buffer for subtree, indirect for src block). It seems, previous window
> configuration is restored correctly when `org-goto'
On 05/10/2021 19:45, Ihor Radchenko wrote:
Max Nikulin writes:
Regression is caused by
commit 399481bad10845a77f210c9320ff1efee9a312c8
Author: Ihor Radchenko
Date: Mon May 31 20:47:45 2021 +0800
Do not ignore user-defined display-buffer-alist in org-insert-link
See the attached
Hi Ihor,
> See the attached fix. The fix looks reasonable, though I fail to
> understand why org-no-popup was even used in org-goto-location. We kind
> of want a popup there. git blame did not reveal anything useful either.
>
> Adam, can you test the fix in different scenarios first? I do not
Max Nikulin writes:
> Regression is caused by
>
> commit 399481bad10845a77f210c9320ff1efee9a312c8
> Author: Ihor Radchenko
> Date: Mon May 31 20:47:45 2021 +0800
>
> Do not ignore user-defined display-buffer-alist in org-insert-link
See the attached fix. The fix looks reasonable,
21 matches
Mail list logo
