Re: Vector form for strings in ~/.bbdb

2013-01-27 Thread Sriram Karra
On Sat, Jan 26, 2013 at 11:01 PM, Roland Winkler wink...@gnu.org 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-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 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-25 Thread Roland Winkler
On Thu Jan 24 2013 Sriram Karra wrote:
 On Wed, Jan 23, 2013 at 9:35 PM, Roland Winkler wink...@gnu.org 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-25 Thread Sriram Karra
On Fri, Jan 25, 2013 at 8:34 PM, Roland Winkler wink...@gnu.org 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:
 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-24 Thread Sriram Karra
On Wed, Jan 23, 2013 at 9:35 PM, Roland Winkler wink...@gnu.org 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/