elpa.gnu.org packages requiring external packages

elpa.gnu.org packages requiring external packages

[Glenn Morris]

emacs -Q -f list-packages

The following packages are listed as "incompatible":
  ebdb-i18n-chn    # needs "pyim"
  helm-ebdb        # needs "helm"
  org-edna         # needs "org 9.0.5"

because they depend on packages that are not in GNU elpa (or Emacs).
(The last one is an oddity. Apparently the built-in Org isn't
recognized as a package?)

Is it appropriate for elpa.gnu.org to distribute packages that can't be
installed without packages from other repos?

(I don't have an opinion, except that it seems odd to have
"incompatible" packages show up in the default M-x list-packages output.)

Re: elpa.gnu.org packages requiring external packages

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Is it appropriate for elpa.gnu.org to distribute packages that can't be
  > installed without packages from other repos?

Thanks for reporting this.

    > ebdb-i18n-chn    # needs "pyim"
    > helm-ebdb        # needs "helm"

Those should be removed.

    > org-edna         # needs "org 9.0.5"

Perhaps that's a bug in the package handling code
rather than a problem with that package itself.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: elpa.gnu.org packages requiring external packages

[Eric Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Is it appropriate for elpa.gnu.org to distribute packages that can't be
>   > installed without packages from other repos?
>
> Thanks for reporting this.
>
>     > ebdb-i18n-chn    # needs "pyim"
>     > helm-ebdb        # needs "helm"
>
> Those should be removed.

These two are mine, I can put them in MELPA instead.

Eric

Re: elpa.gnu.org packages requiring external packages

[Stefan Monnier]

>>     > ebdb-i18n-chn    # needs "pyim"

BTW, I think Emacs comes with 99% of what's needed already (it does
have a pinyin table and looking at pyim-hanzi2pinyin, there doesn't
seem to be much more to it), so maybe we could add to Emacs a function
equivalent to pyim-hanzi2pinyin and get rid of this dependency.

[ Of course, we should also try and get pyim.el into GNU ELPA, but those
  two are orthogonal.  ]

>>     > helm-ebdb        # needs "helm"

Clearly, getting Helm into GNU ELPA would be great.

Also, looking at the code I see 2 dependencies:
- the helm-ebdb function uses helm-other-buffer: so the helm-ebdb
  function is basically a specialized entry point into Helm, so it is
  useless without Helm.
- half the other functions call helm-marked-candidates.

So, if we could get rid of the second dependency, I'd argue that the
helm-ebdb package could be useful on its own (i.e. even without Helm),
for example it could be used with some (hypothetical) other
Helm-like framework.

IOW if we could get rid of the second dependency, then I think it would
make sense to remove `helm` as a dependency (and probably just merge
helm-ebdb into ebdb).  So my question here is: why do we need to call
helm-marked-candidates?

Is there some way to get Helm to pass us the list of candidates as an
argument (i.e. pass us what we compute via (or (helm-marked-candidates)
(list candidate)))?  If not, maybe we should make this a feature request
in Helm, to make the API between Helm and its backend functions such
that the backend functions don't need to call Helm function.


        Stefan

Re: elpa.gnu.org packages requiring external packages

[Glenn Morris]

Glenn Morris wrote:

> (The last one is an oddity. Apparently the built-in Org isn't
> recognized as a package?)

Adding a Version: header fixes this.
(But I imagine this has been covered before.)


--- i/lisp/org/org.el
+++ w/lisp/org/org.el
@@ -7,6 +7,7 @@
 ;; Maintainer: Carsten Dominik <carsten at orgmode dot org>
 ;; Keywords: outlines, hypermedia, calendar, wp
 ;; Homepage: http://orgmode.org
+;; Version: 9.1.6
 ;;
 ;; This file is part of GNU Emacs.
 ;;

Re: elpa.gnu.org packages requiring external packages

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >     > ebdb-i18n-chn    # needs "pyim"
  > >     > helm-ebdb        # needs "helm"
  > >
  > > Those should be removed.

  > These two are mine, I can put them in MELPA instead.

Another possible solution is to put pyim and helm into ELPA.
Would we want to do that?  Do they meet our criteria?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: elpa.gnu.org packages requiring external packages

[Eric Abrahamsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>>     > ebdb-i18n-chn    # needs "pyim"
>
> BTW, I think Emacs comes with 99% of what's needed already (it does
> have a pinyin table and looking at pyim-hanzi2pinyin, there doesn't
> seem to be much more to it), so maybe we could add to Emacs a function
> equivalent to pyim-hanzi2pinyin and get rid of this dependency.

I'll take a look and see how close it already is. I'd be happy to add a
function to Emacs to do this or, if it's a real no-brainer, just add it
to EBDB and remove this dependency (and probably the whole package).

> [ Of course, we should also try and get pyim.el into GNU ELPA, but those
>   two are orthogonal.  ]
>
>>>     > helm-ebdb        # needs "helm"
>
> Clearly, getting Helm into GNU ELPA would be great.
>
> Also, looking at the code I see 2 dependencies:
> - the helm-ebdb function uses helm-other-buffer: so the helm-ebdb
>   function is basically a specialized entry point into Helm, so it is
>   useless without Helm.
> - half the other functions call helm-marked-candidates.
>
> So, if we could get rid of the second dependency, I'd argue that the
> helm-ebdb package could be useful on its own (i.e. even without Helm),
> for example it could be used with some (hypothetical) other
> Helm-like framework.
>
> IOW if we could get rid of the second dependency, then I think it would
> make sense to remove `helm` as a dependency (and probably just merge
> helm-ebdb into ebdb).  So my question here is: why do we need to call
> helm-marked-candidates?

I don't quite understand -- the package is useless without the call to
`helm-other-buffer' (that's the whole point), so how could I remove
that, or fold this into ebdb? I would need to call that function at some
point no matter what. Or do you mean let the user set a customization
option like (setq ebdb-completion-backend 'helm) and then let it blow up
if they don't have helm installed?

> Is there some way to get Helm to pass us the list of candidates as an
> argument (i.e. pass us what we compute via (or (helm-marked-candidates)
> (list candidate)))?  If not, maybe we should make this a feature request
> in Helm, to make the API between Helm and its backend functions such
> that the backend functions don't need to call Helm function.

It's possible to create helm sources without using any actual helm
functions: the sources can either be created as classes, which obviously
depends on helm, or as alists, which doesn't. The problem is the list of
"actions" you can take on completion candidates: if you create the
source with a plain alist, the action functions only act on a single
candidate. If you want the ability to act on multiple marked candidates,
you need to call that function yourself (though now I see the code in
this package is broken, ugh).

I think the only way around that would be to ask the helm maintainers to
allow some sort of flag to be set in the alist definition, saying "these
actions should accept all the marked candidates". I'm not too optimistic
they'd do that.

Eric

Re: elpa.gnu.org packages requiring external packages

[Stefan Monnier]

>>>>     > ebdb-i18n-chn    # needs "pyim"
>> BTW, I think Emacs comes with 99% of what's needed already (it does
>> have a pinyin table and looking at pyim-hanzi2pinyin, there doesn't
>> seem to be much more to it), so maybe we could add to Emacs a function
>> equivalent to pyim-hanzi2pinyin and get rid of this dependency.
> I'll take a look and see how close it already is. I'd be happy to add a
> function to Emacs to do this or, if it's a real no-brainer, just add it
> to EBDB and remove this dependency (and probably the whole package).

AFAICT the pinyin table is only kept in the quail table: quail tables
are somewhat similar to keymaps, so they work well to incrementally map
a sequence of ASCII chars to the possible chinese characters, but for
pyim-hanzi2pinyin we'll need to traverse this table to build a "reverse
table" (most likely represented as a char-table).

>> IOW if we could get rid of the second dependency, then I think it would
>> make sense to remove `helm` as a dependency (and probably just merge
>> helm-ebdb into ebdb).  So my question here is: why do we need to call
>> helm-marked-candidates?
>
> I don't quite understand -- the package is useless without the call to
> `helm-other-buffer' (that's the whole point), so how could I remove
> that, or fold this into ebdb?

The helm-ebdb function is useless without Helm, yes.  But that doesn't
mean that it has to appear as a dependency on the containing package.

Imagine if font-lock, outline, newcomment, and indent were packaged as
ELPA packages.  Would you want separate python-font-lock,
python-outline, python-comment, and python-indent packages each with its
corresponding dependency?

I think it makes a lot of sense to fold helm-ebdb into the ebdb package,
without adding `helm` as a dependency.  This way, users of Helm and EBDB
won't have to additionally install helm-ebdb to enjoy the combination of
the two: just by installing `ebdb` and `helm` they'll get `helm-ebdb`.

> I think the only way around that would be to ask the helm maintainers to
> allow some sort of flag to be set in the alist definition, saying "these
> actions should accept all the marked candidates".

Something along these lines sounds good, yes.

> I'm not too optimistic they'd do that.

Why not?


        Stefan

Re: elpa.gnu.org packages requiring external packages

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>>     > ebdb-i18n-chn    # needs "pyim"
>>> BTW, I think Emacs comes with 99% of what's needed already (it does
>>> have a pinyin table and looking at pyim-hanzi2pinyin, there doesn't
>>> seem to be much more to it), so maybe we could add to Emacs a function
>>> equivalent to pyim-hanzi2pinyin and get rid of this dependency.
>> I'll take a look and see how close it already is. I'd be happy to add a
>> function to Emacs to do this or, if it's a real no-brainer, just add it
>> to EBDB and remove this dependency (and probably the whole package).
>
> AFAICT the pinyin table is only kept in the quail table: quail tables
> are somewhat similar to keymaps, so they work well to incrementally map
> a sequence of ASCII chars to the possible chinese characters, but for
> pyim-hanzi2pinyin we'll need to traverse this table to build a "reverse
> table" (most likely represented as a char-table).

Okay, I'll take a look. I suppose we can defer building it until first
usage, etc.

>>> IOW if we could get rid of the second dependency, then I think it would
>>> make sense to remove `helm` as a dependency (and probably just merge
>>> helm-ebdb into ebdb).  So my question here is: why do we need to call
>>> helm-marked-candidates?
>>
>> I don't quite understand -- the package is useless without the call to
>> `helm-other-buffer' (that's the whole point), so how could I remove
>> that, or fold this into ebdb?
>
> The helm-ebdb function is useless without Helm, yes.  But that doesn't
> mean that it has to appear as a dependency on the containing package.
>
> Imagine if font-lock, outline, newcomment, and indent were packaged as
> ELPA packages.  Would you want separate python-font-lock,
> python-outline, python-comment, and python-indent packages each with its
> corresponding dependency?
>
> I think it makes a lot of sense to fold helm-ebdb into the ebdb package,
> without adding `helm` as a dependency.  This way, users of Helm and EBDB
> won't have to additionally install helm-ebdb to enjoy the combination of
> the two: just by installing `ebdb` and `helm` they'll get `helm-ebdb`.

Oh I'm all in favor, but I assumed it would be a no-no from a
dependency-graph point of view. If it doesn't matter, I can fold this
back into ebdb and just use `declare-function' with "ext:" to quiet the
compiler? In which case, I might as well just do the same for
`helm-marked-candidates' and leave it as-is?

I've also got these other silly little packages -- counsel-ebdb,
company-ebdb -- etc, should those all be reabsorbed? There are an awful
lot of counsel-* packages in there already.

Sorry, I'm just trying to figure out best policy for managing this kind
of stuff.

>> I think the only way around that would be to ask the helm maintainers to
>> allow some sort of flag to be set in the alist definition, saying "these
>> actions should accept all the marked candidates".
>
> Something along these lines sounds good, yes.
>
>> I'm not too optimistic they'd do that.
>
> Why not?

My observation is that the helm maintainers are not enthusiastic about
adding complexity without a good reason, and I would guess this wouldn't
count. I've opened an issue, though.

Eric

Re: elpa.gnu.org packages requiring external packages

[Stefan Monnier]

>> AFAICT the pinyin table is only kept in the quail table: quail tables
>> are somewhat similar to keymaps, so they work well to incrementally map
>> a sequence of ASCII chars to the possible chinese characters, but for
>> pyim-hanzi2pinyin we'll need to traverse this table to build a "reverse
>> table" (most likely represented as a char-table).
> Okay, I'll take a look.

Thanks.  I played a bit with quail tables in the past, so even though
I don't understand them 100% I should be able to help if needed.

> I suppose we can defer building it until first usage, etc.

Indeed.

>> I think it makes a lot of sense to fold helm-ebdb into the ebdb package,
>> without adding `helm` as a dependency.  This way, users of Helm and EBDB
>> won't have to additionally install helm-ebdb to enjoy the combination of
>> the two: just by installing `ebdb` and `helm` they'll get `helm-ebdb`.
> Oh I'm all in favor, but I assumed it would be a no-no from a
> dependency-graph point of view.

Not at all (actually, back when we got EBDB into elpa.git I mentioned
this possibility).

> If it doesn't matter, I can fold this back into ebdb and just use
> `declare-function' with "ext:" to quiet the compiler?

Yes.

> In which case, I might as well just do the same for
> `helm-marked-candidates' and leave it as-is?

Yes.

> I've also got these other silly little packages -- counsel-ebdb,
> company-ebdb -- etc, should those all be reabsorbed? There are an awful
> lot of counsel-* packages in there already.

I don't have an opinion on counsel-ebdb, but for company-ebdb an even
better option is to turn the company backend into
a completion-at-point-function (so it works not only for company users
but also for old-style TAB-completion users).

> Sorry, I'm just trying to figure out best policy for managing this kind
> of stuff.

And overall, I really wish someone could sit down, take the ivy,
company, helm, and completion-at-point-function APIs and design a new
API which can be used by all of those UIs so you don't have to implement
N different slight variations of the same thing.


        Stefan

Re: elpa.gnu.org packages requiring external packages

[Feng Shu]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>>>     > ebdb-i18n-chn    # needs "pyim"
>>
>> BTW, I think Emacs comes with 99% of what's needed already (it does
>> have a pinyin table and looking at pyim-hanzi2pinyin, there doesn't
>> seem to be much more to it), so maybe we could add to Emacs a function
>> equivalent to pyim-hanzi2pinyin and get rid of this dependency.
>
> I'll take a look and see how close it already is. I'd be happy to add a
> function to Emacs to do this or, if it's a real no-brainer, just add it
> to EBDB and remove this dependency (and probably the whole package).

Maybe we should add a hanzi2pinyin package to elpa, for this
hanzi->pinyin feature is very important to Chinese emacs user.

>
>> [ Of course, we should also try and get pyim.el into GNU ELPA, but those
>>   two are orthogonal.  ]
>>
>>>>     > helm-ebdb        # needs "helm"
>>
>> Clearly, getting Helm into GNU ELPA would be great.
>>
>> Also, looking at the code I see 2 dependencies:
>> - the helm-ebdb function uses helm-other-buffer: so the helm-ebdb
>>   function is basically a specialized entry point into Helm, so it is
>>   useless without Helm.
>> - half the other functions call helm-marked-candidates.
>>
>> So, if we could get rid of the second dependency, I'd argue that the
>> helm-ebdb package could be useful on its own (i.e. even without Helm),
>> for example it could be used with some (hypothetical) other
>> Helm-like framework.
>>
>> IOW if we could get rid of the second dependency, then I think it would
>> make sense to remove `helm` as a dependency (and probably just merge
>> helm-ebdb into ebdb).  So my question here is: why do we need to call
>> helm-marked-candidates?
>
> I don't quite understand -- the package is useless without the call to
> `helm-other-buffer' (that's the whole point), so how could I remove
> that, or fold this into ebdb? I would need to call that function at some
> point no matter what. Or do you mean let the user set a customization
> option like (setq ebdb-completion-backend 'helm) and then let it blow up
> if they don't have helm installed?
>
>> Is there some way to get Helm to pass us the list of candidates as an
>> argument (i.e. pass us what we compute via (or (helm-marked-candidates)
>> (list candidate)))?  If not, maybe we should make this a feature request
>> in Helm, to make the API between Helm and its backend functions such
>> that the backend functions don't need to call Helm function.
>
> It's possible to create helm sources without using any actual helm
> functions: the sources can either be created as classes, which obviously
> depends on helm, or as alists, which doesn't. The problem is the list of
> "actions" you can take on completion candidates: if you create the
> source with a plain alist, the action functions only act on a single
> candidate. If you want the ability to act on multiple marked candidates,
> you need to call that function yourself (though now I see the code in
> this package is broken, ugh).
>
> I think the only way around that would be to ask the helm maintainers to
> allow some sort of flag to be set in the alist definition, saying "these
> actions should accept all the marked candidates". I'm not too optimistic
> they'd do that.
>
> Eric

-- 

Re: elpa.gnu.org packages requiring external packages

[Stefan Monnier]

>>>>>     > ebdb-i18n-chn    # needs "pyim"
>>> BTW, I think Emacs comes with 99% of what's needed already (it does
>>> have a pinyin table and looking at pyim-hanzi2pinyin, there doesn't
>>> seem to be much more to it), so maybe we could add to Emacs a function
>>> equivalent to pyim-hanzi2pinyin and get rid of this dependency.
>> I'll take a look and see how close it already is. I'd be happy to add a
>> function to Emacs to do this or, if it's a real no-brainer, just add it
>> to EBDB and remove this dependency (and probably the whole package).
> Maybe we should add a hanzi2pinyin package to elpa, for this
> hanzi->pinyin feature is very important to Chinese Emacs user.

My impression is that it will be simple enough that we could add it to
lisp/language/chinese.el or something like that, but indeed distributing
it via ELPA would make it easier for other packages to start using it,
so we'd have to put it in a separate file.


        Stefan

Re: elpa.gnu.org packages requiring external packages

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> AFAICT the pinyin table is only kept in the quail table: quail tables
>>> are somewhat similar to keymaps, so they work well to incrementally map
>>> a sequence of ASCII chars to the possible chinese characters, but for
>>> pyim-hanzi2pinyin we'll need to traverse this table to build a "reverse
>>> table" (most likely represented as a char-table).
>> Okay, I'll take a look.
>
> Thanks.  I played a bit with quail tables in the past, so even though
> I don't understand them 100% I should be able to help if needed.

By dint of heroic grepping I found the simplest entrypoint to the
table:

(nth 2 (quail-package "chinese-py"))

But this value is already heavily processed in the *wrong* direction
(optimized for pinyin-to-character). It's built from the intermediate
file "lisp/leim/quail/PY.el", which is produced during `make' from
"leim/MISC-DIC/pinyin.map", which is the same source as Feng Shu uses
for the pyim package.

So the data is accessible in different formats at different stages:
build, compile, and load. Now I'm thinking that it might make sense to
build the reverse table earlier on -- anyway, I'll explore what's
possible there.

[...]

>>> I think it makes a lot of sense to fold helm-ebdb into the ebdb package,
>>> without adding `helm` as a dependency.  This way, users of Helm and EBDB
>>> won't have to additionally install helm-ebdb to enjoy the combination of
>>> the two: just by installing `ebdb` and `helm` they'll get `helm-ebdb`.
>> Oh I'm all in favor, but I assumed it would be a no-no from a
>> dependency-graph point of view.
>
> Not at all (actually, back when we got EBDB into elpa.git I mentioned
> this possibility).

Wish I'd been paying closer attention!

>> If it doesn't matter, I can fold this back into ebdb and just use
>> `declare-function' with "ext:" to quiet the compiler?
>
> Yes.
>
>> In which case, I might as well just do the same for
>> `helm-marked-candidates' and leave it as-is?
>
> Yes.
>
>> I've also got these other silly little packages -- counsel-ebdb,
>> company-ebdb -- etc, should those all be reabsorbed? There are an awful
>> lot of counsel-* packages in there already.
>
> I don't have an opinion on counsel-ebdb, but for company-ebdb an even
> better option is to turn the company backend into
> a completion-at-point-function (so it works not only for company users
> but also for old-style TAB-completion users).

company primarily does popup-on-a-timer; I think calling it as an
explicit completion command (while supported) isn't how it's expected to
be used.

>> Sorry, I'm just trying to figure out best policy for managing this kind
>> of stuff.
>
> And overall, I really wish someone could sit down, take the ivy,
> company, helm, and completion-at-point-function APIs and design a new
> API which can be used by all of those UIs so you don't have to implement
> N different slight variations of the same thing.

But they do their things in such different ways. Some work on a timer
with a popup (company), others tie into the existing completion
mechanisms (helm and ivy), and others provide their own versions of
basic Emacs commands (helm and counsel). How much unification is
possible?

Eric

Re: elpa.gnu.org packages requiring external packages

[Dmitry Gutov]

On 2/3/18 03:43, Eric Abrahamsen wrote:

> company primarily does popup-on-a-timer;

popup-on-a-timer is irrelevant. company supports 
completion-at-point-functions via company-capf.

The only major feature that completion-at-point-functions don't get 
(that company backends do) is asynchronous operation.

 > I think calling it as an
 > explicit completion command (while supported) isn't how it's expected
 > to be used.

M-x company-<backend> is a well-established way of using it (not the 
most popular one, of course).

>> And overall, I really wish someone could sit down, take the ivy,
>> company, helm, and completion-at-point-function APIs and design a new
>> API which can be used by all of those UIs so you don't have to implement
>> N different slight variations of the same thing.

It would be nice to see some input from Ivy's author: it does support 
asynchronous operation, and even operating on an incomplete set of 
results. That's something CAPF does not have yet. Add fuzzy matching, 
and that's basically everything we want such API to have.

> But they do their things in such different ways. Some work on a timer
> with a popup (company), others tie into the existing completion
> mechanisms (helm and ivy), and others provide their own versions of
> basic Emacs commands (helm and counsel). How much unification is
> possible?

company-capf is an example of one such unification. And given a 
powerful-enough API, all packages could have the ability, at least, to 
switch to it.

Re: elpa.gnu.org packages requiring external packages

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 2/3/18 03:43, Eric Abrahamsen wrote:
>
>> company primarily does popup-on-a-timer;
>
> popup-on-a-timer is irrelevant. company supports
> completion-at-point-functions via company-capf.
>
> The only major feature that completion-at-point-functions don't get
> (that company backends do) is asynchronous operation.
>
>> I think calling it as an
>> explicit completion command (while supported) isn't how it's expected
>> to be used.
>
> M-x company-<backend> is a well-established way of using it (not the
> most popular one, of course).
>
>>> And overall, I really wish someone could sit down, take the ivy,
>>> company, helm, and completion-at-point-function APIs and design a new
>>> API which can be used by all of those UIs so you don't have to implement
>>> N different slight variations of the same thing.
>
> It would be nice to see some input from Ivy's author: it does support
> asynchronous operation, and even operating on an incomplete set of
> results. That's something CAPF does not have yet. Add fuzzy matching,
> and that's basically everything we want such API to have.
>
>> But they do their things in such different ways. Some work on a timer
>> with a popup (company), others tie into the existing completion
>> mechanisms (helm and ivy), and others provide their own versions of
>> basic Emacs commands (helm and counsel). How much unification is
>> possible?
>
> company-capf is an example of one such unification. And given a
> powerful-enough API, all packages could have the ability, at least, to
> switch to it.

I think I came off more skeptical than I meant to here. I really was
just curious how this would work. It's not an area of Emacs I've spent
much time with (and am not likely to).