~protesilaos/denote

3 2

Workaround for using diredfl and denote-dired-mode together

Details
Message ID
<m0tu6q6bg0.fsf@disroot.org>
DKIM signature
pass
Download raw message
> For the time being, the diredfl package is not compatible with this
> facility.

According to the manual, the diredfl-mode and denote-dired-mode
don't work well together. So I want to share for workaround to enable
diredfl-mode only in non denote-directory, and it turns out to work
quit well.

(defun my-denote-dired-mode-hook()
  (denote-dired-mode-in-directories)
  (if denote-dired-mode
      (dired-hide-details-mode +1)
    (diredfl-mode +1)))

(add-hook 'dired-mode-hook #'my-denote-dired-mode-hook)


So that we can enable denote-dired-mode only in denote-directory and
enable diredfl-mode only in non denote-directory.

Regards,
Hilde
Details
Message ID
<87a68ia8fx.fsf@protesilaos.com>
In-Reply-To
<m0tu6q6bg0.fsf@disroot.org> (view parent)
DKIM signature
pass
Download raw message
> From: Hilde Rhyne <hilde.rhyne@disroot.org>
> Date: Fri, 05 Aug 2022 21:56:31 +0800

Hello Hilde,

>> For the time being, the diredfl package is not compatible with this
>> facility.
>
> According to the manual, the diredfl-mode and denote-dired-mode
> don't work well together.

Correct!  Ideally, we would modify our code in such a way as to work
with diredfl.  Though I don't have high hopes because our fontification
overlaps with its own: something has to give.

> So I want to share for workaround to enable diredfl-mode only in non
> denote-directory, and it turns out to work quit well.
>
> (defun my-denote-dired-mode-hook()
>   (denote-dired-mode-in-directories)
>   (if denote-dired-mode
>       (dired-hide-details-mode +1)
>     (diredfl-mode +1)))
>
> (add-hook 'dired-mode-hook #'my-denote-dired-mode-hook)
>
> So that we can enable denote-dired-mode only in denote-directory and
> enable diredfl-mode only in non denote-directory.

Thanks for sharing!  Perhaps we should provide such sample code in the
manual of Denote in lieu of a proper solution (assuming there can be
one).

On the technical level, I notice you enable dired-hide-details-mode in
Denote but not elsewhere.  Is there any benefit to this workflow?
Perhaps there is something we can learn from this.  Just me being
curious.

[ I just hide everything in all Dired buffers and toggle it on demand
  with the default '(' key (left parenthesis without the quotes). ]

All the best,
Protesilaos (or simply "Prot")

-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<m0mtci5xle.fsf@disroot.org>
In-Reply-To
<87a68ia8fx.fsf@protesilaos.com> (view parent)
DKIM signature
pass
Download raw message
Hi, Prot!

> Perhaps we should provide such sample code in the
> manual of Denote in lieu of a proper solution (assuming there can be
> one).

This code snippet could be used freely! Currently diredfl is enabled by
a lot of Emacs users. And I think it is a good idea to add this in the
manual before a solution come out, as diredfl is a popular package, so
that people won't lose diredfl's functionalily in other dired buffer.

> On the technical level, I notice you enable dired-hide-details-mode in
> Denote but not elsewhere.  Is there any benefit to this workflow?
> Perhaps there is something we can learn from this.  Just me being
> curious.

It is totally on my personal preferences.

Usually When I use a ordinary (not denote) dired buffer, I concentrate
more on the properties of files, like the modified time and file
permissions. That is why I disable dired-hide-details-mode by default.

But when I use a denote dired buffer, I focus more on the filenames,
titles of notes, tags etc. And I find extra details are distracting and
ugly, properties of files don't matter in this situation.

--
Regards,
Hilde
Details
Message ID
<87h72q2hpe.fsf@protesilaos.com>
In-Reply-To
<m0mtci5xle.fsf@disroot.org> (view parent)
DKIM signature
pass
Download raw message
> From: Samuel Lee <hilde.rhyne@disroot.org>
> Date: Sat, 06 Aug 2022 01:53:48 +0800
>
> Hi, Prot!

Good day!

>> Perhaps we should provide such sample code in the
>> manual of Denote in lieu of a proper solution (assuming there can be
>> one).
>
> This code snippet could be used freely! Currently diredfl is enabled by
> a lot of Emacs users. And I think it is a good idea to add this in the
> manual before a solution come out, as diredfl is a popular package, so
> that people won't lose diredfl's functionalily in other dired buffer.

Yes, diredfl is a popular package.  I agree that we need a better way to
handle it.  The reason I have not done it directly in Denote's code is
because I have not found the cleanest solution yet: diredfl forces its
faces on top of regular dired, which complicates the task as we would
need to undo that arrangement before applying our own faces.  (Perhaps
diredfl is at fault here, though I wouldn't state this with confidence.)

>> On the technical level, I notice you enable dired-hide-details-mode in
>> Denote but not elsewhere.  Is there any benefit to this workflow?
>> Perhaps there is something we can learn from this.  Just me being
>> curious.
>
> It is totally on my personal preferences.
>
> Usually When I use a ordinary (not denote) dired buffer, I concentrate
> more on the properties of files, like the modified time and file
> permissions. That is why I disable dired-hide-details-mode by default.
>
> But when I use a denote dired buffer, I focus more on the filenames,
> titles of notes, tags etc. And I find extra details are distracting and
> ugly, properties of files don't matter in this situation.

Thank you for taking the time to explain this!

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com
Reply to thread Export thread (mbox)