You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(4) |
Nov
|
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(7) |
Feb
(7) |
Mar
(16) |
Apr
(2) |
May
(8) |
Jun
(10) |
Jul
(5) |
Aug
(19) |
Sep
(3) |
Oct
(18) |
Nov
(10) |
Dec
(3) |
2002 |
Jan
(13) |
Feb
(10) |
Mar
(8) |
Apr
(6) |
May
(4) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(2) |
2003 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(13) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
(5) |
2004 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(9) |
May
|
Jun
|
Jul
(4) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
(4) |
Sep
(35) |
Oct
(27) |
Nov
(8) |
Dec
(6) |
2006 |
Jan
|
Feb
|
Mar
(4) |
Apr
(4) |
May
|
Jun
(2) |
Jul
(1) |
Aug
(22) |
Sep
(17) |
Oct
(4) |
Nov
(1) |
Dec
(4) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
(2) |
Feb
(16) |
Mar
(1) |
Apr
|
May
|
Jun
(15) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
(1) |
Dec
(2) |
2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(8) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(8) |
Jun
(3) |
Jul
(2) |
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
|
Dec
(18) |
2013 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(11) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
2015 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
(5) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2021 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Raphaël <rap...@gm...> - 2021-01-03 03:07:01
|
Applied into latest -master. Thank you! On Thu, Aug 09, 2018 at 05:32:44PM +0200, Rieger Anton wrote: > Dear all, > > I noticed a missing German translation, so I thought to add it. > In the process I looked through the complete de.po and corrected/added translations. > > Maybe I overlooked but I didn't find a standard way to contribute, so I'm > trying it via the ML and a simple git-patch as attachment. > So please review and maybe except this patch/PR. > > If you have another standard way to contribute translations please mention it. > > I'm also interested how to contribute source code Patches/PRs and discuss issues. > (I've only used Github, so the this is kinda new to me) > > Best regards > > Anton Rieger |
From: Raphaël <rap...@gm...> - 2021-01-03 03:03:36
|
Thank you for the patchset Corey. Sounds good and safe. + it removed a gotcha about concatenating "From:" I just merged into -master + added a couple of wording fixes and a mention in --help. Note: To avoid possible misunderstandings I modified the original option name to --email-fields (instead of just --fields) Best regards On Thu, Jan 31, 2019 at 12:07:28PM -0600, mi...@ac... wrote: > From: Corey Minyard <cmi...@mv...> > > abook did not have the ability to add addresses from the To: or Cc: > lists. This adds the ability to specify the fields to use when > looking for addresses. |
From: Raphaël <rap...@gm...> - 2021-01-02 23:10:54
|
Hi Andreas, Thank you very much for your contribution. It's definitely a good idea but there are several redundancies in the patch. and ~ 100 LoC added to abook.c. You may want to create small helpers like - `get_config_dir(int create_if_not_exists)` - `get_data_dir(int create_if_not_exists)` Where the fallback logic could be set once for all. Given that data-dir/config-dir are so similar both may even be factored in advantageous (but still readable) ways. The xdg_data_home_needs_free is not a very nice construct and the code paths could be improved/optimized to avoid this. Basically, try to only replace a handful of lines related to `datafile = strconcat(...)` by the call to your new helper. That would make the code clear, the diff small and the function more testable. Also feel free to add function's comments to define the file selection heuristic in a human way so that it's possible to compare with actual code. About the heuristic itself, I think, for backward compatibility (and least surprise) principles, that ~/.abook must be considered as long as that directory exist on the FS (even if XDG_DATA_DIR is set or even if the ~/.abook/addressbook file does not exist). So ` strconcat(getenv("HOME"), "/" DIR_IN_HOME, NULL)` would come first. Same for the config. Roughly: Assume that ~/.abook presence inhibit all the XDG mechanism (and conversely, ~/.abook absence allow for full XDG compliance). - That would avoid semi-compliance setup where only one of the variable is defined meanwhile ~/.abook still exist. - And also because switching to XDG datafile must really be done voluntarily by users instead of semi-automatically. (Users may have to change their backup scripts for example ...) Hope it helps, and makes sense. and thank you again for the contribution. Best regards and happy new year. On Sun, Nov 29, 2020 at 10:30:01AM +0100, Andreas Grapentin wrote: > Hello, > > I’ve seen that there’s been some interest in adding XDG specification support to the way that abook determines its directories for data and config files in this feature request: > > https://sourceforge.net/p/abook/feature-requests/13/ <https://sourceforge.net/p/abook/feature-requests/13/> > > The attached patch attempts to fulfil that request by applying the following changes to abook.c: > > in abook_check_directory: > - determine whether XDG_DATA_DIR is set in the environment, and if not, default to $HOME/.local/share/ as per the specification > - determine whether XDG_DATA_DIR/abook exists, and, if not > - determine whether HOME/.abook exists, and, if not > - create HOME/.abook > > in short, do not create HOME/.abook if a supported location — including the XDG specified HOME/.local/share/abook — exists. > > in set_filenames for datafile: > - determine whether XDG_DATA_DIR is set in the environment, and if not, default to $HOME/.local/share/ as per the specification > - determine whether XDG_DATA_DIR/abook/addressbook exists > - if it exists, use it as datafile, otherwise continue with the previous behaviour > > in set_filenames for configfile > - determine whether XDG_CONFIG_DIR is set in the environment, and if not, default to $HOME/.local/share/ as per the specification > - determine whether XDG_CONFIG_DIR/abook/abookrc exists > - if it exists, use it as configfile, otherwise continue with the previous behaviour > > This behaviour is identical to the previous behaviour on existing installations, and will produce expected behaviour on future installations, while allowing users to customise their installation by moving their data folder to the XDG specified location, where abook will then be able to pick it up with the changes. > > Documentation changes are included in the patch. > > If you want anything changed with this patch, please let me know. I’ll happily go through a couple of iterations to get this right :) > > Thanks for your time, > Andreas |
From: Andreas G. <an...@gr...> - 2020-11-29 09:30:16
|
Hello, I’ve seen that there’s been some interest in adding XDG specification support to the way that abook determines its directories for data and config files in this feature request: https://sourceforge.net/p/abook/feature-requests/13/ <https://sourceforge.net/p/abook/feature-requests/13/> The attached patch attempts to fulfil that request by applying the following changes to abook.c: in abook_check_directory: - determine whether XDG_DATA_DIR is set in the environment, and if not, default to $HOME/.local/share/ as per the specification - determine whether XDG_DATA_DIR/abook exists, and, if not - determine whether HOME/.abook exists, and, if not - create HOME/.abook in short, do not create HOME/.abook if a supported location — including the XDG specified HOME/.local/share/abook — exists. in set_filenames for datafile: - determine whether XDG_DATA_DIR is set in the environment, and if not, default to $HOME/.local/share/ as per the specification - determine whether XDG_DATA_DIR/abook/addressbook exists - if it exists, use it as datafile, otherwise continue with the previous behaviour in set_filenames for configfile - determine whether XDG_CONFIG_DIR is set in the environment, and if not, default to $HOME/.local/share/ as per the specification - determine whether XDG_CONFIG_DIR/abook/abookrc exists - if it exists, use it as configfile, otherwise continue with the previous behaviour This behaviour is identical to the previous behaviour on existing installations, and will produce expected behaviour on future installations, while allowing users to customise their installation by moving their data folder to the XDG specified location, where abook will then be able to pick it up with the changes. Documentation changes are included in the patch. If you want anything changed with this patch, please let me know. I’ll happily go through a couple of iterations to get this right :) Thanks for your time, Andreas |
From: <mi...@ac...> - 2019-01-31 18:07:51
|
From: Corey Minyard <cmi...@mv...> abook did not have the ability to add addresses from the To: or Cc: lists. This adds the ability to specify the fields to use when looking for addresses. Signed-off-by: Corey Minyard <mi...@ac...> --- abook.1 | 5 +++ abook.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 107 insertions(+), 9 deletions(-) diff --git a/abook.1 b/abook.1 index 96d665d..8460f13 100644 --- a/abook.1 +++ b/abook.1 @@ -97,6 +97,11 @@ Read an e\-mail message from stdin and add the sender to the addressbook. \fB\-\-add\-email\-quiet\fP Same as \-\-add\-email but doesn't confirm adding. .TP +\fB\-\-fields\fP \fI<fields>\fR +Comma separated list of the mail fields to look for when adding email +addresses. Defaults to "from". Adding most everything would be +"from,to,cc". +.TP \fB\-\-formats\fP List available formats. diff --git a/abook.c b/abook.c index e6cb866..19019c2 100644 --- a/abook.c +++ b/abook.c @@ -46,6 +46,7 @@ static void init_mutt_query(); static void convert(char *srcformat, char *srcfile, char *dstformat, char *dstfile); static void add_email(int); +static void set_email_fields(char *fl); char *datafile = NULL; static char *rcfile = NULL; @@ -314,6 +315,7 @@ parse_command_line(int argc, char **argv) enum { OPT_ADD_EMAIL, OPT_ADD_EMAIL_QUIET, + OPT_EMAIL_FIELDS, OPT_MUTT_QUERY, OPT_CONVERT, OPT_INFORMAT, @@ -327,6 +329,7 @@ parse_command_line(int argc, char **argv) { "help", 0, 0, 'h' }, { "add-email", 0, 0, OPT_ADD_EMAIL }, { "add-email-quiet", 0, 0, OPT_ADD_EMAIL_QUIET }, + { "fields", 1, 0, OPT_EMAIL_FIELDS }, { "datafile", 1, 0, 'f' }, { "mutt-query", 1, 0, OPT_MUTT_QUERY }, { "config", 1, 0, 'C' }, @@ -356,6 +359,9 @@ parse_command_line(int argc, char **argv) case OPT_ADD_EMAIL_QUIET: change_mode(&mode, MODE_ADD_EMAIL_QUIET); break; + case OPT_EMAIL_FIELDS: + set_email_fields(optarg); + break; case 'f': set_filename(&datafile, optarg); alternative_datafile = TRUE; @@ -792,12 +798,97 @@ add_email_add_item(int quiet, char *name, char *email) return 1; } +static char *default_email_fields[] = { + "from", + NULL +}; + +static char **email_fields = default_email_fields; + static void -add_email(int quiet) +set_email_fields(char *fl) +{ + char **f = email_fields; + unsigned int i, j, fieldcount = 1; + + if(f != default_email_fields) { + free(f[0]); + free(f); + } + for(i = 0; fl[i]; i++) { + if(fl[i] == ',') + fieldcount++; + } + if(i == 0) { + fprintf(stderr, "No fields given\n"); + exit(EXIT_FAILURE); + } + f = xmalloc(sizeof(char *) * (fieldcount + 1)); + fl = xstrdup(fl); + f[0] = fl; + for(i = 0, j = 1; fl[i]; i++) { + if(fl[i] == ',') { + fl[i] = '\0'; + if(strlen(f[j-1]) == 0) { + fprintf(stderr, "Empty field given\n"); + exit(EXIT_FAILURE); + } + f[j++] = fl + i + 1; + } + } + if(strlen(f[j-1]) == 0) { + fprintf(stderr, "Empty field given\n"); + exit(EXIT_FAILURE); + } + f[j] = NULL; + email_fields = f; +} + +static char * +mailaddr_prefix(char *line) { - char *line; + unsigned int i; + char **f = email_fields; + + for(i = 0; f[i]; i++) { + unsigned int len = strlen(f[i]); + + if(strncasecmp(f[i], line, len) == 0 && line[len] == ':') + return line + len + 1; + } + return NULL; +} + +static void +add_email_list(char *line, int quiet) +{ + char *next; char *name = NULL, *email = NULL; + + while(line) { + while(isspace(*line)) + line++; + if (!*line) + break; + next = strchr(line, ','); + if(next) + *next++ = '\0'; + add_email_found++; + getname(line, &name, &email); + add_email_count += add_email_add_item(quiet, + name, email); + xfree(name); + xfree(email); + line = next; + } +} + +static void +add_email(int quiet) +{ + char *line, *alist; struct stat s; + bool in_email_list = FALSE; if( (fstat(fileno(stdin), &s)) == -1 || S_ISDIR(s.st_mode) ) { fprintf(stderr, _("stdin is a directory or cannot stat stdin\n")); @@ -808,13 +899,15 @@ add_email(int quiet) do { line = getaline(stdin); - if(line && !strncasecmp("From:", line, 5) ) { - add_email_found++; - getname(line+5, &name, &email); - add_email_count += add_email_add_item(quiet, - name, email); - xfree(name); - xfree(email); + if(line) { + if (in_email_list && isspace(*line)) { + add_email_list(line, quiet); + } else if((alist = mailaddr_prefix(line))) { + add_email_list(alist, quiet); + in_email_list = TRUE; + } else { + in_email_list = FALSE; + } } xfree(line); } while( !feof(stdin) ); -- 2.17.1 |
From: <mi...@ac...> - 2019-01-31 18:07:49
|
From: Corey Minyard <cmi...@mv...> When adding multiple emails from a line, it's not going to work to pass in. It's really inconvenient, anyway (as you can see from the getname() uses in filter.c). So remove it before calling and don't expect it to be there in getname(). Signed-off-by: Corey Minyard <cmi...@mv...> --- abook.c | 2 +- filter.c | 9 ++------- getname.c | 8 ++++---- 3 files changed, 7 insertions(+), 12 deletions(-) diff --git a/abook.c b/abook.c index eeef5d7..e6cb866 100644 --- a/abook.c +++ b/abook.c @@ -810,7 +810,7 @@ add_email(int quiet) line = getaline(stdin); if(line && !strncasecmp("From:", line, 5) ) { add_email_found++; - getname(line, &name, &email); + getname(line+5, &name, &email); add_email_count += add_email_add_item(quiet, name, email); xfree(name); diff --git a/filter.c b/filter.c index 5ae7bd6..becec17 100644 --- a/filter.c +++ b/filter.c @@ -890,7 +890,6 @@ static void mutt_parse_email(list_item item) { char *line = item_fget(item, NAME); - char *tmp; char *name, *email; #if 0 char *start = line; @@ -898,9 +897,7 @@ mutt_parse_email(list_item item) #endif mutt_fix_quoting(line); - tmp = strconcat("From: ", line, NULL); - getname(tmp, &name, &email); - free(tmp); + getname(line, &name, &email); if(name) item_fput(item, NAME, name); @@ -917,9 +914,7 @@ mutt_parse_email(list_item item) */ #if 0 while( (start = strchr(start, ',')) && i++ < MAX_EMAILS - 1) { - tmp = strconcat("From: ", ++start, NULL); - getname(tmp, &name, &email); - free(tmp); + getname(++start, &name, &email); free(name); if(email) { if(*email) { diff --git a/getname.c b/getname.c index 3deea8c..c84d5fa 100644 --- a/getname.c +++ b/getname.c @@ -163,7 +163,7 @@ getname(char *line, char **namep, char **emailp) ** No '@' sign here so ... */ if (strchr(line, '(')) { /* From: bob (The Big Guy) */ - c = strchr(line, ':') + 1; + c = line; while (*c == ' ' || *c == '\t') c++; for (i = 0; *c && *c != '(' && *c != ' ' && @@ -182,7 +182,7 @@ getname(char *line, char **namep, char **emailp) * - check if From: uu.net!kent formatted line * - check if "From: kent" formatted line */ - c = strchr(line, ':') + 1; + c = line; while (*c == ' ' || *c == '\t') c++; for (i = 0; *c && *c != ' ' && *c != '\t' && @@ -224,7 +224,7 @@ getname(char *line, char **namep, char **emailp) */ if (strchr(line, '<')) { - c = strchr(line, ':') + 1; + c = line; while (*c == ' ' || *c == '\t') c++; @@ -268,7 +268,7 @@ getname(char *line, char **namep, char **emailp) while (*c == ' ' || *c == '\t') c++; } else if (strchr(line, '[')) { - c = strchr(line, ':') + 1; + c = line; while (*c == ' ' || *c == '\t') c++; -- 2.17.1 |
From: <mi...@ac...> - 2019-01-31 18:07:39
|
I'm switching to mutt, and adding email addresses has been a bit of a pain. So, adding things from To: and Cc: lines seemed convenient. But abook wouldn't do it. This adds that capability. I sent a previous version of this, but I think this one is more flexible and clear. |
From: Rieger A. <ab...@ji...> - 2018-08-09 15:33:05
|
Dear all, I noticed a missing German translation, so I thought to add it. In the process I looked through the complete de.po and corrected/added translations. Maybe I overlooked but I didn't find a standard way to contribute, so I'm trying it via the ML and a simple git-patch as attachment. So please review and maybe except this patch/PR. If you have another standard way to contribute translations please mention it. I'm also interested how to contribute source code Patches/PRs and discuss issues. (I've only used Github, so the this is kinda new to me) Best regards Anton Rieger |
From: ilf <il...@ze...> - 2017-07-03 11:16:46
|
Raphaël: >> mobile=+1234567890,+2345678901 > does not represent 2 cellphone in abook file format semantic (and there > is no way to do that for cellphone, contrary to email). Why does it work for email but not for cellphones? I assume the code is already there, it would just need to be adjusted? -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung |
From: Raphaël <rap...@gm...> - 2017-07-03 04:07:24
|
> mobile=+1234567890,+2345678901 does not represent 2 cellphone in abook file format semantic (and there is no way to do that for cellphone, contrary to email). Using multiple emails you'd get: > EMAIL;PREF;INTERNET:email1 > EMAIL;1;INTERNET:email2 best regards On Sun, Jul 02, 2017 at 05:02:49PM +0200, ilf wrote: > What is the correct way to enter multiple mobile phone numbers, so that they > can be correctly converted to vCard? > > This abook file: > > > [0] > > name=First Last > > mobile=+1234567890,+2345678901 |
From: ilf <il...@ze...> - 2017-07-02 15:20:43
|
What is the correct way to enter multiple mobile phone numbers, so that they can be correctly converted to vCard? This abook file: > [0] > name=First Last > mobile=+1234567890,+2345678901 results in this vcard: > BEGIN:VCARD > FN:First Last > N:Last;First > TEL;CELL:+1234567890,+2345678901 > END:VCARD …which is not valid. It should be like this: > BEGIN:VCARD > FN:First Last > N:Last;First > TEL;CELL:+1234567890 > TEL;CELL:+2345678901 > END:VCARD Is this a problem with the conversion? Or with the original abook format? Thanks, and keep up the good work! -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung |
From: Roger <rog...@gm...> - 2015-12-18 19:01:07
|
> On Fri, Dec 18, 2015 at 04:32:23AM +0000, Raf Czlonka wrote: >On Fri, Dec 18, 2015 at 01:02:54AM GMT, Roger wrote: > >> Woo. Although I use mutt, didn't realize abook could finally sort by >> last names. > >It's not in the man page but it is in the "interactive" help available >from within abook - simply press '?'. > >> However, I prefer (like many other applications) to enter the first >> and last names into separate fields. More definitive sorting when >> dealing with people's names having three names. (ie. Sir Bleekin Blah) > >What about people with two first and two last names for example? :^) > >> Also with separate fields, I can explicitly see the last name. (ie. >> surname) >> >> The following abookrc entries almost does this, except I have no idea >> how to print the last and first names within the listing view. >> >> File: .abookrc --- Snip --- field name_last = "Last Name", string >> field name_first = "First Name", string >> >> view CONTACT = name_last, name_first, name, email >> >> set sort_field=name_last --- Snip --- > >Look for 'index_format' in the manual. > Ah wonderful, I skipped over that definition. File:.abook/abookrc --- Snip --- # Declare a few custom fields field name_last = "Last Name", string field name_first = "First Name", string # Define how fields should be displayed in tabs view CONTACT = name_last, name_first, name, email # Format of entries lines in list #set index_format=" {name:22} {email:40} {phone:12|workphone|mobile}" set index_format=" {name_last:22} {name_first:10} {name:22} {email:40} {phone:12|workphone|mobile}" set address_style=us set sort_field=name_last --- Snip --- File:.abook/addressbook --- Snip --- [32] name=Roger TheGreat name_last=TheGreat name_first=Roger --- Snip --- Finally, an easier and more common method for viewing addressbook entries! (This was one of those low priority tasks on my TODO lists.) -- Roger http://rogerx.freeshell.org/ |
From: Raf C. <rcz...@gm...> - 2015-12-18 04:32:32
|
On Fri, Dec 18, 2015 at 01:02:54AM GMT, Roger wrote: > Woo. Although I use mutt, didn't realize abook could finally sort by > last names. It's not in the man page but it is in the "interactive" help available from within abook - simply press '?'. > However, I prefer (like many other applications) to enter the first > and last names into separate fields. More definitive sorting when > dealing with people's names having three names. (ie. Sir Bleekin Blah) What about people with two first and two last names for example? :^) > Also with separate fields, I can explicitly see the last name. (ie. > surname) > > The following abookrc entries almost does this, except I have no idea > how to print the last and first names within the listing view. > > File: .abookrc --- Snip --- field name_last = "Last Name", string > field name_first = "First Name", string > > view CONTACT = name_last, name_first, name, email > > set sort_field=name_last --- Snip --- Look for 'index_format' in the manual. Regards, Raf |
From: Roger <rog...@gm...> - 2015-12-18 01:03:04
|
> On Thu, Dec 17, 2015 at 08:49:12PM +0000, Raf Czlonka wrote: >On Thu, Dec 17, 2015 at 08:21:37PM GMT, Roger wrote: > >> Are there default first and last name fields, so that sorting can be >> performed by last name? >> >> According to my =app-misc/abook-0.6.0_pre2, only a Name field is >> present, and sorting is horrid as sorting is only performed by first >> name. >> >> Another option seems to be creating custom fields. >> >> Looks like there may have been patches submitted for these fields back >> in 2002. > >Hi Roger, > >In 0.6.1, released two months ago, you just press 'S' - it's capital >'S', so "Shift + S". > >You can obviously define your own fields, i.e. first, second, 1middle, >2middle, 3middle, 1last, 2last, etc. > >Personally, I like the 'name' field - it's simple[0]. > Woo. Although I use mutt, didn't realize abook could finally sort by last names. However, I prefer (like many other applications) to enter the first and last names into seperate fields. More definitive sorting when dealing with people's names having three names. (ie. Sir Bleekin Blah) Also with separate fields, I can explicitly see the last name. (ie. surname) The following abookrc entries almost does this, except I have no idea how to print the last and first names within the listing view. File: .abookrc --- Snip --- field name_last = "Last Name", string field name_first = "First Name", string view CONTACT = name_last, name_first, name, email set sort_field=name_last --- Snip --- -- Roger http://rogerx.freeshell.org/ |
From: Raf C. <rcz...@gm...> - 2015-12-17 20:49:22
|
On Thu, Dec 17, 2015 at 08:21:37PM GMT, Roger wrote: > Are there default first and last name fields, so that sorting can be > performed by last name? > > According to my =app-misc/abook-0.6.0_pre2, only a Name field is > present, and sorting is horrid as sorting is only performed by first > name. > > Another option seems to be creating custom fields. > > Looks like there may have been patches submitted for these fields back > in 2002. Hi Roger, In 0.6.1, released two months ago, you just press 'S' - it's capital 'S', so "Shift + S". You can obviously define your own fields, i.e. first, second, 1middle, 2middle, 3middle, 1last, 2last, etc. Personally, I like the 'name' field - it's simple[0]. Regards, Raf [0] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ |
From: Roger <rog...@gm...> - 2015-12-17 20:21:46
|
Are there default first and last name fields, so that sorting can be performed by last name? According to my =app-misc/abook-0.6.0_pre2, only a Name field is present, and sorting is horrid as sorting is only performed by first name. Another option seems to be creating custom fields. Looks like there may have been patches submitted for these fields back in 2002. -- Roger http://rogerx.freeshell.org/ |
From: Raphaël D. <rap...@gm...> - 2015-10-24 22:28:03
|
On Fri, Sep 25, 2015 at 02:10:52PM +0100, Raf Czlonka wrote: > There's no information about 0.6.1 release on the website[0] and only > after checking the release notes[2] in the repository had I found out > that it has been release over a month ago. Would you mind updating the > page to reflect it, please? fixed The tarball uploaded contains the version @a423ced387 instead of the 0.6.1 tags so that notable 303a43 (was already part of debian custom patches) and 8602a8d are included. - Let --datafile also work through -f short option - custom output filter: fixed a bug on 64 bit Write the list if anything is wrong with the tarball (signing, compilation, ...) -- GPG id: 0xF41572CEBD4218F4 |
From: Raphaël <rap...@gm...> - 2015-09-30 13:38:34
|
On Wed, Sep 30, 2015 at 01:51:16PM +0200, Rhonda D'Vine wrote: > This sounds extremely alarming, and given that it seems we can't get > through to Jaakko Just a quick reply that I got an email from Jaako, I now have the ability to do uploads. Will do that soon. About the sourceforge.net issue, thank you for passing the information. It's something worth thinking about. |
From: Raphaël D. <rap...@gm...> - 2015-09-28 23:42:30
|
Just pushed something similar in d7371920. > ui/interactive: when abook quits, it does not rewrite the database anymore > *if* no change has been done to the items. > > Running 2 abook instances concurrently is now less race-prone. > An indicator is added to the top line showing whether the database needs > saving on disk or not. > > Warning: The indicator *is* introduced by the commit, but to stay safe, the > change about optionnal database disk write is only effective for debug builds > (= compiled using DEBUG = `make CFLAGS=-DDEBUG`) > > Note: right now editing a field (even without changing to the contained string) is > enough to be considered a "database change" - if a field is modified in some way and the "*"-noted indicator does *not* show up => it's a bug, please report - if a field is not modified and the "*"-noted indicator show up => it's a bug, please report Starting the edition of a field is enough to imply database-modification (right it's the expected behavior, ie: "not a bug") "optional on-disk write" is only activated if abook is built using debug (make CFLAGS=-DDEBUG) In that case: - pressing "w" does not write the file on-disk anymore *if* it's considered unnecessary (since this must be a bug). Given how counter-intuitive this behavior is, we may reconsider this later. - the option has been implemented with auto-save in mind - if auto-save is off, the user is *always* asked to save before "quitting" (as before), in the event he replies "yes", the database is *always* written to disk, even if it was unmodified ("least-surprise principle") Internally a "force_save" parameter has been introduced added to database_save() in the following commit (aef4219d27) so that we can keep control over this database-change-autodetection feature. On Thu, May 08, 2014 at 02:17:07PM -0300, Raphaël Droz wrote: > Hi, > > > attached is a tricky patch: > It skip database rewrites to disk when no changes actually happened. > > > The current issue is that there is no locking/notify mechanism for the > database file and, especially if using autosave=true, multiple abook > instances imply that "latest closed wins". > > Reproducer: > - term1 run abook > - term2 run mutt, add an email (trigger abook --add-email) > # here datafile is changed on disk with the new email > - close abook in term1 > # here datafile is changed on disk, the email is lost > > > There are several ways to avoid/warn when this happens, but all of them > first needs that we avoid file rewrites when no change happened, that > means isolating write operations. > > Currently: > $ ls -i .abook/addressbook > 8535 .abook/addressbook > $ abook > # press "q" to quit > $ ls -i .abook/addressbook > 7943 .abook/addressbook > > > This is what the patch attempts to solve by marking the database "need > save" after (every) "write" operation on items. > That allowed adding a "*" indicator à la emacs to show the "db modified" > status. > > The more sensible here is to ensure that *every* possible action > implying modification of the database will really triggers > db_need_save = TRUE. > > If some are missing from the patch the related modifications will *not* > be saved to disk. That is to say that this patch has to be *sure*. > > > I need to think more about the behavior when autosave=false but IHMO > the check for "is db modified" must be activated for all *saving* > vectors, that means that pressing "w" to explicitly save the database to > disk will *not* rewrite if there is no modification. > > > I tried many (if not all) of the possible operations offered by the UI > and hope to not have missed any. But as shown by the hunk affecting edit.c, > database write operations are not strictly restricted to database.c. > Further testing welcome. > > > > Next I'd see a more robust way to handle concurrent write accesses to > datafile. I can think about file-lock and inotify and I'd rather want > to avoid any need of datafile "merge". > > > > regards -- GPG id: 0xF41572CEBD4218F4 |
From: Raf C. <rcz...@gm...> - 2015-09-25 13:11:01
|
On Fri, Sep 25, 2015 at 05:07:37AM BST, Raphaël Droz wrote: Hi all, > CC'ed abook mailng-list. > > Hi Scott, > > On Wed, Sep 23, 2015 at 11:46:43AM -0700, J. Scott Heppler wrote: > > I wanted to follow up on updating the abook port in OpenBSD. Presently > > the port uses the 2006 abook-0.5.6 code. > > > > Debian presently has pulled abook from testing but has 6.0-pre2.5 in > > unstable. > > You probably meant 0.6.0-pre2-5. > Indeed. I didn't found differing patches from Debian's 0.6.0-pre2-3 > > Side note: @Rhonda I wonder why 3be3adcf308e, which was stated to fix > the spurious data deletions, wasn't provided (Debian #727245)? > > > > In OpenBSD, the code git tagged as 6.1 does not compile while the > > unpatched Debian 6.0-pre2.5 code does. I am somewhat confused by this > > My guess: autotools was given 2 or 3 updates in the meantime. > (versioned) autogenerated files were ... autoregenerated (autoreconf -f). > > Could you post the error? > Which version of autoconf/automake are you using? > Did you tried an autoreconf / autoreconf -fiv? > > > > and was hoping you could tell me which code base the abook developers > > would like to stand behind as stable enough for release? > > Other than bugfixes, the core code wasn't much touched other than > strictly needed for implementing new features. I'd say that core > stability is intact (especially if compiled/configured to mimic the > 0.6.0-pre2: no colors, no mouse, no libvformat, no use of custom export, ...) > > But newly added features were not deeply tested. Eg: today I pushed > something (8602a8d5) fixing a bug laying around for 7 months (affecting > one of the "new features"). > Anyway I'd say that packaging the 0.6.1 in a experimental-like repository > is safe enough. There's no information about 0.6.1 release on the website[0] and only after checking the release notes[2] in the repository had I found out that it has been release over a month ago. Would you mind updating the page to reflect it, please? I was meant to get in touch earlier regarding possible updates to the OpenBSD port[2] but only subscribed to the mailing list last week (hence my email) - looks like Scott beat me to it :^) Regards, Raf [0] http://abook.sourceforge.net/ [1] http://sourceforge.net/p/abook/git/ci/master/tree/RELEASE_NOTES [2] https://marc.info/?l=openbsd-ports&m=143574632308538 |
From: Raphaël D. <rap...@gm...> - 2015-09-25 04:07:49
|
CC'ed abook mailng-list. Hi Scott, On Wed, Sep 23, 2015 at 11:46:43AM -0700, J. Scott Heppler wrote: > I wanted to follow up on updating the abook port in OpenBSD. Presently > the port uses the 2006 abook-0.5.6 code. > > Debian presently has pulled abook from testing but has 6.0-pre2.5 in > unstable. You probably meant 0.6.0-pre2-5. Indeed. I didn't found differing patches from Debian's 0.6.0-pre2-3 Side note: @Rhonda I wonder why 3be3adcf308e, which was stated to fix the spurious data deletions, wasn't provided (Debian #727245)? > In OpenBSD, the code git tagged as 6.1 does not compile while the > unpatched Debian 6.0-pre2.5 code does. I am somewhat confused by this My guess: autotools was given 2 or 3 updates in the meantime. (versioned) autogenerated files were ... autoregenerated (autoreconf -f). Could you post the error? Which version of autoconf/automake are you using? Did you tried an autoreconf / autoreconf -fiv? > and was hoping you could tell me which code base the abook developers > would like to stand behind as stable enough for release? Other than bugfixes, the core code wasn't much touched other than strictly needed for implementing new features. I'd say that core stability is intact (especially if compiled/configured to mimic the 0.6.0-pre2: no colors, no mouse, no libvformat, no use of custom export, ...) But newly added features were not deeply tested. Eg: today I pushed something (8602a8d5) fixing a bug laying around for 7 months (affecting one of the "new features"). Anyway I'd say that packaging the 0.6.1 in a experimental-like repository is safe enough. > I also have noted that the newer version now has a solid line in the > contacts panel above email2. Is this intentional or a minor bug? I did > not see it mentioned in the changelogs. I don't understand: http://i.imgur.com/W1kvStu.jpg I don't see solid line between email1 and email2. You may have resized the virtual terminal window: it more than often corrupts the display until it got refreshed? best regards |
From: Raphaël D. <rap...@gm...> - 2015-08-14 01:16:29
|
On Thu, Aug 13, 2015 at 05:21:35PM +0200, Rhonda D'Vine wrote: > * Raphaël Droz <rap...@gm...> [2015-08-11 16:50:04 CEST]: > > Abook 0.6.1 tagged: https://sourceforge.net/p/abook/git/ci/master/tree/ > I don't see a tag there. :) I take it you will tag 6b6a47393127 with ver_0_6_1? thanks for the report. Indeed I just pushed said tag. |
From: Raphaël D. <rap...@gm...> - 2015-08-11 14:50:15
|
Abook 0.6.1 tagged: https://sourceforge.net/p/abook/git/ci/master/tree/ Hopefully the git repository as been well-tested during last years and no regression will pop up now. Please have a look at RELEASE_NOTES and ChangeLog files. thanks to everybody |
From: Raphaël <rap...@gm...> - 2015-08-11 13:55:53
|
On Sun, Aug 09, 2015 at 12:04:54PM +0000, Jorrit Tijben wrote: > The issue has been fixed in git [2] but abook hasn't seen an official > release for some time now. I'm not sure whether a release is planned at all, > maybe someone else can answer this? I've no problem tagging "0.6.1" the current git master's HEAD. (I'll will do that soon, after a quick version-change-commit) But for the release/tarball stuff I don't have upload permissions on sourceforge nor I've HTML edit permissions on the SF.net "website" (@Jaakko) About Debian, wasn't the patch part of the previous package versions? -- GPG id: 0xF41572CEBD4218F4 |
From: Jorrit T. <jo...@ti...> - 2015-08-09 12:36:09
|
On Sun, Aug 09, 2015 at 01:28:08PM +0200, Denis Briand wrote: > Hello, > We have found a grave bug in abook on Debian GNU/Linux. > see: http://bugs.debian.org/727245 [...] See the relevant discussion on the abook-devel mailing list [1]. Make sure to click 'view entire thread' at the bottom. The issue has been fixed in git [2] but abook hasn't seen an official release for some time now. I'm not sure whether a release is planned at all, maybe someone else can answer this? Kind regards, Jorrit Tijben [1] http://sourceforge.net/p/abook/mailman/message/24506494/ [2] http://sourceforge.net/p/abook/git/ci/3be3adcf308ee7c9c8775e2176d0592138b220ed/ |