[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#2887: Suggestions for simple.el

From: Arni Magnusson
Subject: bug#2887: Suggestions for simple.el
Date: Sun, 19 Apr 2009 01:13:05 +0000 (GMT)


I would only consider some general "kill-next-kill" feature which would allow to turn any killing command into a deleting one (e.g. a kill-next-kill command which would cause the subsequent commands's effect on the kill-ring to be cancelled).

This would mean two keystrokes to delete a word, right? First `kill-next-kill' and then `kill-word'. It's an idea, but I still believe that many users would appreciate binding single keystrokes to the functions I suggested. They would most likely bind them to C-backspace and C-delete.


The reimplementation doesn't change anything: its performance will still suck on large files. It's just fundamentally an operation that is slow and that we should generally avoid, so I don't want to add yet more ways (additionally to goto-line) to do that.

I don't understand, I think these functions are blazing fast. In practice, I would probably not use Emacs to perform 100,000 iterations on a 200 MB file - but that's why I'm surprised to see that it takes less than a second:

  100000 M-x benchmark (pos-at-end-of-line 10)  ; 0.421s

I'm using a small arg of 10, because that's the case where you predicted that `line-end-position' would be much faster.

  100000 M-x benchmark (line-end-position 10)  ; 0.220s

This is necessarily faster, since `pos-at-end-of-line' calls `line-end-position', but the (save-excursion (goto-char (point-min)) overhead is not as great as one might expect.

With few iterations and large arg, the speed is also comparable:

  10 M-x benchmark (pos-at-end-of-line 100000)  ; 0.156s
  10 M-x benchmark (line-end-position 100000)   ; 0.156s

Most things become more sluggish with a 200 MB file. Overall, I think these functions make it considerably easier to read and write functions that operate on buffer text - with minimal performance cost. In practice, I use it without iteration, and with a 1 MB source code file it doesn't register in a benchmark (0.000000s).

I hesitate to introduce another function to the discussion, but here's an example where I use `pos-at-beginning-of-line' and `pos-at-end-of-line'. Since you're the maintainer of newcomment.el, it might pique your interest:

(defun comment-line-or-region ()
  "Comment line or region."
  (require 'newcomment)
  (if (and mark-active transient-mark-mode)
       (pos-at-beginning-of-line (line-number-at-pos (region-beginning)))
       (pos-at-end-of-line (line-number-at-pos (region-end))))
    (comment-region (line-beginning-position)(line-end-position))))

Same idea as `kill-line-or-region'. Without the `pos-at-beginning-of-line' and `pos-at-end-of-line',


it would misbehave when the region consists of a partially selected first and/or last line. Someone like you might be able to improve this function, but it's served me well and has no discernible speed lag.


Can someone figure out a way to tweak flush-lines such that it can be used for that purpose without having to jump through as many hooks? Maybe we can just say that if you call flush-lines with an empty argument (which currently would flush *all* lines) it will flush all empty lines.

This is definitely an idea, making better use of the default value of the regexp. But do you really mean flush all empty lines, or just the empty lines below the point? The idea behind `delete-all-blank-lines' is to really delete all empty lines, without moving the point, in one keystroke. I could probably edit `flush-lines' to do exactly that, although it operates only on text after the point for non-default regexps.

Phew, it looks like the rest of our discussion threads have closed successfully, meaning that we have fully understood each others' ideas, and the decisions will depend on your good judgement and the Emacs elders.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]