I'd like to implement some automated method for creating getters and
setters for private fields in Java classes, but I'm not having any luck
figuring out how to do it.
My first thought was to set a bookmark where new getters and setters
would be inserted in the file and then put the cursor on the line
declaring the field to be got/set. (Typically, methods and fields are
separated by at least a constructor, and usually the methods are
declared after fields in the same order that the fields were.) I'm
unable to do this because bookmarks aren't exposed as variables to
commands/macros/etc. This also doesn't scale if there's more than one
Does anyone have any suggestions on how to implement this?
/ / / __/ Brian Lalor
/ _ \/__ \ blalor(a)bravo5.org
I updated the PHPDocumentor [ http://phpdoc.org/ ] snippet bundle for
PHP 5 constructs. The commands are still useful for PHP 4 too. It
also has an auto-installer (bash script) that sets the default value
for @author in a separate text file so you don't have to edit the
snippets. You should run the install script and replace the old bundle
if you had it installed before.
btw .... anyone know what is happening with the main page of the wiki?
There was a place for post-1.01 bundles but I can't find it anymore.
was going to modify a download link I had up there.
On Mon, 29 Nov 2004 21:03:14 +0100, Sune Foldager <cryo(a)diku.dk> wrote:
> On 29. nov 2004, at 17:45, Josh DiMauro wrote:
> > [i-search...] As to the command key: please, let's keep it ^-s. It's
> > consistent
> > across multiple applications, and I'm already having to learn too many
> > new commands as it is, thanks.
> But of course this doesn't work on keymaps where ^ is dead, such as
> danish :-/.
I meant ^ as in the control key. Your layout really kills the control
key? Or just the carat (^) key?
Regardless, Allan's idea of linking to the keybinding of the i-search
plugin is genius. It can be edited if it's not what you like,
(forwarded because I was stupid and replied directly to Sune, sorry.)
> Date: Sun, 28 Nov 2004 20:48:11 -0500
> From: Josh DiMauro <jdimauro(a)gmail.com>
> That's pretty much it... but the advantage is less the shorter find
> string, and more the ability to fine tune by either narrowing or
> widening the search with a couple keystrokes, without having to reopen
> a dialog box. The difference is subtle, but (I feel) important.
> Incremental search seems to be one of those things that makes a subtle
> difference in reducing resistance to use. It's not so much that I need
> it to do all my searching. It's more that, when I don't have it
> available, I search less, and that makes me less efficient.
Incremental search changes the way you do searching. Using Firefox or
Mozilla, on a web page I can just type '/' and then the thing I'm
looking for. cmd-f and filling in a dialog box is requires much more
cognitive effort because of the two context switches required (into
the dialog box and back). Many times I've wanted to type '/something'
and then realized I needed to do cmd-f etc... and decided just to
page-up or page-down instead. May I suggest cmd-/ for incremental search?
I noticed that a lot of the syntax highlight bundles use different
colours, and on top of that also other decoration such as underline and
My experience is that italics in most fixed-width fonts does not look
that good and is bad for readability.
The other thing is that the italics is mostly superfluous: the aim is to
differentiate text from surrounding text and most of the time, this is
already achieved by using a different colour and using italics as well
does not really help.
So I propose that authors of syntax highlight bundles use italics
sparingly and only if it really has extra value to use it.
How do other users feel about this? And does anyone else have tips for
increasing usability of syntax highlight bundles?
Hello. New user, here.
I'm loving TextMate so far, although I've only used it for about 12
hours. :) And I googled the mailing list archives for an answer to a
question I had, but couldn't find it. Thus, I ask you:
I'm an addicted user of the i-search cocoa plugin, which duplicates
Emacs' isearch functionality, with the same keystroke: ^-s forward,
However, I find that this doesn't work inside TextMate, and that makes me sad.
Can you help make me not sad?
Hello, folks. Pardon the length of this email, but I wanted to throw my
hat into this ring.
I've just downloaded TextMate, and it has taken much restraint to
suppress the constant urge to toss that ugly icon into the Trash. I'll
make no apologies for the fact that I find it hideous, and if it were
up to me, I'd start over from scratch with a completely new design.
Alas, I am not a designer, so I cannot give you a mockup. But I would
like to get a description of my idea out into the open, so that someone
with artistic skills could give it a go.
A Mac OS X application icon is supposed to show the type of document
the program works with, and a tool that one might use to work with that
kind of document. See TextEdit, AppleWorks, and Preview. However since
there are many apps that do not exactly follow this guideline -- I'm
thinking of iTunes, Safari, Mail, and Address Book -- I think we have a
little room for interpretation. But I am still in favor of keeping the
same visual style and perspective used in the Apple icons.
I envision the finished icon as mostly white. The "document" part of my
icon idea is two sheets of white unlined paper, at the familiar angle
(see TextEdit), which look like they could be homework assignments or
test papers. I envision that text is hand-written on the papers -- but
it should be made clear from the indentation and varying line length
and such that it is programming code, not paragraphs of text. There
should be red markings on it, indicating where corrections have been
made, and possibly a red hand-written and circled A at the top of the
page, indicating the grade this assignment has theoretically received,
or just a checkmark or some other indication that the document is now
A-OK, thanks to TextMate.
The "tool" part is where I think we can depart from the recommendations
a bit, given the state of other Apple icons. I can't get along with the
current robot, so I suggest a happy anime cartoon boy. In anime, as in
other cartoons, characters often have superpowers or hidden abilities,
and this guy's power therefore is sprucing up your document quickly and
efficiently without getting in your way. He's standing proudly to the
right side of the papers, legs slightly apart, arms folded in front of
him, a red marker clearly visible in his hand, and with a stereotypical
spiky outrageously-colored anime hairstyle, possibly partially hidden
by a backwards-turned baseball cap. I see him wearing long white pants
and a white shirt or sweatshirt (and if only MacroMates had a logo, it
could be printed on the sweatshirt). I see the hair as being the icon's
primary source of color, but this could prove to be too little color,
so the shirt and/or pants may have to get some color too. The color of
the SubEthaEdit icon changed from blue to green with the 2.0 release,
and iTunes' icon has changed color with every major version as well;
the hair and/or clothing colors of this icon could also be changed
across TextMate versions if desired.
Document icons should be easy to make based on this idea -- just the
marked-up paper by itself, not at an angle, with the customary turned
So that's the idea. If we have any designers out there wanting to
tackle it, please go for it! I'm of course available by email for
further discussions of this idea, and I'll try to monitor the list as
ryan schmidt // hello at ryandesign dot com