bug#17880: 24.4.50; [FEATURE] abbrev with skeleton

bug#17880: 24.4.50; [FEATURE] abbrev with skeleton

[Leo Liu]

I was looking for packages to obsolete and find this expand.el. The
skeleton DSL is certainly more powerful. Comments?

BTW, we should be able to extend skeleton to cover snippet.el or
whatever nicely. I mean snippet.el/yas-snippet.el might not be the one
we want to converge to.

=== modified file 'lisp/abbrev.el'
--- lisp/abbrev.el	2014-05-27 01:09:45 +0000
+++ lisp/abbrev.el	2014-06-30 01:02:15 +0000
@@ -776,7 +776,7 @@
   (let ((value abbrev))
     ;; If this abbrev has an expansion, delete the abbrev
     ;; and insert the expansion.
-    (when (stringp (symbol-value abbrev))
+    (cond ((stringp (symbol-value abbrev))
       (goto-char wordstart)
       ;; Insert at beginning so that markers at the end (e.g. point)
       ;; are preserved.
@@ -806,6 +806,9 @@
               ;; Change just that.
               (upcase-initials-region (point) (1+ (point)))
               (goto-char end))))))
+	  ((consp (symbol-value abbrev))
+	   (delete-char (- wordstart wordend))
+	   (skeleton-insert (symbol-value abbrev))))
     ;; Now point is at the end of the expansion and the beginning is
     ;; in last-abbrev-location.
     (when (symbol-function abbrev)

bug#17880: 24.4.50; [FEATURE] abbrev with skeleton

[Stefan Monnier]

> I was looking for packages to obsolete and find this expand.el. The
> skeleton DSL is certainly more powerful. Comments?

Yes, expand.el might be a good candidate for obsolescence.

> BTW, we should be able to extend skeleton to cover snippet.el or
> whatever nicely.  I mean snippet.el/yas-snippet.el might not be the one
> we want to converge to.

The discussion with Joao convinced me that "extending skeleton" is not
going to work quite right (IOW, it won't "cover it nicely").  So the
idea is rather to introduce yet-another thingy, but try to make sure
that skeleton.el can be rewritten as a "compatibility front-end", and
same for tempo.el.


        Stefan

bug#17880: 24.4.50; [FEATURE] abbrev with skeleton

[Leo Liu]

On 2014-06-30 09:43 -0400, Stefan Monnier wrote:
> The discussion with Joao convinced me that "extending skeleton" is not
> going to work quite right (IOW, it won't "cover it nicely").  So the
> idea is rather to introduce yet-another thingy, but try to make sure
> that skeleton.el can be rewritten as a "compatibility front-end", and
> same for tempo.el.

Is the discussion available somewhere? The original snippet.el (the one
that stirred the whole interest of textmate snippet feature in emacs) is
string-based and the core concept is linking similar fields with naming
i.e. multiple occurences of $${filed_name} are changed together. So if
we introduce [field-name] (or :field-name) as a new element to skeleton
to do the same that would seem to offer the core of snippet. Just
thinking though. I have never used anything beyond the original
snippet.el which is only a few hundred lines.

Leo

bug#17880: 24.4.50; [FEATURE] abbrev with skeleton

[Lars Ingebrigtsen]

Leo Liu <sdl.web@gmail.com> writes:

> I was looking for packages to obsolete and find this expand.el. The
> skeleton DSL is certainly more powerful. Comments?

[...]

> === modified file 'lisp/abbrev.el'
> --- lisp/abbrev.el	2014-05-27 01:09:45 +0000
> +++ lisp/abbrev.el	2014-06-30 01:02:15 +0000
> @@ -776,7 +776,7 @@

[...]

> +	  ((consp (symbol-value abbrev))
> +	   (delete-char (- wordstart wordend))
> +	   (skeleton-insert (symbol-value abbrev))))

I think the conclusion here was that we don't really want to make
abbrev.el depend on skeleton here, so the patch was never applied.

For the other issue -- I'm going to go ahead and guess that expand.el is
still used by people (because it's so simple that some people might
prefer it), so obsoleting it would be controversial, I think.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no