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

Key binding and link displays #43

Open
carwin opened this issue May 16, 2022 · 7 comments
Open

Key binding and link displays #43

carwin opened this issue May 16, 2022 · 7 comments

Comments

@carwin
Copy link

carwin commented May 16, 2022

Context: I open my dashboard.org file manually and switch to mu4e-dashboard-mode, nothing fancy - no sidebars, dedicated buffers, or hooks attached to this mode yet. I'm using Evil as well as general.el to define some custom leader-based bindings.

My "Unread" link.

I've used the example dashboard to start with, but I wanted to limit query to a single inbox rather than showing ALL the unread messages.

The documentation and examples seem to show that a single | character separates the query from the desired format options, however, I could only ever get that to show a link that looks like ++++++++. While the + are present, the link doesn't go anywhere when clicked.
Here's an example:

  [[mu:m:/Home/inbox and flag:unread|%3d Unread][---]]

Purely by coincidence, I got the link to become clickable and actually take me to my query by adding a second |.

The below option never shows any format other than ---, but it does take me to the results of the query.

  [[mu:m:/Home/inbox and flag:unread||%3d Unread][---]]

What might I be doing wrong here?

Keybinding issues

I'm not sure where to begin with these - they just seem to never register at all. Evaluating (current-local-keymap) shows none of the options from the file's #+KEYMAP entries and examining the entries using something like describe-key or describe-key-briefly doesn't show anything at all.

This is my first encounter with local keymaps as org properties like this (using #+KEYMAP), so I'm not exactly sure how to debug from here and would appreciate any advice. I was in the midst of defining a minor-mode map for this when I decided I should probably just ask about this first.

Thanks in advance!

@rougier
Copy link
Owner

rougier commented May 20, 2022

Stupid question but are you in "mu4e-dashboard-mode"?

@carwin
Copy link
Author

carwin commented May 26, 2022

Yep, I sure was - I tried going back and forth to see if I could trigger some kind of error but the Message log didn't have anything interesting.

I'll spin it up with Doom or one of the other pre-configs and see if that changes anything for me.

@rougier
Copy link
Owner

rougier commented May 26, 2022

Can you try a manual mu4e-dahsboard-update to see what happens?

@dmgerman
Copy link

dmgerman commented Jul 1, 2022

I think I found the reason for the keybinding problem!

It seems that when mu4e-dashboard-mode is called, mu4e-dashboard-parse-keymap does not process the current buffer. It seems to process ~/.emacs.d/mu4e-dashboard.el instead.

If the file does not exist, nothing is actually bound.

This is the culprit line:

   (with-current-buffer (find-file-noselect mu4e-dashboard-file)

I think carwin and I were under the impression that the bindings are done in the current file.

Perhaps this line is unnecessary? I have removed it (and its corresponding parenthesis) and the bindings are now happening.

@rougier
Copy link
Owner

rougier commented Jul 11, 2022

That's weird. The mu4e-dashboard-file is supposed to point to the dashboard org file. What is the value in your case?

@dmgerman
Copy link

That's weird. The mu4e-dashboard-file is supposed to point to the dashboard org file. What is the value in your case?

mu4e-dashboard-file is a variable defined in ‘mu4e-dashboard.el’.
Its value is "~/.emacs.d/mu4e-dashboard.org"

here is the definition:

(defcustom mu4e-dashboard-file "~/.emacs.d/mu4e-dashboard.org"
"Path to the dashboard org file."
:type 'string)

Our problem is that we didn't know this was the dashboard.

I think this is because mu4e-dashboard-mode does not load mu4e-dashboard-file. It acts on the current file, so we simply assumed that the current file is the dashboard.

My suggestion is to choose one of following two when calling mu4e-dashboard-mode:

  1. Process the current file: comment the line (with-current-buffer (find-file-noselect mu4e-dashboard-file)

  2. Switch to mu4e-dashboard-file and make it the dashboard file.

I vote for #1.

@rougier
Copy link
Owner

rougier commented Jul 13, 2022

I also vote for #1. Do you want to make a PR?

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

No branches or pull requests

3 participants