Check for derived modes instead of listing all the modes, and comint buffers problem.

[vspinu]

SP configuration relies on explicitly listing modes. For example in
sp-local-pair and a couple of other places.

Would it be feasible for sp to check for derived modes (derived-mode-p)?

Then, instead of giving the full list as in sp--lisp-modes one would give only
the parent mode 'lisp-mode. Similarly for comint buffers. There are hundredes of
derived modes from comint out there.

The commint mode is also marked as special mode. Thus sp is not activated there,
and this is unfortunate because comint buffers are also editable by users and sp
should work there as well. This is related to #83 as inferior ESS is also a
comint buffer.

[Fuco1]

We had a brief discussion about this in #47 might be relevant.

How do you propose the checks will be done? Suppose there is be a function sp-check-modes, you give it a list of symbols, each symbol a name of mode or list of modes (like sp--lisp-modes) and possibly some special symbols? (like 'special property). So instead of doing (memq major-mode list-of-modes) we would do (sp-check-modes list-of-modes).

What should it then do? When to return t, when nil. This looks like a good idea to allow more sophisticated configuration, but it needs some cleaner specification.

This could work almost everywhere where memq major-mode approach is used "out of the box". But I don't think I can easily make it work for sp-local-pair, beacuse the data structure used (sp-pairs) is an alist major-mode -> configuration. It would need more significant rewrite.

[vspinu]

My limited knowledge of sp internals don't allow me to fully grasp the nature of the problem you have described.

What I have proposed is instead of (memq major-mode list-of-modes), which is presumably what sp does internally, do (derived-mode-p list-of-modes).

So I just can do:

(sp-local-pair 'comint-mode "(" nil :unless '(sp-point-before-word-p))

and I will get "(" working in my shell buffer.

For the handling of comint buffers, I was proposing a special treatment of comint. I think it is the only special buffer that can actually be edited in emacs:

;;;###autoload
(defun turn-on-smartparens-mode ()
  "Turn on `smartparens-mode'."
  (interactive)
  (unless (or (member major-mode sp-ignore-modes-list)
              (and (not (derived-mode-p 'comint-mode))
                   (eq (get major-mode 'mode-class) 'special)))
    (smartparens-mode t)))

[Fuco1]

Right, the second patch is reasonable. Do you want to make a pull request or should I add it myself?

As for the sp-local-pair example, that's not really possible now, and would require lot of work. Honestly, I'm still unsure what would be the best way to handle the pair data. It's complicated because there's lots of inheritance and shadowing... if we add things like derived modes or collections of modes where something should apply, it will need a lot better structure than alist of major mode <-> data

[vspinu]

Could you please add it yourself. There is at least one more place in turn-on-show-smartparens-mode where it should be handled.

Thanks.

[Fuco1]

okey.

[Fuco1]

Bump. Is it possible to get the "parent" modes of a mode instead of only checking explicitely if it is derived from some?

[chrisbarrett]

This seems to work. From the internals of derived-mode-p:

(define-derived-mode child-mode    parent-mode   nil)
(define-derived-mode parent-mode   ancestor-mode nil)
(define-derived-mode ancestor-mode nil           nil)

(get 'child-mode 'derived-mode-parent) ; => parent-mode

[Fuco1]

Nice, so with that I can possibly generate a list/tree structure of all parent modes. I think there is one possible problem, namely autoloading (the "mode symbol" is loaded as autoload method, but the properties aren't set yet), but I suppose global minor mode hooks are run after the mode is loaded.

Either way, thanks for the tip, it should be all I need.

[bbatsov]

Btw, most Lisp REPL modes don't derive neither Lisp nor Comint mode, so all cases cannot be covered automatically, anyways.