Help improving an elisp function

Help improving an elisp function

[Glen Stark]

Hi Everyone.

Still trying to reach journeyman level with elisp.  I've written a little 
something that helps my workflow, but it's pretty kludgy, and I'd like to 
get some feedback how to improve it.  The code below makes finding and 
inserting a missing include a lot easier:

F9:  goes to the definition (via ggtags) of thing-at-point.
F10: copies the buffer name, closes the buffer, and inserts the missing 
include file.

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.

Also, I had originally had the line (seq gas-cpp-include-path (buffer-
file-name)) in the find-what-provides function, but that wound up giving 
me the path to the buffer I was starting in, not the one that ggtags-find-
definition took me to.  Can someone let me know what's going on there?  
Is the buffer only being updated after the function exits?

Many thanks.  Here's the code:


(require ggtags)

(setq gas-cpp-include-path)
(defun find-what-provides ()
  (interactive)
  (ggtags-find-definition (thing-at-point `symbol))
  )

(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"))
  )

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

RE: Help improving an elisp function

[Doug Lewan]

> On
> Behalf Of Glen Stark
> Sent: Thursday, 2015 April 02 10:55
> To: help-gnu-emacs@gnu.org
> Subject: Help improving an elisp function
> 
> 
> 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.


It sounds like (with-current-buffer) is what you want to use
to avoid jumping to the other buffer.

> 
> Also, I had originally had the line (seq gas-cpp-include-path (buffer-
> file-name)) in the find-what-provides function, but that wound up
> giving
> me the path to the buffer I was starting in, not the one that ggtags-
> find-
> definition took me to.  Can someone let me know what's going on there?
> Is the buffer only being updated after the function exits?

You might want to look at (file-name-directory).
Use it in (find-what-provides) to build the path you want,
then use the new (find-what-provides) in M-x insert-missing-include.

> 
> Many thanks.  Here's the code:
> 
> 
> (require ggtags)
> 
> (setq gas-cpp-include-path)
> (defun find-what-provides ()
>   (interactive)
>   (ggtags-find-definition (thing-at-point `symbol))
>   )
> 
> (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"))
>   )
> 
> (global-set-key (kbd "<f9>") 'find-what-provides)
> (global-set-key (kbd "<f10>") 'insert-missing-include)

-- 
,Doug
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224 or ext 4335

The human brain is the most complex thing known to man, according to the human brain.

Re: Help improving an elisp function

[Emanuel Berg]

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

Re: Help improving an elisp function

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

() Glen Stark <mail@glenstark.net>
() Thu, 02 Apr 2015 14:54:59 GMT

     (insert (concat "\n#include \""
                     (file-name-nondirectory
                      gas-cpp-include-path)
                     "\"\n"))

You can replace ‘(insert (concat STRING1 ... STRINGN))’ with
‘(insert STRING1 ... STRINGN)’.  This you can discover for
yourself by typing ‘C-h f insert RET’ and noting "&rest ARGS" in
the resulting *Help* buffer.

-- 
Thien-Thi Nguyen -----------------------------------------------
  (if you're human and you know it) read my lisp:
    (defun responsep (type via)
      (case type
        (technical (eq 'mailing-list via))
        ...))
---------------------------------------------- GPG key: 4C807502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]