follow mode, helm sources, helm-attrset and helm-setup-user-source

[Sameer Sahasrabuddhe]

Hi all,

I am trying to enable the "follow mode" on some helm sources, so that "C-n" and "C-p" also display the current candidate in the original buffer. I tried the following for helm-occur and it worked:

(defmethod helm-setup-user-source ((source helm-source-multi-occur))
  (setf (slot-value source 'follow) 1))

But the source class to be used for helm-mark-ring is not obvious and the following does not work:

(defmethod helm-setup-user-source ((source helm-source-mark-ring))
  (setf (slot-value source 'follow) 1))

I get the error: "Unknown class type helm-source-mark-ring in method parameters".

The typical method mentioned on web searches (and coincidentally, also in a recent conversation) is the following:

(add-hook 'helm-before-initialize-hook
  #'(lambda () (helm-attrset 'follow 1 helm-source-mark-ring)))

This probably works, but I have not tried it yet. I would prefer using helm-setup-user-source because it seems to be the canonical way of modifying source attributes. But for that, how do I find out what is the class to be used for helm-source-mark-ring?

Sameer.
--
https://www.emacswiki.org/emacs/SameerDS

[Thierry Volpiatto]

Sameer Sahasrabuddhe <same...@gmail.com> writes:

> But the source class to be used for helm-mark-ring is not obvious and
> the following does not work:
>
> (defmethod helm-setup-user-source ((source helm-source-mark-ring))
> (setf (slot-value source 'follow) 1))
>
> I get the error: "Unknown class type helm-source-mark-ring in method parameters".

helm-source-mark-ring is indeed not a class but a helm source (an alist).

> The typical method mentioned on web searches (and coincidentally, also
> in a recent conversation) is the following:
>
> (add-hook 'helm-before-initialize-hook
> #'(lambda () (helm-attrset 'follow 1 helm-source-mark-ring)))

Indeed that should work.

> This probably works, but I have not tried it yet. I would prefer using
> helm-setup-user-source because it seems to be the canonical way of
> modifying source attributes.

helm-setup-user-source is a method and a method needs a class, so as
long as mark-ring have not its own class helm-setup-user-source is not
usable there.

> But for that, how do I find out what is the class to be used for
> helm-source-mark-ring?

Theres is no specific class for now.

--
Thierry

[Sameer Sahasrabuddhe]

On Mon, Aug 29, 2016 at 1:34 PM, Thierry Volpiatto <thierry....@gmail.com> wrote:

helm-setup-user-source is a method and a method needs a class, so as
long as mark-ring have not its own class helm-setup-user-source is not
usable there.

> But for that, how do I find out what is the class to be used for
> helm-source-mark-ring?

Theres is no specific class for now.

I saw this reply from you (Thierry) on a bug that mentions a similar problem with helm-source-grep:

https://github.com/emacs-helm/helm/issues/530#issuecomment-192809829

Apparently, even the helm-before-initialize-hook hack does not work with all sources. There was the promise of a change that will make it possible to use helm-setup-user-source for for helm-source-grep. Can that be done for the command helm-mark-ring too? Is this meant to be the correct/universal way to modify helm sources?

In general, setting up a default follow mode seems to be a very common demand, but one which lacks any simple universal way of specifying what the user wants.

To me, the most intuitive interface is that the user populates a list of helm commands where follow-mode should be enabled, and the internal machinery takes care of the rest. If that is a good idea, then I could take a crack it, but I have zero prior experience working with emacs packages. My total elisp experience is limited to making small customizations in my init.el file!

Sameer.
--
https://www.emacswiki.org/emacs/SameerDS

[Thierry Volpiatto]

Sameer Sahasrabuddhe <same...@gmail.com> writes:

> Apparently, even the helm-before-initialize-hook hack does not work
> with all sources.

It does unless the source is not defined at load time, which is the case
for some sources.

> There was the promise of a change that will make it possible to use
> helm-setup-user-source for for helm-source-grep.

It's done, for helm-source-grep, helm-source-grep-git and
helm-source-grep-ag.
For the last it's easy, for the two first it's a little bit tricky if
you want follow for one and not the other, otherwise it is as easy as
for ag.

> Can that be done for the command helm-mark-ring too?

Could be.

> Is this meant to be the correct/universal way to modify helm sources?

Not forcibly, some sources will still be not modifiable.

> In general, setting up a default follow mode seems to be a very common
> demand, but one which lacks any simple universal way of specifying
> what the user wants.

You have actually a very simple way to enable follow for all your emacs
session:

(setq helm-follow-mode-persistent t)

Then as soon you hit C-c C-f somewhere in helm, the next time you run
the same helm command, follow will be enabled until you hit C-c C-f
again.

> To me, the most intuitive interface is that the user populates a list
> of helm commands where follow-mode should be enabled, and the internal
> machinery takes care of the rest.

That's a good idea, I will think at it.

Thanks.

--
Thierry

[Sameer Sahasrabuddhe]

On Mon, Aug 29, 2016 at 5:36 PM, Thierry Volpiatto <thierry....@gmail.com> wrote:

> In general, setting up a default follow mode seems to be a very common
> demand, but one which lacks any simple universal way of specifying
> what the user wants.

You have actually a very simple way to enable follow for all your emacs
session:

(setq helm-follow-mode-persistent t)

<snip>

> To me, the most intuitive interface is that the user populates a list
> of helm commands where follow-mode should be enabled, and the internal
> machinery takes care of the rest.

That's a good idea, I will think at it.

Here's some further thoughts on this idea, where the point is to prevent over-designing. The fact is that some commands in helm are very useful to go look at individual locations in files. Examples are grep, occur, moccur, mark-ring. But in other commands, locations inside files are not very relevant. For example find-file, where the user is looking at filenames and not the contents in the files. With this observation, it would be very intuitive if there was a single variable that affects the follow-mode in all commands where it is useful to show the location of the current candidate.

Slightly tangential comment: I recently discovered helm and I think it's a huge improvement over icicles after using the latter for almost a year. But when I discovered helm-swoop, the most impressive part of the demo was how the display got updated with each candidate. I incorrectly assumed that this was not available in vanilla helm-occur until I discovered follow-mode. But once I knew how to enable it in helm-occur, I got so used to it that I removed helm-swoop!

The point of this long story is that follow-mode is a powerful feature, but not easily visible up front. For the class of commands that I identified earlier, I think it should be okay to even enable it by default.

Sameer.

[Thierry Volpiatto]

Thanks for your comments.

Sameer Sahasrabuddhe <same...@gmail.com> writes:

> Here's some further thoughts on this idea, where the point is to
> prevent over-designing. The fact is that some commands in helm are
> very useful to go look at individual locations in files. Examples are
> grep, occur, moccur, mark-ring. But in other commands, locations
> inside files are not very relevant. For example find-file, where the
> user is looking at filenames and not the contents in the files. With
> this observation, it would be very intuitive if there was a single
> variable that affects the follow-mode in all commands where it is
> useful to show the location of the current candidate.

We will have a variable (helm-source-names-using-follow) where source
names can be stored. When running a source with its name in this list
follow will be used only if `helm-follow-mode-persistent` is non-nil.

But knowing the source name of each source you want follow to be enabled
can be tedious, so to customize this list the user will have only to set
`helm-follow-mode-persistent` and then at each time C-c C-f is used in a
source, the name of this source will be saved or removed from the list.

> Slightly tangential comment: I recently discovered helm and I think
> it's a huge improvement over icicles after using the latter for almost
> a year. But when I discovered helm-swoop, the most impressive part of
> the demo was how the display got updated with each candidate. I
> incorrectly assumed that this was not available in vanilla helm-occur
> until I discovered follow-mode. But once I knew how to enable it in
> helm-occur, I got so used to it that I removed helm-swoop!

Yes, helm-(m)occur have all the features that *swoop propose and more,
it have the advantage to select buffers from helm-buffers-list, mini
etc... and its implementation makes it faster than *swoop.

It is just more popular because of this kind of follow feature
(different from helm-follow-mode) enabled by default.

> The point of this long story is that follow-mode is a powerful
> feature, but not easily visible up front. For the class of commands
> that I identified earlier, I think it should be okay to even enable it
> by default.

Not by default, I personally don't use follow and don't want it enabled
everywhere.
Note that one can use also C-<down> and C-<up>...

--
Thierry

[Sameer Sahasrabuddhe]

On Tue, Aug 30, 2016 at 3:16 PM, Thierry Volpiatto <thierry....@gmail.com> wrote:

We will have a variable (helm-source-names-using-follow) where source
names can be stored.  When running a source with its name in this list
follow will be used only if `helm-follow-mode-persistent` is non-nil.

But knowing the source name of each source you want follow to be enabled
can be tedious, so to customize this list the user will have only to set
`helm-follow-mode-persistent` and then at each time C-c C-f is used in a
source, the name of this source will be saved or removed from the list.

That sounds good. Is it correct that "C-c C-f" will only affect this variable in the current emacs session? Any value that the user has set in init.el for this variable should be restored in the next emacs session ... the user can always use `customize' to update that value.

Sameer.

[Thierry Volpiatto]

Sameer Sahasrabuddhe <same...@gmail.com> writes:

> That sounds good. Is it correct that "C-c C-f" will only affect this
> variable in the current emacs session?

No, across emacs sessions.

> Any value that the user has set in init.el for this variable should be
> restored in the next emacs session ...

Yes it is now the current behavior when helm-follow-mode-persistent is
non-nil.

> the user can always use `customize' to update that value.

If he wants to do that manually (without pressing C-c C-f) it can of
course.

--
Thierry