unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [ELPA] New package: loccur
@ 2015-12-30 21:08 Alexey Veretennikov
  2015-12-30 21:10 ` John Wiegley
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Alexey Veretennikov @ 2015-12-30 21:08 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:08 [ELPA] New package: loccur Alexey Veretennikov
@ 2015-12-30 21:10 ` John Wiegley
  2015-12-30 23:27   ` Alexey Veretennikov
  2015-12-30 21:22 ` Marcin Borkowski
  2015-12-31  0:30 ` Juri Linkov
  2 siblings, 1 reply; 16+ messages in thread
From: John Wiegley @ 2015-12-30 21:10 UTC (permalink / raw)
  To: Alexey Veretennikov; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:08 [ELPA] New package: loccur Alexey Veretennikov
  2015-12-30 21:10 ` John Wiegley
@ 2015-12-30 21:22 ` Marcin Borkowski
  2015-12-30 21:29   ` John Wiegley
  2015-12-31  0:30 ` Juri Linkov
  2 siblings, 1 reply; 16+ messages in thread
From: Marcin Borkowski @ 2015-12-30 21:22 UTC (permalink / raw)
  To: Alexey Veretennikov; +Cc: emacs-devel



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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:22 ` Marcin Borkowski
@ 2015-12-30 21:29   ` John Wiegley
  2015-12-30 21:32     ` Lars Magne Ingebrigtsen
  2015-12-31  5:57     ` CHENG Gao
  0 siblings, 2 replies; 16+ messages in thread
From: John Wiegley @ 2015-12-30 21:29 UTC (permalink / raw)
  To: Marcin Borkowski; +Cc: Alexey Veretennikov, emacs-devel

>>>>> 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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:29   ` John Wiegley
@ 2015-12-30 21:32     ` Lars Magne Ingebrigtsen
  2015-12-30 21:39       ` John Wiegley
  2015-12-31  5:57     ` CHENG Gao
  1 sibling, 1 reply; 16+ messages in thread
From: Lars Magne Ingebrigtsen @ 2015-12-30 21:32 UTC (permalink / raw)
  To: Marcin Borkowski; +Cc: Alexey Veretennikov, emacs-devel

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:32     ` Lars Magne Ingebrigtsen
@ 2015-12-30 21:39       ` John Wiegley
  2015-12-30 22:41         ` Artur Malabarba
  0 siblings, 1 reply; 16+ messages in thread
From: John Wiegley @ 2015-12-30 21:39 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: Alexey Veretennikov, emacs-devel

>>>>> 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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:39       ` John Wiegley
@ 2015-12-30 22:41         ` Artur Malabarba
  2015-12-31  0:20           ` John Wiegley
  0 siblings, 1 reply; 16+ messages in thread
From: Artur Malabarba @ 2015-12-30 22:41 UTC (permalink / raw)
  To: emacs-devel, Alexey Veretennikov, Lars Magne Ingebrigtsen,
	Marcin Borkowski

[-- 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 --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:10 ` John Wiegley
@ 2015-12-30 23:27   ` Alexey Veretennikov
  0 siblings, 0 replies; 16+ messages in thread
From: Alexey Veretennikov @ 2015-12-30 23:27 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 22:41         ` Artur Malabarba
@ 2015-12-31  0:20           ` John Wiegley
  0 siblings, 0 replies; 16+ messages in thread
From: John Wiegley @ 2015-12-31  0:20 UTC (permalink / raw)
  To: Artur Malabarba; +Cc: Lars Magne Ingebrigtsen, Alexey Veretennikov, emacs-devel

>>>>> 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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:08 [ELPA] New package: loccur Alexey Veretennikov
  2015-12-30 21:10 ` John Wiegley
  2015-12-30 21:22 ` Marcin Borkowski
@ 2015-12-31  0:30 ` Juri Linkov
  2015-12-31  3:14   ` daniel sutton
  2 siblings, 1 reply; 16+ messages in thread
From: Juri Linkov @ 2015-12-31  0:30 UTC (permalink / raw)
  To: Alexey Veretennikov; +Cc: emacs-devel

> 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).



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-31  0:30 ` Juri Linkov
@ 2015-12-31  3:14   ` daniel sutton
  2015-12-31 12:49     ` Alexey Veretennikov
  0 siblings, 1 reply; 16+ messages in thread
From: daniel sutton @ 2015-12-31  3:14 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Alexey Veretennikov, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-30 21:29   ` John Wiegley
  2015-12-30 21:32     ` Lars Magne Ingebrigtsen
@ 2015-12-31  5:57     ` CHENG Gao
  2015-12-31  8:49       ` Michael Albinus
  1 sibling, 1 reply; 16+ messages in thread
From: CHENG Gao @ 2015-12-31  5:57 UTC (permalink / raw)
  To: emacs-devel

*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.




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-31  5:57     ` CHENG Gao
@ 2015-12-31  8:49       ` Michael Albinus
  2015-12-31  9:36         ` CHENG Gao
  2015-12-31 14:38         ` Rasmus
  0 siblings, 2 replies; 16+ messages in thread
From: Michael Albinus @ 2015-12-31  8:49 UTC (permalink / raw)
  To: CHENG Gao; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-31  8:49       ` Michael Albinus
@ 2015-12-31  9:36         ` CHENG Gao
  2015-12-31 14:38         ` Rasmus
  1 sibling, 0 replies; 16+ messages in thread
From: CHENG Gao @ 2015-12-31  9:36 UTC (permalink / raw)
  To: emacs-devel

*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......




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-31  3:14   ` daniel sutton
@ 2015-12-31 12:49     ` Alexey Veretennikov
  0 siblings, 0 replies; 16+ messages in thread
From: Alexey Veretennikov @ 2015-12-31 12:49 UTC (permalink / raw)
  To: daniel sutton; +Cc: emacs-devel, Juri Linkov

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [ELPA] New package: loccur
  2015-12-31  8:49       ` Michael Albinus
  2015-12-31  9:36         ` CHENG Gao
@ 2015-12-31 14:38         ` Rasmus
  1 sibling, 0 replies; 16+ messages in thread
From: Rasmus @ 2015-12-31 14:38 UTC (permalink / raw)
  To: emacs-devel

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. . .




^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2015-12-31 14:38 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-30 21:08 [ELPA] New package: loccur Alexey Veretennikov
2015-12-30 21:10 ` John Wiegley
2015-12-30 23:27   ` Alexey Veretennikov
2015-12-30 21:22 ` Marcin Borkowski
2015-12-30 21:29   ` John Wiegley
2015-12-30 21:32     ` Lars Magne Ingebrigtsen
2015-12-30 21:39       ` John Wiegley
2015-12-30 22:41         ` Artur Malabarba
2015-12-31  0:20           ` John Wiegley
2015-12-31  5:57     ` CHENG Gao
2015-12-31  8:49       ` Michael Albinus
2015-12-31  9:36         ` CHENG Gao
2015-12-31 14:38         ` Rasmus
2015-12-31  0:30 ` Juri Linkov
2015-12-31  3:14   ` daniel sutton
2015-12-31 12:49     ` Alexey Veretennikov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).