I don't think I've spent enough time on your review to understand it and its consequences fully yet. Here is some early feedback anyway. Can you please take it into account and I will review again?
instead of updating the hashtable as soon as a buffer is killed, you could just check when the hashtable is read that the requested buffer hasn't been kiiled already. The code will be simpler.
An alternative is to cleanup the whole hashtable each time it is read. It's a bit costly as the code will have to iterate over every key for each read, but it's no big deal as there won't be more keys than the number of installed applications using navigel.
instead of updating the hashtable as soon as a buffer is killed, you could just check when the hashtable is read that the requested buffer hasn't been kiiled already. The code will be simpler.
An alternative is to cleanup the whole hashtable each time it is read. It's a bit costly as the code will have to iterate over every key for each read, but it's no big deal as there won't be more keys than the number of installed applications using navigel.
could you please extract this code into a dedicated function? Something like (navigel-get-entity-buffer app entity) It is copy/pasted from navigel-refresh.
could you please extract this code into a dedicated function? Something like `(navigel-get-entity-buffer app entity)` It is copy/pasted from `navigel-refresh`.
thanks for the review. i'll address all your comments above, and also fix a couple of glitches i've found these days using single-buffer for mpdel (maintaining the cache should be in list-children, and we can leave refresh mostly alone, except for finding the appropriate buffer).
thanks for the review. i'll address all your comments above, and also fix a couple of glitches i've found these days using single-buffer for mpdel (maintaining the cache should be in list-children, and we can leave refresh mostly alone, except for finding the appropriate buffer).
i've just pushed a second version. it's not as concise as i had hoped for, but i think it's cleaner, and tries to follow your previous review. let me know what you think. my mpdel branch single-buffer uses this one, if you want to try (but glitches there could be mpdel's fault!).
i've just pushed a second version. it's not as concise as i had hoped for, but i think it's cleaner, and tries to follow your previous review. let me know what you think. my mpdel branch `single-buffer` uses this one, if you want to try (but glitches there could be mpdel's fault!).
okay, they say third's lucky: should be ready for a new review. this version has been working for me reasonably well with mpdel so far, and should address your previous comment.
okay, they say third's lucky: should be ready for a new review. this version has been working for me reasonably well with mpdel so far, and should address your previous comment.
please add to the docstring some info about the keys as well. Something like:
```emacs
An alist of (APP . BUFFER) associating an application name to its buffer.
```
i am not sure. using mpdel these days in single buffer mode, i've seen once something that resembled it, but that might be a problem on (my branch of) mpdel browser. all that said, the check for nil app, allows callers to use nil to signify "current-app", and the check for navigel-app allows using this function before the app has been set, so i'd say the checks don't hurt.
i am not sure. using mpdel these days in single buffer mode, i've seen once something that resembled it, but that might be a problem on (my branch of) mpdel browser. all that said, the check for nil app, allows callers to use nil to signify "current-app", and the check for navigel-app allows using this function before the app has been set, so i'd say the checks don't hurt.
the optional argument, when the buffer is created, is for internal use only. the one without optional argument is public, for users of the library (again, i use it in mpdel), and i don't want to give the users the ability to mess things up by asking for the creation of the buffer (which is raw and needs further set up).
the optional argument, when the buffer is created, is for internal use only. the one without optional argument is public, for users of the library (again, i use it in mpdel), and i don't want to give the users the ability to mess things up by asking for the creation of the buffer (which is raw and needs further set up).
I would even extract the rest of the code in a dedicated function (e.g., navigel--single-app-buffer-create).
```emacs
(unless (or (buffer-live-p buffer) no-create)
```
I would even extract the rest of the code in a dedicated function (e.g., `navigel--single-app-buffer-create`).
I don't think I've spent enough time on your review to understand it and its consequences fully yet. Here is some early feedback anyway. Can you please take it into account and I will review again?
Anyway, I think I like what you did. Thank you.
what about storing navigel buffers in a hashtable with the app as key? This would make it very fast to check if there is already a buffer and get it.
yes, we can do that. one has to take care of updating the hash table on kill buffer, adding a hook i guess. i'll see to it.
instead of updating the hashtable as soon as a buffer is killed, you could just check when the hashtable is read that the requested buffer hasn't been kiiled already. The code will be simpler.
An alternative is to cleanup the whole hashtable each time it is read. It's a bit costly as the code will have to iterate over every key for each read, but it's no big deal as there won't be more keys than the number of installed applications using navigel.
not all navigel buffers use
navigel-tablist-mode
. For example mpdel's song buffer doesn't.in which cases the parameter
app
is nil? It seems weird to me.i was being overcatious. will be gone.
in which cases the parameter
entity
is nil? If there are cases like that, I would expect(format "%s" app)
instead of"%s - empty"
wouldn't the folowing be simpler?
yes, and, actually, i've realized the code can be simplified in other ways.
could you please extract this code into a dedicated function? Something like
(navigel-get-entity-buffer app entity)
It is copy/pasted fromnavigel-refresh
.thanks for the review. i'll address all your comments above, and also fix a couple of glitches i've found these days using single-buffer for mpdel (maintaining the cache should be in list-children, and we can leave refresh mostly alone, except for finding the appropriate buffer).
i've just pushed a second version. it's not as concise as i had hoped for, but i think it's cleaner, and tries to follow your previous review. let me know what you think. my mpdel branch
single-buffer
uses this one, if you want to try (but glitches there could be mpdel's fault!).@DamienCassou please hold on, i've got more changes
okay, they say third's lucky: should be ready for a new review. this version has been working for me reasonably well with mpdel so far, and should address your previous comment.
Some initial feedback. I'm still not done though.
we are talking about "Applications using..." so I suggest "none" instead of "never".
please add to the docstring some info about the keys as well. Something like:
can you please introduce that in a separate PR that we could quickly merge? I think
navigel-equal
could use this by default instead ofequal
.this function has a reason d'etre in this pr too, and a long docstring that doesn't make sense outside the pr... i'll do it if you prefer, though
ok, keep it there
are there cases where
app
is nil? Wherenavigel-app
is nil?i am not sure. using mpdel these days in single buffer mode, i've seen once something that resembled it, but that might be a problem on (my branch of) mpdel browser. all that said, the check for nil app, allows callers to use nil to signify "current-app", and the check for navigel-app allows using this function before the app has been set, so i'd say the checks don't hurt.
+1
I think this function could be made private with a double-dash.
i use in mpdel, so i'd rather keep it public
ok
find => return
I would inline the function
navigel--app-buffer
inside this one as I don't see the rationale for having 2 functions.the optional argument, when the buffer is created, is for internal use only. the one without optional argument is public, for users of the library (again, i use it in mpdel), and i don't want to give the users the ability to mess things up by asking for the creation of the buffer (which is raw and needs further set up).
it makes sense, thanks for the clarification
I guess this variable should be made private
indeed
can you please describe some more what type of variable it is and what is stored in there?
should the first parameter of
navigel-refresh
be deleted? It doesn't seem we use it anymore.it's a public function, so other users might be interested in it... in particular, i think mpdel uses it while refreshing the current song status.
I think
map-delete
reveals intention better.it does. i didn't know about map-delete, thanks!
I would even extract the rest of the code in a dedicated function (e.g.,
navigel--single-app-buffer-create
).makes sense
can you please rename
k
to something more explicit such asid
?@DamienCassou i've just pushed changes addressing your latest review (and commented when i didn't). Sorry for the delay!
Awesome. Please squash your 2 commits into one and merge it. Thank you!