[ANN] project-buffers.el

[ANN] project-buffers.el

[Steven Degutis]

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

https://github.com/sdegutis/project-buffers.el

Basically, gives you `next-buffer`, `previous-buffer`, `switch-to-buffer`
and more, but limited to buffers that are in the "current project" (defined
as an ancestor dir containing one of a defcustomizable list of files, like
".git", "Makefile", etc).

It's in MELPA.

Why didn't something like this already exist? The only reason I've heard so
far was "it'll be too slow when you're editing remote files". Are there
other reasons?

P.S. Sorry if this is showing up twice. I didn't see it posted at first,
and figured it's because I ticked the "conceal email address" option, so it
went overboard and concealed my email by just not posting my message.

-Steven

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

Re: [ANN] project-buffers.el

[Bob Proulx]

> P.S. Sorry if this is showing up twice. I didn't see it posted at first,
> and figured it's because I ticked the "conceal email address" option, so it
> went overboard and concealed my email by just not posting my message.

This is the first time your address is seen to the mailing list.
Spammers like to subscribe and then post messages to scam the "must be
subscribed to post" filters which renders them useless.  Therefore all
new subscribers are moderated until they post a valid message.  After
the initial valid email posting then you are unmoderated subsequently.

It looks like you posted your message at 09:31:53 -0600 and it was
delivered at 15:24:07 -0600.  Volunteers are sometimes busy with jobs
and life.

Additionally the network through the lists.gnu.org machine is often
saturated delivering email especially when people attach multimegabyte
files (log files, pictures, screenshots, pdfs, random things) that are
delivered to hundreds or thousands of subscribers multiplying the
bandwidth significantly.  That will often cause the mailing list to
have long delays in being able to deliver all mail through it even
small ones.  To curb that problem large emails are also held for
moderation.

Additionally there has until recently been a problem where the mailing
list machine would inappropriately think it was overloaded and
throttle delivery until the load subsided.  That was also causing long
mailing list delivery delays to appear out of the blue.  That
particular problem has been fully mitigated now.

Bob

Re: [ANN] project-buffers.el

[Steven Degutis]

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

Oh.

Thanks.

-Steven


On Mon, Apr 1, 2013 at 4:59 PM, Bob Proulx <bob@proulx.com> wrote:

> > P.S. Sorry if this is showing up twice. I didn't see it posted at first,
> > and figured it's because I ticked the "conceal email address" option, so
> it
> > went overboard and concealed my email by just not posting my message.
>
> This is the first time your address is seen to the mailing list.
> Spammers like to subscribe and then post messages to scam the "must be
> subscribed to post" filters which renders them useless.  Therefore all
> new subscribers are moderated until they post a valid message.  After
> the initial valid email posting then you are unmoderated subsequently.
>
> It looks like you posted your message at 09:31:53 -0600 and it was
> delivered at 15:24:07 -0600.  Volunteers are sometimes busy with jobs
> and life.
>
> Additionally the network through the lists.gnu.org machine is often
> saturated delivering email especially when people attach multimegabyte
> files (log files, pictures, screenshots, pdfs, random things) that are
> delivered to hundreds or thousands of subscribers multiplying the
> bandwidth significantly.  That will often cause the mailing list to
> have long delays in being able to deliver all mail through it even
> small ones.  To curb that problem large emails are also held for
> moderation.
>
> Additionally there has until recently been a problem where the mailing
> list machine would inappropriately think it was overloaded and
> throttle delivery until the load subsided.  That was also causing long
> mailing list delivery delays to appear out of the blue.  That
> particular problem has been fully mitigated now.
>
> Bob
>
>

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

RE: [ANN] project-buffers.el

[Drew Adams]

> Basically, gives you `next-buffer`, `previous-buffer`,
> `switch-to-buffer` and more, but limited to buffers that
> are in the "current project" (defined as an ancestor dir
> containing one of a defcustomizable list of files, like
> ".git", "Makefile", etc).
>
> Why didn't something like this already exist?

Something like that does exist.  Several such somethings.

http://www.emacswiki.org/emacs/CategoryProject

Re: [ANN] project-buffers.el

[Steven Degutis]

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

Thanks for the link, haven't seen that page before.

Most packages on that page don't do what project-buffers.el does.

Projectile almost does, but it doesn't have a per-project version of
next-buffer and previous-buffer, which was probably the main reason I wrote
project-buffers.el.

-Steven


On Mon, Apr 1, 2013 at 5:17 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > Basically, gives you `next-buffer`, `previous-buffer`,
> > `switch-to-buffer` and more, but limited to buffers that
> > are in the "current project" (defined as an ancestor dir
> > containing one of a defcustomizable list of files, like
> > ".git", "Makefile", etc).
> >
> > Why didn't something like this already exist?
>
> Something like that does exist.  Several such somethings.
>
> http://www.emacswiki.org/emacs/CategoryProject
>
>

[-- Attachment #2: Type: text/html, Size: 1430 bytes --]

Re: [ANN] project-buffers.el

[Dmitry Gutov]

Steven Degutis <sbdegutis@gmail.com> writes:

> Thanks for the link, haven't seen that page before.
>
> Most packages on that page don't do what project-buffers.el does.
>
> Projectile almost does, but it doesn't have a per-project version of
> next-buffer and previous-buffer, which was probably the main reason I
> wrote project-buffers.el.

You could have contributed two new commands to projectile, no?

Re: [ANN] project-buffers.el

[Steven Degutis]

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

I didn't realize Projectile had similar functionality until after I had
written project-buffers.el in the first place. And I probably wouldn't have
noticed, because I didn't realize that what I needed was similar to
Projectile until after `next-buffer-in-project` and
`previous-buffer-in-project` were written, because those were the two
functions I really wanted, and the functions `switch-project` and
`close-buffers-in-project` came afterwards due to a realization that they
would be really easy. Once those were written, it became more obvious that
what I had was similar to Projectile.

But now that I look at Projectile, I think it does Too Many Things™. For
example, to find a file in my project, I use find-file-in-repository
(MELPA) which does just one thing and does it extremely well. For running
tests in my project there are other utilities that do this too, same for
TAG files, grep, etc.

-Steven


On Mon, Apr 1, 2013 at 10:40 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> Steven Degutis <sbdegutis@gmail.com> writes:
>
> > Thanks for the link, haven't seen that page before.
> >
> > Most packages on that page don't do what project-buffers.el does.
> >
> > Projectile almost does, but it doesn't have a per-project version of
> > next-buffer and previous-buffer, which was probably the main reason I
> > wrote project-buffers.el.
>
> You could have contributed two new commands to projectile, no?
>

[-- Attachment #2: Type: text/html, Size: 1928 bytes --]

RE: [ANN] project-buffers.el

[Drew Adams]

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

Consider mentioning your library on that wiki project-category page.
 
Maybe consider also renaming your library, since there is another, older one
there whose name is very similar: project-buffer-mode.el
(http://www.emacswiki.org/emacs/ProjectBufferMode). Renaming might help people
distinguish the two and find each one easier.

I didn't realize Projectile had similar functionality until after I had written
project-buffers.el in the first place. And I probably wouldn't have noticed,
because I didn't realize that what I needed was similar to Projectile until
after `next-buffer-in-project` and `previous-buffer-in-project` were written,
because those were the two functions I really wanted, and the functions
`switch-project` and `close-buffers-in-project` came afterwards due to a
realization that they would be really easy. Once those were written, it became
more obvious that what I had was similar to Projectile. 

But now that I look at Projectile, I think it does Too Many ThingsT. For
example, to find a file in my project, I use find-file-in-repository (MELPA)
which does just one thing and does it extremely well. For running tests in my
project there are other utilities that do this too, same for TAG files, grep,
etc.


> Thanks for the link, haven't seen that page before.
> Most packages on that page don't do what project-buffers.el does.
> Projectile almost does, but it doesn't have a per-project version of
> next-buffer and previous-buffer, which was probably the main reason I
> wrote project-buffers.el.

You could have contributed two new commands to projectile, no?


[-- Attachment #2: Type: text/html, Size: 2827 bytes --]