Re: Vector form for strings in ~/.bbdb

2013-01-27 Thread Roland Winkler
On Sun Jan 27 2013 Daniel Doherty wrote:
> For what it's worth, I would like to see text properties kept out
> of the db until there is some need for them. Right now, one of the
> big pluses for BBDBv3 to my mind is that it allows two-way syncing
> with Sriram's Asynk facility, which is what motivated me to try to
> make the move to begin with.

As I said before:

If one day text properties are added to BBDB:

(1) this should bring some noticable advantage to BBDB

(2) this should include an option to completely disable this feature
(I guess without such a user option, it would not be BBDB
anymore. BBDB is fully customizable.)

Roland

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/


Re: Vector form for strings in ~/.bbdb

2013-01-27 Thread Daniel Doherty
Roland,

For what it's worth, I would like to see text properties kept out of the 
db until there is some
need for them.  Right now, one of the big pluses for BBDBv3 to my mind 
is that it allows two-way syncing with
Sriram's Asynk facility, which is what motivated me to try to make the 
move to begin with.

What makes v3 difficult for me to use right now is (1) the 
text-properties issue (which impacts Asynk) and
(2) the lack of fully-developed Wanderlust integration, which is really 
a problem for Wanderlust
users to fix I suppose.

Anyway Roland, thanks for your great work on bringing BBDB up to snuff, 
but I would vote for
BBDB being just a repository of data, not appearances.  Elisp ought to 
be able to handle any
decoration with text properties (perhaps with the help of a customized 
field in BBDB itself) when and if
the need arises.

Regards,

On 01/27/2013 07:21 AM, Roland Winkler wrote:
> On Sun Jan 27 2013 Sriram Karra wrote:
>> (a) The "True Origin" of the text is not known (I mean, it is either from a
>> minibuffer, or a MUA, but could conceivably be a script or whatever). The
>> properties that come with a piece of text today come with whatever that
>> property means at the point of origin. BBDB makes no promises to retain or
>> return such properties.
> Right now, I can only think of one way for deliberately introducing
> text properties into BBDB in a meaningful way: There would have to
> be some BBDB command for that. But I have not thought about details.
> (If someone has a "permanent external feeding trough" for BBDB that
> uses text properties in a predictable way, it could be another thing.)
>
> Yet first of all, right now there is no context coming to my mind
> where having such a feature was an improvement of some kind.
>
>>   Yet all the text processing in between the grabbing of text
>>   strings and adding them to the database should preserve text
>>   properties.
>>
>> Makes a lot of sense. And we could do all this even before we come
>> up with any real use of having text properties in the database,
>> making it more flexible but keeping the database format more
>> predictable for those who desire it to be so.
> Exactly.
>
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> ___
> bbdb-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bbdb-info
> BBDB Home Page: http://bbdb.sourceforge.net/


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/


Re: Vector form for strings in ~/.bbdb

2013-01-27 Thread Roland Winkler
On Sun Jan 27 2013 Sriram Karra wrote:
> (a) The "True Origin" of the text is not known (I mean, it is either from a
> minibuffer, or a MUA, but could conceivably be a script or whatever). The
> properties that come with a piece of text today come with whatever that
> property means at the point of origin. BBDB makes no promises to retain or
> return such properties.

Right now, I can only think of one way for deliberately introducing
text properties into BBDB in a meaningful way: There would have to
be some BBDB command for that. But I have not thought about details.
(If someone has a "permanent external feeding trough" for BBDB that
uses text properties in a predictable way, it could be another thing.)

Yet first of all, right now there is no context coming to my mind
where having such a feature was an improvement of some kind.

>  Yet all the text processing in between the grabbing of text
>  strings and adding them to the database should preserve text
>  properties.
> 
> Makes a lot of sense. And we could do all this even before we come
> up with any real use of having text properties in the database,
> making it more flexible but keeping the database format more
> predictable for those who desire it to be so.

Exactly.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/


Re: Vector form for strings in ~/.bbdb

2013-01-27 Thread Sriram Karra
On Sat, Jan 26, 2013 at 11:01 PM, Roland Winkler  wrote:

>
> I thought more about this, and I do not believe anymore that simply
> replacing calls of (buffer-)substring with (buffer-)substring-no-properties
> throughout BBDB is a meaningful strategy.
>
> - In the future, it could be meaningful to deliberately introduce
>   text properties into BBDB (here, I mean the database itself).
>   So IMO BBDB should not remove text properties when operating on
>   text strings originating from BBDB --unless these strings are passed on
>   to an application for which it is known that it cannot handle text
>   properties.
>

Hm I cannot argue that having text properties in BBDB is a bad idea for all
of eternity. But at the moment I cannot see any use for such - for two
reasons:

(a) The "True Origin" of the text is not known (I mean, it is either from a
minibuffer, or a MUA, but could conceivably be a script or whatever). The
properties that come with a piece of text today come with whatever that
property means at the point of origin. BBDB makes no promises to retain or
return such properties.

(b) A fontified contact name has no counterpart in any contact manager that
I am familiar with.


> - Once BBDB starts using text properties deliberately, there should
>   also be a user option that inhibits that text properties ever
>   enter the database itself. This option will have to be implemented
>   rather low-level, where text strings "are really added to the
>   database".
>
>   Yet all the text processing in between the grabbing of text
>   strings and adding them to the database should preserve text
>   properties.


Makes a lot of sense. And we could do all this even before we come up with
any real use of having text properties in the database, making it more
flexible but keeping the database format more predictable for those who
desire it to be so.
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/

Re: Vector form for strings in ~/.bbdb

2013-01-26 Thread Roland Winkler
On Fri Jan 25 2013 Sriram Karra wrote:
> On Fri, Jan 25, 2013 at 8:34 PM, Roland Winkler  wrote:
> But I just went through the code and replaced occurences of
> (buffer-)substring with (buffer-)substring-no-properties where
> copying text properties appears not meaningful to me. I'll install
> this patch shortly.
> 
> Nice.

I thought more about this, and I do not believe anymore that simply
replacing calls of (buffer-)substring with (buffer-)substring-no-properties
throughout BBDB is a meaningful strategy.

- In the future, it could be meaningful to deliberately introduce
  text properties into BBDB (here, I mean the database itself).
  So IMO BBDB should not remove text properties when operating on
  text strings originating from BBDB --unless these strings are passed on
  to an application for which it is known that it cannot handle text
  properties.

- Of course, right now BBDB does not have any means to deliberately
  introduce text properties into BBDB (nor means to use them in a
  meaningful way). IMO, all currently implemented ways of populating
  BBDB should explicitly avoid that BBDB gets randomly populated
  with text properties. For this, the above strategy of replacing
  calls of (buffer-)substring with (buffer-)substring-no-properties
  is not sufficient.

- Any code grabbing text strings for BBDB should explicitly consider
  text properties.

- Once BBDB starts using text properties deliberately, there should
  also be a user option that inhibits that text properties ever
  enter the database itself. This option will have to be implemented
  rather low-level, where text strings "are really added to the
  database".

  Yet all the text processing in between the grabbing of text
  strings and adding them to the database should preserve text
  properties.

What do you think?

Roland


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/


Re: Vector form for strings in ~/.bbdb

2013-01-25 Thread Roland Winkler
On Thu Jan 24 2013 Sriram Karra wrote:
> The function bbdb-divide-name uses substring to extract the first
> and last names.

Note that this code uses both substring and match-string.  And the
latter uses substring, too (not substring-no-properties).  So it
really does not make sense to try to rely on functions like 
bbdb-divide-name to make sure that text properties do not propagate
into the database.  I guess this must have been a basic design
decision for GNU Emacs years ago: By default GNU Emacs could either
always propagate text properties, unless one explicitly uses a
function such as substring-no-properties.  Or by default these
functions would not propagate text properties.  The design decision
was made in the former way, I believe for good reason.  Otherwise,
each function like match-string would require a second variant
match-string-with-properties. Basic built-in functions like concat
copy the text properties of their args, too.

Yet this implies that you need to be careful when grabbing a text
string: do you want to grab it with its text properties or without
them.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/


Re: Vector form for strings in ~/.bbdb

2013-01-25 Thread Sriram Karra
On Fri, Jan 25, 2013 at 8:34 PM, Roland Winkler  wrote:


> But I just went through the code and replaced occurences of
> (buffer-)substring with (buffer-)substring-no-properties where
> copying text properties appears not meaningful to me. I'll install
> this patch shortly.


Nice.


> Yet I want to ask: Where did the text string come from that was
> decorated with some text property so that the text string including
> its text properties ended up in BBDB? I cannot see how this could
> happen with the "plain" code of BBDB 3. Could it be that the user who
> reported this problem was using some customization to feed BBDB that
> was grabbing text strings including their text properties? Then this
> is what he or she should fix first.
>

I agree with what you are saying here. Now that I know a bit more about
what's going on, I'll be able to help that user debug this issue further.
Will report back anything of interest. Thanks for your help.

-Karra
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/

Re: Vector form for strings in ~/.bbdb

2013-01-25 Thread Roland Winkler
On Thu Jan 24 2013 Sriram Karra wrote:
> On Wed, Jan 23, 2013 at 9:35 PM, Roland Winkler  wrote:
> On Wed Jan 23 2013 Sriram Karra wrote:
> > #("John" 0 4 (fontified nil))
> Could you be a bit more specific? Which version of BBDB are
> you talking about?
> 
> BBDB v3
> 
> Is it your own experience, or are you talking about someone else?
> 
> Someone else's. I could not reproduce it myself. The report came
> to me because ASynK is not able to process this vector form, and a
> sync of BBDB to google was failing.

Thanks, now I understand better what you are talking about.

> I guess that text properties can end up in the database itself if
> you are using something like (buffer-)substring instead of
> (buffer-)substring-no-properties when grabbing a fontified text
> string that ends up in BBDB.
> 
> The function bbdb-divide-name uses substring to extract the first and last
> names. Let me check if changing that fixes the issue for the user who
> complained about that.

OK!

> At any rate given what you have mentioned, does it make sense to
> use the -no-properties versions consistently across the code base?
> I could see ~25 instances in total.

This would be too radical. For a command such as
bbdb-copy-records-as-kill it makes sense to copy text properties.
But I just went through the code and replaced occurences of
(buffer-)substring with (buffer-)substring-no-properties where
copying text properties appears not meaningful to me. I'll install
this patch shortly. The functions which do not copy text properties
are anyway simpler than the ones that do copy them. So there is no
need to call the latter unless the text properties should be kept.

Yet I want to ask: Where did the text string come from that was
decorated with some text property so that the text string including
its text properties ended up in BBDB? I cannot see how this could
happen with the "plain" code of BBDB 3. Could it be that the user who
reported this problem was using some customization to feed BBDB that
was grabbing text strings including their text properties? Then this
is what he or she should fix first.

Roland

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/

Re: Vector form for strings in ~/.bbdb

2013-01-24 Thread Sriram Karra
On Wed, Jan 23, 2013 at 9:35 PM, Roland Winkler  wrote:

> On Wed Jan 23 2013 Sriram Karra wrote:
> >
> > #("John" 0 4 (fontified nil))
> >
>


> Could you be a bit more specific? Which version of BBDB are
> you talking about?


BBDB v3


> Is it your own experience, or are you talking about someone else?
>

Someone else's. I could not reproduce it myself. The report came to me
because ASynK is not able to process this vector form, and a sync of BBDB
to google was failing.


> I guess that text properties can end up in the database itself if
> you are using something like (buffer-)substring instead of
> (buffer-)substring-no-properties when grabbing a fontified text
> string that ends up in BBDB.
>

The function bbdb-divide-name uses substring to extract the first and last
names. Let me check if changing that fixes the issue for the user who
complained about that.

At any rate given what you have mentioned, does it make sense to use the
-no-properties versions consistently across the code base? I could see ~25
instances in total.
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/

Re: Vector form for strings in ~/.bbdb

2013-01-23 Thread Roland Winkler
On Wed Jan 23 2013 Sriram Karra wrote:
> In some instances it has been observed that the strings written to
> the .bbdb file are in vector form containing some fontification
> metadata. For e.g. in the field position for a contact's first
> name, where one would normally expect to find a string "John" one
> finds, instead, this:
> 
> #("John" 0 4 (fontified nil))
> 
> It has been reported that this happens for contacts inserted from
> Gnus using bbdb-mua-display-sender function, although it has not
> been reproducible by others. So it is likely some customization or
> some version-specific behaviour triggering this.

I am sorry, this sounds a bit like a vague fairy tale from nowhere
land. Could you be a bit more specific? Which version of BBDB are
you talking about? Is it your own experience, or are you talking
about someone else?

I guess that text properties can end up in the database itself if
you are using something like (buffer-)substring instead of
(buffer-)substring-no-properties when grabbing a fontified text
string that ends up in BBDB.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/