[andreas.roehler@online.de: edit-abbrevs questions - new edit-sorted-abbrevs function]

[Richard Stallman <rms@gnu.org>]

He is trying to solve the problems he reported.  Could someone
please see if his solutions are good ones?

------- Start of forwarded message -------
Date: Mon, 20 Mar 2006 15:08:01 +0100
From: Andreas Roehler <andreas.roehler@online.de>
MIME-Version: 1.0
To: emacs-pretest-bug@gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: edit-abbrevs questions - new edit-sorted-abbrevs function

Herewith a more detailed description of already
mentioned problems with `edit-abbrevs' - proposed
solutions inclusive.

1) in contrast with the documentation, which declares
   edit-abbrevs and list-abbrevs to differ only in
   displaying, I see no way to call edit-abbrevs with
   an option `local'.

`edit-abbrevs' starts at the top of the
*Abbrev*-Buffer with the complete listing of all
abbrevs below. Presently its up to the user to select
the abbrev-table to edit.

As the mode-line of  `my-file.el' I switched from
displayed (Emacs-Lisp Abbrev), I concluded to edit the
`(emacs-lisp-mode-abbrev-table)' - what was a
mistake. Editing there had no effect, I had to edit
`(lisp-mode-abbrev-table)', only then are new
definitions afterwards are available.

2) if editing *Abbrevs* with narrowed buffer, a call of
   edit-abbrevs-redefine on this narrowed buffer
   deletes all other abbrevs without warning. That's
   dangerous.

Proposed Solutions:

AFAIS there is a quick solution to #2 by providing `(widen)' to
`edit-abbrevs-redefine':

*** ar-emacs/lisp/abbrev.el	2006-03-20 10:43:26.000000000 +0100
- --- emacs/lisp/abbrev.el	2006-03-17 21:02:38.000000000 +0100
***************
*** 159,165 ****
  (defun edit-abbrevs-redefine ()
    "Redefine abbrevs according to current buffer contents."
    (interactive)
- -   (widen)
    (define-abbrevs t)
    (set-buffer-modified-p nil))

- --- 159,164 ----

Proposal to #1: To facilitate the selection of the
abbrev-table to edit, AFAIS there is a minor and a
major solution. The latter I conceive in reverting the
global-abbrev-editing approach into an table-by-table
style, always editing and re-writing a section in order
to avoid loading a big abbrev-file at once.

The minor solution would always load the complete
abbrev_defs, - as its the current state - introduce
narrowing and use `(abbrev-table-name
local-abbrev-table)' to set the
`region-beginning'. Together with the already described
introduction of `widen' there will be no harm.

My results so far in the minor way (the option now is
global, not local, as I usually need the mode-abbrevs
to edit:)

(defun edit-sorted-abbrevs (&optional global)
  ""
  (interactive "P")
  (save-excursion
    (let ((table local-abbrev-table)
	  (table-name (abbrev-table-name local-abbrev-table)))
      (set-buffer (get-buffer-create "*Abbrevs*"))
      (switch-to-buffer "*Abbrevs*")
      (erase-buffer)
      (dolist (table abbrev-table-name-list)
	(insert-abbrev-table-description table t))
      (goto-char (point-min))
      (set-buffer-modified-p nil)
      (edit-abbrevs-mode)
      (unless global
	(re-search-forward (format "(%s)" table-name) nil t 1)
	(let ((table-head (line-beginning-position))
	      (start (progn
		       (re-search-forward "^\"" nil t 1)
		       (match-beginning 0)))
	      (end (save-excursion
		     (re-search-forward "^[ \t]*(.+mode-abbrev-table" nil t 1)
		     (forward-line -1)
		     (point))))
	  (narrow-to-region start end)
	  ;; multiline-abbrevs will make trouble when sort
	  (save-excursion
	    (if
		(re-search-forward "^[A-Za-zäöüÄÖÜß0-9 \t]" nil t 1)
		(message "%s %s" "Cann't sort. Don't declare multiline-abbrevs. Error
at point: " (point)))
	    (beginning-of-line)
	    (sort-lines nil start end))
	  (widen)
	  (narrow-to-region table-head end)
	  (goto-char (point-min))
	  (forward-line 1)
	  (just-one-empty-line)))
      (when global
	(widen)
	(point-min)))))


______

Andreas Roehler









_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------