reddit (was: Re: ediff question ...)

reddit (was: Re: ediff question ...)

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Try asking at http://emacs.reddit.com/ the folks
> there are more into fancy packages like ediff than
> people are here.

Are there a lot of interesting stuff going on there?

Did anyone do an Emacs or Gnus interface to reddit?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: reddit

[Stefan Monnier]

> Are there a lot of interesting stuff going on there?

I keep an eye on it, but there's not much interesting, IMO.
There's more (and more interesting) activity here and on emacs.stackexchange.


        Stefan

Re: reddit

[Artur Malabarba]

2015-05-01 13:37 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> Are there a lot of interesting stuff going on there?
>
> I keep an eye on it, but there's not much interesting, IMO.
> There's more (and more interesting) activity here and on emacs.stackexchange.

Yes, it's a bit quiet there. But every once in a while it gets a nice
discussion going that wouldn't really fit on stack exchange.

Re: reddit

[Stefan Monnier]

> Yes, it's a bit quiet there.  But every once in a while it gets a nice
> discussion going that wouldn't really fit on stack exchange.

I haven't noticed those.  The only thing I find worthwhile there,
really, is the occasional announcement of a new Elisp package.  And that
doesn't fit in emacs.stackexchange either (it does fit in
gnu.emacs.announce, of course but mailing-lists/newsgroups are so last
century for the young ones out there that it wouldn't occur to them to
use it).


        Stefan

Re: reddit

[Artur Malabarba]

> > Yes, it's a bit quiet there.  But every once in a while it gets a nice
> > discussion going that wouldn't really fit on stack exchange.
>
> I haven't noticed those.

There was a very mildly interesting one recently, about what have people
removed from their init file.
And once a year or so a huge thread usually pops up with recommendations
(most of which are "try org mode").

Overall, though, it's pretty quiet.

Re: reddit

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> but mailing-lists/newsgroups are so last century for
> the young ones out there that it wouldn't occur to
> them to use it)

And that will work to their disadvantage - big time.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: reddit

[Jai Dayal]

>And that will work to their disadvantage - big time.

Not really. It's actually to the tool's detriment when the maintainers do
not seek out modern outlets.

Nobody loses productivity by not using emacs and instead using one of the
modern IDEs that exist today.


On Sat, May 2, 2015 at 1:38 PM, Emanuel Berg <embe8573@student.uu.se> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > but mailing-lists/newsgroups are so last century for
> > the young ones out there that it wouldn't occur to
> > them to use it)
>
> And that will work to their disadvantage - big time.
>
> --
> underground experts united
> http://user.it.uu.se/~embe8573
>

Re: reddit

[Emanuel Berg]

Jai Dayal <dayalsoap@gmail.com> writes:

>> And that will work to their disadvantage -
>> big time.
>
> Not really. It's actually to the tool's detriment
> when the maintainers do not seek out modern outlets.
>
> Nobody loses productivity by not using emacs and
> instead using one of the modern IDEs that
> exist today.

The word "modern" doesn't carry any payload. (In the
future, by the way, things will be even more modern.)
What matter is what comes with the most *power*.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: reddit

[Jai Dayal]

Well in the context of technology, modern generally means tools that keep
up-to-date with the latest improvements and changes in technology and
culture. What you're presenting is just a hard-headed excuse. There's a
reason GCC is losing out to Clang, and Emacs has lost to IDEs. Ya'll have
maybe, what, 20 years or so before you guys die or retire? Who's going to
take carry Emacs over for the next few generations? These excuses of "hey,
look, I can implement that feature in 10k lines of Elisp!! Emacs is just as
usable and feature-full!!!!!!!!" just don't fly in the today's world where
there are 10's of IDEs that have an easier user experience. Not to mention,
some things just flat out don't work (C++ code completion in Emacs).

Reddit and stackexchange are far more user friendly than antiquated mailing
lists full of old senile grandpas complaining about "top posting" and all
kinds of other pedantic rubbish. Reddit will also increase exposure to
Emacs as a whole, so people who write software, but are unaware of great
plugins (i.e., the things Tudho writes), will occasionally stumble upon
Emacs threads. I get that the grandpas like to cling to the "way it used to
be", but in the end, modern liberalism always wins out over dogmatic
old-school conservatism.

On Sat, May 2, 2015 at 2:59 PM, Emanuel Berg <embe8573@student.uu.se> wrote:

> Jai Dayal <dayalsoap@gmail.com> writes:
>
> >> And that will work to their disadvantage -
> >> big time.
> >
> > Not really. It's actually to the tool's detriment
> > when the maintainers do not seek out modern outlets.
> >
> > Nobody loses productivity by not using emacs and
> > instead using one of the modern IDEs that
> > exist today.
>
> The word "modern" doesn't carry any payload. (In the
> future, by the way, things will be even more modern.)
> What matter is what comes with the most *power*.
>
> --
> underground experts united
> http://user.it.uu.se/~embe8573
>

Re: reddit

[Emanuel Berg]

Jai Dayal <dayalsoap@gmail.com> writes:

> Well in the context of technology, modern generally
> means tools that keep up-to-date with the latest
> improvements and changes in technology and culture.

Emacs should be up-to-date with improvements if they
actually are improvements and apply to the Emacs
field, which granted is big. You'll see there is
constant activity with Emacs all over the place. If,
even so, none of that picks up on the supposed
improvements, that tells me it probably wasn't
worthwhile to begin with.

And that brings me to the next point, which is, what
improvements exactly do you have in mind, which Emacs
hasn't benefited from because of negligence from the
Emacs community?

> Who's going to take carry Emacs over for the next
> few generations?

Those with skills and style.

> These excuses of "hey, look, I can implement that
> feature in 10k lines of Elisp!! Emacs is just as
> usable and feature-full!!!!!!!!" just don't fly in
> the today's world where there are 10's of IDEs that
> have an easier user experience.

What features are you talking about? And how do you
think those features are implemented in those IDEs?
Besides, what are those IDEs? Eclipse? MS Access?

If you are used to clicking the mouse and browsing
menus and all that there is a transition phase when
you re-learn. This is nothing dramatic and very
pleasant because you literally feel the power
increasing for every keystroke (at least in the
beginning). Because it is more pleasant, fun, and
interesting, growth is exponential. You'll smash
through the roof of those IDEs in no time.

Also, how "easy" something is day one doesn't matter.
It is how *powerful* it is the 100th day, and the
1000th day - and how much you enjoy doing it.

> Reddit and stackexchange are far more user friendly
> than antiquated mailing lists

Just like with Emacs and the shell, with mailing lists
(newsgroups), you can be who you want to be and do
what you want to do. You can get new skills and new
realizations. You can even behave like a moron.
This is what I mean by self-expression. On the
SX-sites - just try to write what you just wrote and
see what happens!

> liberalism always wins out over dogmatic old-school
> conservatism

I think the dogmatism is on the IDEs and forums and
SX-sites where the rules (dogmatism) is built-in.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: reddit

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Yes, it's a bit quiet there. But every once in
> a while it gets a nice discussion going that
> wouldn't really fit on stack exchange.

Discussions are not "allowed" there which is one of
the reason I don't use them sites actively. But if
I Google an error message the solution is often in one
of their sites. So their system works, no doubt.
What doesn't work, or wouldn't work for yours truly
anyway, is to get better by being active. It isn't
relaxed enough. There you should know everything to
the point or shut up. Also, there is no
self-expression (different personalities of
posters)... It works as a method, but is it
a community? If so, too much Aspergers.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: reddit

[Marcin Borkowski]

On 2015-05-02, at 19:38, Emanuel Berg <embe8573@student.uu.se> wrote:

> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>> Yes, it's a bit quiet there. But every once in
>> a while it gets a nice discussion going that
>> wouldn't really fit on stack exchange.
>
> Discussions are not "allowed" there which is one of
> the reason I don't use them sites actively. But if
> I Google an error message the solution is often in one
> of their sites. So their system works, no doubt.
> What doesn't work, or wouldn't work for yours truly
> anyway, is to get better by being active. It isn't
> relaxed enough. There you should know everything to
> the point or shut up. Also, there is no
> self-expression (different personalities of
> posters)... It works as a method, but is it
> a community? If so, too much Aspergers.

Just my 2 cents: try TeX.StackExchange.  /Completely/ different
experience: it's much less strict than StackOverflow, for instance,
waaaay friendlier, and there /are/ personalities (one the most famous is
Barbara Beeton, whose posts are exclusively in lowercase /unless/ she
writes officially on behalf of the AMS or TUG - this would be
unacceptable on SO - also Enrico Gregorio's posts, and probably also
David Carlisle's - and a few others - are easy to recognize after a few
lines).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: reddit

[Sivaram Neelakantan]

On Fri, May 01 2015,Stefan Monnier wrote:

>> Are there a lot of interesting stuff going on there?
>
> I keep an eye on it, but there's not much interesting, IMO.
> There's more (and more interesting) activity here and on emacs.stackexchange.

Is there a way to see the Emacs.stackexchange Q&A in gnus?


 sivaram
 -- 

Gnus + emacs.stackexchange (was: Re: reddit)

[Emanuel Berg]

Sivaram Neelakantan <nsivaram.net@gmail.com> writes:

>>> Are there a lot of interesting stuff going on
>>> there? I keep an eye on it, but there's not much
>>> interesting, IMO. There's more (and more
>>> interesting) activity here and on
>>> emacs.stackexchange.
>
> Is there a way to see the Emacs.stackexchange Q&A
> in gnus?

In the Group buffer, do `gnus-group-enter-server-mode'
(or hit S-6, or '^' - I have that 'S' instead, which
is much better, by the way).

Now, you should see a line:

    nntp: news.gwene.org

Go to it and hit RET.

If you don't see it, try to add this to you the/an
init file:

    (setq gnus-secondary-select-methods
      '( ; ...
         (nntp "news.gwene.org") ))

Next, find

    K   2597: gwene.com.stackexchange.emacs

Hit 'u' for `gnus-browse-unsubscribe-current-group' (I
have that 's') to remove the "K" sign (for killed,
i.e. not added).

It is very confusing: to subscribe, you have to
unsubscribe, and if you haven't done anything, you are
a killer... "You get ship if I get trip. ... That's
a ship? Who cares, as long as it flies."

Only bummer is you can't reply to Gwene posts.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange (was: Re: reddit)

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> Next, find
>
>     K 2597: gwene.com.stackexchange.emacs

I also see there are

    gwene.com.reddit.emacs
    gwene.com.reddit.pay.r.emacs

but even tho it reports there are posts to be fetched,
when I do, I don't get anything.

/Stealth 'R Us

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Sivaram Neelakantan]

On Sun, May 03 2015,Emanuel Berg wrote:

> Sivaram Neelakantan <nsivaram.net@gmail.com> writes:
>
>>>> Are there a lot of interesting stuff going on
>>>> there? I keep an eye on it, but there's not much
>>>> interesting, IMO. There's more (and more
>>>> interesting) activity here and on
>>>> emacs.stackexchange.
>>
>> Is there a way to see the Emacs.stackexchange Q&A
>> in gnus?

[snipped 30 lines]

>
> Only bummer is you can't reply to Gwene posts.

Thanks, will check this out.

 sivaram
 -- 

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

2015-05-05 3:32 GMT+01:00 Sivaram Neelakantan <nsivaram.net@gmail.com>:
> On Sun, May 03 2015,Emanuel Berg wrote:
>
>> Sivaram Neelakantan <nsivaram.net@gmail.com> writes:
>>
>>>>> Are there a lot of interesting stuff going on
>>>>> there? I keep an eye on it, but there's not much
>>>>> interesting, IMO. There's more (and more
>>>>> interesting) activity here and on
>>>>> emacs.stackexchange.
>>>
>>> Is there a way to see the Emacs.stackexchange Q&A
>>> in gnus?
>
> [snipped 30 lines]
>
>>
>> Only bummer is you can't reply to Gwene posts.
>
> Thanks, will check this out.

Try out sx.el. It's on Melpa, it has full reply/posting capabilities,
and it's very easy to learn.
Obviously you'll need a stackexchange account.

Re: Gnus + emacs.stackexchange

[Sharon Kimble]

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

Sivaram Neelakantan <nsivaram.net@gmail.com> writes:

> On Sun, May 03 2015,Emanuel Berg wrote:
>
>> Sivaram Neelakantan <nsivaram.net@gmail.com> writes:
>>
>>>>> Are there a lot of interesting stuff going on
>>>>> there? I keep an eye on it, but there's not much
>>>>> interesting, IMO. There's more (and more
>>>>> interesting) activity here and on
>>>>> emacs.stackexchange.
>>>
>>> Is there a way to see the Emacs.stackexchange Q&A
>>> in gnus?
>
> [snipped 30 lines]
>
>>
>> Only bummer is you can't reply to Gwene posts.
>
> Thanks, will check this out.
>
I looked into this and was disappointed that it only showed you the
questions and not any replies. It also seemed that the questions
that I read were very short, possibly just one paragraph and with no
code examples. A big disappointment!

Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.0, fluxbox 1.3.7, emacs 24.5.50.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Gnus + emacs.stackexchange

[Sivaram Neelakantan]

On Tue, May 05 2015,Sharon Kimble wrote:


[snipped 20 lines]

>> Thanks, will check this out.
>>
> I looked into this and was disappointed that it only showed you the
> questions and not any replies. It also seemed that the questions
> that I read were very short, possibly just one paragraph and with no
> code examples. A big disappointment!

Oh,that will not be useful for me too.  I'll try the sx.el one and see
how it goes.


 sivaram
 -- 

Re: Gnus + emacs.stackexchange

[Sivaram Neelakantan]

On Wed, May 06 2015,Sivaram Neelakantan wrote:


[snipped 12 lines]

> Oh,that will not be useful for me too.  I'll try the sx.el one and see
> how it goes.
>
>

Well, I did try sx.el and I must say it was a breeze to use.  you must
have an sx account and everything works smoothly after that. The UI
could do with some work but it's eminently usable as is.  Many thanks
to the author(s) who developed it.  


 sivaram
 -- 

Re: Gnus + emacs.stackexchange

[Jude DaShiell]

Good luck, that won't een download over here since it uses a version of 
company that won't download either.  The correct version of company has to 
be installed on the system before sx.el will even download.



-- Twitter: JudeDaShiell


On Fri, 8 May 2015, Sivaram Neelakantan wrote:

> On Wed, May 06 2015,Sivaram Neelakantan wrote:
>
>
> [snipped 12 lines]
>
>> Oh,that will not be useful for me too.  I'll try the sx.el one and see
>> how it goes.
>>
>>
>
> Well, I did try sx.el and I must say it was a breeze to use.  you must
> have an sx account and everything works smoothly after that. The UI
> could do with some work but it's eminently usable as is.  Many thanks
> to the author(s) who developed it.
>
>
> sivaram
> --
>
>
>

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

2015-05-08 21:10 GMT+01:00 Jude DaShiell <jdashiel@panix.com>:
> Good luck, that won't een download over here since it uses a version of
> company that won't download either.  The correct version of company has to
> be installed on the system before sx.el will even download.

Are you sure? sx.el doesn't depend on company (nor do any of its
dependencies AFAICT).

Re: Gnus + emacs.stackexchange

[Sivaram Neelakantan]

On Fri, May 08 2015,Artur Malabarba wrote:

> 2015-05-08 21:10 GMT+01:00 Jude DaShiell <jdashiel@panix.com>:
>> Good luck, that won't een download over here since it uses a version of
>> company that won't download either.  The correct version of company has to
>> be installed on the system before sx.el will even download.
>
> Are you sure? sx.el doesn't depend on company (nor do any of its
> dependencies AFAICT).

That's right.

I don't have company installed.  All I had to do was download from
melpa and it simply worked.

And I did a M-x list-packages just to double check

--8<---------------cut here---------------start------------->8---
  company            0.8.12       available  gnu        Modular text completion framework
  company            0.8.12       available  melpa      Modular text completion framework
  company-cabal      0.1.1        available  melpa      company-mode cabal backend
  company-cmake      0.1          available  marmalade  company-mode completion back-end 
--8<---------------cut here---------------end--------------->8---

and it's not installed on my system.  The problem could be elsewhere. 

 sivaram
 -- 

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

> have an sx account and everything works smoothly after that. The UI
> could do with some work but it's eminently usable as is.

Feel free to send us any comments at the github repo or on the Gitter room.

> Many thanks
> to the author(s) who developed it.

Thanks for trying it. :-)

Re: Gnus + emacs.stackexchange

[Sivaram Neelakantan]

On Sat, May 09 2015,Artur Malabarba wrote:

>> have an sx account and everything works smoothly after that. The UI
>> could do with some work but it's eminently usable as is.
>
> Feel free to send us any comments at the github repo or on the Gitter room.
>
>> Many thanks
>> to the author(s) who developed it.
>
> Thanks for trying it. :-)
>

And will do. Thanks once again

 sivaram
 -- 

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Sharon Kimble <boudiccas@skimble.plus.com> writes:

> I looked into this and was disappointed that it only
> showed you the questions and not any replies.

Indeed, and that is because there is only one feed,
precisely "recent questions feed" [1] on emacs.sx.

If you check out

    nntp: news.gwene.org

and make a search for "comments", you see that many
blogs have a separate feed for comments. I can't see
why the SX question solution can't be easily extended
to include answers and comments, but I don't know
the details.

The best solution would be to have only one feed that
would result in a threaded Gnus summary where SX
answers and comments (and blog comments) were
subordinated the question (just like we get it for
mail/listbots/Usenet).

Because it is such a natural thing to wish for,
I suspect we are not the first to react like this and
probably there are technical complications. It looks
simple but because it isn't done I suspect it isn't.

The step after that would be to be able to answer (and
add comments) just by replying to the OP as we are
also accustomed to.

If we can make the SX sites, blogs, and so on behave
our way I'd start participating day one. I interpret
Gwene as a step in that direction, toward the desired
and magical but realistic (or possible I should say)
all access interface-independent future of manual as
well as automatic data processing...

> It also seemed that the questions that I read were
> very short, possibly just one paragraph and with no
> code examples. A big disappointment!

Isn't it exactly the way they write them? I see quite
long posts right now which include code. But if stuff
do appear in abbreviated form that is a feed issue as
well which should (again if so) be directed to the
Emacs SX people. Gnus just shows the data.

[1] http://emacs.stackexchange.com/feeds

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Ted Zlatanov]

On Wed, 06 May 2015 02:30:55 +0200 Emanuel Berg <embe8573@student.uu.se> wrote: 

EB> If you check out

EB>     nntp: news.gwene.org

EB> and make a search for "comments", you see that many
EB> blogs have a separate feed for comments. I can't see
EB> why the SX question solution can't be easily extended
EB> to include answers and comments, but I don't know
EB> the details.

EB> The best solution would be to have only one feed that
EB> would result in a threaded Gnus summary where SX
EB> answers and comments (and blog comments) were
EB> subordinated the question (just like we get it for
EB> mail/listbots/Usenet).

EB> Because it is such a natural thing to wish for,
EB> I suspect we are not the first to react like this and
EB> probably there are technical complications. It looks
EB> simple but because it isn't done I suspect it isn't.

I've suggested it, but it's incredibly complicated to make a generic
solution for posting to a comment feed. Gwene would have to support
potentially hundreds of comment feed formats; the formatting and other
things would be broken.

But this is still theoretically possible, whereas...

EB> The step after that would be to be able to answer (and
EB> add comments) just by replying to the OP as we are
EB> also accustomed to.

Even just for SX sites it would be very difficult to make a NNTP-to-SX
gateway without the active participation and commitment of the people
who write and maintain those sites' software. Most sites nowadays make
it hard to post mechanically on purpose since the potential for abuse is
very high.

Ted

Re: Gnus + emacs.stackexchange

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 06, 2015 at 05:39:45AM -0400, Ted Zlatanov wrote:

[...]

> Even just for SX sites it would be very difficult to make a NNTP-to-SX
> gateway without the active participation and commitment of the people
> who write and maintain those sites' software. Most sites nowadays make
> it hard to post mechanically on purpose since the potential for abuse is
> very high.

Yep, I think that's the main issue: how (as a site, in this case SX) do
you distinguish a news gateway from a sufficiently skilled spambot
selling the next herbal treatment (or something more disgusting)?

If you crack this one nut, the rest are technical details...

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlVJ63AACgkQBcgs9XrR2kbawgCfWp6T9IKHUJxvyj+24ytmhIyr
OLAAnjYItDbDrOjt2b0RYWMcJLsdj6xN
=46Q3
-----END PGP SIGNATURE-----

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I've suggested it, but it's incredibly complicated
> to make a generic solution for posting to a comment
> feed. Gwene would have to support potentially
> hundreds of comment feed formats; the formatting and
> other things would be broken.

Formatting isn't anything to be concerned with. If one
wants the supposedly "modern" features just use the
real thing. The idea of using Gnus would be to have
the familiar interface, and not trying to replicate
what we already have elsewhere (and don't like).
I.e., bypassing the interface to get what we *do* like
(sometimes), which is the contents of the blogs
(including the comments), and to be able to use it
ourselves, only in our ways.

As for the hundreds of feed formats, are there really
that many? Even so, not all need to be covered!
When there are 100 meals in a restaurant, I think the
ten most popular make up for 90% of what people buy,
and the same principle probably holds if those ten
were compared "internally" as well.

Also, it is possible that some feed format is more
popular within what typically interests the Gnus
people, than if the whole blog world is considered.

Besides, just doing it *once* (the most popular
comment feed format) would be interesting because it
would show it is possible and how nice it would be.
From then on, the wheels are in motion. It is just
like the Linux kernel which is now ported to all
hardware no matter how goofy and obscure. No one
thought of doing that day one.

> Even just for SX sites it would be very difficult to
> make a NNTP-to-SX gateway without the active
> participation and commitment of the people who write
> and maintain those sites' software. Most sites
> nowadays make it hard to post mechanically on
> purpose since the potential for abuse is very high.

Indeed, the participation would be needed. So start
with the Emacs SX! But the sx.el people already did it
(tho I didn't got it to work myself). But because they
already did it (not NNTP perhaps but something to the
extent of what we discuss) I'd say the "all-in",
nested thread post/comments blog idea is more
interesting and beneficial to the Gnusers around the
world...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

> Indeed, the participation would be needed. So start
> with the Emacs SX! But the sx.el people already did it
> (tho I didn't got it to work myself). But because they
> already did it (not NNTP perhaps but something to the
> extent of what we discuss)

It's the Stackexchange API.

> I'd say the "all-in",
> nested thread post/comments blog idea is more
> interesting and beneficial to the Gnusers around the
> world...

I've toyed with the idea of combining sx.el with some sort of mailbot,
so that each question on Emacs.stackexchange gets sent to some list,
and if people reply to that list the bot would post the reply to the
site (using sx.el).

Issues with this are:
1) I've no idea how (and no time) to write a mailbot.
2) It would have to be VERY smart about which replies it posts and be
moderated. The SX API has a very incisive “Quality of Content” clause,
which indicates the bot might get banned quickly if it's just posting
random comments everywhere.
3) On SX, it's possible to call's someones attention by directly
@naming them. I'm not sure how the bot would handle these
notifications. I think the only answer would be someone with a lot of
common sense (possibly the same who moderates item 2), would manually
check all notifications.

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> Indeed, the participation would be needed. So start
>> with the Emacs SX! But the sx.el people already did
>> it (tho I didn't got it to work myself).
>> But because they already did it (not NNTP perhaps
>> but something to the extent of what we discuss)
>
> It's the Stackexchange API.

Well, yeah :) A solution with Gnus would be a gateway
from/to the NNTP protocol and the SX interface (or
API). Actually Gnus can do and does other things than
that (NNTP) but I don't see why anyone would choose
the small shop when there is a big. Anyway if there
already is considerable work on sx.el as it seems it
might not be a real need to have it in Gnus as well.
It would be nice tho, and it would make sense in terms
of technology.

>> I'd say the "all-in", nested thread post/comments
>> blog idea is more interesting and beneficial to the
>> Gnusers around the world...
>
> I've toyed with the idea of combining sx.el with
> some sort of mailbot, so that each question on
> Emacs.stackexchange gets sent to some list, and if
> people reply to that list the bot would post the
> reply to the site (using sx.el).
>
> Issues with this are: 1) I've no idea how (and no
> time) to write a mailbot. 2) It would have to be
> VERY smart about which replies it posts and be
> moderated. The SX API has a very incisive “Quality
> of Content” clause, which indicates the bot might
> get banned quickly if it's just posting random
> comments everywhere. 3) On SX, it's possible to
> call's someones attention by directly @naming them.
> I'm not sure how the bot would handle these
> notifications. I think the only answer would be
> someone with a lot of common sense (possibly the
> same who moderates item 2), would manually check
> all notifications.

You don't need to worry about all that. It would only
be a new *interface* to the SX sites (perhaps only the
Emacs site as a pilot case). So you don't have to
worry about doing everything SX does. You have only to
make sure hooking to SX is done in the same way it
happens when something is posted the ordinary way
(i.e. with their web GUI). If you do that then SX will
handle material the same way - how it originated (i.e.
what interface was used) will not be considered -
it'll be transparent to whatever checks and balances
that kicks in at that point.

Check out these extentions [1] to Emacs-w3m to see
what I mean. Notice they mention Google, YouTube,
different search sites like Wikipedia,
the Urban Dictionary, and so on. Notice I don't do
anything to replicate what functionality is on those
sites - I only care about hooking to them the same way
their web GUIs are. If you do that spotlessly they
have no choice but to give ou what you want. If they
don't, that means their own services are down.

[1] http://user.it.uu.se/~embe8573/conf/emacs-init/w3m/w3m-unisearch.el
    http://user.it.uu.se/~embe8573/conf/emacs-init/isbn.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

2015-05-08 0:58 GMT+01:00 Emanuel Berg <embe8573@student.uu.se>:
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>>> Indeed, the participation would be needed. So start
>>> with the Emacs SX! But the sx.el people already did
>>> it (tho I didn't got it to work myself).
>>> But because they already did it (not NNTP perhaps
>>> but something to the extent of what we discuss)
>>
>> It's the Stackexchange API.
>
> Well, yeah :) A solution with Gnus would be a gateway
> from/to the NNTP protocol and the SX interface (or
> API). Actually Gnus can do and does other things than
> that (NNTP) but I don't see why anyone would choose
> the small shop when there is a big. Anyway if there
> already is considerable work on sx.el as it seems it
> might not be a real need to have it in Gnus as well.
> It would be nice tho, and it would make sense in terms
> of technology.

Yeah, it's something I'll keep on the back of my mind. The important
thing is that it's all in Emacs :)

> You don't need to worry about all that. It would only
> be a new *interface* to the SX sites (perhaps only the
> Emacs site as a pilot case). So you don't have to
> worry about doing everything SX does. You have only to
> make sure hooking to SX is done in the same way it
> happens when something is posted the ordinary way
> (i.e. with their web GUI). If you do that then SX will
> handle material the same way - how it originated (i.e.
> what interface was used) will not be considered -
> it'll be transparent to whatever checks and balances
> that kicks in at that point.
>
> Check out these extentions [1] to Emacs-w3m to see
> what I mean. Notice they mention Google, YouTube,
> different search sites like Wikipedia,
> the Urban Dictionary, and so on. Notice I don't do
> anything to replicate what functionality is on those
> sites - I only care about hooking to them the same way
> their web GUIs are. If you do that spotlessly they
> have no choice but to give ou what you want. If they
> don't, that means their own services are down.
>
> [1] http://user.it.uu.se/~embe8573/conf/emacs-init/w3m/w3m-unisearch.el
>     http://user.it.uu.se/~embe8573/conf/emacs-init/isbn.el

I took a quick glance. Are you referring to things like this snippet?

  (w3m-web-search
   "https://www.google.com/search?hl=en&site=imghp&tbm=isch&source=hp&q=%s"
   (get-search-string "image"))

I think this sort of thing would work for browsing and searching on
the stack exchange network, but posting isn't done like that in the
web GUI (though I haven't investigated into how it's done, it's
probably javascript).

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> I think this sort of thing would work for browsing
> and searching on the stack exchange network, but
> posting isn't done like that in the web GUI (though
> I haven't investigated into how it's done, it's
> probably javascript).

All services have interfaces to the outside world - if
they didn't, they couldn't be used. So it is a matter
of finding out that interface and then using it as it
is used by their already provided interface.

It not about replicating functionality externally.
That would amount to creating a parallel service.
It is not even replicating the entire interface (tho
that would be nice). The new interface doesn't need
every little detail and it doesn't have to look the
same (if that is desired, why do it and not just use
the original UI to begin with?). But what the
interface has to do is relay data consistent with what
the native interface produces.

If it cannot be done like this - and this would be
because they don't like their service to be used in
other ways than their own - that attitude would
discourage me from doing it, because it would be a cat
and mouse game who can keep up with who. Then it is
better to do something else entirely. Is what I think!

The Emacs site is not like that and sx.el shows it.
And it is natural they want people to use it with/from
Emacs. They should want this themselves! So to use it
from Gnus would/could/should be and interface to sx.el
which in turn is an interface to the Emacs SX site.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Try out sx.el. It's on Melpa, it has full
> reply/posting capabilities, and it's very easy to
> learn. Obviously you'll need
> a stackexchange account.

Couldn't one post there anonymously at some point?
Perhaps they removed that possibility.

sx.el is worth a try no doubt but it would be even
better with a Gnus extention as it is the universal
tool for tech communication (mail, listbots,
newsgroups, RSS, and more) and people including yours
truly have taken its equally uniform interface to
their hearts or rather fingertips.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

>> Try out sx.el. It's on Melpa, it has full
>> reply/posting capabilities, and it's very easy to
>> learn. Obviously you'll need
>> a stackexchange account.
>
> Couldn't one post there anonymously at some point?
> Perhaps they removed that possibility.

I'm not sure, but if one could then they've definitely removed it.

> sx.el is worth a try no doubt but it would be even
> better with a Gnus extention as it is the universal
> tool for tech communication (mail, listbots,
> newsgroups, RSS, and more) and people including yours
> truly have taken its equally uniform interface to
> their hearts or rather fingertips.

I'd like to that eventually. Though I've used gnus before, I don't
think any of the sx.el developers are deep into gnus. If I switch to
gnus this year (which I've been meaning to) I might ammend that.

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> Couldn't one post there anonymously at some point?
>> Perhaps they removed that possibility.
>
> I'm not sure, but if one could then they've
> definitely removed it.

I think it is a bit illogical there are accounts on
the SX sites and yet everyone is encouraged to edit
posts, including those that aren't written by
the editor.

On Wikipedia the whole idea is anyone can edit, and
the result of the collective effort will prevail in
the end (is the assumption). But it doesn't say who
wrote what with an assigned reputation to go with it,
which would seem to run contrary to that principle
(?).

But if it works I suppose it doesn't matter what is
logical or not. Personally I like no one to edit what
I write and if I make a mistake (it has been known to
happen) I'm confident someone will point it out, which
is the way I like it.

As for reputation that should be implied. During the
Russian civil war the Reds didn't have any signs to
tell who was the commander in each squad, but still
everyone knew who was the boss. It's usually not that
difficult to tell.

But again (explicit) reputation is a way of making it
a competition and it seems to inspire people to
produce material, so tho I personally am opposed to
that for several reasons I'm not blind to see that it
seems to work for them and to some extent to me, as
I often Google error messages and the like and find
the answer on one of them sites.

>> sx.el is worth a try no doubt but it would be even
>> better with a Gnus extention as it is the universal
>> tool for tech communication (mail, listbots,
>> newsgroups, RSS, and more) and people including
>> yours truly have taken its equally uniform
>> interface to their hearts or rather fingertips.
>
> I'd like to that eventually. Though I've used gnus
> before, I don't think any of the sx.el developers
> are deep into gnus.

No :)

It seems they have gotten quite far with sx.el, but to
do it with Gnus would be better for many reasons, and
one would be to be able to use all the stuff that has
been there for ages (the message-mode I'm using right
now, for example). But reinventing the wheel is not
necessarily a bad thing. The most important thing is
that you are able to use it with Emacs with the same
finger-habits and configs you are used to. Be it Gnus
or sx.el is secondary.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

> >> Couldn't one post there anonymously at some point?
> >> Perhaps they removed that possibility.
> >
> > I'm not sure, but if one could then they've
> > definitely removed it.
>
> I think it is a bit illogical there are accounts on
> the SX sites and yet everyone is encouraged to edit
> posts, including those that aren't written by
> the editor.

Kind of. Everyone with a bit of reputation is encouraged to submit edits.
And it takes quite a bit more to be able to edit directly.

> On Wikipedia the whole idea is anyone can edit, and
> the result of the collective effort will prevail in
> the end (is the assumption). But it doesn't say who
> wrote what with an assigned reputation to go with it,
> which would seem to run contrary to that principle
> (?).
>
> But if it works I suppose it doesn't matter what is
> logical or not. Personally I like no one to edit what
> I write and if I make a mistake (it has been known to
> happen) I'm confident someone will point it out, which
> is the way I like it.
>
> As for reputation that should be implied. During the
> Russian civil war the Reds didn't have any signs to
> tell who was the commander in each squad, but still
> everyone knew who was the boss. It's usually not that
> difficult to tell.
>
> But again (explicit) reputation is a way of making it
> a competition and it seems to inspire people to
> produce material, so tho I personally am opposed to
> that for several reasons I'm not blind to see that it
> seems to work for them and to some extent to me, as
> I often Google error messages and the like and find
> the answer on one of them sites.

Yes, I think you've said it all. :-)
Maybe one could arguably say that Wikipedia's model is more successful due
to its size. But that might just be comparing apples and oranges. Both
clearly worked very well for their applications.

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Try out sx.el. It's on Melpa, it has full
> reply/posting capabilities, and it's very easy to
> learn. Obviously you'll need
> a stackexchange account.

I installed it from Melpa with no problems but then
I do `sx-search' and it asks what site and I say
"emacs" and then I type a search string but then it
invariably (?) says

    (wrong-type-argument char-or-string-p nil) in tabulated-list-print

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

2015-05-06 1:45 GMT+01:00 Emanuel Berg <embe8573@student.uu.se>:
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>> Try out sx.el. It's on Melpa, it has full
>> reply/posting capabilities, and it's very easy to
>> learn. Obviously you'll need
>> a stackexchange account.
>
> I installed it from Melpa with no problems but then
> I do `sx-search' and it asks what site and I say
> "emacs" and then I type a search string but then it
> invariably (?) says
>
>     (wrong-type-argument char-or-string-p nil) in tabulated-list-print

That's odd. What's your Emacs version?
We had some stupid autoloading issues in the past, so you might
workaround it if you load the file `sx-load'.
Also, do other commands work? (try the `sx-tab-all-questions')

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> That's odd. What's your Emacs version?

    GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+
    Version 3.14.5) of 2015-03-07 on trouble, modified
    by Debian

> We had some stupid autoloading issues in the past,
> so you might workaround it if you load the file
> `sx-load'.

If you mean

    ~/.emacs.d/elpa/sx-20150502.440/sx-load.el

it didn't change anything to `load' that.

And it makes sense that didn't save the day. If any
sx- command is available it should be possible to
invoke without having to load anything or, if
necessary, it should take care of that transparently.

> Also, do other commands work? (try the
> `sx-tab-all-questions')

I get the same error message:

    (wrong-type-argument char-or-string-p nil) in
    tabulated-list-print

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

>> Also, do other commands work? (try the
>> `sx-tab-all-questions')
>
> I get the same error message:
>
>     (wrong-type-argument char-or-string-p nil) in
>     tabulated-list-print

Ok, would you be willing to produce a backtrace? (with M-x
toggle-debug-on-error)

Re: Gnus + emacs.stackexchange

[Emanuel Berg]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> I get the same error message:
>>
>> (wrong-type-argument char-or-string-p nil) in
>> tabulated-list-print
>
> Ok, would you be willing to produce a backtrace?
> (with M-x toggle-debug-on-error)

This is what it says for `sx-search': 

    Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
      tabulated-list-print-fake-header()
      tabulated-list-print(remember)
      sx-question-list-refresh(redisplay)
      sx-search("emacs" "face" nil nil)
      call-interactively(sx-search record nil)
      command-execute(sx-search record)
      execute-extended-command(nil "sx-search")
      call-interactively(execute-extended-command nil nil)
      command-execute(execute-extended-command)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

>>> I get the same error message:
>>>
>>> (wrong-type-argument char-or-string-p nil) in
>>> tabulated-list-print
>>
>> Ok, would you be willing to produce a backtrace?
>> (with M-x toggle-debug-on-error)
>
> This is what it says for `sx-search':
>
>     Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
>       tabulated-list-print-fake-header()
>       tabulated-list-print(remember)
>       sx-question-list-refresh(redisplay)
>       sx-search("emacs" "face" nil nil)
>       call-interactively(sx-search record nil)
>       command-execute(sx-search record)
>       execute-extended-command(nil "sx-search")
>       call-interactively(execute-extended-command nil nil)
>       command-execute(execute-extended-command)

Ok. It looks like something is setting your
`tabulated-list-use-header-line' variable to nil *between* the buffer
initialization and the list printing. So the
`tabulated-list--header-string' variable doesn't get set (it's
normally set during buffer initialization), but when it's time to
print, the variable is expected to be a string.
I think that's a bug in tabulated-list-mode (which I'll try to get
fixed now), but do you have any hooks or advices that may be causing
that?

RE: Gnus + emacs.stackexchange

[Drew Adams]

> >>> (wrong-type-argument char-or-string-p nil) in
> >>> tabulated-list-print
> >>
> >> Ok, would you be willing to produce a backtrace?
> >> (with M-x toggle-debug-on-error)
> >
> > This is what it says for `sx-search':
> >
> >     Debugger entered--Lisp error: (wrong-type-argument char-or-
> >                                    string-p nil)
> >       tabulated-list-print-fake-header()
> >       tabulated-list-print(remember)
> 
> Ok. It looks like something is setting your
> `tabulated-list-use-header-line' variable to nil *between* the
> buffer initialization and the list printing. So the
> `tabulated-list--header-string' variable doesn't get set (it's
> normally set during buffer initialization), but when it's time to
> print, the variable is expected to be a string.
> I think that's a bug in tabulated-list-mode (which I'll try to get
> fixed now), but do you have any hooks or advices that may be causing
> that?

Check where you call the major (derived) mode, which calls
`tabulated-list-mode'.  If it calls it after you have already
inserted the header line then that line will be removed when
`tabulated-list-mode' (calls `special-mode' which) kills all
local variables.

IMO, the `tabulated-list-mode' doc is not clear about such
things.  Put differently, the design of `tabulated-list-mode'
seems to be a bit fragile.  You need to do things in a specific
order, which is not well documented.

Caveat: I'm no expert on `tabulated-list-mode'.  Just starting
to wade through it myself, actually - which is why I think I
recognize the above error.  When I understand it better I will
perhaps file a bug report or two - doc or otherwise.

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

2015-05-11 14:54 GMT+01:00 Drew Adams <drew.adams@oracle.com>:
>> >>> (wrong-type-argument char-or-string-p nil) in
>> >>> tabulated-list-print
>> >>
>> >> Ok, would you be willing to produce a backtrace?
>> >> (with M-x toggle-debug-on-error)
>> >
>> > This is what it says for `sx-search':
>> >
>> >     Debugger entered--Lisp error: (wrong-type-argument char-or-
>> >                                    string-p nil)
>> >       tabulated-list-print-fake-header()
>> >       tabulated-list-print(remember)
>>
>> Ok. It looks like something is setting your
>> `tabulated-list-use-header-line' variable to nil *between* the
>> buffer initialization and the list printing. So the
>> `tabulated-list--header-string' variable doesn't get set (it's
>> normally set during buffer initialization), but when it's time to
>> print, the variable is expected to be a string.
>> I think that's a bug in tabulated-list-mode (which I'll try to get
>> fixed now), but do you have any hooks or advices that may be causing
>> that?
>
> Check where you call the major (derived) mode, which calls
> `tabulated-list-mode'.  If it calls it after you have already
> inserted the header line then that line will be removed when
> `tabulated-list-mode' (calls `special-mode' which) kills all
> local variables.

Activating the mode is the first thing we do on a new buffer. All
variables are set after that.

And sx has no reference to `tabulated-list-use-header-line' or
`tabulated-list--header-string', which is why I suspect there's a hook
gone rogue somewhere. Of course, I may be wrong.

> IMO, the `tabulated-list-mode' doc is not clear about such
> things.  Put differently, the design of `tabulated-list-mode'
> seems to be a bit fragile.  You need to do things in a specific
> order, which is not well documented.
>
> Caveat: I'm no expert on `tabulated-list-mode'.  Just starting
> to wade through it myself, actually - which is why I think I
> recognize the above error.  When I understand it better I will
> perhaps file a bug report or two - doc or otherwise.

I never had huge problems with this when writing paradox or sx.el.
That said, I was following the lead of `package-menu-mode's
definition, so I can't say how clear the documentation is on its own.

But I do think it's a bug that tabulated-list just barfs if the user
changes a variable to a legal value (even if it's done at the wrong
time). So I'll be fixing that this week.

RE: Gnus + emacs.stackexchange

[Drew Adams]

> >> Ok. It looks like something is setting your
> >> `tabulated-list-use-header-line' variable to nil *between* the
> >> buffer initialization and the list printing. So the
> >> `tabulated-list--header-string' variable doesn't get set (it's
> >> normally set during buffer initialization), but when it's time to
> >> print, the variable is expected to be a string.
> >> I think that's a bug in tabulated-list-mode (which I'll try to
> >> get fixed now), but do you have any hooks or advices that may be
> >> causing that?
> >
> > Check where you call the major (derived) mode, which calls
> > `tabulated-list-mode'.  If it calls it after you have already
> > inserted the header line then that line will be removed when
> > `tabulated-list-mode' (calls `special-mode' which) kills all
> > local variables.
> 
> Activating the mode is the first thing we do on a new buffer. All
> variables are set after that.
> 
> And sx has no reference to `tabulated-list-use-header-line' or
> `tabulated-list--header-string', which is why I suspect there's a
> hook gone rogue somewhere. Of course, I may be wrong.

It should call `tabulated-list-init-header', I believe.  If it does
not then that is perhaps your problem.  See (elisp) `Tabulated List
Mode':

 The body of the `define-derived-mode' form should specify the format
 of the tabulated data, by assigning values to the variables
 documented below; then, it should call the function
 `tabulated-list-init-header' to initialize the header line.

And the doc string of `tabulated-list-mode':

 An inheriting mode should usually do the following in their body:...
  - Call `tabulated-list-init-header' to initialize `header-line-format'
    according to `tabulated-list-format'.

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

2015-05-11 16:47 GMT+01:00 Drew Adams <drew.adams@oracle.com>:
>> >> Ok. It looks like something is setting your
>> >> `tabulated-list-use-header-line' variable to nil *between* the
>> >> buffer initialization and the list printing. So the
>> >> `tabulated-list--header-string' variable doesn't get set (it's
>> >> normally set during buffer initialization), but when it's time to
>> >> print, the variable is expected to be a string.
>> >> I think that's a bug in tabulated-list-mode (which I'll try to
>> >> get fixed now), but do you have any hooks or advices that may be
>> >> causing that?
>> >
>> > Check where you call the major (derived) mode, which calls
>> > `tabulated-list-mode'.  If it calls it after you have already
>> > inserted the header line then that line will be removed when
>> > `tabulated-list-mode' (calls `special-mode' which) kills all
>> > local variables.
>>
>> Activating the mode is the first thing we do on a new buffer. All
>> variables are set after that.
>>
>> And sx has no reference to `tabulated-list-use-header-line' or
>> `tabulated-list--header-string', which is why I suspect there's a
>> hook gone rogue somewhere. Of course, I may be wrong.
>
> It should call `tabulated-list-init-header', I believe.  If it does
> not then that is perhaps your problem.  See (elisp) `Tabulated List
> Mode':

Thanks drew, you're right. We don't call init-header because we don't
use the header. I thought that was ok, but it ends up throwing an
error in the case where `tabulated-list-use-header-line' is non-nil
(which is not our case, but I guess some user/packages might set this
variable globally).

Re: Gnus + emacs.stackexchange

[Artur Malabarba]

>> It should call `tabulated-list-init-header', I believe.  If it does
>> not then that is perhaps your problem.  See (elisp) `Tabulated List
>> Mode':
>
> Thanks drew, you're right. We don't call init-header because we don't
> use the header. I thought that was ok, but it ends up throwing an
> error in the case where `tabulated-list-use-header-line' is non-nil

I mean, in the case where it IS nil.

RE: Gnus + emacs.stackexchange

[Drew Adams]

> >> > Check where you call the major (derived) mode, which calls
> >> > `tabulated-list-mode'.  If it calls it after you have already
> >> > inserted the header line then that line will be removed when
> >> > `tabulated-list-mode' (calls `special-mode' which) kills all
> >> > local variables.
> >>
> >> Activating the mode is the first thing we do on a new buffer. All
> >> variables are set after that.
> >>
> >> And sx has no reference to `tabulated-list-use-header-line' or
> >> `tabulated-list--header-string', which is why I suspect there's a
> >> hook gone rogue somewhere. Of course, I may be wrong.
> >
> > It should call `tabulated-list-init-header', I believe.  If it
> > does not then that is perhaps your problem.  See (elisp) `Tabulated
> > List Mode':
> 
> Thanks drew, you're right. We don't call init-header because we
> don't use the header. I thought that was ok, but it ends up throwing an
> error in the case where `tabulated-list-use-header-line' is non-nil
> (which is not our case, but I guess some user/packages might set
> this variable globally).

OK.  I thought that the original problem was that a header was wanted
but was not showing up.  Sorry if I misunderstood.

Re: reddit (was: Re: ediff question ...)

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> Try asking at http://emacs.reddit.com/ the folks
>> there are more into fancy packages like ediff than
>> people are here.
>
> Are there a lot of interesting stuff going on there?

Not very much.  Tuhdo posts there (he posts here too sometimes), his
stuff can be quite interesting.  For example, he posted a package to
compare directory trees yesterday.

There seem to be a lot of ex-Vim people there, lots of people using Evil
and Spacemacs.  Packages from Melpa & Marmalade seem very popular.

> Did anyone do an Emacs or Gnus interface to reddit?

I think they did but I haven't tried it.

BR,
Robert Thorpe