Re: A lot of questions concerning `gnus-score-edit-file-at-point'

[sigurd@12move.de (Karl Pflästerer)]

On 29 Dec 2003, Reiner Steib <- 4.uce.03.r.s@nurfuerspam.de wrote:

> On Sun, Dec 28 2003, Karl Pflästerer wrote:

>> (a) Does anyone really use `gnus-score-edit-file-at-point' outside a
>>     *Score Trace* buffer?  If not the function could be written simpler.

> I don't think it's necessary that it works outside *Score Trace*
> buffers.  So we could use option [d].

That would be the version I prefer also.

> Since `ffap' is available in all supported (X)Emacs versions, it's
> okay to use it.  If we can do the same with `buffer-substring' it's
> fine.

And perhaps Gnus is 1 millisecond faster and one bit smaller :-)

[...]
> Unlike the old code, your function always goes to the rule.  So we
> should change the manual.

> ,----[ (info "(gnus)Summary Score Commands") ]
> | `V t'
> |      Display all score rules that have been used on the current article
> |      (`gnus-score-find-trace').  In the `*Score Trace*' buffer, you can
> |      use `q' to quit.  `e' edits the corresponding score file.  When
> |      point is on a string within the match element, `e' will try to
> |      bring you to this string in the score file.
> `----

Right. The point needn't be on a string.  It's enough if you are in the
line you are interested in.

That raises another question: is the `(setq truncate-lines t)' really
necessary?  I don't see a reason and I don't like it at all.

>> [d] 

>> (defun gnus-score-edit-file-at-point ()
> [...]
>> 	(file (save-excursion
>> 		;; only works in a Score Trace buffer
>> 		(beginning-of-line)
>> 		(re-search-forward "-> +" nil t)

> Fails in this example:

> ("foo -> bar" 1 nil s)  ->  /some/score/file

Oh right.

> Maybe search for a more strict expression, such as ")  ->  ".

I think a re-search-backward is better.
 
> Example:

> ("^[^)]+" 2 nil r)  ->  /some/score/file

> Or is there a function to jump to the matching parenthesis, even when
> there is one inside the score entry?  If not, using `end-of-line' and
> `re-search-backward' should be more robust.

Yes I think so also (the following solution also groks the non-file rule
expression you have if you use eg. bbdb).

(defun gnus-score-edit-file-at-point ()
  "Edit score file at point.  Useful especially after `V t'."
  (let ((rule (save-excursion
		(beginning-of-line)
		(read (current-buffer))))
	(sep "[ \n\r\t]*")
	(file (save-excursion
		;; only works in a Score Trace buffer
		(end-of-line)
		(if (and (re-search-backward "-> +" (point-at-bol) t)
			 (re-search-forward  "-> +" (point-at-eol) t))
		  (buffer-substring (point) (point-at-eol))
		  nil))))
    (if (or (string-match "non-file" file) (not file) (string= "" file))
      (gnus-message 3 "Can't open no file")
      (gnus-score-edit-file file)
      (when  (consp rule)
	;; the rule exists
	(setq rule (mapconcat #'(lambda (obj)
				  (regexp-quote (format "%S" obj)))
			      rule
			      sep))
	(goto-char (point-min))
	(re-search-forward rule nil t)))))


   KP

-- 
 He took his vorpal sword in hand:
     Long time the manxome foe he sought--
 So rested he by the Tumtum tree,
     And stood awhile in thought.  "Lewis Carroll" "Jabberwocky"