record-lisp.el - current status

record-lisp.el - current status

[yzhh]

Hi,

I've been quiet for some time. But I kept do some coding every day.
The more code I write, the more I find myself unfamiliar with emacs and
lisp. 

Well, record-lisp.el (if you remember) has now progressed. The following is
the code it generated after recording some of my operations. 

(defun recorded-commands (var2)
  "List of latest recorded commands."
  (interactive)
  (let (var3 var4 var7 (case-fold case-fold-search))
    (setq case-fold-search t)
;;; (setq var1 (point-marker)) ; (set-mark-command nil)
    (search-forward (concat "is" var2))
    (search-forward (concat "is" var2))
    (setq var3 (point-marker))          ; (set-mark-command nil)
    (forward-word 1)
    (forward-word nil)
    (setq var4 (buffer-substring-no-properties var3 (point))) ;
(cua-copy-region nil)
;;; (setq var5 (point-marker)) ; (set-mark-command nil)
    (end-of-buffer nil)
;;; (setq var6 (point-marker)) ; (set-mark-command nil)
    (insert var4)                       ; (yank nil)
    (setq var7 (point-marker))          ; (set-mark-command nil)
    (backward-char 2)
;;; (setq var8 (buffer-substring-no-properties var7 (point))) ;
(cua-copy-region nil)
    (forward-char 1)
    (setq case-fold-search case-fold)))

What I did is copy some string, start recording, start isearch, type 'is',
yank what I previously copied string into search string, search again, copy
the word after cursor, move to end of buffer, yank, copy another char, and
stop recording.

You can notice that yank something that is not copied(killed) during the
recording resulted in a argument 'var2' in the defun. And there are other
variables standing for the mark and copied strings. They are used to avoid
changing mark and kill-ring which is not encouraged in emacs lisp code.
Vars that's not used has corresponding code commented. These are the most
commonly needed behaviour, I think.

To further explain how customization of the generated code, please see the
following internal data I used.

The first is a vector of global options regarding the use of
variables -their name, constant values (recorded), and usage (as var, arg
or const), regarding defun name and doc string. All these can be changed,
to get a diffenret version of generated code.

The other is a list of 'code template', they represent the recorded commands
and references the variables in global options. Generated code come out of
this list.

(setq reclisp-global-options
      [(("var8" . ["var8" as-unused "h"])
        ("var7" . ["var7" as-var nil])
        ("var6" . ["var6" as-unused nil])
        ("var5" . ["var5" as-unused nil])
        ("var4" . ["var4" as-var "ch"])
        ("var3" . ["var3" as-var nil])
        ("var2" . ["var2" as-arg "ear"])
        ("var1" . ["var1" as-unused nil]))
       "recorded-commands"
       "List of latest recorded commands."])

(setq reclisp-code-template
      (((isearch-forward nil 1))
       ((isearch-printing-char))
       ((isearch-printing-char))
       ((isearch-yank-kill))
       ((isearch-repeat-forward))
       ((isearch-other-control-char nil))
       ((setq (reclisp-want-var-name "var1") (point-marker))
        (write-var . "var1")
        (orig-cmd set-mark-command nil))
       ((search-forward (concat "is"
(reclisp-want-var-name-or-value "var2")))
        (read-var . "var2"))
       ((search-forward (concat "is"
(reclisp-want-var-name-or-value "var2")))
        (read-var . "var2"))
       ((setq (reclisp-want-var-name "var3") (point-marker))
        (write-var . "var3")
        (orig-cmd set-mark-command nil))
       ((forward-word 1))
       ((forward-word nil))
       ((setq (reclisp-want-var-name "var4")
              (buffer-substring-no-properties
               (reclisp-want-var-name "var3")
               (point)))
        (write-var . "var4")
        (read-var . "var3")
        (orig-cmd cua-copy-region nil))
       ((setq (reclisp-want-var-name "var5") (point-marker))
        (write-var . "var5")
        (orig-cmd set-mark-command nil))
       ((end-of-buffer nil))
       ((setq (reclisp-want-var-name "var6") (point-marker))
        (write-var . "var6")
        (orig-cmd set-mark-command nil))
       ((insert (reclisp-want-var-name-or-value "var4"))
        (read-var . "var4")
        (orig-cmd yank nil))
       ((setq (reclisp-want-var-name "var7") (point-marker))
        (write-var . "var7")
        (orig-cmd set-mark-command nil))
       ((backward-char 2))
       ((setq (reclisp-want-var-name "var8")
              (buffer-substring-no-properties
               (reclisp-want-var-name "var7")
               (point)))
        (write-var . "var8")
        (read-var . "var7")
        (orig-cmd cua-copy-region nil))
       ((forward-char 1))))

I have not implemented a customization user interface yet, and I want
suggestions. Actually the recording is also incomplete - what's missing
include yank-in-minibuffer recording.


-- 
   regards,
yzhh

Re: record-lisp.el - current status

[yzhh]

I noticed these 2 lines are seperated into 4 lines by my email editor (at 80
columns). Actually the 2 cua-copy-region commands are in the comment of the
previous line.

>     (setq var4 (buffer-substring-no-properties var3 (point))) ;
> (cua-copy-region nil)
> ...
> ;;; (setq var8 (buffer-substring-no-properties var7 (point))) ;
> (cua-copy-region nil)

And I need feedback:
Does this approach miss anything important?
Any suggestion on the user interface that provide customization?

-- 
   regards,
yzhh

Re: record-lisp.el - current status

[Juri Linkov]

> And I need feedback:
> Does this approach miss anything important?
> Any suggestion on the user interface that provide customization?

I doubt that someone will want to customize the default conversion logic.
It is easier to fix the resulting Lisp code than to customize very complex
conversion rules.  I think we should try to find the most useful rules and
hard-code them.  When there is no clear preferable level of interactivity
to generate, then we could produce alternative Lisp code commented out in
the output, so the user could uncomment and use it if necessary.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: record-lisp.el - current status

[yzhh]

Juri Linkov wrote:

> I doubt that someone will want to customize the default conversion logic.
> It is easier to fix the resulting Lisp code than to customize very complex
> conversion rules.  I think we should try to find the most useful rules and
> hard-code them.  When there is no clear preferable level of interactivity
> to generate, then we could produce alternative Lisp code commented out in
> the output, so the user could uncomment and use it if necessary.

Sorry, I didn't make it clear that the default conversion IS now hard coded.
The customization I mentioned refers to one that's done just before
generation of code (on a per recording basis). It's meant to be simple but
capture the most differentiating points on what kind of code the user may
expect. In other words, the customization provides a better start point for
further modification with a little effort. The user has the choice to
directly  modify the default version though.

Currently I captures those points as variable usage: the user can choose to
use a variable (strings, mark, etc) as an argument to the defun, or as a
local variable, or as a constant (ie. not a var at all). This has the
convenience that multiple places referring to the same variable all change
accordingly at generation. For the same convenience I also provide var name
and constant value as customization options.

Maybe we need another phrase for the customization provided here, to avoid
misunderstandings.

-- 
   regards,
yzhh

Re: record-lisp.el - current status

[Juri Linkov]

> Currently I captures those points as variable usage: the user can choose to
> use a variable (strings, mark, etc) as an argument to the defun, or as a
> local variable, or as a constant (ie. not a var at all). This has the
> convenience that multiple places referring to the same variable all change
> accordingly at generation. For the same convenience I also provide var name
> and constant value as customization options.

Maybe you can find some subjective levels of details to generate in the
final Lisp code.  Then you can use one customizable user option with
a choice from a few levels.  Any more complex values might be difficult
for the user to customize.

-- 
Juri Linkov
http://www.jurta.org/emacs/