BBEdit capabilities and scripting
Tim Gray
irreplaceable. I have a couple of comments/questions about it
though. This is more meant to generate discussion; are there things
that I'm missing? Are there things we could do as a community (maybe
with the help of Barebones) to collect scripts, clipping sets, etc. to
make the program more usable?
The biggest thing I can think of is the fact that even though BBEdit
is incredible powerful, most people don't realize all that it can do.
Built in capabilities like Tag Maker and Clippings seem to escape many
users. Clippings in particular are very powerful. It's a shame there
aren't better built in clipping sets to demonstrate their usage and
provide with better out-of-the-box usability.
The same goes for Applescripts. One of BBEdit's best features is it's
ridiculous scriptability. However, a lot of people can't seem to get
their head around Applescript. I know I can't. I do some some stuff
with it in BBEdit, but when I just want to really crunch some text, I
usually write a Unix filter instead. I just found a great Applescript
to pipe text through command line utilities, written by Jim C. Why
aren't scripts like this shipped with BBEdit, or at least made
available in one place as a separate download?
I really wish BBEdit was more scriptable with Unix scripting
languages. Unix filters are great for what they are, but it's hard to
make them do much more than filter. The Unix scripts function seems
to be seriously hampered. If only the scripts run from the Unix
scripting menu were given a bit more information, one could do a lot
more with them. Is there anyway those scripts could be passed
information through the environment (or as arguments)? It would be
greatly appreciated if the currently active file and line number/
character position was made available. I could do away with a lot of
hybrid Applescript/shell scripts I have and greatly simplify things.
Sorry if this is just a couple of half-baked thoughts...
G. T. Stresen-Reuter
> Clippings in particular are very powerful. It's a shame there
> aren't better built in clipping sets to demonstrate their usage and
> provide with better out-of-the-box usability.
If you can give a concrete example of a missing usage, I'm sure
someone can produce (or find) a clipping that can do it.
I look forward to reading your reply.
Sincerely,
Ted Stresen-Reuter
http://tedmasterweb.com/php-bbedit-clipping-set/
Doug McNutt
>A whole lot of good stuff
Amen!
Let's have a real UNIX connectivity. Have a look at Linux' gedit tools. They are anything but perfect but a wise software supplier could easily increase the capabilities of the linkage. And there are those who accept only gnu free software but I am not one of them.
I keep thinking that I should just dot it but at age 74 I worry that I just can't get it all done myself.
--
Applescript syntax is like English spelling:
Roughly, though not thoroughly, thought through.
Charlie Garrison
On 16/06/09 at 7:03 PM -0600, Doug McNutt
<doug...@macnauchtan.com> wrote:
>Let's have a real UNIX connectivity. Have a look at Linux'
>gedit tools. They are anything but perfect but a wise software
>supplier could easily increase the capabilities of the linkage.
>And there are those who accept only gnu free software but I am
>not one of them.
Can you give an example? Between all of the following I'm not
sure what else I'd want for "UNIX connectivity":
- unix filters
- unix scripts
- bbedit/bbdiff
- worksheets
- run current script
- did I miss anything?
And of course if you are willing to include osascript/osacompile
in the mix, then pretty much anything you can think of (that is
at all scriptable) should be possible.
Charlie
--
Charlie Garrison <garr...@zeta.org.au>
PO Box 141, Windsor, NSW 2756, Australia
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt
Maarten Sneep
> And of course if you are willing to include osascript/osacompile
> in the mix, then pretty much anything you can think of (that is
> at all scriptable) should be possible.
No, that is the *only* thing that is missing. While BBEdit is running a
unix script or filter, it will not respond to AppleEvents.
The following bash script, when run from the BBEdit #! menu will actually
not quit BBEdit, but send it in an infinite loop instead (cancel with
cmd-.). Just to be sure: try it at your own risk, I haven't tried it in a
while, the issue may have been resolved by now... Just make sure you don't
have any unsaved documents.
#!/bin/bash
osascript -e 'tell application "BBEdit" to quit
# end of script
This limitation - and the wish to resolve it - is already in the request
database, but to the best of my knowledge it has not been resolved yet.
Maarten
Tim Gray
wrote:
> If you can give a concrete example of a missing usage, I'm sure
> someone can produce (or find) a clipping that can do it.
people might get ideas on how to make their own. However, I don't
even think there are any provided sets with some of the languages,
like Python...
Tim Gray
> Can you give an example? Between all of the following I'm not
> sure what else I'd want for "UNIX connectivity":
>
> - unix filters
> - unix scripts
information from BBEdit as to what's going on in the editor. I have a
couple scripts that use rsync to sync some websites, etc., but you
could do a lot more if they had access to what file you are currently
editing and what line you were on.
Harold Tessmann III
Someone else has pointed out that BBEdit doesn't respond to
AppleEvents while running a UNIX script or filter, but does it respond
to them while running an AppleScript (he asks at work, with only
Windows machines handy)? If so, it seems like a pretty easy workaround
to write a launcher AppleScript and then use osascript to retrieve the
frontmost window info, cursor position, etc. Not ideal perhaps, but
it'll get the job done.
Harold, who can't decide whether asking about the reentrancy of a text
editor makes this conversation awesome or overly nerdy
Charlie Garrison
On 18/06/09 at 3:33 PM -0700, Tim Gray <tg...@125px.com> wrote:
>Unix scripts for sure are hobbled by the fact they they get zero
>information from BBEdit as to what's going on in the editor. I have a
>couple scripts that use rsync to sync some websites, etc., but you
>could do a lot more if they had access to what file you are currently
>editing and what line you were on.
I hadn't looked at their (possible) use like that before. If a
unix script had access to some of that, then I can see quite a
few AppleScripts being replaced with Unix Scripts.
The blocking of AppleEvents during the Unix Script run does seem
very limiting though. Hmm, I think I ran into that ages ago and
just went with AppleScripts instead, so forgot about that limitation.
If you have the current characters/lines, file path, etc
available in ENV in a unix script, what do you want to do with
that info? If the document is not saved, I can't count on the
on-disk version being the same, so current selected text ranges
would not be reliable. And the text contents are not available
via AppleEvents.
So, if we could have "information" in ENV for Unix Scripts as
well as access to BBEdit through AppleEvents, I can see much
greater use for them. But at the same time, I can't think of any
examples of anything I might choose a Unix Script for, that I
can't also do fairly easily via an AppleScript. In the case of
complex unix script, I just use AppleScript as glue to set up
environment variables, command arguments, etc.
I'm curious to know what current situations Unix Scripts are
being used for. Who's using them?
G. T. Stresen-Reuter
So, would a set of clippings for doing completion of Python functions/
methods be useful to you?
Also, the manual has a very complete reference on how to create
clippings.
Ted
Maarten Sneep
> Someone else has pointed out that BBEdit doesn't respond to
> AppleEvents while running a UNIX script or filter, but does it respond
> to them while running an AppleScript (he asks at work, with only
> Windows machines handy)? If so, it seems like a pretty easy workaround
> to write a launcher AppleScript and then use osascript to retrieve the
> frontmost window info, cursor position, etc. Not ideal perhaps, but
> it'll get the job done.
Fairly pointless: the point of OSAscript is to use AppleScript snippets
from other languages. If you are already in AppleScript, then you don't
really need this.
My BBEdit-TeX integration scripts start with a series of AppleScripts,
that then call a shell script to do the actual work. Some parts are
completely performed in AppleScript, but I don't like the vagueness of its
syntax.
> Harold, who can't decide whether asking about the reentrancy of a text
> editor makes this conversation awesome or overly nerdy
If this results in getting AppleEvents for BBEdit in other languages
(Python, Ruby), then I vote for awesome.
Maarten
Tim Gray
> If you have the current characters/lines, file path, etc
> available in ENV in a unix script, what do you want to do with
> that info? If the document is not saved, I can't count on the
> on-disk version being the same, so current selected text ranges
> would not be reliable. And the text contents are not available
could do a bit more. Anyways, I could always install something like
Appscript if I actually needed to control BBEdit. But here's an
example - change the permissions on the current file. A shell script
might look something like this:
--------
#! /bin/sh -
chmod 755 ${BBEDIT_FILE}
--------
whereas my Applescript version looks like this:
--------
tell application "BBEdit"
set mypath to get file of active document of window 1
end tell
set cmd to "chmod 755 " & (quoted form of POSIX path of mypath)
do shell script cmd
--------
The Applescript is obviously short, but for certain activities, it
makes a lot more sense just to do it directly in a unix script.
> I'm curious to know what current situations Unix Scripts are
> being used for. Who's using them?
their appropriate webservers, and another one crawls a local website
folder and auto generates some pages. I'd be curious to know what
other people use them for too.
Tim Gray
wrote:
>
> methods be useful to you?
>
> Also, the manual has a very complete reference on how to create
> clippings.
for a long time I've visualized clippings as useful for only pasting
in chunks of text like "#! /bin/sh -", but can be a lot more useful
once you start adding insertion points, etc. To be honest, seeing
what some of the built in snippets that Textmate comes with opened my
eyes a bit to ways I could work more efficiently. I think beefing up
the examples BBEdit came with would help a lot of people in terms of
providing them more functionality and giving better examples on how to
extend things themselves when the time comes.
G. T. Stresen-Reuter
I understand what you mean about having more robust and more capable
clipping sets but I think I need a little more direction, personally,
if you would like me to create one for you.
For example, the PHP clipping set includes a fairly complete class
definition clipping but honestly, even though I created it, I've only
used it once or twice (in the 4 or 5 years it's been in there).
Why is that? Is it possible that although it includes the kitchen sink
that it's simply too much for most of my needs?
Simdude suggested having a clipping for C++: "This would be great to
do something like type "sing" f5 and have a Singleton pattern come up
waiting for the class name."
I tend to agree (although I'm not sure I understand exactly what he's
saying). In PHP there is a fairly robust way to set up the Singleton
pattern (that keeps people from circumventing the limitation on
running a single instance) but I've only had to write a singleton
function 3 or 4 times in the past coulpe of years.
I think the goal of clippings (and I may be wrong about this), is to
minimize frequently REPEATED typing tasks.
A new version of the PHP clipping set will include sq and dq (single
quote and double quote): insert a pair of quotes and drop the
insertion point in between them. This is something I do ALL THE TIME.
Using a clipping for such a small amount of input may actually be more
keystrokes than just typing single quote + single quote + (command +
left arrow) but for me (on a Spanish keyboard on a MacBook Pro) I find
that particular sequence of keystrokes to be awkward and fairly prone
to error. Typing "sq" and Enter (or Tab) and have the insertion point
be right where I need it just seems better to me, especially since it
is something I do all the time.
Note that the existing PHP clipping set includes clippings for all the
control structures (that I'm aware of). Yes, the clippings could be
more refined, but I really need to know what people need in order to
be able to refine them so please don't be shy...
I recently posted a jquery clipping set to this list for someone who
requested it. As usual, I never heard back from that person, not even
a "hey thanks! That was nice of you to invest the time in creating it
and not even charging me for it even though you have a job, a wife, a
house and two kids to pay for..."
In short, I'm happy to try and help but I really need clear
instructions on what you are looking for (examples, please, I need
examples) and some sort of recognition when my efforts are appreciated
(don't we all?)
And Tim, none of this is directed at you in particular. Your
contributions, ideas, and thoughts are all very much appreciated!
Sincerely,
Ted Stresen-Reuter
http://tedmasterweb.com
Patrick Woolsey
[...]
>No, that is the *only* thing that is missing. While BBEdit is running a
>unix script or filter, it will not respond to AppleEvents.
>
>This limitation - and the wish to resolve it - is already in the request
>database, but to the best of my knowledge it has not been resolved yet.
I regret that due to the nature of this issue, the situation is unlikely to
change.
Fortunately, you can easily work around this by running such scripts from
outside BBEdit (e.g. from the system "Scripts" menu, or via LaunchBar/
QuickSilver).
Regards,
Patrick Woolsey
==
Bare Bones Software, Inc. <http://www.barebones.com>
P.O. Box 1048, Bedford, MA 01730-1048
Carlton Gibson
For example, the PHP clipping set includes a fairly complete class
definition clipping but honestly, even though I created it, I've only
used it once or twice (in the 4 or 5 years it's been in there).
Why is that? Is it possible that although it includes the kitchen sink
that it's simply too much for most of my needs?
I tend to agree (although I'm not sure I understand exactly what he's
saying). In PHP there is a fairly robust way to set up the Singleton
pattern (that keeps people from circumventing the limitation on
running a single instance) but I've only had to write a singleton
function 3 or 4 times in the past coulpe of years.
I think the goal of clippings (and I may be wrong about this), is to
minimize frequently REPEATED typing tasks.
A new version of the PHP clipping set will include sq and dq (single
quote and double quote): insert a pair of quotes and drop the
insertion point in between them. This is something I do ALL THE TIME.
Note that the existing PHP clipping set includes clippings for all the
control structures (that I'm aware of). Yes, the clippings could be
more refined, but I really need to know what people need in order to
be able to refine them so please don't be shy...
I recently posted a jquery clipping set to this list for someone who
requested it. As usual, I never heard back from that person, not even
a "hey thanks! That was nice of you to invest the time in creating it
and not even charging me for it even though you have a job, a wife, a
house and two kids to pay for..."
Tim Gray
wrote:
> Why is that? Is it possible that although it includes the kitchen sink
> that it's simply too much for most of my needs?
comprehensive set for it years ago. However there's so much in there
that a more streamlined 'smarter' set would be more useful. It's on
my todo list.
> I think the goal of clippings (and I may be wrong about this), is to
> minimize frequently REPEATED typing tasks.
function clipping would be great. More than just "def #insertion#():"
for Python for example. I started playing around with this the other
day:
---
#INDENT#def #selstart##selectionorplaceholder function##selend#
(#selstart# args #selend#):
"""#selstart# docstring for #selection# #selend#"""
#selstart# body of function #selend#
---
However, I'm thinking of writing a language aware Applescript to
generate functions, either empty ones or language specific ones (like
__init__ for Python). I've already got a rudimentary version of it
working for Python, but I would like to expand it. Maybe next week.
Do any of you think it would be good to have a central repository for
clippings and scripts? Maybe something that Barebones could host? And
if some of the sets/scripts/etc. were polished enough, maybe they
could be bundled with the application...
G. T. Stresen-Reuter
> Hi Ted,
>
> I use the PHP clippings all the time (they're a god send when it
> comes to remembering function signatures: "Which one is it this
> time: needle-haystack or haystack-needle? Who knows? God bless
> PHP!" ;-) My thoughts on them, inter-spaced with yours from today,
> are these:
>
> 1) There's the outstanding issue about the spacing. I (still)
> haven't had the chance to work through your existing XSLT but
> allowing a more compact template should be possible (yes?)
I've got that "fixed". I'm trying to follow the Zend coding style (but
they don't give much detail on spacing, just some examples). They are
very similar, though not identical to, the PEAR coding style.
> On 19 Jun 2009, at 13:46, G. T. Stresen-Reuter wrote:
>
>> For example, the PHP clipping set includes a fairly complete class
>> definition clipping but honestly, even though I created it, I've only
>> used it once or twice (in the 4 or 5 years it's been in there).
>
>> Why is that? Is it possible that although it includes the kitchen
>> sink
>> that it's simply too much for most of my needs?
>
>
> I found this too big. Rather I've created an empty class outline and
> then clippings for functions (allowing for PPP status) -- these
> allow me to build up a class as I go.
That's precisely the experience I've had: the clippings are better off
being small, discrete chunks of code.
> I also have doc-block clippings.
Shall we integrate this into the PHP set? I've been toying with
writing one myself to see if that encourages me to document my code
more (not likely, but worth a try).
>> I tend to agree (although I'm not sure I understand exactly what he's
>> saying). In PHP there is a fairly robust way to set up the Singleton
>> pattern (that keeps people from circumventing the limitation on
>> running a single instance) but I've only had to write a singleton
>> function 3 or 4 times in the past coulpe of years.
>
>> I think the goal of clippings (and I may be wrong about this), is to
>> minimize frequently REPEATED typing tasks.
>>
>> A new version of the PHP clipping set will include sq and dq (single
>> quote and double quote): insert a pair of quotes and drop the
>> insertion point in between them. This is something I do ALL THE TIME.
>
> I have a singleton clipping but I tend to agree with you that
> they're best for REPEATED typing tasks. (The Singleton pattern is
> perhaps an exception in that there is, until PHP 5.3 at least, one
> stereotyped way of doing it; I'm not sure this holds true for other
> patterns...)
As I work on this new set, I find it harder and harder to decide what
to include, beyond the control structures, that doesn't come from the
PHP manual itself. That's why I'm asking for ideas...
>> Note that the existing PHP clipping set includes clippings for all
>> the
>> control structures (that I'm aware of). Yes, the clippings could be
>> more refined, but I really need to know what people need in order to
>> be able to refine them so please don't be shy...
>
> I've used these as a basis for refinement. The trouble is I don't
> think they can really be automatically generated to be perfect — a
> #SELECTION#, and an #INSERTION# there can make all the difference –
> and what perfect is is probably open to debate...
>
> I am happy to contribute what I've got as examples... one thing I
> did was to break the if-elseif-else group up so you can build the
> branching structure as you go. (I don't think I've got any of them
> perfect yet -- mainly because it's only in the heat of battle that
> you think "it would be good if it did this" but they might help...)
Marc Liyanage's XSLT clipping set does some interesting things
launching AppleScripts to support creation of the code right from the
clipping set. I was wondering if we could use that functionality to
make the clipping set better. For example, many date functions have
format string parameters. I frequently find myself doing php.net/date
to look up the codes for each format. Isn't that the kind of thing we
should include in the clipping set? For a clearer example...
When you insert the date function, the clipping would pop up a dialog
offering a variety pre-defined date format strings or let you insert
your own custom string (with a gloss of the meaning of each code right
there so you don't have to go and look it up, or maybe just a link to
php.net/date).
I'm sure that if people think about it a bit, we could come up with a
dozen more examples like this that really would improve the clipping's
functionality, but I simply don't know enough PHP to be able to say
which functions would benefit the most from this type of functionality.
>> I recently posted a jquery clipping set to this list for someone who
>> requested it. As usual, I never heard back from that person, not even
>> a "hey thanks! That was nice of you to invest the time in creating it
>> and not even charging me for it even though you have a job, a wife, a
>> house and two kids to pay for..."
>
> I'm grateful. Thank you.
:D You're WELCOME!
And thank you for at list chiming in and for offering to help move
things along.
Is anyone else following this thread?
Ted
(hey, that rhymes!)
G. T. Stresen-Reuter
> On Jun 19, 8:46 am, "G. T. Stresen-Reuter" <tedmaster...@gmail.com>
> wrote:
>
>> Why is that? Is it possible that although it includes the kitchen
>> sink
>> that it's simply too much for most of my needs?
>
> I understand what you mean. I do a lot of LaTeX and found a very
> comprehensive set for it years ago. However there's so much in there
> that a more streamlined 'smarter' set would be more useful. It's on
> my todo list.
And with the speed at which some of the underlying languages change,
keeping up on such tasks is nearly impossible!
> Do any of you think it would be good to have a central repository for
> clippings and scripts? Maybe something that Barebones could host? And
> if some of the sets/scripts/etc. were polished enough, maybe they
> could be bundled with the application...
Bare Bones already has a list of clipping sets available on their
site, but it would be interesting to have a central repository that
didn't depend on their resources for support. The thing is, I think a
lot of the clipping set authors like hosting the sets on their own
sites as it drives traffic (I know that's the my case, but I may be
willing to give that up as the need for traffic dwindles).
Ted
Simdude
other unamed editor. I believe the bundles are open source and are
being used in a Windows clone of that editor. I suspect this would be
incredibly complex though. I'm not sure it would be cool to do that
either even if it didn't infringe on any licenses.
I do like the idea of building up a central repository. But Barebones
already has a download area for clippings right? I assume you want to
just make this more complete?
Carlton Gibson
On Jun 19, 2009, at 2:24 PM, Carlton Gibson wrote:1) There's the outstanding issue about the spacing. I (still)haven't had the chance to work through your existing XSLT butallowing a more compact template should be possible (yes?)
I've got that "fixed". I'm trying to follow the Zend coding style (but
they don't give much detail on spacing, just some examples). They are
very similar, though not identical to, the PEAR coding style.
On 19 Jun 2009, at 13:46, G. T. Stresen-Reuter wrote:For example, the PHP clipping set includes a fairly complete classdefinition clipping but honestly, even though I created it, I've onlyused it once or twice (in the 4 or 5 years it's been in there).Why is that? Is it possible that although it includes the kitchensinkthat it's simply too much for most of my needs?I found this too big. Rather I've created an empty class outline andthen clippings for functions (allowing for PPP status) -- theseallow me to build up a class as I go.
That's precisely the experience I've had: the clippings are better off
being small, discrete chunks of code.
I also have doc-block clippings.
Shall we integrate this into the PHP set? I've been toying with
writing one myself to see if that encourages me to document my code
more (not likely, but worth a try).
G. T. Stresen-Reuter
>> When you insert the date function, the clipping would pop up a dialog
>> offering a variety pre-defined date format strings or let you insert
>> your own custom string (with a gloss of the meaning of each code
>> right
>> there so you don't have to go and look it up, or maybe just a link to
>> php.net/date).
>>
>> I'm sure that if people think about it a bit, we could come up with a
>> dozen more examples like this that really would improve the
>> clipping's
>> functionality, but I simply don't know enough PHP to be able to say
>> which functions would benefit the most from this type of
>> functionality.
>
> This is a really good idea! A lot of the inbuilt functions would
> benefit, e.g. file_get_contents() --- I use this all the time but
> can I ever remember the flags for the 2nd param? (And that's a
> simple case...)
>
So, what date formats should be offered by default (always leaving the
option of overriding to the end user)?
MM/DD/YYYY (U.S.)
DD/MM/YYYY (Rest of the world)
YYYY-MM-DD (MySQL)
Thu, 21 Dec 2000 16:01:07 +0200 (RFC 2822)
Any others?
I've got something in the works...
Ted
Carlton Gibson
On 21 Jun 2009, at 23:04, G. T. Stresen-Reuter wrote:
> I've got something in the works...
Do you think it's worth us (I mean all on the list) having a Google
Code repository or something?
(BB: is it worth you guys setting us up a Wiki or something?)
Harold Tessmann III
> Harold Tessmann III schreef:
>
>> Someone else has pointed out that BBEdit doesn't respond to
>> AppleEvents while running a UNIX script or filter, but does it respond
>> to them while running an AppleScript (he asks at work, with only
>> Windows machines handy)? If so, it seems like a pretty easy workaround
>> to write a launcher AppleScript and then use osascript to retrieve the
>> frontmost window info, cursor position, etc. Not ideal perhaps, but
>> it'll get the job done.
>
> Fairly pointless: the point of OSAscript is to use AppleScript snippets
> from other languages. If you are already in AppleScript, then you don't
> really need this.
Except you've left AppleScript for your desired scripting language.
The AppleScript launcher just runs the script in the other language.
If this spawns off another thread/process/whatever it takes to get
BBEdit to respond to AppleEvents, the other language script can then
use osascript to read the selection, cursor position, whatever from
BBEdit.
Harold
Tim Gray
features in there. For those not familiar, click on the scripts menu
and select teh Edit User scripts command. Flip through the scripts.
This is the kind of functionality I'd really like in BBEdit. The
ability to run scripts in any language, insert text into the current
document in a reasonable manner (a simple echo, instead of reading in
the entire contents and appending), the ability to set the input as
either the selection or the entire document, pull pertinent variables
from BBEdit, etc. Current you can only do this with Applescript, but
lets face it, text manipulation is painful in Applescript.
I realize this functionality isn't there right now in BBEdit and would
take some reworking in how BBEdit process scripts, but...