Considering that list indentation is a form of compression, this BBEdit
script *sort_and_merge_indented_list.applescript*
<https://gist.github.com/mixio/2a31288be50061f3350a119c24a88b49#file-sort_and_merge_indented_list-applescript>
decompresses
the list, sorts it with the shell `sort` command, and compresses it back
again.
In doing so, the indented list will be sorted, sub lists will be merged and
duplicates will be eliminated.
For sorting options (case insensitive, etc.) see the `sort` man page in
terminal and adapt the do shell script according to your needs.
This script work on the selection of the front document or on the whole
document if nothing is selected. Selected lines should cover whole
sub-lists appropriately to make sense.
By default the script accepts TAB or 4 SPACES indented lists but outputs
TAB indented lists.
If you'd prefer a final 4 SPACES indented list, change the `vIndentation`
variable.
INSTALL
Copy this script to ~/Library/Library/Application\
Support/BBEdit/Scripts/sort_and_merge_indented_list.applescript
Call it from BBEdit's AppleScript menu.
HTH,
Jean Jourdain
On Wednesday, October 12, 2022 at 9:59:34 PM UTC+2 Harvey Pikelberger wrote:
> What comes to mind that might work would be to layer on (and eventually
> migrate to) a database-managed system.
> As an approach it's not necessarily super easy, but it's also not
> impossible or beyond the reach. FileMaker is actually a pretty good /
> easy-to-learn system for this kind of stuff.
> There's a TROI plugin for it that handles metadata. Even better (if you
> have the patience) is to build your own metadata integration using
> something like exiftool (an open source command line app, very powerful)
> which, with a little jujitsu, integrates with FMP very nicely.
>
> Process would go something like this:
> Database that includes a "Photos" table.
> From each photo you extract a list of all associated keywords
> Each new keyword is added to a "Keywords" table in the same database. Any
> duplicate keyword is not added.
> Each item in the Photos table "knows" its associated keywords by means of
> a reference to the Keywords table.
>
> The icing on the cake would be to not only extract but also push-to-update
> those keywords into the IPTC metadata of each individual photo in such a
> way that PM continues to recognize them -- so you use both your custom
> solution and PM seamlessly with each other.
>
> All that assumes you even need embedded keywords. If the point is to
> coordinate how images are presented on a web page or how they appear in web
> searches, you might be able to forego the IPTC data altogether and handle
> everything via database + dynamic web pages with keywords attached.
>
> It can take a while to figure out the best approach, but it sounds like
> you're doing cool stuff.
>
> On Wednesday, October 12, 2022 at 12:23:10 PM UTC-7
> [email protected] wrote:
>
>> Got it, thanks. It's fine, I know it's a complex topic. The 'assets' in
>> this particular case is my keyword library. I love PM, but the limitations
>> it has with managing a keyword library in-program is a severe limitation. A
>> change of any real size clearly needs to be done through a second program
>> and then loaded back into PM.
>> Yeah, I'll want duplicates removed. I've deleted them manually for this,
>> but it's not ideal in a long term solution.
>> PM uses IPTC metadata, and they're linked on a per-photo basis, you're
>> correct. I use PM to attach appropriate keywords to each image and then
>> upload them to my archive site. The structured keyword feature of PM lets
>> me attach them faster and more consistently to a group of many related
>> images. It's just unfortunate that it's not easier to manage the keywords
>> themselves through the program.
>> -Matt
>>
>> On Wednesday, October 12, 2022 at 1:49:24 PM UTC-4 Harvey Pikelberger
>> wrote:
>>
>>> Basically I'm using JavaScript as the solution, and my impression is a
>>> reliable solution might take a while to develop.
>>>
>>> For instance, the 2nd list you sent tripped up the original JS solution
>>> because it included keywords with spaces.
>>> No big deal / easy enough to tweak, but kind of shows how one fix
>>> reveals underlying additional challenges.
>>>
>>> So check this out: You might notice that the case-insensitive sorted
>>> list reveals a lot of duplicate keywords.
>>> I imagine you'd want those removed, which in turn would involve
>>> preserving but not duplicating sub-keywords.
>>>
>>> I'm not familiar with Photo Mechanic, but apparently it uses IPTC
>>> metadata. I wonder if that means the keywords are embedded into the
>>> metadata on a per-photo basis. The best solution would involve better
>>> understanding the underlying logic (along with the idiosyncratic quirks) of
>>> the software + knowing what you're trying to achieve (and how that might
>>> evolve).
>>>
>>> Apologies for the not-so-concise answer here. Asset management can get
>>> pretty involved. imho, everything off-the-shelf has frustrating limits.
>>> And the solution to that -- building out custom solutions -- has a steep
>>> learning curve.
>>>
>>
--
This is the BBEdit Talk public discussion group. If you have a feature request
or need technical support, please email "[email protected]" rather than
posting here. Follow @bbedit on Twitter: <https://twitter.com/bbedit>
---
You received this message because you are subscribed to the Google Groups
"BBEdit Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/bbedit/23d27f1f-1a6b-40e2-9106-3d6a6108c6f6n%40googlegroups.com.
