Re: [Bibdesk-users] Store files in different loctions

[Curtis C. <cur...@ma...>]

On May 31, 2005, at 1:56 PM, Christiaan Hofman wrote:

>
> On May 31, 2005, at 21:24, Maxwell, Adam R wrote:
>
>>
>> On May 31, 2005, at 11:10, Christiaan Hofman wrote:
>>
>>>
>>> On May 31, 2005, at 19:52, Maxwell, Adam R wrote:
>>>
>>>
>>>>
>>>> On May 31, 2005, at 09:37, Geoffrey Simms wrote:
>>>>
>>>>
>>>>> On a related note, I have had a couple of articles with slashes 
>>>>> "/" within the title, and using the title as part of the autofile 
>>>>> filename, they got filed in a subdirectory even though I didn't 
>>>>> want this. I just tested this again with 1.0RC2 and it still 
>>>>> behaves that way.
>>>>>
>>>>> Perhaps string fields embedded in autofile names should be escaped 
>>>>> to prevent inadvertent subdirectory filing, but directory 
>>>>> separators should be allowed in the overall autofile naming 
>>>>> template.
>>>>>
>>>>
>>>> This should not happen.  Please file a bug report at 
>>>> <http://sourceforge.net/tracker/?group_id=61487&atid=497423> so we 
>>>> can track this issue and fix it.
>>>>
>>>> thanks,
>>>> Adam
>>>>
>>>>
>>>
>>> Hmm, I actually have sort of the opposite: I use a field containing 
>>> the slashes, which I _want_ to use to build a subdirectory 
>>> structure. I am not sure how we should handle this in general. 
>>> Replace "/" for certain fields (such asTitle), or perhaps all fields 
>>> but based on a preference option?
>>
>> Yes, I realized the same thing shortly after I sent that message, 
>> since I do the same thing that you mention.  Maybe we could have a 
>> checkbox for "replace slashes in standard fields", which would only 
>> operate on btxdoc-defined fields?  I'm not sure if there is a clean 
>> way to do this, though.
>>
>> Adam
>>
>
> We have no simple way to find the btxdoc defined fields (though the 
> information is in TypeInfo, but it is not directly accessible at the 
> moment).
>
> Maybe we could have 3 options:
>
> Replace "/" in generated format values with string:  [ - ]  for:
> 1. Never replace
> 2. Standard formats %t, %a (and %k, %y, %m ?), but not in custom 
> fields (%f, %c)
> 3. All generated values

It seems like the safest option might be to escape all generated values 
unless the format string specifically says not to.  A new format 
specifier could have the meaning "don't escape the string generated by 
the next format specifier".

This design would not break for "normal" users if they put a "/" in a 
field without thinking about auto-file.  At the same time the design 
would let power users use whatever field trickery that want.  And 
perhaps most importantly, this design doesn't require the user to 
mental track some table of which fields will be escaped and which won't 
be.  If it is challenging to decide which fields should have which 
behavior, it will be even more difficult to remember what the decision 
was.

Just my 2 cents.

Cheers,

Curt

----------------------------------
Curtis Clifton, PhD Candidate
Dept. of Computer Science, Iowa State University
http://www.cs.iastate.edu/~cclifton