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

Add previous inputs to the list of defaults during multiple selection #717

Merged
merged 5 commits into from
Jan 1, 2023

Conversation

aikrahguzar
Copy link
Contributor

Fix #714

This adds the last input to the list of defaults that completing read accepts. As a result it can be quickly inserted using M-n. Indeed all inputs for the current section are available so multiple usage M-n will cycle through them before going through the history.

One consequence of this change is that if one exits with an empty string, the last input gets inserted as one of the references. Previously the first default was set to an empty string to circumvent this. That can be retained but that requires two M-n's or else C-u 2 M-n.

Another possibility is to directly insert the last string using INITIAL-INPUT arg of completing-read or using a hook in minibuffer-with-setup-hook.

@bdarcus
Copy link
Contributor

bdarcus commented Dec 30, 2022

Thanks!

There's a CI failure that I'm not sure ATM how we'd fix. Any ideas?

@aikrahguzar
Copy link
Contributor Author

There's an off CI failure that I'm not sure ATM how we'd fix. Any ideas?

I don't even know how the CI works.

@bdarcus
Copy link
Contributor

bdarcus commented Dec 30, 2022

@roshanshariff there's a compilation error in the CI here related to org. Is there anything we can do to fix it?

@bdarcus
Copy link
Contributor

bdarcus commented Dec 30, 2022

Notwithstanding the CI, @aikrahguzar, I was just trying this, and not figuring out how it should work.

If I do M-x org-cite-insert and then immediately C-n, vertico just cycles to the first candidate.

Can you clarify?

@aikrahguzar
Copy link
Contributor Author

aikrahguzar commented Dec 30, 2022

Notwithstanding the CI, @aikrahguzar, I was just trying this, and not figuring out how it should work.

Can you clarify?

Type something in the minibuffer while in a multiple selection citar command. Select something using TAB and then press M-n. It should insert whatever you had typed before into the minibuffer.

I should say this is just for the duration of a single call to citar--select-multiple.

@bdarcus
Copy link
Contributor

bdarcus commented Dec 30, 2022

Select something using TAB and then press M-n. It should insert whatever you had typed before into the minibuffer.

It might be something about how I'm loading it (I just open the file and do emacs-lisp-native-compile-and-load), but that second part doesn't happen ATM for me.

@aikrahguzar
Copy link
Contributor Author

Select something using TAB and then press M-n. It should insert whatever you had typed before into the minibuffer.

It might be something about how I'm loading it (I just open the file and do emacs-lisp-native-compile-and-load), but that second part doesn't happen ATM for me.

emacs-lisp-native-compile-and-load works for me. What is M-n bound to for you? For me it is next-history-element.

@bdarcus
Copy link
Contributor

bdarcus commented Dec 30, 2022

User error; was using the wrong keys!

I'll play a bit more now that I have it working.

@roshanshariff
Copy link
Collaborator

I've pushed a small commit (#718) that fixes the CI error on Emacs 27. Rebasing this pull request on top of main should fix the failing CI checks here as well.

This makes vertico-repeat work with citar since vertico
repeat uses this-command to determine which command to
run. If more than one reference is selected vertico finds
this-command set to `vertico-exit` which is a non-sensical
value. So we set it back to the original command.
@bdarcus
Copy link
Contributor

bdarcus commented Dec 31, 2022

Thanks @roshanshariff!

I just noticed now that this is a bug in org, which Ihor just fixed this morning.

@bdarcus
Copy link
Contributor

bdarcus commented Dec 31, 2022

One consequence of this change is that if one exits with an empty string, the last input gets inserted as one of the references.

This may be a bit of a problem, as I triggered this without really even knowing how. Playing a bit more, it seems pretty easy to do.

@aikrahguzar
Copy link
Contributor Author

This may be a bit of a problem, as I triggered this without really even knowing how. Playing a bit more, it seems pretty easy to do.

I think I fixed it just now.

@bdarcus
Copy link
Contributor

bdarcus commented Dec 31, 2022

I think I fixed it just now.

Initial quick test confirms.

Here's one other little usability thing:

If you recall the previous input string, the cursor is placed at the beginning of it. So you can't just start typing, as you would otherwise; you need a space.

So perhaps just prepend a space to the string?

Also, do you have time to add a brief note about this to the README?

@aikrahguzar
Copy link
Contributor Author

If you recall the previous input string, the cursor is placed at the beginning of it. So you can't just start typing, as you would otherwise; you need a space.

I don't like the cursor at the beginning but my personal feeling is that the cursor position belongs to completing-read or else the completion UI e.g. vertico. Prepending a space will work for orderless, is not needed for a fuzzy completion style and will not work but styles like prefix.

Also, do you have time to add a brief note about this to the README?

Hopefully tomorrow.

@bdarcus
Copy link
Contributor

bdarcus commented Dec 31, 2022

Prepending a space will work for orderless, is not needed for a fuzzy completion style and will not work but styles like prefix.

Is it feasible, if not now, later, to have a config variable that would address this?

@aikrahguzar
Copy link
Contributor Author

Is it feasible, if not now, later, to have a config variable that would address this?

The reason I think if it best not to do this is that we are using a standard emacs mechanism i.e M-n behaves this way for all uses in minibuffer and if a user wants to tweak this behavior they probably want to tweak it everywhere and not just when recalling a previous input in citar.

I looked around why this was happening and it is basically due to this part in goto-history-element,

(unless (memq last-command '(next-history-element
				 previous-history-element))
      (let ((prompt-end (minibuffer-prompt-end)))
        (setq-local minibuffer-temporary-goal-position
                    (cond ((<= (point) prompt-end) prompt-end)
                          ((eobp) nil)
                          (t (point))))))

(bunch_of_code_to_acutally_insert_the_element)

(goto-char (or minibuffer-temporary-goal-position (point-max)))

Because of the first clause in cond, if the input is empty and one presses M-n the cursor is at the beginning (which is unexpected for me) but if one does SPC M-n the cursor is at the end (expected). This seems like a bug and I can report it.

To get around it, the best way seems to be an advice on goto-history-element i.e.

(advice-add 'goto-history-element :after #'end-of-buffer)

And we can mention that in the README.

@bdarcus
Copy link
Contributor

bdarcus commented Jan 1, 2023

Thanks for digging into that.

This seems like a bug and I can report it.

Yes please.

@aikrahguzar
Copy link
Contributor Author

Yes please.

Done https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60468

@aikrahguzar
Copy link
Contributor Author

Hopefully tomorrow.

Now done.

@bdarcus bdarcus merged commit 37f6b6b into emacs-citar:main Jan 1, 2023
@bdarcus
Copy link
Contributor

bdarcus commented Jan 1, 2023

Merged; thanks!

And Happy New Year!

bdarcus pushed a commit that referenced this pull request Jan 15, 2023
A fixed version of #717.

Co-authored-by: Rahguzar <[email protected]>
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.

Allow retaining input string after selection with citar-select-refs
3 participants