[ELPA] New package: loccur

[ELPA] New package: loccur

[Alexey Veretennikov]

Hi,

I would like to contribute my package loccur
(https://github.com/fourier/loccur) to the GNU ELPA. It is basically
something in between keep-lines and occur: provides the same
functionality as occur but without creating a new buffer/window. It
works great to quickly navigate in the file.
See the animated gifs on how it looks like in work in the link above.

People already use it for quite a while (first time I submitted it to
sourceforge in 2009, then moved to github), so it could be of interest at
least for a few people.

It had one non-trivial contributor except of me, but I was not able to
get his response on copyright papers so I wiped the code out and
rewritten it.

I have my FSF papers signed.

-- 
Br,
/Alexey

Re: [ELPA] New package: loccur

[John Wiegley]

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

>>>>> Alexey Veretennikov <alexey.veretennikov@gmail.com> writes:

> People already use it for quite a while (first time I submitted it to
> sourceforge in 2009, then moved to github), so it could be of interest at
> least for a few people.

> It had one non-trivial contributor except of me, but I was not able to get
> his response on copyright papers so I wiped the code out and rewritten it.

This is great, Alekey, I'd love to include this in ELPA. I'll get this
included this week, since I need to go through this process myself.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

Re: [ELPA] New package: loccur

[Alexey Veretennikov]

John Wiegley <jwiegley@gmail.com> writes:

Great!

I'll have to update header copyrights though; I haven't updated them
because it is not a part of Emacs yet. I'll update them as soon as I'll
get a good to go from you.


>>>>>> Alexey Veretennikov <alexey.veretennikov@gmail.com> writes:
>
>> People already use it for quite a while (first time I submitted it to
>> sourceforge in 2009, then moved to github), so it could be of interest at
>> least for a few people.
>
>> It had one non-trivial contributor except of me, but I was not able to get
>> his response on copyright papers so I wiped the code out and rewritten it.
>
> This is great, Alekey, I'd love to include this in ELPA. I'll get this
> included this week, since I need to go through this process myself.

-- 
Br,
/Alexey

Re: [ELPA] New package: loccur

[Marcin Borkowski]

On 2015-12-30, at 22:08, Alexey Veretennikov <alexey.veretennikov@gmail.com> wrote:

> Hi,

Hi,

this looks very interesting!  I already use Swiper, which gives
a similar functionality, but yours is different in that it does not
create another window.

Any reason to go into Elpa and not core, btw?

Best,

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

Re: [ELPA] New package: loccur

[John Wiegley]

>>>>> Marcin Borkowski <mbork@mbork.pl> writes:

> Any reason to go into Elpa and not core, btw?

Packages which core does not depend on go into ELPA.  More things will go into
ELPA in future, so we're starting that trend now.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] New package: loccur

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> Packages which core does not depend on go into ELPA.  More things will
> go into ELPA in future, so we're starting that trend now.

Speaking of which, should the "async" package go into core, perhaps?
There are packages which depend on it...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [ELPA] New package: loccur

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Speaking of which, should the "async" package go into core, perhaps? There
> are packages which depend on it...

We were thinking about having a "core ELPA", which allows for packages in ELPA
that core can still depend on.

That said, I do think async belongs in core.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] New package: loccur

[Artur Malabarba]

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

On 30 Dec 2015 7:39 pm, "John Wiegley" <jwiegley@gmail.com> wrote:
>
> That said, I do think async belongs in core.

What about "Packages which core does not depend on go into ELPA."? :-)

I've nothing against async. Just trying to understand our guidelines (and
when do we bend them).

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

Re: [ELPA] New package: loccur

[John Wiegley]

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

> What about "Packages which core does not depend on go into ELPA."? :-)

I have a feeling some core packages will decide to depend on async. I can see
Gnus and smtpmail and dired and several others using it, as they already do in
extension modules for those packages out on the Web.

However, until the dependency actually exists in Emacs core, I'd be fine with
it being in ELPA. It should properly go into ELPA until the day when the rest
of core needs it not to be.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] New package: loccur

[CHENG Gao]

*On Wed, 30 Dec 2015 13:29:24 -0800
* Also sprach John Wiegley <jwiegley@gmail.com>:

>>>>>> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Any reason to go into Elpa and not core, btw?
>
> Packages which core does not depend on go into ELPA. More things will
> go into ELPA in future, so we're starting that trend now.

I like this trend.

Just a little curious about definition of "core".
It means files under lisp/emacs-lisp/ and lisp/?
Grep shows several under lisp/emacs-lisp/ and many under lisp/ do
(featurep 'xemacs) check. Are they necessary still? I understand
standalone packages supporting both Emacs and Xemacs need this, but
these files I wonder.

And that'll be good if files under lisp/ be categorized under subdirs
suck as core/, util/ etc. Just my wish.

Re: [ELPA] New package: loccur

[Michael Albinus]

CHENG Gao <chenggao@royau.me> writes:

> Just a little curious about definition of "core".
> It means files under lisp/emacs-lisp/ and lisp/?
> Grep shows several under lisp/emacs-lisp/ and many under lisp/ do
> (featurep 'xemacs) check. Are they necessary still? I understand
> standalone packages supporting both Emacs and Xemacs need this, but
> these files I wonder.

There are packages developped outside Emacs git, and synced from time to
time. They still need such checks for XEmacs.

However, there are signs that Tramp and Gnus will get rid of the XEmacs
compat code.

Best regards, Michael.

Re: [ELPA] New package: loccur

[CHENG Gao]

*On Thu, 31 Dec 2015 09:49:48 +0100
* Also sprach Michael Albinus <michael.albinus@gmx.de>:

> CHENG Gao <chenggao@royau.me> writes:
>
>> Just a little curious about definition of "core". It means files
>> under lisp/emacs-lisp/ and lisp/? Grep shows several under
>> lisp/emacs-lisp/ and many under lisp/ do (featurep 'xemacs) check.
>> Are they necessary still? I understand standalone packages
>> supporting both Emacs and Xemacs need this, but these files I
>> wonder.
>
> There are packages developped outside Emacs git, and synced from time
> to time. They still need such checks for XEmacs.
>
> However, there are signs that Tramp and Gnus will get rid of the
> XEmacs compat code.
>
> Best regards, Michael.

Thank you Michael for your explanation.

Some day, there will be one the only Emacs. Some day......

Re: [ELPA] New package: loccur

[Rasmus]

Michael Albinus <michael.albinus@gmx.de> writes:

> CHENG Gao <chenggao@royau.me> writes:
>
>> Just a little curious about definition of "core".
>> It means files under lisp/emacs-lisp/ and lisp/?
>> Grep shows several under lisp/emacs-lisp/ and many under lisp/ do
>> (featurep 'xemacs) check. Are they necessary still? I understand
>> standalone packages supporting both Emacs and Xemacs need this, but
>> these files I wonder.
>
> There are packages developped outside Emacs git, and synced from time to
> time. They still need such checks for XEmacs.
>
> However, there are signs that Tramp and Gnus will get rid of the XEmacs
> compat code.

AFAIK, Org is dropping XEmacs support as well, mainly because none of the
regular developers are using it.

Rasmus

-- 
I hear there's rumors on the, uh, Internets. . .

Re: [ELPA] New package: loccur

[Juri Linkov]

> I would like to contribute my package loccur
> (https://github.com/fourier/loccur) to the GNU ELPA. It is basically
> something in between keep-lines and occur: provides the same
> functionality as occur but without creating a new buffer/window.

A better analogy to describe your package is narrowing
to non-contiguous regions with boundaries of matching lines
(not sure wherether this feature should be added into core).

Re: [ELPA] New package: loccur

[daniel sutton]

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

hi. had a question about the code.

I'm not familiar with this notation and was wondering if anyone could chime
in with an explanation:
(define-key global-map [(control o)] 'loccur-current)

and then you have the following line
             (let ((ovl-start (if (= prev-end 1) 1 prev-end))...)
where it seems like ovl-start is always equal to prev-end?

Just trying t ounderstand these parts but otherwise the package looks
amazing and I've already incorporated it into my emacs. thanks so much for
sharing


On Wed, Dec 30, 2015 at 6:30 PM, Juri Linkov <juri@linkov.net> wrote:

> > I would like to contribute my package loccur
> > (https://github.com/fourier/loccur) to the GNU ELPA. It is basically
> > something in between keep-lines and occur: provides the same
> > functionality as occur but without creating a new buffer/window.
>
> A better analogy to describe your package is narrowing
> to non-contiguous regions with boundaries of matching lines
> (not sure wherether this feature should be added into core).
>
>

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

Re: [ELPA] New package: loccur

[Alexey Veretennikov]

daniel sutton <danielsutton01@gmail.com> writes:
Hi,

Thanks for noticing this. It is a redundant code (ovl-start) of course
and I've just removed it.

> hi. had a question about the code.
>
> I'm not familiar with this notation and was wondering if anyone could chime in
> with an explanation:
> (define-key global-map [(control o)] 'loccur-current)
>
> and then you have the following line
> (let ((ovl-start (if (= prev-end 1) 1 prev-end))...)
> where it seems like ovl-start is always equal to prev-end?
>
> Just trying t ounderstand these parts but otherwise the package looks amazing
> and I've already incorporated it into my emacs. thanks so much for sharing
>
> On Wed, Dec 30, 2015 at 6:30 PM, Juri Linkov <juri@linkov.net> wrote:
>
>     > I would like to contribute my package loccur
>     > (https://github.com/fourier/loccur) to the GNU ELPA. It is basically
>     > something in between keep-lines and occur: provides the same
>     > functionality as occur but without creating a new buffer/window.
>     
>     A better analogy to describe your package is narrowing
>     to non-contiguous regions with boundaries of matching lines
>     (not sure wherether this feature should be added into core).
>     
>     
>
>

-- 
Br,
/Alexey