Hi everybody,
I would like to share a slight extension I am working on.
I tweaked a little bit the denote-open-or-create command and made the
denote-completing-format-open-or-create command that aligns the different
denote's file name elements and fontifies the candidates of the completing
table to visually facilitate searches. Here is the repo of the extension with a
picture of how it looks:
<https://github.com/b3m3bi/denote-completing-format>
Notice that this command does not perform well on a large scale.
Any feedback and ideas are welcome :)
Thanks to all the developers of this wonderful package.
Best,
Luis García
Hello:
I have two questions:
- The way of annotating the list of completions seems to be supposed
to be the choice of users. That is, maybe this functionality should
be provided by another package, such as Marginalia
<https://github.com/minad/marginalia>?
- Also, what is the use of a hash table in your
`denote-completing-format-file-prompt`? It seems that it is not
necessary to use a hash table here. Maybe I missed something?
This seems to be a useful add-on for denote. :)
--
Durand
> From: Luis García <sharlsberg37@gmail.com>> Date: Tue, 3 Jan 2023 22:31:54 -0600>> Hi everybody,
Hello Luis Garcia,
> I would like to share a slight extension I am working on.
Thanks for sharing!
> I tweaked a little bit the denote-open-or-create command and made the> denote-completing-format-open-or-create command that aligns the different> denote's file name elements and fontifies the candidates of the completing> table to visually facilitate searches. Here is the repo of the extension with a> picture of how it looks:> <https://github.com/b3m3bi/denote-completing-format>> Notice that this command does not perform well on a large scale.> Any feedback and ideas are welcome :)
I think what Durand pointed out in the other message to this thread is
worth considering. Look at the 'marginalia' package. I am not familiar
with how the annotation functions are done, though my understanding is
that doing it that way is better for performance.
> Thanks to all the developers of this wonderful package.
You are welcome!
All the best,
Protesilaos (or simply "Prot")
--
Protesilaos Stavrou
https://protesilaos.com
Hi Durand and Prot,
Thanks for the feedback.
> I have two questions:>> - The way of annotating the list of completions seems to be supposed> to be the choice of users. That is, maybe this functionality should> be provided by another package, such as Marginalia> <https://github.com/minad/marginalia>?> - Also, what is the use of a hash table in your> `denote-completing-format-file-prompt`? It seems that it is not> necessary to use a hash table here. Maybe I missed something?> I think what Durand pointed out in the other message to this thread is> worth considering. Look at the 'marginalia' package. I am not familiar> with how the annotation functions are done, though my understanding is> that doing it that way is better for performance.
Yeah, I should explore more in detail how marginalia works.
(In a quick exploration I noticed that marginalia doesn't display annotations
on denote-open-or-create even if denote completion uses the project-file
category. This may be because the marginalia--project-root function used
by the annotator function marginalia-annotate-project-file depends on the
text of the prompt: "Find file in: path/to/root/of/project". But this
is a different issue...)
Returning to your suggestions I agree that maybe it would be more
convenient to make a custom annotator function and let marginalia do the
magic. Nevertheless, I don't know if annotation text can be matched.
The idea I had is to allow filtering searches based on any element
of the file name while visually aligning the different elements in
compartments. Also I think that if I add the aligned file name elements
as annotations there would be duplicated information as the annotations
would be the same as the completion candidates. That's why instead I
manually formatted the completion candidates text. Which leads to your
second question. To avoid having to remove the formatting on the selected
candidate to pass it to find-file, the unformatted path is saved in the hash
table and retrieved after selection.
Thanks both for your ideas :) I'll continue exploring other ways of
implementing this functionality.
Best,
---
Luis García
> From: Luis García <sharlsberg37@gmail.com>> Date: Wed, 4 Jan 2023 13:47:17 -0600>> Hi Durand and Prot,
Hello again from my side,
> Thanks for the feedback.
You are welcome!
>> I have two questions:>>>> - The way of annotating the list of completions seems to be supposed>> to be the choice of users. That is, maybe this functionality should>> be provided by another package, such as Marginalia>> <https://github.com/minad/marginalia>?>>> - Also, what is the use of a hash table in your>> `denote-completing-format-file-prompt`? It seems that it is not>> necessary to use a hash table here. Maybe I missed something?>>> I think what Durand pointed out in the other message to this thread is>> worth considering. Look at the 'marginalia' package. I am not familiar>> with how the annotation functions are done, though my understanding is>> that doing it that way is better for performance.>> Yeah, I should explore more in detail how marginalia works.>> (In a quick exploration I noticed that marginalia doesn't display annotations> on denote-open-or-create even if denote completion uses the project-file> category. This may be because the marginalia--project-root function used> by the annotator function marginalia-annotate-project-file depends on the> text of the prompt: "Find file in: path/to/root/of/project". But this> is a different issue...)
You are right! Maybe we can arrange for this or report the issue on the
marginalia repo.
> Returning to your suggestions I agree that maybe it would be more> convenient to make a custom annotator function and let marginalia do the> magic. Nevertheless, I don't know if annotation text can be matched.> The idea I had is to allow filtering searches based on any element> of the file name while visually aligning the different elements in> compartments. Also I think that if I add the aligned file name elements> as annotations there would be duplicated information as the annotations> would be the same as the completion candidates. That's why instead I> manually formatted the completion candidates text. Which leads to your> second question. To avoid having to remove the formatting on the selected> candidate to pass it to find-file, the unformatted path is saved in the hash> table and retrieved after selection.
Your approach makes perfect sense. You are right that completion
annotations cannot be matched when using the minibuffer. However, they
can be matched when the completions are presented in a regular buffer.
This can be done, for example, by executing 'embark-collect' in the
minibuffer and then searching inside the resulting buffer. We can
narrow the buffer with somehting like M-x flush-lines or M-x keep-lines
or Consult's M-x consult-keep-lines. Still, this is more trouble than
just searching in the minibuffer, which your interface provides.
Have you tried removing the 'propertize' calls? Maybe those have an
impact at scale. Simplifying the processing will help. Though, yes, it
does not look as pretty.
> Thanks both for your ideas :) I'll continue exploring other ways of> implementing this functionality.
You are welcome! I am looking forward to the status update. Do you
want me to link to your project from Denote's manual or should I wait
for a newer version? Whatever you prefer.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Good day:
>>>>> On Wed, 4 Jan 2023 13:47:17 -0600, Luis García <sharlsberg37@gmail.com> said:
>> [ 19 lines elided ... ]
Luis> Yeah, I should explore more in detail how marginalia works.
Luis> (In a quick exploration I noticed that marginalia doesn't
Luis> display annotations on denote-open-or-create even if denote
Luis> completion uses the project-file category. This may be
Luis> because the marginalia--project-root function used by the
Luis> annotator function marginalia-annotate-project-file depends
Luis> on the text of the prompt: "Find file in:
Luis> path/to/root/of/project". But this is a different issue...)
Luis> Returning to your suggestions I agree that maybe it would be
Luis> more convenient to make a custom annotator function and let
Luis> marginalia do the magic. Nevertheless, I don't know if
Luis> annotation text can be matched. The idea I had is to allow
Luis> filtering searches based on any element of the file name
Luis> while visually aligning the different elements in
Luis> compartments. Also I think that if I add the aligned file
Luis> name elements as annotations there would be duplicated
Luis> information as the annotations would be the same as the
Luis> completion candidates. That's why instead I manually
Luis> formatted the completion candidates text. Which leads to
Luis> your second question. To avoid having to remove the
Luis> formatting on the selected candidate to pass it to
Luis> find-file, the unformatted path is saved in the hash table
Luis> and retrieved after selection.
I see. After taking another look at the package, I now understand
your considerations.
Then I have another idea: Why not use the list of annotated strings as
completion candidates, and propertize the first character with a
property like the following?
```
(mapcar
(lambda (file-name)
(let ((original-file-name file-name)
(annotated-file-name (transformer file-name)))
(put-text-property
0 1
:orig original-file-name
annotated-file-name)))
list-of-original-file-names)
```
(Here `transformer' is a function to return the visually beautiful
file name.)
After the completion returns the result, with
`minibuffer-allow-text-properties' set to t, we just retrieve the text
property and pass it to find-file. In short, we save the original
path in the text property instead of a hash table. I think this can
avoid the overhead of hash tables, though I am not sure if hash tables
are the main bottleneck.
--
Another possibility is to use the same list of file names as
candidates, but give each candidate a 'display' property which is the
transformed and prettified name.
About removing text properties, if `minibuffer-allow-text-properties'
is set to nil, then the result of the completions will not have text
properties at all.
A little snippet of code to see what I mean:
```
(completing-read
"haha: "
(list
(propertize "haha" 'display "ha - ha")
(propertize "hehe" 'display "he - he")
(propertize "yoyo" 'display "yo - yo")))
```
In the resulting completion prompt, the candidates will be displayed
in the separated form in the "completions" buffer, but the result will
be a plain string without text properties (if
`minibuffer-allow-text-properties' is set to nil).
Perhaps this approach is worth considering?
Luis> Thanks both for your ideas :) I'll continue exploring other
Luis> ways of implementing this functionality.
Hope it helps. :)
--
Durand