Background information;
I'm looking for some automated features to help with the mechanics of
Lisp. I found it somewhat difficult to keep track of things like
matching parens and depth of nested functions just by "eyeball".
mic-paren seems to have its heart in the right place, but doesn't
really give enough detailed clues
about the structure of (even) my rudimentary defun.
eg. Code snippet
--------------------------------------------------------------------------------------------------
(defun reform-synplify-log () ;;
;;
(let (
(msg-regexp-buffer "filter.txt");; (buffer-name) ;; Warning
Will Robinson wrt parens within comments -> right of ; default msg-
regexp-buffer
(log-buffer "diamond_warnings.txt")
;; (tiger 'fierce) ;; other non stringp local variables
;; pine ;; default to nil
(regexp-begin 1)
(regexp-end 178)
(regexp-string nil)
(file-name-begin 1)
(file-name-end 32)
(file-name-string nil)
(regexp-replace-begin 1)
(regexp-replace-end 256)
(regexp-replace-string nil)
(sort-begin-found nil) ;; toggle for re-search-forward replace-
match to find "intelligent" start for sorting
(sort-begin 1) ;; sort starting location
(msg-type-count 2) ;; how many different msg types (regexps)?
)
;;(interactive "b\nbuffer w/synplify log filter regexps:") ;; "b
\nsynplify log buffer: " "b\nbuffer of log msg regexp " "p" "b\nbuffer
of idass verilog: " QUOTED RIGHT PAREN!
(if (not (bufferp log-buffer)) ; if only bound to buffer
name (not to buffer itself), could use or ... [finds first t]
(setq log-buffer (get-buffer log-buffer))) ; then bind to buffer
(if (not (bufferp msg-regexp-buffer)) ; if only bound to
buffer name (not to buffer itself), could use or ... [finds first t]
(setq msg-regexp-buffer (get-buffer msg-regexp-buffer))) ; then
bind to buffer
(set-buffer msg-regexp-buffer)
(with-current-buffer msg-regexp-buffer ;; init point to top of msg-
regexp-buffer
(goto-char (point-min)) ;;
)
(while not (zerop msg-type-count)
(with-current-buffer msg-regexp-buffer ;; get regexp(s) to run occur.
[value rtn'd from last form in body]
(setq regexp-begin (point)) ;; occur takes (buffer-substring-no-
properties BEG END), no need to copy regexp to (kill ring)
(set-mark-command nil) ;; set mark - for highlighting only.
(move-end-of-line nil) ;; end of line
(setq regexp-end (point))
;; (kill-ring-save regexp-begin regexp-end) ;; conveniently put
regexp on kill-ring
(setq regexp-string (buffer-substring-no-properties regexp-begin (+ 1
regexp-end))) ;; occur and search regexp
(forward-line 1)
(file-name-begin (point))
(move-end-of-line nil) ;; end of line
(file-name-end (point))
(setq file-name-string (buffer-substring-no-properties file-name-
begin (+ 1 file-name-end))) ;; output filename
(forward-line 1)
(regexp-replace-begin (point))
(move-end-of-line nil) ;; end of line
(regexp-replace-end (point))
(setq regexp-replace-string (buffer-substring-no-properties regexp-
replace-begin (+ 1 regexp-replace-end))) ;; replace regexp
)
(set-buffer log-buffer)
(occur regexp-string)
(set-buffer "*Occur*")
(write-file file-name-string) ;; save it (to make it R/W) (while (re-
search-forward REGEXP nil t) (replace-match TO-STRING nil nil))
;; save it (to make it R/W) (while (re-search-forward REGEXP
nil t) (match-string Nth_substring_match)...)
;; lispref pgs 587, 592
(goto-char (point-min))
;; (setq occur-begin (point))
(while (re-search-forward regexp-string nil t)
(
(if not (sort-begin-found) ;; toggle
(setq sort-begin (match-begining)) (setq sort-begin-found t)
)
(replace-match regexp-replace-string nil nil)
)
)
;; (mark-whole-buffer) ;; for sorting
;; (goto-char (point-max))
;; (setq occur-end (point))
;; (sort-numeric-fields 2 occur-begin occur-end) ;; fix this to start
at better place in *occur*
(sort-numeric-fields 2 sort-begin (point-max)) ;; fixed this to start
at better place in *occur*
(write-file file-name-string) ;; save it
;; any more regexp(s)?
(+ msg-type-count -1)
(or (zerop msg-type-count)
(with-current-buffer msg-regexp-buffer ;; forward-line to next regexp
if not last
(forward-line 1) ;; next regexp for occur
)
)
)
)
)
end Code snippet
--------------------------------------------------------------------------------------------------
I followed the suggestions given at
http://stackoverflow.com/questions/898287/how-can-i-spot-subtle-lisp-syntax-mistakes
but the feedback displayed in the buffer of interest/minibuffer when
using those packages
doesn't seem very well integrated.
Highlighted cues about particular parens are only displayed as one
moves point to the specific opening/closing paren and only transient
messages about the matching paren appear in the minibuffer when the
matching paren is beyond viewing range. So cues are only shown one at
a time and the display of the cue doesn't even persist!
Now my actual comments/questions;
-----------------------------------------------
I "read the fine manual" (lispref) from xemacs.org trying to get a
few ideas (Secs 45.9,10,11 look interesting).
With my limited knowledge of how Xemacs stores and displays internal
structures (esp buffers),
perhaps it's possible to modify the displayed content of each paren to
show the literal paren glyph and to persistently display additional
annotation (adjacent to each one) showing some concise cues about the
structure and nesting of the functions.
Can one dynamically change the display table entries depending upon
the sequence of (opening/closing) parens located in the buffer?
Hopefully leading to annotating each paren with a
useful (generally different) cue. Maybe this is akin to an 'outline'
or skeletal view?
Just fodder for thought. Thanks in advance for any and all comments!