bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#38918: 26.3; EBDB fails to edit (add) tags


From: Eric Abrahamsen
Subject: bug#38918: 26.3; EBDB fails to edit (add) tags
Date: Tue, 07 Jan 2020 09:37:02 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jorge P. de Morais Neto <jorge+list@disroot.org> writes:

> Em [2020-01-06 seg 11:40:30-0800], Eric Abrahamsen escreveu:
>
>> Oh, sorry, these two were actually the same problem, and all should be
>> fixed now.  I've done a 0.6.12 release -- would you update when it's
>> available and check that this fixes everything?  Though I'm not sure
>> if it will address your other error.  Let's get this closed out first.
>
> Yes, with EBDB 0.6.12 I can insert and edit tags, and I can edit them
> with both "e" and "E".  The error message when, in the extended
> customize interface ("E"), I hit "[Apply]" and then "[Accept]", also
> seems to have been fixed.  There is still one quirk: when I insert a
> tags field on a record that already has a tags field, EBDB overwrites
> the old field and, when it asks for the tags, it does not offer the
> previous ones as default.  It would be more user-friendly if EBDB either
> offered the previous tags as default, or simply signaled an error with a
> short and clear message.

Yes, this isn't ideal; there's no indication of which fields are
"singletons" and which aren't. I think you're right that inserting a new
field should essentially behave like editing the old one -- actually
maybe that's all that needs to happen. That plus a message afterwards.
I'll take a look.

> And two feature requests:
>
> 1. Undo.  So far I have never suffered much for the lack of undo (it is
>    only an inconvenience) and of course I leave it up to you to
>    prioritize this feature, but it would be useful, though clearly not
>    as useful as 2:

I've thought about this in the past. Each record has a "cache" object
that stores metadata and computed strings for the record, and this would
be natural place to store undo information. A dumb implementation could
store entire copies of the record as it is edited, and allow you to
switch them out. Alternately, the vCard specs provide for a versioning
system for individual properties
(https://tools.ietf.org/html/rfc6350#section-7), maybe I could adapt
that once I've gone and figured out how it works.

> 2. Compatibility with other contacts formats. I would like to import my
>    Gmail contacts and complete my transition away from G$$gle spyware.

This is definitely on the roadmap, and taking me too long. Presumably
you'd export your Gmail contacts as a vCard file? Or something else? I'm
in the middle of writing a vCard parser, which is actually a separate
library from EBDB (so other software can use it), but will be used in
EBDB code.

Anyway, if we're talking about importing vCards, that's on the way.

> Should I open two bug reports for these two feature requests?

For the undo feature, please -- it's not high priority but it would be
good to keep track of. I've already got Github issues open for the other
request.

Thanks,
Eric





reply via email to

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