unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* uniq
@ 2010-12-04  2:41 Tak Ota
  2010-12-04 12:08 ` uniq Stephen Berman
  0 siblings, 1 reply; 5+ messages in thread
From: Tak Ota @ 2010-12-04  2:41 UTC (permalink / raw)
  To: emacs-devel

Do we have something equivalent to the next command?  I know the name
is bad as it is not same as UNIQ(1).  It works better because sorting
is not required.

-Tak

;;
;; uniq
;;
(defun uniq ()
  "Omit duplicated lines."
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (while (not (= (point) (point-max)))
      (let* ((start (point))
	     (str (format "^%s"
			  (regexp-quote
			   (buffer-substring start
					     (progn (forward-line 1) (point)))))))
	(save-excursion
	  (while (re-search-forward str nil t)
	    (delete-region (match-beginning 0) (match-end 0))))))))




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

* Re: uniq
  2010-12-04  2:41 uniq Tak Ota
@ 2010-12-04 12:08 ` Stephen Berman
  2010-12-04 14:09   ` uniq Stefan Monnier
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Berman @ 2010-12-04 12:08 UTC (permalink / raw)
  To: emacs-devel

On Fri, 3 Dec 2010 18:41:12 -0800 Tak Ota <Takaaki.Ota@am.sony.com> wrote:

> Do we have something equivalent to the next command?  I know the name
> is bad as it is not same as UNIQ(1).  It works better because sorting
> is not required.
>
> -Tak
>
> ;;
> ;; uniq
> ;;
> (defun uniq ()
>   "Omit duplicated lines."
>   (interactive)
>   (save-excursion
>     (goto-char (point-min))
>     (while (not (= (point) (point-max)))
>       (let* ((start (point))
> 	     (str (format "^%s"
> 			  (regexp-quote
> 			   (buffer-substring start
> 					     (progn (forward-line 1) (point)))))))
> 	(save-excursion
> 	  (while (re-search-forward str nil t)
> 	    (delete-region (match-beginning 0) (match-end 0))))))))

Would it be faster to avoid nested while-loops?

(defun uniq ()
  "Omit duplicated lines."
  (interactive)
  (let (lines)
    (save-excursion
      (goto-char (point-min))
      (while (not (eobp))
	(let* ((beg (line-beginning-position))
	       (end (line-end-position))
	       (line (buffer-substring beg end)))
	  (if (member line lines)
	      (delete-region beg (1+ end))
	    (push line lines)
	    (forward-line)))))))

Steve Berman




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

* Re: uniq
  2010-12-04 12:08 ` uniq Stephen Berman
@ 2010-12-04 14:09   ` Stefan Monnier
  2010-12-05 18:54     ` uniq René Kyllingstad
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2010-12-04 14:09 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

> Would it be faster to avoid nested while-loops?

Not sure if `member' is faster than `re-search-forward', but if you
replace re-search-forward with just search-forward (which requires
a bit more care since you need to manually check that matches are
anchored at bol and eol) I'm pretty sure that'll be even faster since it
will then use a more efficient search algorithm that gets faster the
longer the line of text you're looking for.


        Stefan



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

* Re: uniq
  2010-12-04 14:09   ` uniq Stefan Monnier
@ 2010-12-05 18:54     ` René Kyllingstad
  2010-12-05 19:15       ` uniq Lennart Borgman
  0 siblings, 1 reply; 5+ messages in thread
From: René Kyllingstad @ 2010-12-05 18:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Stephen Berman, emacs-devel

On Sat, Dec 4, 2010 at 3:09 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Would it be faster to avoid nested while-loops?
>
> Not sure if `member' is faster than `re-search-forward', but if you
> replace re-search-forward with just search-forward (which requires
> a bit more care since you need to manually check that matches are
> anchored at bol and eol) I'm pretty sure that'll be even faster since it
> will then use a more efficient search algorithm that gets faster the
> longer the line of text you're looking for.

Even better, use a hash table to keep the already seen lines. Maybe
call it delete-duplicate-lines, similar to delete-matching-lines.


-- René



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

* Re: uniq
  2010-12-05 18:54     ` uniq René Kyllingstad
@ 2010-12-05 19:15       ` Lennart Borgman
  0 siblings, 0 replies; 5+ messages in thread
From: Lennart Borgman @ 2010-12-05 19:15 UTC (permalink / raw)
  To: René Kyllingstad; +Cc: Stephen Berman, Stefan Monnier, emacs-devel

2010/12/5 René Kyllingstad <listmailemacs@kyllingstad.com>:
> On Sat, Dec 4, 2010 at 3:09 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> Would it be faster to avoid nested while-loops?
>>
>> Not sure if `member' is faster than `re-search-forward', but if you
>> replace re-search-forward with just search-forward (which requires
>> a bit more care since you need to manually check that matches are
>> anchored at bol and eol) I'm pretty sure that'll be even faster since it
>> will then use a more efficient search algorithm that gets faster the
>> longer the line of text you're looking for.
>
> Even better, use a hash table to keep the already seen lines. Maybe
> call it delete-duplicate-lines, similar to delete-matching-lines.

Or maybe using a schwarzian transform to sort only line numbers and
then from this list just delete duplicates (moving backwards).



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

end of thread, other threads:[~2010-12-05 19:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-04  2:41 uniq Tak Ota
2010-12-04 12:08 ` uniq Stephen Berman
2010-12-04 14:09   ` uniq Stefan Monnier
2010-12-05 18:54     ` uniq René Kyllingstad
2010-12-05 19:15       ` uniq Lennart Borgman

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