help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Making code more Emacs Lisp-like


From: Joseph Brenner
Subject: Re: Making code more Emacs Lisp-like
Date: Mon, 02 Nov 2009 12:05:51 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Sarir Khamsi <address@hidden> writes:

> I wrote this function
>
> (defun sk-convert-to-ctor-init-list ()
>   "Convert a C++ member variable declaration to a ctor init list line.
> To use this, copy all member variable declarations into the constructor's 
> member initialization list area and execute this command on each line. At the 
> end of this command, it moves you to the next line setting it up for a key 
> binding."
>   (interactive)
>   (save-excursion
>     (end-of-line)
>     (delete-horizontal-space)           ; delete whitespace at end of line
>     (backward-delete-char-untabify 1)   ; delete the ";"
>     (insert "(),")
>     (search-backward-regexp "[\t *]")     ; look for whitespace or "*"
>     (set-mark (+ (point) 1))              ; save the current position
>     (beginning-of-line)
>     (kill-region (point) (mark))
>     (c-indent-command))
>   (next-line 1))
>
> to take a region that containers C++ code for member variable
> declarations and convert it to a constructor's member init list. Is
> there a better (or a more ELisp) way than this approach? Thanks.

If you look up the Help screen for each function (using the default
bindings: cursor to the function, and do a "f1 f"), you'll often see
hints on better ways of doing things from inside of elisp.

For example, if you look up "set-mark", there's an example that's
easily adapted to what you're doing here:

>     (set-mark (+ (point) 1))              ; save the current position
>     (beginning-of-line)
>     (kill-region (point) (mark))

Would become:

   (let ((beg (point)))
      (beginning-of-line)
      (delete-region beg (point)))

The goal there is to avoid messing with the kill-ring or the mark
history if that's not necessary.  Otherwise you may surprise the
user with the unwanted side-effects.



reply via email to

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