more little nnselect things...

more little nnselect things...

[Eric Abrahamsen]

I know this is planned, but it would be nice if permanent nnselect
groups were activated at startup. Whether or not they're actually
scanned at startup I don't mind (or if they are set by default to a
higher subscription level, etc), but it would be great just not to have
the little asterisk where the unread count is, which always screams to
me "your Gnus is broken!"

Also: the `gnus-group-line-format' can't be set per-server or per-group,
can it? I'd really like to have nnselect groups show the total message
count, not the unread count. Nine times out of ten I use these groups
for quick reference/access, meaning the messages are pretty much always
read. Total message count would be more useful, but if this variable can
only have one global value...

One other related idea: displaying select groups as nnselect:<foo> isn't
all that helpful -- or at least, it could be more helpful. What about
having an optional nnselect-label group parameter, which would be used
as an alternate in the group format line, if present? Search groups
could be labeled "search:<foo>", I'd use "gnorb:<foo>" for Gnorb groups,
etc.

Just some ideas. It's really nice seeing this come together.

E

Re: more little nnselect things...

[Andrew Cohen]

>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

    Eric> I know this is planned, but it would be nice if permanent
    Eric> nnselect groups were activated at startup. Whether or not
    Eric> they're actually scanned at startup I don't mind (or if they
    Eric> are set by default to a higher subscription level, etc), but
    Eric> it would be great just not to have the little asterisk where
    Eric> the unread count is, which always screams to me "your Gnus is
    Eric> broken!"

I'll get to it. Its just a matter of keeping a file with the groups to
be activated in it.

    Eric> Also: the `gnus-group-line-format' can't be set per-server or
    Eric> per-group, can it? I'd really like to have nnselect groups
    Eric> show the total message count, not the unread count. Nine times
    Eric> out of ten I use these groups for quick reference/access,
    Eric> meaning the messages are pretty much always read. Total
    Eric> message count would be more useful, but if this variable can
    Eric> only have one global value...

No, it can't be set on a per-server or per-group basis. But you can
achieve the desired effect using gnus-user-format-functions (when used
in a summary buffer it gets passed the article header as argument; when
used in the group buffer I believe it gets passed the group name). 


    Eric> One other related idea: displaying select groups as
    Eric> nnselect:<foo> isn't all that helpful -- or at least, it could
    Eric> be more helpful. What about having an optional nnselect-label
    Eric> group parameter, which would be used as an alternate in the
    Eric> group format line, if present? Search groups could be labeled
    Eric> "search:<foo>", I'd use "gnorb:<foo>" for Gnorb groups, etc.

I'm not sure where you are talking about: in the group buffer? Somewhere
else? If the group buffer I guess this means you are using the "g"
spec---this shows the full group name. You could instead use the "G"
spec which shows the "short" group name (it won't have the nnselect:
prefix). And if you want something else you can easily do this using
user-format-functions.

Best,
Andy

Re: more little nnselect things...

[Eric Abrahamsen]

Andrew Cohen <cohen@bu.edu> writes:

>>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>     Eric> I know this is planned, but it would be nice if permanent
>     Eric> nnselect groups were activated at startup. Whether or not
>     Eric> they're actually scanned at startup I don't mind (or if they
>     Eric> are set by default to a higher subscription level, etc), but
>     Eric> it would be great just not to have the little asterisk where
>     Eric> the unread count is, which always screams to me "your Gnus is
>     Eric> broken!"
>
> I'll get to it. Its just a matter of keeping a file with the groups to
> be activated in it.

Cool. I knew you would, but I've switched to using this full time, and
it's so close to done that the little things stand out.

>     Eric> Also: the `gnus-group-line-format' can't be set per-server or
>     Eric> per-group, can it? I'd really like to have nnselect groups
>     Eric> show the total message count, not the unread count. Nine times
>     Eric> out of ten I use these groups for quick reference/access,
>     Eric> meaning the messages are pretty much always read. Total
>     Eric> message count would be more useful, but if this variable can
>     Eric> only have one global value...
>
> No, it can't be set on a per-server or per-group basis. But you can
> achieve the desired effect using gnus-user-format-functions (when used
> in a summary buffer it gets passed the article header as argument; when
> used in the group buffer I believe it gets passed the group name).

Okay, that's what I figured. I guess I'll write myself a format function.

>     Eric> One other related idea: displaying select groups as
>     Eric> nnselect:<foo> isn't all that helpful -- or at least, it could
>     Eric> be more helpful. What about having an optional nnselect-label
>     Eric> group parameter, which would be used as an alternate in the
>     Eric> group format line, if present? Search groups could be labeled
>     Eric> "search:<foo>", I'd use "gnorb:<foo>" for Gnorb groups, etc.
>
> I'm not sure where you are talking about: in the group buffer? Somewhere
> else? If the group buffer I guess this means you are using the "g"
> spec---this shows the full group name. You could instead use the "G"
> spec which shows the "short" group name (it won't have the nnselect:
> prefix). And if you want something else you can easily do this using
> user-format-functions.

In the *Group* buffer, yes. On second thought, what I probably mean is
providing the "server" string to be displayed as part of the group name.
Ie:

nnselect+search:<my search group>

Packages which create select groups could provide their own string for
identification purposes. I'd have gnorb create "nnselect+gnorb:<group
name>" groups, for instance. The string would be missing for
user-created groups.

This might be a mild abuse of the "server" concept, I don't know. But I
think it's a useful idea to explore.

This reminds me that what I really want is a spec that shows
server-plus-group, not backend-plus-server-plus-group. A bit like
omitting the protocol in a browser URL bar. But that's a different
problem.

E

Re: more little nnselect things...

[Andrew Cohen]

>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

    Eric> Andrew Cohen <cohen@bu.edu> writes:
    >>>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
    >> 

[...]


    Eric> In the *Group* buffer, yes. On second thought, what I probably
    Eric> mean is providing the "server" string to be displayed as part
    Eric> of the group name.  Ie:

    Eric> nnselect+search:<my search group>

    Eric> Packages which create select groups could provide their own
    Eric> string for identification purposes. I'd have gnorb create
    Eric> "nnselect+gnorb:<group
    name> " groups, for instance. The string would be missing for
    Eric> user-created groups.

    Eric> This might be a mild abuse of the "server" concept, I don't
    Eric> know. But I think it's a useful idea to explore.

    Eric> This reminds me that what I really want is a spec that shows
    Eric> server-plus-group, not backend-plus-server-plus-group. A bit
    Eric> like omitting the protocol in a browser URL bar. But that's a
    Eric> different problem.

I think there is already a spec for that (I don't have time to look it
up right now, but maybe its "s" for the server, with "G" for the
group?)

I haven't paid much attention to the server name for nnselect (since it
doesn't really make sense for this kind of thing). But since its there
we might be able to co-opt it for what you suggest. Allow the creation
of multiple servers with method nnselect. Then you could have your gnorb
server, search server, and anything else. This would also be useful
since you could then do activation on a per-server basis which might be
useful. 

Re: more little nnselect things...

[Eric Abrahamsen]

Andrew Cohen <cohen@bu.edu> writes:

>>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>     Eric> Andrew Cohen <cohen@bu.edu> writes:
>     >>>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>     >> 
>
> [...]
>
>
>     Eric> In the *Group* buffer, yes. On second thought, what I probably
>     Eric> mean is providing the "server" string to be displayed as part
>     Eric> of the group name.  Ie:
>
>     Eric> nnselect+search:<my search group>
>
>     Eric> Packages which create select groups could provide their own
>     Eric> string for identification purposes. I'd have gnorb create
>     Eric> "nnselect+gnorb:<group
>     name> " groups, for instance. The string would be missing for
>     Eric> user-created groups.
>
>     Eric> This might be a mild abuse of the "server" concept, I don't
>     Eric> know. But I think it's a useful idea to explore.
>
>     Eric> This reminds me that what I really want is a spec that shows
>     Eric> server-plus-group, not backend-plus-server-plus-group. A bit
>     Eric> like omitting the protocol in a browser URL bar. But that's a
>     Eric> different problem.
>
> I think there is already a spec for that (I don't have time to look it
> up right now, but maybe its "s" for the server, with "G" for the
> group?)

Good point. I could have figured that out.

> I haven't paid much attention to the server name for nnselect (since it
> doesn't really make sense for this kind of thing). But since its there
> we might be able to co-opt it for what you suggest. Allow the creation
> of multiple servers with method nnselect. Then you could have your gnorb
> server, search server, and anything else. This would also be useful
> since you could then do activation on a per-server basis which might be
> useful. 

Right, that's pretty much what I was thinking. Not particularly crucial,
but it would be nice to have.

Re: status of nnselect and gnus-search

[Eric Abrahamsen]

On 08/14/17 17:11 PM, George McNinch wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.gnus.general as well.

I didn't see this on the list, but am replying to the list...

> Hi,
>
> I'm curious what is the status of nnselect/gnus-search? I started using
> them in June or so (not too extensively, though I haven't/didn't
> encounter(ed) any issues) after seeing the announcement in the gnus-list
> from May or so.
>
> But at this point, if one clones the emacs git distribution, and then
> does either "git checkout origin/scratch/gnus-search"
> or "git checkout origin/feature/gnus-select" followed by "git pull", it
> seems that one encounters incompatibilities that I don't feel competent
> resolving.
>
> (Well, I'm a bit git-ignorant...so frankly I don't really
> know *how* to do so).

My understanding is, Andy had a certain window of time where he was able
to work on the nnselect stuff, and that window closed before we were
able to get anything pushed. That's a bummer, because I think the
changes are pretty solid -- there were a couple of potential features
that didn't get implemented, but I haven't encountered any bugs, either.

> Maybe someone can briefly explain how to resolve the incompatibilities?
> Or maybe there is an updated way to get these features?

It's certainly not your responsibility to update those branches --
they're pretty far behind master at this point, and are only going to
get farther behind. What should happen now is that feature/gnus-select
either gets rebased onto master, or master gets merged in. Then it gets
merged into master.

Then that could sit for a while, and in the meantime I would keep
scratch/gnus-search up to date with master. When it looked like it was
mature enough, I'd merge to master as well.

I think we've got Lars' blessing on all this, so we should be good to
go. Andy, if you're there -- what do you think about just taking the
plunge? I can be available to put out fires, if necessary.

Eric

Re: status of nnselect and gnus-search

[George McNinch]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

Hi Eric,

Thanks for the reply.

> I didn't see this on the list, but am replying to the list...

Yes - I seem to have done something wrong with the post. Hopefully I've
fixed it this time.

> My understanding is, Andy had a certain window of time where he was
> able to work on the nnselect stuff, and that window closed before we
> were able to get anything pushed. That's a bummer, because I think the
> changes are pretty solid -- there were a couple of potential features
> that didn't get implemented, but I haven't encountered any bugs,
> either.

>> Maybe someone can briefly explain how to resolve the
>> incompatibilities?  Or maybe there is an updated way to get these
>> features?

Well, after writing, I meanwhile got stubborn and did manage to get the
"origin/scratch/gnus-search" version merged after cloning an emacs
image. (The situation arose because I needed to install on a new
machine...)

There was one issue I encountered using gnus-search and notmuch as
search engine (certain kinds of searches failed with an error message
which essentially said "(if thread ....)" is not a string"). I'm
attaching a patch (inclusion of a comma that seems to have been missing)
which fixes this trouble for me.

(Actually, I'm pretty sure I found this typo/glitch in June, fixed it,
and then forgot that I had discovered it. Should have reported it then;
sorry!)

> Then that could sit for a while, and in the meantime I would keep
> scratch/gnus-search up to date with master. When it looked like it was
> mature enough, I'd merge to master as well.

> I think we've got Lars' blessing on all this, so we should be good to
> go. Andy, if you're there -- what do you think about just taking the
> plunge? I can be available to put out fires, if necessary.

Well, I like the work; thanks! - I'm looking forward to its
inclusion...!

See below for the patch.

best,
george


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnus-search-patch.patch --]
[-- Type: text/x-diff, Size: 658 bytes --]

diff -u --label /usr/local/share/emacs/26.0.50/lisp/gnus/gnus-search.el.gz --label /usr/local/share/emacs/26.0.50/lisp/gnus/gnus-search-new.el /tmp/jka-com7573izb /usr/local/share/emacs/26.0.50/lisp/gnus/gnus-search-new.el
--- /usr/local/share/emacs/26.0.50/lisp/gnus/gnus-search.el.gz
+++ /usr/local/share/emacs/26.0.50/lisp/gnus/gnus-search-new.el
@@ -1750,7 +1750,7 @@
     (with-slots (switches config-file) engine
       `(,(format "--config=%s" config-file)
 	"search"
-	(if thread
+	,(if thread
 	    "--output=threads"
 	  "--output=files")
 	"--duplicate=1" ; I have found this necessary, I don't know why.

Diff finished.  Mon Aug 14 21:31:31 2017

[-- Attachment #3: Type: text/plain, Size: 67 bytes --]


-- 
-o- George McNinch
-o- http://math.tufts.edu/faculty/gmcninch

Re: status of nnselect and gnus-search

[Eric Abrahamsen]

George McNinch <gmcninch@zoho.com> writes:

> Hi Eric,
>
> Thanks for the reply.
>
>> I didn't see this on the list, but am replying to the list...
>
> Yes - I seem to have done something wrong with the post. Hopefully I've
> fixed it this time.
>
>> My understanding is, Andy had a certain window of time where he was
>> able to work on the nnselect stuff, and that window closed before we
>> were able to get anything pushed. That's a bummer, because I think the
>> changes are pretty solid -- there were a couple of potential features
>> that didn't get implemented, but I haven't encountered any bugs,
>> either.
>
>>> Maybe someone can briefly explain how to resolve the
>>> incompatibilities?  Or maybe there is an updated way to get these
>>> features?
>
> Well, after writing, I meanwhile got stubborn and did manage to get the
> "origin/scratch/gnus-search" version merged after cloning an emacs
> image. (The situation arose because I needed to install on a new
> machine...)
>
> There was one issue I encountered using gnus-search and notmuch as
> search engine (certain kinds of searches failed with an error message
> which essentially said "(if thread ....)" is not a string"). I'm
> attaching a patch (inclusion of a comma that seems to have been missing)
> which fixes this trouble for me.
>
> (Actually, I'm pretty sure I found this typo/glitch in June, fixed it,
> and then forgot that I had discovered it. Should have reported it then;
> sorry!)

Thanks for this! I've made the change in the Emacs scratch branch.

>> Then that could sit for a while, and in the meantime I would keep
>> scratch/gnus-search up to date with master. When it looked like it was
>> mature enough, I'd merge to master as well.
>
>> I think we've got Lars' blessing on all this, so we should be good to
>> go. Andy, if you're there -- what do you think about just taking the
>> plunge? I can be available to put out fires, if necessary.
>
> Well, I like the work; thanks! - I'm looking forward to its
> inclusion...!

Me too :)

Eric