Re: Changing default key

Hi Scott,

I see basically the same behaviour as you with my .pybrc.py file.

I always type Webster, Scott, or Webster, S. to get the desired key.

As you describe, presumably you could modify the Author.__init__
method to get
your preferred input format to work. Or you could hack your .pybrc.py
some more to split each
'last' variable on upper case, and just keep the final part, or
something. I guess it might be hard to write something which
satisfies everybody at once though!

If you're using bibtex (or anything else, I guess) you should also
double check that the final produced .bib file is processed correctly
by latex/bibtex. It is for me, but I've managed to break this in the
past with other programs.

hope that helps,

Dave

---- Message from Scott Webster <[email protected]> at 2005-02-03
14:20:00 ------
>I finally got around to trying out my own key generating routine, but
>have run into a problem.  I also tried David Evans .pybrc.py which he
>forwarded to the list on Nov. 18 last year, and it has the same
>problem for me.
>
>The problem is that everything I type into the author box becomes the
>"last name" of the author.  So, for instance, the line:
>
>honorific, first, last, lineage = aut [0].format ()
>
>in the key generation routine returns:
>
>(None, None, 'Scott Webster', None)
>
>if I entered "Scott Webster" (without quotes) into the author field.
>
>This obviously causes the keys to be mangled.
>
>So, for example, if I use David Evans .pybrc.py which should
generate format:
>
>AuthorBCDYY, where Author is the surname of the first author, B,C etc
>the first letters of the surnames of subsequent authors, and YY the
>last two digits of the year.
>
>then for an entry with authors "Scott Webster" and "Tom Tiedje"
>(entered on separate lines) with a year of "2000" the key is:
>
>ScottWebsterWTT00
>
>Because it put "ScottWebster" as the "last" name of the first author,
>then went through and picked up initials... but the initials are not
>the initials of the last names, but rather all initials, since it
>thinks the whole thing is the last name.
>
>I tried looking at the Author class in Fields.py, and this appears to
>be consistent with "strict" behaviour, but I am not sure where that
>gets decided.
>
>I have developed a work around for myself, since you can deal with
the
>situation if you know what to expect, but this doesn't seem ideal.
>
>It would appear that this isn't the case for everyone though, or else
>it wouldn't work for David Evans either.  Anyone have any ideas?
>
>Thanks,
>
>Scott Webster
>
>On Thu, 18 Nov 2004 11:27:29 +0000, david.evans-I9fZos/[email protected]
><david.evans-I9fZos/[email protected]> wrote:
>> Hello,
>> 
>> My last post was sent before receiving this one. Thank you for the
>> pre-emptive reply :-)
>> I've just tested my key-generating routine by putting it in
.pybrc.py
>> instead of Utils.py, and it seems to work perfectly. Python is a
>> wonderful thing :-) I'd ignore my previous suggestions to modify
>> Utils.py, unless you really want to change the configuration for
the
>> whole system.
>> 
>> my new .pybrc.py is attached, and generates keys of format
>> AuthorBCDYY, where Author is the surname of the first author, B,C
etc
>> the first letters of the surnames of subsequent authors, and YY the
>> last two digits of the year.
>> 
>> Thanks again
>> 
>> Dave
>> 
>> ---- Message from Frederic Gobry <[email protected]> at 2004-11-18
>> 12:02:43 ------
>> >> Some other people had already answered some topics, but as I
don't
>> know
>> >> anything about the python language, I have some doubts regarding
>> the
>> >> changed that are requested to create a new type of key.
>> >
>> >Well, a good thing would be to collect existing functions for
their
>> >inclusion in the official distribution.
>> >
>> >So if you've written a function, please consider sending it along
>> with a
>> >description of how it formats the key :-)
>> >
>> >> 1. We define a new type of entry code in
>> >> /usr/share/pybliographer/Pyblio/Utils.py including the statement
>> >> Autoload.register ("key", "MyKey", generate_my_key)
>> >
>> >Alternatively, you can write this function in ~/.pybrc.py, which
has
>> the
>> >advantage of not being overwritten when you install a new version
of
>> >pyblio.
>> >
>> >> 2. After this, we need to run pybliographic in order to change
the
>> >> desired new key under the preference menu.
>> >
>> >Right.
>> >
>> >> As I know, python is a scripting language (please correct me if
I
>> am
>> >> wrong) but I saw some .py.c and .py.o files. It is necessary to
>> perform
>> >> some kind of compilation onder Utils.py after changes?
>> >
>> >These files are automatically generated by pyblio when needed.
They
>> are
>> >here to improve the startup time, but you can safely ignore them
and
>> >consider python as a scripting language.
>> >
>> >Frédéric
>> >
>> 
>> 
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive
Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF,
etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Pybliographer-general mailing list
>Pybliographer-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/pybliographer-general
>
>
>


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl