Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target buffer selection #52

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

aikrahguzar
Copy link

Makes the default choice target buffer sensitive to the major-mode of the buffer from which the search was started.

Also changes the behavior of biblio--selection-change-buffer. Now it only offers buffers with major mode derived from frombibtex-mode. This uses directory-name-p with requires emacs 25.1 but can be avoided.

Copy link

@dankessler dankessler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Came across a few typos in docstrings

biblio-core.el Outdated
@@ -71,6 +72,13 @@ This variable is local to each search results buffer.")
:group 'biblio-core
:type 'integer)

(defcustom biblio-target-buffer-functions (list #'biblio-target-buffer-default)
"Select the target buffer for a bibliographci search.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: bibliographci -> bibliographic

biblio-core.el Outdated
(defcustom biblio-target-buffer-functions (list #'biblio-target-buffer-default)
"Select the target buffer for a bibliographci search.
Each function should take no arguments and return either nil or a buffer.
The first non-nill resukt is set as the target buffer."

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: resukt -> result

@dankessler
Copy link

dankessler commented Apr 21, 2022

This looks really useful! :)

As I discussed in #54, I think it'd be nice to support the use case where the user (or a calling library) can just specify precisely what buffer should be used.

I think you could accomplish this by

  1. rename biblio-target-buffer-default to something like biblio-get-default-target-buffer
  2. declare a new customizable variable biblio-target-buffer-default
  3. adjust the logic in biblio-get-default-target-buffer to respect the value of biblio-target-buffer-default, if set, and if not, to proceed with the lookup logic that it already has.

@dankessler
Copy link

Assuming we can get this integrated, I think this would set the stage for a nice enhancement in helm-bibtex and likely many other tools, where a nigh top-level let form can be extended to bind biblio-target-buffer-default to something sensible, e.g., for helm-bibtex we could add (biblio-target-buffer-default bibtex-completion-bibliography) to the list of bindings inside the let* form.

@aikrahguzar
Copy link
Author

Came across a few typos in docstrings

Thanks I fixed these.

@aikrahguzar
Copy link
Author

This looks really useful! :)

As I discussed in #54, I think it'd be nice to support the use case where the user (or a calling library) can just specify precisely what buffer should be used.

This seems like a good idea to me so I implemented it but directly. biblio-lookup takes three optional arguments the last of which is the target buffer. biblio-target-buffer-functions machinery is used only if no target buffer is passed. That seemed like a better way to doing this than through a variable.

Copy link

@dankessler dankessler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few design suggestions and found one more typo

(defcustom biblio-target-buffer-functions (list #'biblio-target-buffer-default)
"Select the target buffer for a bibliographic search.
Each function should take no arguments and return either nil or a buffer.
The first non-nill result is set as the target buffer."

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: nill to nil

(directory-name-p file)))))))
(if (equal "bib" (file-name-extension filename))
filename
(user-error "Choosen file %s is not a bib file" filename))))

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the user wants to insert into a file that doesn't end in .bib (either because they are using a different extension or because they want to insert directly into say a .tex or .org file) is there a way they can work around this?

"Just like `biblio-lookup' on BACKEND and QUERY, but never prompt."
(let ((results-buffer (biblio--make-results-buffer (current-buffer) query backend)))
(defun biblio--lookup-1 (backend query target)
"Just like `biblio-lookup' on BACKEND, QUERY and TARGET, but never prompt."

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that technically biblio--lookup-1 is, by convention, a private function, but any code that currently calls it with two arguments will now behave oddly: it will pass nil as target to biblio--make-results-buffer which is different than the previous behavior (which would pass (current-buffer).

I think it would make more sense to move the (unless target (setq target...) logic from where it currently is in biblio-lookup and put it here instead.

`biblio-backends'. Returns the buffer in which results will be
inserted."
`biblio-backends'. TARGET is the buffer into which bibliographic
entries will be inserted. Returns the buffer in which results

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be nice to add something to the doc string about what happens if target is nil, i.e., refer to biblio-target-buffer-functions to control the behavior of how target is chosen when passed as nil.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants