Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Ok, so change pushed... I'm sorry, but this is going too fast. We're discussing core design here (the parser), and I couldn't even answer your proposal. Let's at least reach an agreement on the change to make. Regards, -- Nicolas Goaziou
[RFC PATCH] Changes to pop-up source buffers
This patch changes some implementation details of org-src-switch-to-buffer and org-edit-src-exit, to more consistently use pop-to-buffer to open the source buffer, and quit-restore-window to close it. It also adds a new default option to org-src-window-setup. I'll explain some details and motivation for this now. First, on killing the source buffer. Currently, we kill it with kill-buffer, then restore the previous saved window configuration with set-window-configuration. The downside is that, if changes to the windows were made while editing the source buffer, for example if a new window is opened to refer to some other file, then these changes will be lost after the original window configuration is restored. By contrast, this patch uses quit-restore-window to close the source window, which won't affect other windows that may have been changed. quit-restore-window is also smart enough to decide whether the source window should be deleted (if the source buffer was popped up in a new window), or whether the window should be kept and switched to some previous buffer (if the source buffer was popped up on an existing window). Next, I changed org-src-window-setup to consistently use pop-to-buffer to create the source window. This is needed for quit-restore-window to figure out whether to delete the source window. Otherwise, if we separately create the window and switch to it, then quit-restore-window won't know whether the window was previously used for something else. Finally, I added a new default option to org-src-window-setup, to use the user's default configuration of display-buffer. Personally, I have configured my own display-buffer-base-action and would like org-babel to use it. Also, if a user is not satisfied with any of the options in org-src-window-setup, this allows them to use their own configuration. In most cases, the new default for org-src-window-setup will behave similarly to the previous default (reorganize-frame). It will only behave differently when 3 or more windows are currently open. A final advantage I'd like to note for pop-to-buffer and quit-restore-window, is that these are the mechanisms used by many built-in Emacs functions to pop up and close windows, such as *Help* windows. There was one previous option for org-src-window-setup, reorganize-frame, that I couldn't reimplement using pop-to-buffer. That option required keeping around some logic for deleting windows and restoring the configuration. I tested the new implementation for org-src-switch-to-buffer, for all options of org-src-window-setup, and it appears to work correctly. I tested this on Emacs 26.3. >From fe2df20f3ddb72ca083c75eee7ece302abecf75a Mon Sep 17 00:00:00 2001 From: Jack Kamm Date: Sat, 18 Jan 2020 07:55:48 -0800 Subject: [PATCH] org-src: use display-buffer, quit-restore-window for source buffers --- etc/ORG-NEWS| 14 --- lisp/org-src.el | 65 +++-- 2 files changed, 42 insertions(+), 37 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 67c3ca2ed..cbbd50cf0 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -30,10 +30,18 @@ group new datetime entries by month. Babel Java blocks recognize header argument =:cmdargs= and pass its value in call to =java=. -*** Refinement in window behavior on exiting Org source buffer +*** Improved window behavior for Org source buffer -After editing a source block, Org will restore the window layout when -~org-src-window-setup~ is set to a value that modifies the layout. +More consistently use the ~display-buffer~ framework for popping up +source buffers. + +Added an option ~default~ to ~org-src-window-setup~, that respects the +user's default configuration of ~display-buffer~ to pop up +buffers. This is the new default value for ~org-src-window-setup~. + +The option ~reorganize-frame~ was also reverted to the previous +behavior of restoring the window configuration after exiting the +source buffer. ** New functions *** ~org-columns-toggle-or-columns-quit~ diff --git a/lisp/org-src.el b/lisp/org-src.el index 878821b14..949638fa0 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -144,26 +144,24 @@ the existing edit buffer." :package-version '(Org . "8.0") :type 'boolean) -(defcustom org-src-window-setup 'reorganize-frame +(defcustom org-src-window-setup 'default "How the source code edit buffer should be displayed. Possible values for this option are: +defaultUse default `display-buffer' action. current-window Show edit buffer in the current window, keeping all other windows. split-window-below Show edit buffer below the current window, keeping all other windows. split-window-right Show edit buffer to the right of the current window, keeping all other windows. -other-window Use `switch-to-buffer-other-window' to display edit buffer. +other-window Use some other window to display edit
Re: [RFC PATCH] Changes to pop-up source buffers
Hi Sam, > for me, trying to get commands or functions that call pop-to-buffer to > behave as i need them to, which is to say, for them to use the full > (and same) window for accessibility reasons,* has been so unfixable in > the past that i had to give up. Thank you for raising this, I wasn't aware that pop-to-buffer might cause accessibility issues. I want to make sure that this patch won't cause any accessibility issues and hope I can address your concerns. What setting of org-src-window-setup are you using? If it is "current-window" or "reorganize-frame", this patch shouldn't affect you at all, as those implementations are left the same. I tested all the other options for org-src-window-setup as well, and their behavior remained the same when I tested them. Most options do call pop-to-buffer or display-buffer at some point or other, this patch mainly simplifies and unifies the way they call pop-to-buffer. This includes the "current-window" option, which calls "pop-to-buffer-same-window". So I don't think the patch should cause new accessibility problems.
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi! org-attach-store-link-p with option t is supposed to store a link to the original location (i.e. the location the file was/is in before it was attached to the node. That was the default before I started working with attachments I believe. Haven't ever used that feature myself but the patch you provide would change the functionality which I don't think is correct. It would also not match the documentation any longer. See the documentation for the customization parameter: #+begin_src emacs-lisp (defcustom org-attach-store-link-p nil "Non-nil means store a link to a file when attaching it." :group 'org-attach :version "24.1" :type '(choice (const :tag "Don't store link" nil) (const :tag "Link to origin location" t) (const :tag "Link to the attach-dir location" attached))) #+end_src Regards Gustav > -Original Message- > From: stardiviner > Sent: den 18 januari 2020 15:56 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > > stardiviner writes: > > I finally figured out why the link always failed. Because it use wrong > variable which is old filename path. I attached a patch. > > > Gustav Wikström writes: > > > >> Hi, > >> > >>> -Original Message- > >>> From: stardiviner > >>> Sent: den 15 januari 2020 07:21 > >>> To: Gustav Wikström > >>> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > >>> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach > >>> options > >>> > >>> [...] > >>> > >>> >> I found when I set option ~(setq org-attach-store-link-p t)~. > >>> >> Then attach a file, store file link with =[C-c C-l]=. The stored > >>> >> link. I open this link got error "No such file: ". I tested > >>> >> this with minimal Emacs config. confirmed this problem. > >>> >> > >>> > > >>> > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) > >>> > and > >>> with only that single customization it works for me. I'm testing it > >>> in linux. A wild guess.. Could it be that you used the move > >>> operation instead of the copy operation when attaching the file? > >>> > > >>> > Regards > >>> > Gustav > >>> > >>> Did you reproduce this issue with =emacs -q= ? That is a built-in > >>> Org Mode version which does not contains the latest version =org- > attach.el=. > >>> > >>> Here is my minimal Emacs config: > >>> > >>> [...] > >>> > >>> ;;== > >>> == > >>> == > >>> ;;; Here is org-attach.el customization > >>> > >>> (require 'org-attach) > >>> > >>> ;; store link auto with `org-store-link' using `file:' link type or > >>> `attachment:' link type. > >>> (setq org-attach-store-link-p 'attached) (setq > >>> org-attach-dir-relative t) (setq org-attach-preferred-new-method > >>> 'ask) #+end_src > >>> > >>> #+begin_src sh :eval no > >>> emacs -q -l '~/.config/emacs/minimal-init.el' > >>> #+end_src > >> > > > >> Hmm, in the first mail you said that you set org-attach-store-link-p > >> to t, but in your config it says 'attached. > > > > Sorry about this. > > > >> I've tried with a minimal config as well (using emacs -q because I > >> build the newest org mode version into the emacs > >> folder) and can only reproduce your issue when using the attached > >> option for org-attach-store-link-p and then inserting that link with > >> C-c C-l /in another heading/. Pasting the link in another heading is > >> expected to break since the attachment link is context dependent (i.e. > requires an attachment folder). > >> Makes sense? If I'm still misunderstanding your use-case, would you > >> care to describe the steps to reproduce it more in detail? > > > > After updated commit, don't know why, but all links worked again. I'm > > not good at expressing thanks, but you got all my thanks on this. :) > > > >> Regards > >> Gustav > >> > > -- > [ stardiviner ] >I try to make every word tell the meaning what I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >
Re: [O] FW: [RFC] Link-type for attachments, more attach options
stardiviner writes: I finally figured out why the link always failed. Because it use wrong variable which is old filename path. I attached a patch. > Gustav Wikström writes: > >> Hi, >> >>> -Original Message- >>> From: stardiviner >>> Sent: den 15 januari 2020 07:21 >>> To: Gustav Wikström >>> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org >>> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >>> >>> [...] >>> >>> >> I found when I set option ~(setq org-attach-store-link-p t)~. Then >>> >> attach a file, store file link with =[C-c C-l]=. The stored link. I >>> >> open this link got error "No such file: ". I tested this with >>> >> minimal Emacs config. confirmed this problem. >>> >> >>> > >>> > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) and >>> with only that single customization it works for me. I'm testing it in >>> linux. A wild guess.. Could it be that you used the move operation instead >>> of the copy operation when attaching the file? >>> > >>> > Regards >>> > Gustav >>> >>> Did you reproduce this issue with =emacs -q= ? That is a built-in Org Mode >>> version which does not contains the latest version =org-attach.el=. >>> >>> Here is my minimal Emacs config: >>> >>> [...] >>> >>> ;; >>> == >>> ;;; Here is org-attach.el customization >>> >>> (require 'org-attach) >>> >>> ;; store link auto with `org-store-link' using `file:' link type or >>> `attachment:' link type. >>> (setq org-attach-store-link-p 'attached) (setq org-attach-dir-relative t) >>> (setq org-attach-preferred-new-method 'ask) #+end_src >>> >>> #+begin_src sh :eval no >>> emacs -q -l '~/.config/emacs/minimal-init.el' >>> #+end_src >> > >> Hmm, in the first mail you said that you set org-attach-store-link-p to t, >> but >> in your config it says 'attached. > > Sorry about this. > >> I've tried with a minimal config as well >> (using emacs -q because I build the newest org mode version into the emacs >> folder) and can only reproduce your issue when using the attached option for >> org-attach-store-link-p and then inserting that link with C-c C-l /in another >> heading/. Pasting the link in another heading is expected to break since the >> attachment link is context dependent (i.e. requires an attachment folder). >> Makes sense? If I'm still misunderstanding your use-case, would you care to >> describe the steps to reproduce it more in detail? > > After updated commit, don't know why, but all links worked again. I'm not good > at expressing thanks, but you got all my thanks on this. :) > >> Regards >> Gustav >> -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >From 006583a83bc3b05b28ed1ad3610081066c0b1f95 Mon Sep 17 00:00:00 2001 From: stardiviner Date: Sat, 18 Jan 2020 22:51:53 +0800 Subject: [PATCH] Fix org-attach store link use old filename --- lisp/org-attach.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-attach.el b/lisp/org-attach.el index 6bb438c72..c3d3ecda9 100644 --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -504,8 +504,8 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from (file-name-nondirectory fname)) org-stored-links)) ((eq org-attach-store-link-p t) - (push (list (concat "file:" file) - (file-name-nondirectory file)) + (push (list (concat "file:" fname) + (file-name-nondirectory fname)) org-stored-links))) (if visit-dir (dired attach-dir) -- 2.25.0
Re: Missing `org-attach-set-inherit' function
Gustav Wikström writes: > Hi, > >> -Original Message- >> From: Emacs-orgmode On >> Behalf Of stardiviner >> Sent: den 17 januari 2020 08:39 >> To: emacs-orgmode@gnu.org >> Subject: Missing `org-attach-set-inherit' function >> >> >> I found the function ~org-attach-set-inherit~ is missing. I noticed it in >> the Info document. >> >> #+begin_quote >> ‘i’ (‘org-attach-set-inherit’) >> Set the ‘ATTACH_DIR_INHERIT’ property, so that children use >> the same directory for attachments as the parent does. >> #+end_quote > > I can't find that reference in the newest version of the documentation. > Should be removed since commit ae9cd437. > > Are you sure the documentation and your Org mode version is the same? You're right, seems my org.info file is old. I recompiled it with command =make info=, That "i" is gone now. Thanks for hint. :) > >> >> -- >> [ stardiviner ] >>I try to make every word tell the meaning what I want to express. >> >>Blog: https://stardiviner.github.io/ >>IRC(freenode): stardiviner, Matrix: stardiviner >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >> -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
RE: attachment: link type export to HTML invalid attach dir
Hi, > -Original Message- > From: Nicolas Goaziou > Sent: den 18 januari 2020 12:34 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: attachment: link type export to HTML invalid attach dir > > Hello, > > Gustav Wikström writes: > > > Ok, so change pushed... > > I'm sorry, but this is going too fast. We're discussing core design here > (the parser), and I couldn't even answer your proposal. Let's at least > reach an agreement on the change to make. Yes, agreed, it was a bit fast. The final changes was done to not stop "in the middle" so to say, with something both you and me think is suboptimal. Functionally it's in a good (and maintainable) state right now, in my opinion. But I do understand that the contextual attribute added to the parser may require some discussion. If the decision is to not allow contextual attributes in the parser I'm prepared to revert and change again. No stress though. Just to add a note about the trail of my thoughts regarding this... And why I thought the contextual attribute was a good option here: I argue that the attachment folder is a part of the attachment link, even though the information is found at a different location in the document (i.e. as a property to nodes in the document hierarchy). Parsing an attachment link would then be incomplete if that information is discarded. One option to adding an attribute could be to modify existing properties by adding the attachment folder to, for example, the path property. But that means to remove information about what was written as path in the original link. So I argue to keep path as the original path. But that means extra information is needed to also make it work in the filesystem. If we would translate an attachment link to a file link in ox.el that means we remove the option for exporters to decide for themselves what to do with the link. And I think the exporter should have that option. :) Right now the ASCII exporter for example outputs attachment links as attachment:expanded_path instead of file:expanded_path. Since the link type actually is attachment. And for a solemnly textual export the exported information should be kept as close to source as possible. So either we explicitly and always say attachment-links *are* file-links in disguise (i.e. even change type in the parser), or we don't say that, and then don't say that all the way to the edge of the system. And let the uses of the link type decide themselves what to do. Which is what I propose. But with the addition of a bit of extra information contextual for the attachment links. Whoops long paragraph, sorry... I'm just trying to explain my current way of looking at this. Regards Gustav
Re: [RFC PATCH] Changes to pop-up source buffers
i can't comment on your ideas at all, but just have one concern, which maybe could trip up others like me. namely, pop-to-buffer, as stated in its very docstring, prefers not the same window. if i remember correctly, this is the window management problem i have been struggling with since 2002. for me, trying to get commands or functions that call pop-to-buffer to behave as i need them to, which is to say, for them to use the full (and same) window for accessibility reasons,* has been so unfixable in the past that i had to give up. i've resorted to brittle uses of defadvice, putting up with the rare completion windows that should work not working, heavy-handed overly-general solutions with things like same-window-buffer-names, etc. just to get them to behave. the nuclear option is redefinitions. the result is a whole file full of kludges that partly work. i know in this case i could possibly use yet another defadvice. i also know that recent version of emacs have a complex, new layer of window management functions, which have evolved, and which i tried to understand but just did not. so they are useless to me. packages like shackle do the opposite of what i need. and are workarounds. and could end up unsupported at any time. i guess i just wanted to point out that i, personally, hate pop-to-buffer? assuming this is the same issue i have been strugglign with for 18 years. of course there are hardcoded other-windowness, also, maybe like in occur and help buffers. but pop-to-buffer if i recall correctly is the cause of most of these problems. well, for what it's worth, those are my tangential comments. please carry on. probably you have good reasons and i should not interfere. but i do not look forward to working around them. kludge file will grow. * only exceptions possible are things like rare cases with temporary completion windows, sometimes. On 1/18/20, Jack Kamm wrote: > This patch changes some implementation details of > org-src-switch-to-buffer and org-edit-src-exit, to more consistently use > pop-to-buffer to open the source buffer, and quit-restore-window to > close it. It also adds a new default option to org-src-window-setup. > > I'll explain some details and motivation for this now. > > First, on killing the source buffer. Currently, we kill it with > kill-buffer, then restore the previous saved window configuration with > set-window-configuration. The downside is that, if changes to the > windows were made while editing the source buffer, for example if a new > window is opened to refer to some other file, then these changes will be > lost after the original window configuration is restored. > > By contrast, this patch uses quit-restore-window to close the source > window, which won't affect other windows that may have been > changed. quit-restore-window is also smart enough to decide whether the > source window should be deleted (if the source buffer was popped up in a > new window), or whether the window should be kept and switched to some > previous buffer (if the source buffer was popped up on an existing > window). > > Next, I changed org-src-window-setup to consistently use pop-to-buffer > to create the source window. This is needed for quit-restore-window to > figure out whether to delete the source window. Otherwise, if we > separately create the window and switch to it, then quit-restore-window > won't know whether the window was previously used for something else. > > Finally, I added a new default option to org-src-window-setup, to use > the user's default configuration of display-buffer. Personally, I have > configured my own display-buffer-base-action and would like org-babel to > use it. Also, if a user is not satisfied with any of the options in > org-src-window-setup, this allows them to use their own configuration. > > In most cases, the new default for org-src-window-setup will behave > similarly to the previous default (reorganize-frame). It will only > behave differently when 3 or more windows are currently open. > > A final advantage I'd like to note for pop-to-buffer and > quit-restore-window, is that these are the mechanisms used by many > built-in Emacs functions to pop up and close windows, such as *Help* > windows. > > There was one previous option for org-src-window-setup, > reorganize-frame, that I couldn't reimplement using pop-to-buffer. That > option required keeping around some logic for deleting windows and > restoring the configuration. > > I tested the new implementation for org-src-switch-to-buffer, for all > options of org-src-window-setup, and it appears to work correctly. I > tested this on Emacs 26.3. > > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: > Hi! > > org-attach-store-link-p with option t is supposed to store a link to the > original location (i.e. the location the file was/is in before it was > attached to the node. That was the default before I started working with > attachments I believe. Haven't ever used that feature myself but the patch > you provide would change the functionality which I don't think is correct. It > would also not match the documentation any longer. > > See the documentation for the customization parameter: > > #+begin_src emacs-lisp > (defcustom org-attach-store-link-p nil > "Non-nil means store a link to a file when attaching it." > :group 'org-attach > :version "24.1" > :type '(choice > (const :tag "Don't store link" nil) > (const :tag "Link to origin location" t) > (const :tag "Link to the attach-dir location" attached))) > #+end_src > > Regards > Gustav I've been used this functionality for a long time, I always store the link after attached file. Because the old path is gone. For example, I have a file in =~/Downloads/kk.png=, then I attached it under a node, then the file moved to =data/images/kk.png=. The original file =~/Downloads/kk.png= is gone, does not exist, because I use =mv= method. If still link to original location, so the link file does not exist. That's why I found it inconsistent. Here is the commit which might affected this behavior if I guess right. #+begin_src diff 26ace9004 origin/master Make org-attach store links using attachment-links modified lisp/org-attach.el @@ -487,33 +479,37 @@ (defun org-attach-attach (file visit-dir method) "Move/copy/link FILE into the attachment directory of the current outline node. If VISIT-DIR is non-nil, visit the directory with dired. METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from `org-attach-method'." (interactive (list (read-file-name "File to keep as an attachment:" (or (progn (require 'dired-aux) (dired-dwim-target-directory)) default-directory)) current-prefix-arg nil)) (setq method (or method org-attach-method)) (let ((basename (file-name-nondirectory file))) (let* ((attach-dir (org-attach-dir 'get-create)) (fname (expand-file-name basename attach-dir))) (cond ((eq method 'mv) (rename-file file fname)) ((eq method 'cp) (copy-file file fname)) ((eq method 'ln) (add-name-to-file file fname)) ((eq method 'lns) (make-symbolic-link file fname)) ((eq method 'url) (url-copy-file file fname))) (run-hook-with-args 'org-attach-after-change-hook attach-dir) (org-attach-tag) (cond ((eq org-attach-store-link-p 'attached) - (org-attach-store-link fname)) +(push (list (concat "attachment:" (file-name-nondirectory fname)) +(file-name-nondirectory fname)) + org-stored-links)) ((eq org-attach-store-link-p t) - (org-attach-store-link file))) + (push (list (concat "file:" file) +(file-name-nondirectory file)) + org-stored-links))) (if visit-dir (dired attach-dir) (message "File %S is now an attachment." basename) #+end_src And in the commit "26ace9004260a056acef58a7c1c80222bc9587c9": #+begin_src diff modified lisp/org-attach.el @@ -457,14 +457,6 @@ DIR-property exists (that is different than the unset one)." "Turn the autotag off." (org-attach-tag 'off)) -(defun org-attach-store-link (file) - "Add a link to `org-stored-link' when attaching a file. -Only do this when `org-attach-store-link-p' is non-nil." - (setq org-stored-links - (cons (list (org-attach-expand-link file) - (file-name-nondirectory file)) - org-stored-links))) - (defun org-attach-url (url) (interactive "MURL of the file to attach: \n") (let ((org-attach-method 'url)) @@ -511,9 +503,13 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from (run-hook-with-args 'org-attach-after-change-hook attach-dir) (org-attach-tag) (cond ((eq org-attach-store-link-p 'attached) - (org-attach-store-link fname)) +(push (list (concat "attachment:" (file-name-nondirectory fname)) +(file-name-nondirectory fname)) + org-stored-links)) ((eq org-attach-store-link-p t) - (org-attach-store-link file))) + (push (list (concat "file:" file) +(file-name-nondirectory file)) + org-stored-links))) (if visit-dir (dired attach-dir) (message "File %S is now an attachment." basename) @@ -642,12 +638,6 @@ See `org-attach-open'." Basically, this adds the path to the attachment
Re: [RFC PATCH] Changes to pop-up source buffers
On 1/18/20, Jack Kamm wrote: > What setting of org-src-window-setup are you using? If it is > "current-window" or "reorganize-frame", this patch shouldn't affect you > at all, as those implementations are left the same. you're right, i have that set to current-window, as you might expect. and it is reasonable to expect that any patch would continue to respect it. thanks for your response. jack> A final advantage I'd like to note for pop-to-buffer and quit-restore-window, is that these are the mechanisms used by many built-in Emacs functions to pop up and close windows, such as *Help* windows. i'm not sure what the latest is on what one should use. or whether the latest is on what one should use is problematic for my modest needs. maybe you have looked into the former. help does things like popping up in the fisrt place, opening a linked help buffer, and opening up source code. idk if they all use the same mechanism? i've had issues with 2-3 of them. anomalies on rare occasions occur despite my kludging. iirc stefan once wrote that using the wrong function will break his configuration. there are subtly different purposes for displaying a buffer. one covers the minibuffer, or something.
Re: [RFC PATCH] Changes to pop-up source buffers
Jack Kamm writes: > This patch changes some implementation details of > org-src-switch-to-buffer and org-edit-src-exit, to more consistently use > pop-to-buffer to open the source buffer, and quit-restore-window to > close it. It also adds a new default option to org-src-window-setup. > [...] Thanks for working on this. I am not much of a babel user and didn't follow the recent org-edit-src-exit thread too closely, but in general I think relying more on display-buffer-based functions is a good thing. > Subject: [PATCH] org-src: use display-buffer, quit-restore-window for source > buffers I suspect you left out the changelog entry because it's an RFC patch, but I figured I'd note it just in case. Also, it'd be nice to include a shortened version of the motivation you gave above in the commit message. > -(defcustom org-src-window-setup 'reorganize-frame > +(defcustom org-src-window-setup 'default >"How the source code edit buffer should be displayed. > Possible values for this option are: > > +defaultUse default `display-buffer' action. Hmm, I dislike using "default" as a value for an option. When it's used to say "this is the default behavior for this option", it seems shortsighted because that will be a bad name if the default value changes. But here it seems to instead mean "what a plain display-buffer call would do". I think it'd be good to choose another name to avoid confusion. Perhaps "plain" or "vanilla" or "pop[-to-buffer]" ... I'm also not sure whether this patch should change the default. > -other-frameUse `switch-to-buffer-other-frame' to display edit buffer. > - Also, when exiting the edit buffer, kill that frame. > - > -Values that modify the window layout (reorganize-frame, split-window-below, > -split-window-right) will restore the layout after exiting the edit buffer." > + window and the edit buffer. Restore windows after exiting. convention nit: Please use two spaces after sentences in docstrings. > - (when (memq org-src-window-setup '(reorganize-frame > - split-window-below > - split-window-right)) > + (when (eql org-src-window-setup 'reorganize-frame) nit: eq would do here and would be more in line with the codebase: $ git grep "(eq " master | wc -l 1739 $ git grep "(eql " master | wc -l 6 > (defun org-src-switch-to-buffer (buffer context) >(pcase org-src-window-setup > +(`default (pop-to-buffer buffer)) > (`current-window (pop-to-buffer-same-window buffer)) > (`other-window > - (switch-to-buffer-other-window buffer)) > + (pop-to-buffer buffer '(nil > + ((reusable-frames . nil) > + (inhibit-same-window . t) The actions here and elsewhere have incorrectly specified alists. It's probably easier to see that this misbehaves with the below example: ;; extra parentheses, like above => ignores inhibit-same-window (display-buffer (get-buffer-create "*blah*") '(display-buffer-same-window ((inhibit-same-window . t ;; dropping the outer parentheses (display-buffer (get-buffer-create "*blah*") '(display-buffer-same-window (inhibit-same-window . t))) This means the `other-window' case behaves the same as the `default' case. But stepping back, I don't see much point in switching to pop-to-buffer here. switch-to-buffer-other-window uses pop-to-buffer underneath, so you should be able to use it directly and still get the quit-restore-window behavior you're after. > (`split-window-below > - (if (eq context 'exit) > - (delete-window) > - (select-window (split-window-vertically))) > - (pop-to-buffer-same-window buffer)) > + (let ((split-width-threshold) > +(split-height-threshold 0)) > + (pop-to-buffer buffer '((display-buffer-reuse-window > + display-buffer-pop-up-window) > +((reusable-frames . nil) > + (inhibit-same-window . t)) Quickly testing, this has a slight change in behavior. If there is already a window below the current Org buffer window, the new source window will be popped up below the _other_ window rather than the Org buffer. I think this could be fixed (and the code in general simplified) by using display-buffer-below-selected. > (`split-window-right > - (if (eq context 'exit) > - (delete-window) > - (select-window (split-window-horizontally))) > - (pop-to-buffer-same-window buffer)) > + (let ((split-width-threshold 0) > +(split-height-threshold)) > + (pop-to-buffer buffer '((display-buffer-reuse-window > + display-buffer-pop-up-window) > +((reusable-frames . nil) > + (inhibit-same-window
Re: [RFC PATCH] Changes to pop-up source buffers
> A final advantage I'd like to note for pop-to-buffer and > quit-restore-window, is that these are the mechanisms used by many > built-in Emacs functions to pop up and close windows, such as *Help* > windows. I agree to use =pop-to-buffer=. Propose too. > > There was one previous option for org-src-window-setup, > reorganize-frame, that I couldn't reimplement using pop-to-buffer. That > option required keeping around some logic for deleting windows and > restoring the configuration. > > I tested the new implementation for org-src-switch-to-buffer, for all > options of org-src-window-setup, and it appears to work correctly. I > tested this on Emacs 26.3. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
