#26 Add an option to use the new single-buffer mode of navigel in mpdel

Closed
jao wants to merge 3 commits from jao/mpdel:single-buffer into master
jao commented 1 year ago
Collaborator

Sorry for the long wait, busy times! I guess this is going to need a bump in navigel's version, if it's not already done. Thanks!

Sorry for the long wait, busy times! I guess this is going to need a bump in navigel's version, if it's not already done. Thanks!
DamienCassou requested changes 1 year ago
mpdel-browser.el Outdated
(navigel-method mpdel navigel-entity-tablist-mode ((_e (eql browser)))
(mpdel-browser-mode))
(navigel-method mpdel navigel-entity-tablist-mode ((_e (eql albums)))
DamienCassou commented 1 year ago

there is a conflicting definition of this in mpdel-tablist.el. I'm not sure which one is better but we probably can't keep both.

there is a conflicting definition of this in `mpdel-tablist.el`. I'm not sure which one is better but we probably can't keep both.
jao commented 1 year ago

mmm. to me it's browser mode, but perhaps this should be customizable?

(as an aside, sorry for taking so long to anwser, but i didn't receive any mail notifications of your latest comments)

mmm. to me it's browser mode, but perhaps this should be customizable? (as an aside, sorry for taking so long to anwser, but i didn't receive any mail notifications of your latest comments)
jao commented 1 year ago
Poster
Collaborator

so, in my normal use of mpdel, i often get confused to the switch to mpdel-tablist-mode for some views, like search results or the list of artists, specially because we've given a way to get there with the links in the browser's top level. what's confusing there is that, when i come from the browser, i expect ^ to bring me back to the top-level, but in mpdel-tablist-mode that's not always so, one goes to the entity at point's parent.

a possible solution would be to keep a single mode, mdpel-browse-mode, but don't change there the meaning of ^ (i.e., keep it as entity at point's parent), and then provide a new shortcut for "Back to previously browsed buffer" (which is now, arguably erroneously, bound to ^). both operations would be the same when the entity at point is "..", but not in general.

does that make sense?

so, in my normal use of mpdel, i often get confused to the switch to `mpdel-tablist-mode` for some views, like search results or the list of artists, specially because we've given a way to get there with the links in the browser's top level. what's confusing there is that, when i come from the browser, i expect ^ to bring me back to the top-level, but in `mpdel-tablist-mode` that's not always so, one goes to the entity at point's parent. a possible solution would be to keep a single mode, mdpel-browse-mode, but don't change there the meaning of ^ (i.e., keep it as entity at point's parent), and then provide a new shortcut for "Back to previously browsed buffer" (which is now, arguably erroneously, bound to ^). both operations would be the same when the entity at point is "..", but not in general. does that make sense?
Poster
Owner

does that make sense?

I don't undestand. Can you please tell me exactly how to reproduce, what you expected and what you got?

> does that make sense? I don't undestand. Can you please tell me exactly how to reproduce, what you expected and what you got?
jao commented 1 year ago
Poster
Collaborator

if one goes to the browser's main page and opens a directory, the buffer is in browser-mode and ^ will go back to the parent of the directory, no matter where point in the buffer is. if one goes to the list of albums from the browser's main page, one ends in a different mode mpdel-tab (which is already a bit of a surprise) and if presses ^ in a given position, one does not return to the main page, but sees a list of the parents of the entry at point. so when navigating with the browser one ends up in modes that behave differently, which is a bit jarring specially in single-window mode (or at least i find it a bit jarring)...

if one goes to the browser's main page and opens a directory, the buffer is in browser-mode and ^ will go back to the parent of the directory, no matter where point in the buffer is. if one goes to the list of albums from the browser's main page, one ends in a different mode mpdel-tab (which is already a bit of a surprise) and if presses ^ in a given position, one does not return to the main page, but sees a list of the parents of the entry at point. so when navigating with the browser one ends up in modes that behave differently, which is a bit jarring specially in single-window mode (or at least i find it a bit jarring)...
Poster
Owner

I understand what you mean now. I would like ^ to always mean "go to the parent of the entity at point".

Usually going back to the previous buffer is done with l (e.g., for info-mode or help-mode). Unfortunately, this keybinding is used for the current playlist and L for stored playlist.

I think [ could be used to navigate back to the previous buffer.

I understand what you mean now. I would like <kbd>^</kbd> to always mean "go to the parent of the entity at point". Usually going back to the previous buffer is done with <kbd>l</kbd> (e.g., for `info-mode` or `help-mode`). Unfortunately, this keybinding is used for the current playlist and <kbd>L</kbd> for stored playlist. I think <kbd>[</kbd> could be used to navigate back to the previous buffer.
jao commented 1 year ago
Poster
Collaborator

[ sounds good to me. In time we could even have some kind of ring buffer and enable ], but i don't see a pressing need right now.

If we do that, and unify the meaning of ^, are you also okay with having just a single tablist major mode for all buffers, or does it still make sense to have a separate one for the results of searches?

In this PR, using single-buffer mode means that everything mpdel shows goes to the same buffer, so, for instance, a search will overwrite whatever directory one is visiting; asking for the current playlist could show it in a buffer previously showing a search result; and so on and so forth. I am starting to think that that's probably not great. Maybe 'single buffer' should apply only to results of browsing 'directories' (i'm quoting it because when one uses a backend such as mopidy that can access remote services such as spotify, one sees entries there logically organized as folders, although obviously they don't map to any local file system), and then have another 'single buffer' dedicated to searches, and yet another dedicated to the current playlist. In that way we'd be a bit like ncmpcpp and similar clients, which is a modus operandi i don't dislike.

What do you think?

`[` sounds good to me. In time we could even have some kind of ring buffer and enable `]`, but i don't see a pressing need right now. If we do that, and unify the meaning of `^`, are you also okay with having just a single tablist major mode for all buffers, or does it still make sense to have a separate one for the results of searches? In this PR, using single-buffer mode means that everything mpdel shows goes to the same buffer, so, for instance, a search will overwrite whatever directory one is visiting; asking for the current playlist could show it in a buffer previously showing a search result; and so on and so forth. I am starting to think that that's probably not great. Maybe 'single buffer' should apply only to results of browsing 'directories' (i'm quoting it because when one uses a backend such as mopidy that can access remote services such as spotify, one sees entries there logically organized as folders, although obviously they don't map to any local file system), and then have another 'single buffer' dedicated to searches, and yet another dedicated to the current playlist. In that way we'd be a bit like ncmpcpp and similar clients, which is a modus operandi i don't dislike. What do you think?
Poster
Owner

If we do that, and unify the meaning of ^, are you also okay with having just a single tablist major mode for all buffers, or does it still make sense to have a separate one for the results of searches?

I would like that we simplify the behavior. One major mode seems the right thing to do.

What do you think?

I think having per-type single-buffer makes more sense than having a global mpdel single-buffer. I'm all for your suggestion.

> If we do that, and unify the meaning of ^, are you also okay with having just a single tablist major mode for all buffers, or does it still make sense to have a separate one for the results of searches? I would like that we simplify the behavior. One major mode seems the right thing to do. > What do you think? I think having per-type single-buffer makes more sense than having a global mpdel single-buffer. I'm all for your suggestion.
jao commented 1 year ago
Poster
Collaborator

per-type single buffer is non-trivial in the current state, so it'll take a bit of effort. so perhaps here we could just first clean things up a bit, do the [ keybinding and merge?

[sorry it takes so long for me to answer lately... busy times, and, also, the fact that i have to use a browser to comment always makes me forget!]

per-type single buffer is non-trivial in the current state, so it'll take a bit of effort. so perhaps here we could just first clean things up a bit, do the `[` keybinding and merge? [sorry it takes so long for me to answer lately... busy times, and, also, the fact that i have to use a browser to comment always makes me forget!]
Poster
Owner

per-type single buffer is non-trivial in the current state, so it'll take a bit of effort. so perhaps here we could just first clean things up a bit, do the keybinding and merge?

sure

[sorry it takes so long for me to answer lately... busy times, and, also, the fact that i have to use a browser to comment always makes me forget!]

don't worry, I'm also very busy these last days.

> per-type single buffer is non-trivial in the current state, so it'll take a bit of effort. so perhaps here we could just first clean things up a bit, do the keybinding and merge? sure > [sorry it takes so long for me to answer lately... busy times, and, also, the fact that i have to use a browser to comment always makes me forget!] don't worry, I'm also very busy these last days.
jao force-pushed single-buffer from f4d0f8a44a to a5372c03b5 10 months ago
jao commented 9 months ago
Poster
Collaborator

Hi, and, first of all, apologies for the long delay.

I've been using this pr for a while during the last months, and i've got mixed feelings about it, specially with the mix of modes, and no clear solution yet.

I'm closing this PR for now, and open instead one with a couple of orthogonal little featuares related to the browser. Hopefully, i'll revisit single buffer mode before another nine months lapse!

Hi, and, first of all, apologies for the long delay. I've been using this pr for a while during the last months, and i've got mixed feelings about it, specially with the mix of modes, and no clear solution yet. I'm closing this PR for now, and open instead one with a couple of orthogonal little featuares related to the browser. Hopefully, i'll revisit single buffer mode before another nine months lapse!
jao closed this pull request 9 months ago
Poster
Owner

No problem. Thank you for pushing improvements!

No problem. Thank you for pushing improvements!
Some checks failed
continuous-integration/drone/pr Build is failing
Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.