Re: Help improving an elisp function

[Emanuel Berg <embe8573@student.uu.se>]

Glen Stark <mail@glenstark.net> writes:

> But it's pretty awful. What I'd really like to do is
> have one function that looks up the buffer-name in
> question, and inserts the include statement, without
> jumping there.

You are exactly right the problem is the user-level
mucking around with the buffers. I could help you with
that but I don't get the ggtags to work right away and
as I never felt the need for that unless you provide
me with step by step instructions I'll leave it
at that.

But: for all on-the-top user-level mucking around with
buffers there are the equivalents to do that below
where it isn't noticed, so you should find
those equivalents.

Also, the byte compiler (see the Emacs man page) can
help you with some bad habits - often it tells you
what you should use as well, and the buffer issue is
one where the compiler is strict :)

But... as for your problem, in principle it is
absolutely correct to automatize the workflow, however
in this case if you do any amount of C++ henceforth
you will very rapidly not need this anyway, because
you will know where stuff is and putting the includes
in place manually won't bother you.

So what you do is over-engineering, but we will of
course help you nonetheless if you continue to post.

> (require ggtags)

(require 'ggtags)

> (setq gas-cpp-include-path)

Better than a global variable is a `let' in the
function where it belongs (i.e., is used):

    (let ((gas-cpp-include-path ...)
          (other-var ...))
      ; do stuff with the vars
      )

> (defun find-what-provides ()
>   (interactive)
>   (ggtags-find-definition (thing-at-point `symbol))
>   )

No need to backtick "symbol", (thing-at-point 'symbol)
is fine.

> (defun insert-missing-include ()
>   (interactive)
>   (setq gas-cpp-include-path (buffer-file-name))
>   (kill-buffer)
>   (beginning-of-buffer)
>   (while (re-search-forward "#include \".*\"" nil t))
>   (insert (concat "\n#include \""
> 				  (file-name-nondirectory gas-cpp-include-path)
> 				  "\"\n"))
>   )

Apart from what I mentioned - let, and the buffers -
I've found that `format' is more manageable than
`concat', especially when it gets complicated.
With format, you can specify the structure first,
which will communicate the purpose (to you), then you
only set up the data once (all to the right) and never
bother with it again:

    (format "purpose and structure" data_1 ... data_n)

> (global-set-key (kbd "<f9>") 'find-what-provides)
> (global-set-key (kbd "<f10>") 'insert-missing-include)

You can type those as [f9] instead of (kbd "<f9>") -
try evaluating it, if you are unsure!

But: Those keys aren't good. You don't want to let go
of your hands from the typing position, which is the
"asdf" and "jkl;" keys for the left and right hand,
respec... uhm, you get it. Tho seemingly as single key
is faster and easier and less error-prone than
a combination, that isn't so with time and practice if
the combination is close and short, because then the
"reach, find and reset" can be eliminated. Remember,
speed kills!

Good luck! Come back with more questions, of course.

-- 
underground experts united
http://user.it.uu.se/~embe8573