[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

address@hidden: edit-abbrevs questions - new edit-sorted-abbrevs functio

From: Richard Stallman
Subject: address@hidden: edit-abbrevs questions - new edit-sorted-abbrevs function]
Date: Mon, 20 Mar 2006 20:01:55 -0500

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 <address@hidden>
MIME-Version: 1.0
To: address@hidden
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

Proposed Solutions:

AFAIS there is a quick solution to #2 by providing `(widen)' to

*** 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."
- -   (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")
    (let ((table local-abbrev-table)
          (table-name (abbrev-table-name local-abbrev-table)))
      (set-buffer (get-buffer-create "*Abbrevs*"))
      (switch-to-buffer "*Abbrevs*")
      (dolist (table abbrev-table-name-list)
        (insert-abbrev-table-description table t))
      (goto-char (point-min))
      (set-buffer-modified-p nil)
      (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)
          (narrow-to-region start end)
          ;; multiline-abbrevs will make trouble when sort
                (re-search-forward "^[A-Za-zäöüÄÖÜß0-9 \t]" nil t 1)
                (message "%s %s" "Cann't sort. Don't declare multiline-abbrevs. 
at point: " (point)))
            (sort-lines nil start end))
          (narrow-to-region table-head end)
          (goto-char (point-min))
          (forward-line 1)
      (when global


Andreas Roehler

emacs-pretest-bug mailing list
------- End of forwarded message -------

reply via email to

[Prev in Thread] Current Thread [Next in Thread]