emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Marco Wahl <marcowahlsoft@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Max Nikulin <manikulin@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken
Date: Wed, 13 Oct 2021 11:44:20 +0200	[thread overview]
Message-ID: <87pms9mf7v.fsf@gmail.com> (raw)
In-Reply-To: <87o87tso54.fsf@localhost> (Ihor Radchenko's message of "Wed, 13 Oct 2021 09:35:03 +0800")

Thanks Ihor!

> Marco Wahl <marcowahlsoft@gmail.com> 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 "protection".
> I fully agree. That was the motivation behind removing
> dislpay-buffer-alist in 399481bad1. It is indeed not a good idea to
> overwrite user customisations. They can be deliberate. For example, see
> https://orgmode.org/list/87h7ij12t8.fsf@localhost
> Max Nikulin <manikulin@gmail.com> writes:
>> However current version of macro does not protect against
>>    (setq display-buffer-base-action
>> 	 '((display-buffer-reuse-window display-buffer-pop-up-frame)
>> 	   (reusable-frames . 0)))
>> The example is taken from (info "(elisp) Choosing Window Options"). I 
>> have no idea if such customization can be considered as shooting a foot.
> display-buffer-base-action, if customised by user, can later be
> fine-tuned using display-buffer-alist. If necessary, the user can easily
> add org-goto popup as an exception. At least, it is my understanding
> from reading docs.
> However, pop-up-frames and pop-up-windows are different beasts. They
> cannot be fine-tuned by the user to not affect org-goto.  AFAIK, the
> only way for the user to overcome the problem would be advicing
> org-goto.
>> Summary: The org-goto interface today is somewhat broken.  I vote for
>> taking the occasion and kicking out the macro org-no-popups entirely.
>> This way the org-goto interface is functional AFAICS.  If problems occur
>> on that path we'll take care and action.
>> Do you agree?
> My second version of the patch also fixes org-goto interface :)

Indeed, thanks.

> On the other hand, kicking org-no-popups macro completely may be an
> option. pop-up-windows and pop-up-frames are obsolete and should not be
> used anymore.
> Also, a compromise could be changing org-no-popups to just
> (let (pop-up-frames) ...)

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.

But that's just me.  All the other fixes may have advantages too.  In
the first place I want back a usable org-goto interface.

I'd like to leave it to you to commit a fix.

Best regards,

  reply	other threads:[~2021-10-13  9:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05  6:31 [BUG] Org 9.5: org-goto UI seems broken Adam Porter
2021-10-05 11:35 ` Max Nikulin
2021-10-05 12:45   ` [PATCH] " Ihor Radchenko
2021-10-05 12:52     ` Adam Porter
2021-10-05 14:49     ` Max Nikulin
2021-10-05 16:32       ` Ihor Radchenko
2021-10-07 16:14         ` Max Nikulin
2021-10-08 10:22           ` Marco Wahl
2021-10-12 14:59             ` Max Nikulin
2021-10-12 20:58               ` Marco Wahl
2021-10-13  1:35                 ` Ihor Radchenko
2021-10-13  9:44                   ` Marco Wahl [this message]
2021-10-13 12:23                     ` Max Nikulin
2021-10-13 12:35                       ` Eric S Fraga
2021-10-14  9:54                         ` Marco Wahl
2021-10-14 10:16                           ` Ihor Radchenko
2021-10-14 15:44                             ` Max Nikulin
2021-10-15 16:37                               ` Max Nikulin
2021-10-16  6:52                                 ` Ihor Radchenko
2021-10-17 16:35                                   ` Max Nikulin
2021-10-18  9:25                                     ` Eric S Fraga
2021-10-18 16:53                                       ` Max Nikulin
2021-10-19  7:45                                         ` Eric S Fraga
2021-10-05 12:48   ` Adam Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pms9mf7v.fsf@gmail.com \
    --to=marcowahlsoft@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    --cc=yantar92@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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).