bug#2887: Suggestions for simple.el

[Arni Magnusson <arnima@hafro.is>]

>> `backward-delete-word'
>> `delete-word'
>
> 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.



>> `pos-at-beginning-of-line'
>> `pos-at-end-of-line'
>
> 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."
   (interactive)
   (require 'newcomment)
   (if (and mark-active transient-mark-mode)
       (comment-region
        (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',

       (comment-region
        (region-beginning)
        (region-end))

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.



>> `delete-all-blank-lines'
>
> 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.


Cheers,

Arni