"Hello World" – The SlickEdit Developer Blog http://blog.slickedit.com "Hello World" - The SlickEdit Developer Blog Wed, 28 Jan 2015 20:02:26 +0000 en-US hourly 1 From 0 to 4K: a belated Christmas story http://blog.slickedit.com/2015/01/from-0-to-4k-a-belated-christmas-story/ Wed, 28 Jan 2015 20:02:26 +0000 http://blog.slickedit.com/?p=1691 For the past three months, my desktop monitor has been a shiny new Seiki 39″ 4K television. That’s right, 39 inches of glorious pixels, 3840×2160 of them to be exact. It works beautifully, and was worth every penny. Serious programmers who want to look at a lot of code at once, I welcome you to do your own research on 4K TVs and monitors and consider one for yourself.

Seiki SE39UY04

However, that is not what this post is really about, because life wasn’t always so easy.

This is where the Christmas story comes in: 8th grade. One of the most memorable Christmases of my life, because this was the Christmas when I got my first computer: a Commodore VIC-20. Hooked up to a TV, it produced a 176×184 pixel display, good for 22 rows by 23 columns of text. But, sadly, it did not start out that way. We had difficulties right out of the box getting the TV synced up, so there was no display at all. Did this stop this budding programmer to be? Heck no. I started typing in my first Commodore Basic program in the blind. Now, let’s not get into the details about how well that program turned out, but suffice it to say, that as far as computer monitor resolution goes, I started at zero.

The VIC-20That’s not me… my screen was blank.

Years later, the VIC-20 would be replaced with a C64, and my pixels nearly doubled. I now had 320×200, and 40 columns of text. They again doubled when I graduated to an Amiga 500 in college and found myself staring at a flickering interlace display of 640×400 pixels. I could see 80 columns of text!

My first taste of wide-column programming was the VT-100 terminal in the college computer lab which I could set to 132-columns. By the way, this annoyed other students who didn’t know how to change the display mode settings and also did not enjoy squinting as much as I did. I should take this opportunity to apologize to those guys, writing Pascal on a VAX 11/780 had enough pitfalls for a college freshman — I shouldn’t have made it worse for them. Another interesting side-note is that the Slick-C command record_macro_end_execute_key() which you might find assigned to Ctrl+Shift+F1–F10 was inspired by the macro recording features of the Eve editor on the VAX.

Terminally beautiful.

In graduate school, I was exposed to Sun workstations with 19 inch CRT monitors that were about the size of a mini-fridge and consumed about as much energy as a Nissan Leaf at a tractor pull. 1152×900 pixels of delightful X-windows wonder. I eventually would trade my Amiga 2000 for a Sun 3 of my own, which became my home computer for quite some time. These were the salad days of C and C++ programming with the VI editor.

Sun 3/60 (pizza box)

When I joined SlickEdit, I moved to Windows as my primary machine and eventually graduated to a machine with a 19 inch 1600×1200 CRT monitor that kept my desk firmly pinned to the floor. This served me well, until the day that SlickEdit started getting daily complaints about how list-members in SlickEdit 4.0 did not work correctly with a multi-monitor setup on Windows. Apparently, the list was coming up on the wrong monitor, and this would just not do. Happy with my one big monitor, I felt like these people were just being silly using two smaller monitors to get about the same amount of resolution, but I begrudgingly set up a dual-monitor configuration on my machine and proceeded to fix the display bugs. What I did not expect was that I would fall in love with having multiple monitors. It allowed me to work faster and keep track of more things at once. I thought I would never go back to a single monitor.

When 17-inch 1280×1024 resolution LCD monitors dropped below the $100 price point, I soon I had four monitors on my desk. This was the most pixels I’d ever had in front of me, but it was not enough, because they were too narrow for DiffZilla. I would eventually replace two of the LCDs with 21-inch HD monitors, one in vertical orientation and one in landscape for DiffZilla.

Where are they now?

All those machines and all those monitors are gone now, dust in the winds of change. 4K is the current zenith of display technology. A lot of people are already using dual 4K monitors, and Apple is shipping 5k retina displays. I look forward to seeing 50 inch curved 8k displays in the future.

The advancements made in computing hardware are normally broken down by speed, memory, storage, hardware size, and cost. Often the advancements made in display and input technology are forgotten. Compare the computer I sit behind today to that VIC-20.

  • CPU — 2.8 GHz vs 1 Mhz — even simplistically measured, thousands of times faster
  • Memory — 8G vs 5k — over a million times more
  • Storage — 1 terabyte vs a 170k floppy — more than 5 million times more
  • Size — actually, about the same
  • Cost — $500 notebook + $339 4K TV vs $199 VIC-20 + cheap TV — adjusted for inflation, a lot less expensive.
  • Display — 39 inch 4K TV vs 13 inch color TV (176×184 pixels) — over 256 times more pixels.

I could tile 252 VIC-20 screens on my current display. That’s a whole screen for every other character the on the VIC-20.

I concede that the gains in the other areas are somewhat more dramatic. But, when you are a programmer, what tends to matter the most to you is how many lines of code you can look at at once, and more importantly, with what degree of comfort you can absorb and navigate through the code. My personal opinion is that 4k has both improved my productivity and allowed me to award myself with a slightly larger font to cut down on eye strain. Given the current bargain prices (less than $400), it was more than worth it.

iPhone 6 Plus vs Samsung Note 4. Which Should You Choose? http://blog.slickedit.com/2014/09/iphone-6-plus-vs-samsung-note-4-which-should-you-choose/ http://blog.slickedit.com/2014/09/iphone-6-plus-vs-samsung-note-4-which-should-you-choose/#comments Fri, 26 Sep 2014 14:54:28 +0000 http://blog.slickedit.com/?p=1682 If you are thinking about buying an iPhone 6 Plus or a Samsung Note 4, this article may help you. Trying to decide between these phones mostly comes down to the software, familiarity with one of the OSes, your purchasing habits (are you invested in iTunes?), and product support.

I have experience using both the iPhone and Samsung phones as well as investigating, pretty intensely, how to get the most out of Android/Samsung apps. I really like how Samsung has copied some of the iPhone software features. For example, the Samsung OS displays badges on your Phone, Messages, and Email app icons just like the iPhone. I’m not a big fan of just having Android centralized notifications. The Samsung OS also has a much more iPhone-like phone app with integrated voice mail. For me, this is also a big deal since many of the Android phone apps are terrible compared to the iPhone phone app.

I have ended up purchasing the iPhone 6 Plus after using the Samsung S3 for 2 years and an iPhone for about 3 years before that. This decision was so close that I’ll be jealous of anyone who has the Note 4.

Are you Capable of Switching OSes?

If you’ve been using an iPhone or an Android for a long time, switching OSes takes time. Unless you are a slightly more advanced user and/or have a compelling reason, I wouldn’t recommend switching OSes. It’s probably not worth your time since both these OSes will get the job done. A number of basic things are implemented very differently like: adjusting the cursor position, copy/paste, and selecting text. I find both the iOS and Android implementations of these important features very good. It took me a while to get used to how my Samsung S3 did these. Where to find configuration settings is very different. Not all iOS apps are available on Android and vice versa. Before you switch OSes, be sure to check if the apps you need are available.

Advantages of Note 4 Over iPhone 6 Plus:

  • Back button at the bottom of the phone. The iPhone 6 Plus needs this for better one handed phone use. The back button has more value than just one hand use too. If you are reading an email which has a URL link in it, clicking on it brings up your web browser. Then you can press the back button to return to your email (not the home screen). Android has an internal stack which the Back button uses. iOS needs this too.
  • The Samsung Note 4 is not quite as tall as the iPhone 6 Plus and has a slightly larger screen. This is partly due to the fact that the Note 4 has a thin horizontal button which takes up less space. At least the new iPhone 6 Plus has a smaller home button than older iPhone models.
  • As you’ve probably already heard, the Note 4 is less bendable. If you put your phone in your pocket, the iPhone 6 plus is much more likely to bend. I don’t keep my phone in my pocket. I used to keep my phone in my pocket until I noticed my hip starting to hurt. I’ve learned the hard way that radiation from your cell phone affects your bodies ability to heal. Once I stopped keeping my phone in my pocket, the pain went away. My body wasn’t able to heal itself enough after my workouts due to the combination of radiation from my cell phone and my age.
  • Easier to configure home screens. I especially don’t like how iOS auto arranges icons. I like my more important app icons to be in very specific places on my home screens and iOS makes this difficult to manage.
  • Menu button at the bottom. The iPhone needs this too but since many apps have buttons at the bottom, it’s not that big a deal.
  • More apps which display lists support multi select operations.
  • Many more configuration options. This is only useful if there’s an option you like and can’t find something similar in iOS.
  • Widgets (like contacts and weather) can be placed on the home screen just like apps. I found the default widgets useless and large so I removed them but I love putting contacts on my home screen. The new iOS 8 double click the home button feature to display recent phone history and favorites is OK. I still would prefer to have some contact icons on my home screen. I suspect Apple will add support for Widgets in a future OS and maybe then iOS will have the ability to add Contact icons to your home screen.
  • Android has more of a typical file system. This is especially useful for copying pictures from a computer onto your Android phone. I really don’t like to use iTunes to import/export pictures.
  • Can root phone. This can be useful for more advanced users. For me, this has very little value. Some Android users root their phone so they can use their phone as a Wifi hotspot. Now, most users don’t need to do this due to carrier changes.

Advantages of iPhone 6 Plus Over Note 4

  • Better support for product. The Apple store offers better support for the iPhone than any other mobile device. If you are a less advanced user, this is a very big deal and arguably makes the Note 4, or any non-Apple device, a no go.
  • Easier to use and configure. More things just work for me with less or no configuring.
  • UI experience. More of the apps I’ve seen have a consistent look and feel with good looking graphics.
  • Slightly better apps. This will be very different for everyone. For me, the following apps are slightly better on iPhone: phone, email, calendar, camera, text messaging, photos viewer, and ScoreMobile (Exceptions: GTasks on Android is a little better than all iOS Google Tasks apps I tried, and Mobi Calculator Free on Android is better than any iOS calculator app I tried)
  • Slightly better one handed use due to the new Reachability feature. I love this Reachability feature. If the iPhone also had a back button, this would make the iPhone a much clearer winner here. Right now, there’s not much difference. I give the iPhone 6 plus the edge because the Note 4’s “One-handed operation” feature is not very good. For me the iPhone 6 Plus is the clear winner here because I hold my phone with my left hand (even though I’m right handed) which makes the back button at the top left of the screen easy for my big mitt to reach.
  • iTunes. If you buy apps, movies, books, or whatever, Apple has a slightly better buying experience.
  • Touch screen. I find the iPhone screen slightly more accurate/responsive.
  • I slightly prefer how iOS does cut/paste with worded buttons near the cursor instead of non-worded icon buttons at the top or bottom of the screen.
  • Speaker on bottom instead of back of phone
  • Security. Arguably better because apps go through an Apple review.


There are many features in both devices I have not mentioned to keep this article short (Family Sharing, AirPlay, Siri, hardware specifics, etc.). I have only mentioned the more basic or significant advantages of either device. I hope this information helps you decide which phone is best for you. Keep in mind that switching OSes can be difficult. You can’t go wrong buying either of these phones.

http://blog.slickedit.com/2014/09/iphone-6-plus-vs-samsung-note-4-which-should-you-choose/feed/ 1
Yeah, that’s right, we’re doing March Madness http://blog.slickedit.com/2014/03/yeah-thats-right-were-doing-march-madness/ Mon, 24 Mar 2014 15:53:39 +0000 http://blog.slickedit.com/?p=1617 That’s right folks.   It’s hacky.  It’s silly.  It’s inevitable.  But it’s time for March Madness (Note – Readers outside the US read this to catch up March Madness).   That’s right.  It’s time for a bracket of 32 (because I can’t come up with 64, and certainly not 68) things that annoy us.  Some programming related, some not, in our search for the most annoying item that wins the First (perhaps annual) SlickEdit March Madness Tournament.


Vote for your favorite item in the comment section below.  Much like Whose Line is it Anyway, where the rules are made up and points don’t  matter, it won’t matter what you vote for because we’ll pick the winners of each round and report them to you as though your vote mattered.


Up first, the Grace Hopper Division: Programming Languages.  Everybody has a language that annoys them simply by its existence.

  • COBOL – It’s an acronym that stands for somthing with “Business” in it.  It’s way too wordy, and it’s outlived all the languages that were supposed to replace it.
  • Perl – There’s a lot to like in Perl. But unfortunately TMTOWTDI has gone way too far here. When you have 5 ways to do a regex search, that’s 3 too many. And while using $_ for “the last expression result” is pretty cool, all the rest of the short-hand two-character $ variables are simply there for the cognoscenti to show off and confound all but the author.
  • Java – Sun invents their own interpreted, object oriented language.  The whole world jumps on board.  As far as I can tell, for the first 10 years the only applications written in Java are Java Development Kits.
  • C# – Microsoft wants an interpreted, object oriented language.  Obviously, they invent their own.
  • C++ – For our beloved tagging guru, I will simply list the STL as the biggest sin of C++.
  • “Semicolons Optional” languages – Good grief. Why do this? Sure, using syntactically significant whitespace makes your source code look nice and tidy. But languages that do this make it harder for tool vendors to write proper support for the language, thereby limiting the number of 3rd party tools.
  • The Functional Language Diaspora – I’m not against functional languages. They’re vital and valuable, but still something of a niche, and shall always be thus. So do we need so darned many to fill said niche? Let’s put grandpa (Lisp) on the ice floe and push him out to sea along with Haskell, Erlang, and Scheme. Scala and F# can stay. Clojure gets a pass for now…
  • XML – It’s one language that contains every other language.  Its overly-broad application and misuse is responsible for the forced early retirement of the INI format. 

Dennis Miller Division: Cultural/Societal Phenomena

  • People who go on about organic food – If I’m eating a salad, I’m trying.  I don’t want to hear about the problems with the lettuce being genetically modified.  It’s LETTUCE.  Until it gets up and walks around, leave me alone.
  • Checks with 20__ in the date line – Forget the fact that I had to shred a pile of unused 19__ checks when Y2K rolled around, and I know I’ll never need to write a check with 21__ in it. But still, I don’t like the fact that the few checks I do write look like March 17th 2013
  • People who spend all day cluttering your Facebook feed by liking photos – I should learn how to shut this off.
  • Twitter – I guess it’s here to stay… but after 5+ years I’ll just admit, I don’t get it.
  • “Not Responsible for Windshield Damage” – Yes, you are responsible, you accountability-dodging cretins. You slap on a bumper stick that says “Stay Back 300 feet”  (ignoring the fact it can only be read when within 150 feet) and you think that gives you carte blanche to scatter gravel all over the roadways?
  • $1.59 for a 16oz Coke – I don’t mind the price, per se, just the fact the same Circle K sells a 2 liter bottle for only 40¢ more. Well, I can’t jam a 2 liter bottle into my car’s cup holders. Why don’t they jack up the price of the 2 liter to $2.50 and use that to subsidize my impulse purchase down to $1? And I won’t feel so ripped off.
  • $1 Double Cheeseburgers – I just don’t need this kind of temptation in my life.
  • Hacky Humor-oriented March Madness Bracket Lists – Yep.

 Rolling Stone Division: Music and Movies:

  • Coldplay – It sounds like U2 played by a comic lounge singer
  • Kanye West’s performance at that benefit show – I’m thinking of the 12/12/12 one, but others may apply
  • Boy bands – a trend that keeps coming back like the bad guy in a horror movie
  • Whoever expanded the “Best Picture” category to 10 movies – Did Toy Story 3 really have a chance?  You’re just trying to get people to watch the Oscars®©™²³£¥ television broadcast.  Don’t patronize me.
  • Everybody involved with the writing and production of The Blues Brothers 2000 – May God have mercy on your souls.
  • The stuff that passes for Heavy Metal today – Give me the NWOBHM bands.  I’m old.
  • Coldplay – New album is different you say?  Nope – It still sounds like U2 played by a comic lounge singer


Computer I Grew Up With Division (Under 40 need not apply): Oddities of the “computers” we grew up with.  Computers is in quotation marks because they aren’t exactly what we consider computers now.

  • The Commodore Vic-20 – How can I include my beloved first computer?  Because after it loaded the BASIC interpreter it had 3.5K of RAM, that’s how.  3.5K.  Not G, not M.  K.  Dim A$ 16,16,16. Error out of memory.
  • The Atari 400 – I never had one, but  it didn’t have a real keyboard.  Those touch pads probably seemed really futuristic until you actually tried to type on it.
  • The Apple II E – Somebody has to take the blame for unleashing the original Apple fan boys on the world.  I nominate the IIE.
  • The Apple II GS – Sleeker and more colorful than previous Apple II series, but not quite as cool as the impending Macintosh II. An expensive ,short-lived tease.
  • The Atari 2600 BASIC programming cartridge – A controller that looked like this, and no way to save anything?  It’s a wonder they didn’t sell more.
  • The Timex Sinclair 1000 – It was a calculator that you had to hook up to a TV.  They were kind enough to include the same keyboard technology as the Atari 400 though.
  • Whoever was in charge of marketing the Commodore Amiga – You should have ruled the computer world, you brought us a rotating bouncy ball.  Way to go.
  • Coleco Adam – You can tell it’s from the 80’s, it had a dual cassette deck.



SlickEdit Defeats “patent troll” Uniloc in Patent Lawsuit http://blog.slickedit.com/2014/03/slickedit-defeats-patent-troll-uniloc-in-patent-lawsuit/ http://blog.slickedit.com/2014/03/slickedit-defeats-patent-troll-uniloc-in-patent-lawsuit/#comments Thu, 06 Mar 2014 16:27:47 +0000 http://blog.slickedit.com/?p=1675 Greetings!

I wanted to keep you up to date on whats going on with SlickEdit.

In October of 2012, Uniloc USA, Inc. filed a lawsuit against SlickEdit, Inc., alleging patent infringement (U.S. patent 5,579,222) concerning a license management system.

Uniloc USA, Inc. is a patent-assertion entity or “patent troll,” i.e. a company whose sole business is to sue software companies including Adobe, Microsoft, Sony, and Symantec. It has sued more than a dozen companies over this patent.

In an unusual turn of events, after more than a year of litigation Uniloc USA, Inc. asked the Court to dismiss its own lawsuit against SlickEdit, Inc.  This came a week after the court held a three-hour Markman hearing on February 13, 2014 in which SlickEdit argued that Uniloc’s patent covered far less than what Uniloc was claiming.

Make no mistake, this is a BIG win for SlickEdit in what amounts to be a David vs. Goliath scenario.

Patent infringement suits are considered extremely costly to defend against. Even in cases like this where there is no infringement, small companies are often forced to settle due to the astronomical legal fees associated with patent cases.

I knew SlickEdit did not infringe. I hired a great attorney and worked closely with him. We were able to put together a solid case and ultimately saved the company a lot of money.

I interviewed nine different patent attorneys at nine different firms and easily chose Tim Shannon of Verrill Dana, LLP.  Tim and his team mastered the patent, mastered our product inside and out, and led a claim construction argument that literally threatened to derail Uniloc’s entire national campaign. Tim never let up and got us a great result. I highly recommend his service.

Glad to be done with this mess. Now I can continue to have a blast working on the product!

Clark, CEO

http://blog.slickedit.com/2014/03/slickedit-defeats-patent-troll-uniloc-in-patent-lawsuit/feed/ 1
Dan Rants About Things That Don’t Make Much Sense to Him, vol 1 http://blog.slickedit.com/2013/07/dan-rants-about-things-that-dont-make-much-sense-to-him-vol-1/ http://blog.slickedit.com/2013/07/dan-rants-about-things-that-dont-make-much-sense-to-him-vol-1/#comments Tue, 23 Jul 2013 17:48:33 +0000 http://blog.slickedit.com/?p=1663 This (‘/’) is a slash.  It is used to separate pieces of paths and filenames.  It is used by all the UNIX systems I am aware of, the Mac (that’s right, I said UNIX and the Mac separately, and I will continue to), and  URLs around the world.  On a US QWERTY keyboard, it is on the same key as the ‘?’.  It is located in a convenient place so that a touch typist can sit down at virtually any keyboard type a filename and know where it is. a/b/c/d/e/file.c.  Wow, that’s easy.

This (‘\’) is a backslash.  It is used by Microsoft to separate pieces of paths and filenames.  It is used by Microsoft Windows.  On a US QWERTY keyboard, it is usually above the enter key, except in some cases where it is in the same place but ½ the size, or other cases where it is located at the bottom of the keyboard. a\b\c\d\e\file.c.  I can’t say that was exactly painful  but it wasn’t as easy.  It just wasn’t.  Also, this could just be me, it looks funny.

Sometimes when we start a project, we do something to differentiate ourselves from other similar projects that came first.  Sometimes these things don’t serve much purpose except to say “See?  I’m not doing what you did, I’m doing something different”.  It could be that’s how the backslash came about.

Regardless of why it’s here with us, it is time for it to be put to rest.  Support both for a few versions if it makes you comfortable.  Or just make a clean break.  I’m OK with either one.

Next time on “Dan Rants About Things That Don’t Make Much Sense to Him”, I’ll cover the Mac using the Control+Click as a Right Button Click even though two button mice have been widely available since Nirvana was a garage band.  I’ll cover drive letters in an upcoming episode but I just exposed the uselessness and confusion of the backslash and I don’t want to stick it to one company twice in a row.  Plus we don’t have to do it all at once.  c:/a/b/d/e/file.c.  I can live with that.

http://blog.slickedit.com/2013/07/dan-rants-about-things-that-dont-make-much-sense-to-him-vol-1/feed/ 2
SlickEdit tip #431 http://blog.slickedit.com/2013/02/slickedit-tip-431/ Tue, 19 Feb 2013 16:58:25 +0000 http://blog.slickedit.com/?p=1601 Today’s tip, as most of these prime numbered tips, comes from something that was a default years ago that I stuck with.

Put your build output in an edit window.

Most programmer’s editors or IDE’s relegate the output from a build to some sort of tool window that is typically in a tab group docked a the bottom.  This is how SlickEdit works by default, because it is what is expected today.  Sometimes you have to jump off the bridge because all of your competitors did.  But that doesn’t mean that is the most powerful way to work.

Try right clicking in the Build tab and selecting “Send Compile Output to Editor Window”.  This means the build window (what we call the the “concurrent process buffer” or simply “process buffer”) is in the ring of open files when you cycle through them using the next-buffer/prev-buffer commands, or pick one from the Files tool window.  This is actually very powerful.  At first it may seem that you can’t move freely, but you can.  The cursor-up key will cycle through the command history by default, but clicking the mouse or using a non-cursor key to move (page-up for example) will allow you to move freely through the output, or delete it by hand.  I find this much more useful than trying to view my output through a porthole.  Try it out and let me know what you think.  You can always turn this off by right clicking in the Build tab (or the process buffer) and turning off “Send Compile Output to Editor Window”.

A Dozen Roses http://blog.slickedit.com/2013/02/a-dozen-roses/ Thu, 14 Feb 2013 17:01:23 +0000 http://blog.slickedit.com/?p=1608 Guys usually get the shorter end of the stick when it comes to Valentine’s Day gift-giving. The best we can usually hope for is to be allowed to sneak a couple chocolates from the heart shaped box we overpaid for. But if the Techo-Universe at large wanted to be my Valentine, here are some thoughtful, if not realistic gift suggestions.

  1. I would like Time Machine to not start up right away as soon as I log on. Please, please allow me to fire up Outlook, start a Terminal session, and fetch the latest from subversion before you start monopolizing the disk I/O.
  2. Non-silent ‘everything’s OK’ compile output. Some compilers and linkers do a decent job of this. Some report useful things like “All files up to date”. It’d be great if all command line tools did this.
  3. Some helpful hints when it’s time to create a new password. Every couple months I am forced to dream up a new password, something sufficiently secure but easy and fast to type. Perhaps an interface similar to Captcha prompts? Give me a couple suggestions that already meet the password complexity criteria.
  4. Rechargeable batteries for my Magic Mouse that actually hold a charge for more than 1 week.
  5. A release of Java that is free of Zero Day security flaws.
  6. Ditto for Flash…
  7. …and Internet Explorer
  8. An e-mail client feature that automatically truncates replies. All we really need are the most recent 3 or 4 responses of a long-running back-and-forth e-mail thread when composing yet another reply. I can’t remember if it was web-based gmail or the Mail app on my iPad that did this for me recently. I sure wish this was everywhere.
  9. Selective Bookmark Syncing. There are some links I’d like to have everywhere, and there are some links I have at the office that I’d like to show up on my home devices (and vice-versa). But it seems that most current implementations are an “all or nothing” affair.
  10. A Seat Belt detector for my phone. I can’t count the number of times I’ve gotten to the first traffic light on my way home and remembered that I’ve left my mobile phone in my front pants pocket. Perhaps a clever trick could be done with the accelerometer to detect the motion of getting into the driver’s seat.
  11. A big red reset button. When you’ve got a runaway process that’s hogging all your system resources, how do you stop it? Right, by invoking the Task Manager or Force Quit dialog, which itself requires resources. It’s a huge chicken/egg problem. In my grade school days there was this awesome red button on the TRS-80 (complete with ergonomic recessed finger tip dimple) that would reset the system. How about something similar that would would kill everything except kernel and OS processes?
  12. Stretchy Cables. Ok, so this one’s a little bit strange. But it sure would be convenient to be able to stretch a cable to exactly the length you need. Right now on my desk I have a headphone cable that is much longer than needed to reach from my speakers to my head and a power cable on my MacMini that is just a teensy bit too short for where I’d prefer to position it relative to my UPS. The only perfectly sized cable is the USB cord that reaches from my keyboard to the back of the computer.

Did I miss anything?

“I don’t need SlickEdit because…” http://blog.slickedit.com/2013/02/i-dont-need-slickedit-because/ http://blog.slickedit.com/2013/02/i-dont-need-slickedit-because/#comments Mon, 11 Feb 2013 18:42:04 +0000 http://blog.slickedit.com/?p=1578 The only proper way to finish the title sentence is “… I don’t write code”.  The way that it absolutely not be finished is “…I just use vi”.  Here are the reasons people seem to claim for using vi most often:

  • It’s always there.
  • It’s always the same.

But there’s more to it than just that.  Insisting on relying on vi for your editing needs is a pride thing.  The pride of walking into the wilderness with nothing but a knife.

That’s right.  We all want to believe we’re able to rush out into the wilderness with nothing but a knife, able to survive for days like John “Yes, I do have a first name” Rambo.  After all, it’s not just a blade.  It also has a compass, a couple of waterproof matches, and a needle and thread in case we need to stitch a large gash up ourselves.  You picture yourself, looking rugged with a headband and makeshift burlap shirt, running through a rocky ravine and stopping to check the compass built into the end cap of the handle (an image which I looked for for literally hours, impeded by copyright police and the fact that I can’t remember which Rambo movie it was in – so please take a second to paint the mental picture).  The truth is you look more like Michael Scott out in the woods wearing his pants on his head (an image I spent absolutely no time looking for – if you’ve never seen The Office (the U.S. version), Michael Scott is a man who is far too dumb to breathe, and he tries to prove he is clever enough to walk into the woods wearing just what he has on and survive.  He’s not, and somehow he winds up wearing his pants on his head.  It is marginally funnier than it sounds).

So, we’ve established that vi is like a survival knife with a blade and little else except a compass and some waterproof matches and enough needle and thread to stitch up a cut yourself.

A slightly more acceptable answer for why you don’t need SlickEdit is that you use whatever editor is included in your modern IDE.  The IDE editor tends to be sort of like a Leatherman tool.

(Leatherman is a trademark, but I think they were first in this space, I’ve used their products for over 20 years.  Although I am not a paid spokesperson, I am completely willing to be.  Just contact me here by leaving a comment below).  The Leatherman type multi-tool is sort of like a Swiss Army knife that is actually usable.  It has usable screwdrivers (different types and sizes), pliers, wire cutters, scissors, a saw, and of course a knife. They have different models that have different types and numbers of tools, and any knife maker worth their salt has their own version.   And these can be used for more reasonable tasks.  I’ve never had to stitch myself up, but I have found myself needing pliers, a screwdriver, file, saw, etc.  You could actually use one to perform an emergency car repair.  Pliers are not ideal for this sort of thing, but in a pinch, you could probably use this to change a belt, and certainly use it to replace a hose.  But you can’t use it to rebuild an engine.  There are a number of reasons why.  But here’s a big one:

This is a piston ring compressor.  It is a specialized tool used to compress the rings on a piston when you put them back in an engine.  And there is probably a way to get a piston into the cylinder without one.  It probably involves cutting up a beer can and using a strap wrench, getting a really nasty cut, and making it worse trying to stitch yourself up with the thread in your survival knife, then going to the doctor who informs you that you should never, ever try to stitch yourself up again unless you’d like to lose your hand, and finally going to an auto parts store on the way home to buy a piston ring compressor.  You could probably do something like that.   But I wouldn’t try it.  If I were doing serious work on engines day in and day out, I would try to have the right tools on hand.

And that’s the thing.  If you’re reading this, odds are you’re not a guy who is not making emergency code repairs on the side of the road.  Odds are you are a guy who is building and rebuilding engines (race car engines, right?), or at least maintaining them, every day.  You won’t do your job effectively with a survival knife or a multi-tool.  You need a tool box.  A big one.

And this tool box is SlickEdit.  A great deal of it is stocked when you get it.  There are other tools that you have to put in the box, but it leaves a nice drawer there for you.  It’s customizable, so you can cut a piece of foam out to fit your special tools.

Quit trying to build engines with a pocket knife.  Get the tools that will best help you do your job. Some of my best friends are mechanics.  They have to buy their own tools and move them from job to job.   They don’t buy cheap ones.

http://blog.slickedit.com/2013/02/i-dont-need-slickedit-because/feed/ 3
Manifesto – Part 11 – Your Version Control System Shouldn’t Try To Do Too Much http://blog.slickedit.com/2013/01/manifesto-part-11-your-version-control-system-shouldnt-try-to-do-too-much/ Thu, 10 Jan 2013 16:53:36 +0000 http://blog.slickedit.com/?p=1562 The third installment of my version control manifesto is a short story made long with a simple moral at the end.  If you’d rather skip the story, just read the title and take that to heart.

Recently what started as a lovely afternoon at Guitar Center ended with me changing a car battery in a parking lot after dark.  On New Year’s Eve.  I’m not really complaining.  I’m not that handy, so when I can fix a car and look manly in front of my family, I’m pretty happy to do so.

Fortunate as I am to have a good job, I can drive cars that are just new enough I don’t carry tools in the trunk anymore.  Just emergency reflectors and jumper cables.  This is fine because:

  1. As acknowledged above, I’m not that handy.
  2. You can’t do anything to cars yourself anymore. Changing spark plugs on one of my cars requires removing the intake manifold.

Despite my best efforts with jumper cables, I could not get the car to start.  So, I found myself at Walmart buying a battery and asking if I might borrow a wrench, because even though I went home and picked up tools, I couldn’t fit a ratchet and socket into the space I needed.  The gentleman went to the back and got me a side-post battery terminal wrench:

This is a 1/4″ ratcheting box end wrench.  The handle is short, so if you slip, it should not be long enough short between the two terminals of a car battery (yes, I have done this with a ratchet before).  Also, the handle is insulated so were you to do that, hopefully it still won’t short anything out.  It is flimsy (as wrenches go).  It says right on it not to use it on anything except a battery terminal.  And that flimsiness serves a purpose.  Car battery terminals are made of lead, so you don’t want to over-torque them.  Also, because it’s flimsy they sell for about $5, which means I was happy to just buy one so I could throw it in the trunk when I was done.
This little tool is genius.  Why?  It does not try to do too much.  It is an affordable solution for a niche use.
So, if you’re at home in your basement writing the next big version control system:
  1. Don’t try to do too much.
  2. Stop.  There are enough out there.  We talked about this already.

There are larger systems out there have their own file systems and work well when developers are distributed across multiple sites.  That’s fine.  This doesn’t mean that to win my seal of approval (which I know is all the rage in the version control world) your system needs to scale things back to the features of RCS.  It means that the interface should be straight forward enough that a user can figure out the basic features common to all version control systems without trying too hard.  Diffing a single file, viewing a version of a single file, viewing the history for a file, checking in a file – these should be easy.

Have I overlapped another episode of the manifesto?  Perhaps.  But

  1. In general, manifestos are supposed to be long rambling documents written by the semi-crazy, and it seems like it’s OK to repeat myself.
  2. This particular issue is this important.

Don’t believe me?  You can’t figure out how I could possibly be right, and you be wrong, given that I’m toiling away in a cubicle filled with years of so much junk my desk is nearly unusable, while you are on the precipice of taking over the version control world? OK, let’s take a look at what happens when you try to do too much. A great idea, years ahead of it’s time that just didn’t catch on.  And still hasn’t. Ladies and gentleman, I give you Aerocar:

What are the most important methods of travel in our modern world? The automobile, and the airplane.  The automobile, an amazing invention that let’s us live 30 miles from our office, or go to the store when we need something, even if it’s dark already.  I am told before the automobile was invented people got along somehow.  Personally I don’t even like to think about it.  And don’t even get me started on the airplane.  Without the airplane, my children would never have seen Disney-world – because I could never handle that drive (not with my kids anyway).  It’s just like a big, fast, car in the sky.  And like an automobile, practically anybody can drive one – provided you have hundreds of hours of training and understand that in an airplane when you have a “fender bender”, everybody dies.

But what happens when you get where you’re flying?  If you left home, you probably left your beloved automobile there.  Well not if your airplane is a car.  A car that is an airplane. An airplane that is a car.  It’s like peanut butter and jelly.  No, it’s even better than that.  It’s like peanut butter and chocolate.  So why did I embed a video from when people got their news from movie theaters because 24-hour television news channels did not exist?    More recent films of Aerocar exist.  But the truth is they don’t matter.  Why?  Because it’s a car that is an airplane.  It’s not just a chance crash into another car on the highway at 70 miles per hour.  It’s a chance to hurdle out of the sky at terminal velocity into cars on the highway that are doing 70 miles per hour.  It’s not like peanut butter and chocolate.  It’s like alcohol and power tools.  Let’s put safety aside for a moment.  As a car, it makes the Edsel look attractive.  And to be effective as an airplane, you have to bring a small trailer (just about the size of an airplane wing) wherever you go.  It tried to do too much.  So you can go see one of the six that were built at various museums around the United States.

I’m a guy.  I love tools, whether I need them or not.  I love a lot of things that don’t make sense.  I love sledgehammers.  I love drag racing – because I can think of no pursuit more ridiculous pursuit than going 1/4 mile in a straight line as fast as possible.  Naturally, I love this thing.  If I have to check out of this world, I can’t think of a better way than crashing a flying car.  There would be no terminally ill men in this country if crashing a flying car were offered as a method of euthanasia.  But it was the best thing I could come up with to make my point.  A tiny motorcycle that fits in your plane is a more practical idea.

To sum up:

  1. Don’t try to do too much.
  2. Stop it!  There are enough version control systems in the world.
2012 – The Year In Review http://blog.slickedit.com/2013/01/2012-the-year-in-review/ Wed, 02 Jan 2013 15:11:37 +0000 http://blog.slickedit.com/?p=1536 It’s time to review the year that was 2012.  I would like to thank the good folks at Wikipedia for helping me to remember (for the first time in some cases) what happened this year.
  • January, 2012 – I solemnly vow not to lose a single ounce during 2012, or at least that’s how I remember it now.  This was a runaway success.
  • January 20th, 2012 – We release our first “real” version of SlickEdit for Mac. Our Mac beta testers rejoice that the near-weekly beta builds are now at an end.
  • February 3, 2012 – Van Halen releases it’s first album with David Lee Roth singing in 28 years.  Mostly comprised of completed songs that have been floating around on their demo bootleg for years, it is actually good.  The tour got derailed halfway through for a myriad of reasons.  Long time Van Halen fans still see this as “better than average”.
  • March 13, 2012 – (directly from Wikipedia) “After 244 years since its first publication, the Encyclopædia Britannica discontinues its print edition.”  This was bound to happen as nobody has bought an “old school” encyclopedia since sometime around 2004.
  • April 4th, 2012 – Public beta testing for SlickEdit 2012 begins. Two weeks after the Spring Equinox each year we are required by law to release the first beta of our upcoming version. Check your almanac.
  • April 8, 2012 – Jack Tramiel, founder of Commodore Portable Typewriter, which became Commodore Business Machines, dies at the age of 83.  Rest in peace, sir.  As noted in last week’s post, your VIC-20 led me to a career.  Mr. Tramiel was also a holocaust survivor, having been liberated from Auschwitz in 1945.
  • April 13, 2012 – North Korea launches an ” Earth observation satellite“.  It goes about as well as my weight loss efforts.  I hope they did it at night, it was probably much cooler than any fireworks display.
  • Spring-Summer-Fall, 2012 – After losing 100 games in 2011, The Chicago Cubs have a new General Manager, Manager, and the fans have renewed hope.  The Cubs lose 101 games in 2012.  Ron Santo, veteran Cubs player and broadcaster is inducted into the baseball hall of fame.  I think he would have liked to be inducted on the previous ballot, when he was alive to see it.
  • May 2, 2012 – (directly from Wikipedia) “A pastel version of The Scream, by Norwegian painter Edvard Munch, sells for US$120 million in a New York City auction, setting a new world record for an auctioned work of art.”  While we continue to hear about a sluggish economy here in the U.S., and in fact, around the world, apparently some of us still have lots of disposable income.  I could have taken the original, run it through some Instagram filters, and sent it to a place that prints pictures on canvas for a US$1 million, and netted a profit of around US$999,900.
    • Instagram was in the news this year.  I’ve never used it so I’ll mention it vaguely.  I rarely take a picture worth sharing, and if I do I don’t usually want to convert it to sepia-tone first.
  • June 24, 2012 – Lonesome George, the last known Pinta Island tortoise, dies at an unknown age believed to be over 100.   I don’t know about you, but a world without the Pinta Island tortoise, is a world I can live in just fine… because it looks exactly like every other larger tortoise I’ve seen at a zoo or Disney’s Animal Kingdom.  George was quoted as having said “The meaning of life is…”.  I’m joking.  He was a tortoise folks.  If he could have spoken he would have asked “Is there any more of that lettuce?  I would like some lettuce”.
  • July 27 – August 12, 2012 – The Summer Olympics are held in London.  This event gives swimmers a chance to be sports icons … until there is a professional league for them to compete in.  It also serves as a reminder that by and large, Americans do not “get”, or care very much about, soccer.  Also, we aren’t very good at it.
  • October 14, 2102 – (directly from Wikipedia) ” Austrian skydiver Felix Baumgartner becomes the first person to break the sound barrier without any machine assistance during a record space dive out of the Red Bull Stratos helium-filled balloon from 24 miles (39 kilometers) over Roswell, New Mexico in the United States.”  I’m curious if he’s scared of heights.
  • October 23rd, 2012 – Apple formally announces the iPad Mini, confirming and ending a years worth of speculation. Still to be determined is if this was the first Apple product released against Steve Job’s wishes, or simply the culmination of the late founder’s final act of misdirection and subterfuge.
  • October 26th, 2012 – Microsoft releases the Surface. For the first time in a long time the Microsoft faithful can stick out their tongues at the Apple and Android tablet disciples and chant “nya-nya-na-boo-boo”.
  • October 29th, 2012 – I was going to write something about Scott Forstall being forced out at Apple. But the man’s name will forever be associated with the first iteration of Apple Maps for iOS, so I feel no need to pile on further.
  • All of November, 2012 – A whole lot of nothing continues to happen in the NHL labor talks. This could have serious consequences for SlickEdit in 2013. In addition to our observance of the Spring Equinox, we also usually rely on waiting until the Carolina Hurricanes are mathematically eliminated from the Stanley Cup playoffs before readying the beta builds.
  • November 23, 2012 – Actor  Larry Hagman dies.  I remember as a child when JR was shot.  I still don’t know who shot him, and it wouldn’t matter very much since I’ve never seen another episode of Dallas – I just happened to be up that night.  But whether you loved Dallas or not, I think we can agree that in the last few years Mr. Hagman’s eyebrows had become kinda creepy.
  • December 20, 2012 – I write a Christmas themed post about receiving a VIC-20 for Christmas in 1983.  Along with the Commodore ad that features William Shatner, I try to fit a video of William Shatner singing (or perhaps it’s a dramatic reading of) “Rocket Man” at a Sci-Fi award show in the late 1970s.  We decide it doesn’t fit and it is omitted.  If you haven’t seen this, look it up on YouTube.  It is much funnier than anything I will write here.
  • December 21, 2012 – The world failed to end, highlighting the fact that if the Mayans were so terrific at predicting things, we would have more… Mayans.  My favorite Facebook post regarding this had Marvin the Martian staring into a telescope saying “Where was the Kaboom?  There was supposed to be an Earth-shattering kaboom”.
  • December 30th, 2012 – The Carolina Panthers eke out a come from behind victory over the New Orleans Saints, capping off yet another almost-but-not-quite season at 7-9, stringing us North Carolinians along for yet another year. Perhaps the Earth-shattering kaboom would have been preferable.  Can we get Cam Newton to stop doing that “Clark Kent ripping open his shirt- Superman thing” until they have a winning record after the fourth week of the season?
  • December 31, 2012 – Our first year in review post is completed.  Unless we did one before, I didn’t check.  The NHL and the player’s union are supposed to meet today.    We would love to add one more entry…
Christmas, 1983 http://blog.slickedit.com/2012/12/christmas-1983/ http://blog.slickedit.com/2012/12/christmas-1983/#comments Fri, 21 Dec 2012 15:23:57 +0000 http://blog.slickedit.com/?p=1497 Just before Christmas of 1983 my family moved from (state1) to (state2).  I’m happy to announce I was an Air Force Brat and didn’t move to either state voluntarily.  I would normally make jokes about why anybody would live in (state2) on purpose, or suggest that if anybody ever wanted to make a prison colony in the United States that we make a wall around (state1).  This is pretty Christmas-y so far right?

Let me setup the fall of 1983 for you.  The cold war was raging.  The base I moved to in (state2) was full of B-52s that were made could carry air launched cruise missiles. In September, a Korean Air Lines flight from New York City to Seoul (via Anchorage), with 269 people aboard, was shot down by the Soviet Union.  Later that same month, Stanislav Petrov, a lieutenant colonel in the Soviet Air Defense Forces, may have saved the world.  WarGames was in theaters, and probably only because my parents had not seen it, they relented and got me a Commodore Vic-20 for Christmas.

I have received a number of truly great Christmas presents over the years.  Among them are:

  • A remote control R2-D2 in 1978
  • My first electric guitar
  • My first son coming home from the hospital on Christmas Eve (after a rough entrance to the world 3-week hospital stay)

However, the Vic-20 holds a special place, because it probably kept me from saying “Would you like fries with that?” any longer than necessary.  When you’re a military kid, if you move when school is out it is difficult to meet people, so I learned to program in BASIC pretty quickly.

I would give some stats on the Commodore Vic-20, but it cannot be compared to any modern device.  I imagine any graphing calculator from 1993 was actually more powerful and had more memory.  I suspect there are kitchen appliances that have more RAM than the Vic-20 did.   I received a Commodore 64 the following Christmas, which was a far more usable device, but the Vic-20 set the hook.  And certainly you can see why here:

When coupled with the Commodore 1530 Datasette – which allowed you to save your BASIC programs on a cassette, you really had something.

So, thank you Mom and Dad.  This wise decision probably played a large role in me not still living at your house.

Merry Christmas!

http://blog.slickedit.com/2012/12/christmas-1983/feed/ 2
DiffZilla – Part 4 http://blog.slickedit.com/2012/12/diffzilla-part-4/ Mon, 17 Dec 2012 19:34:05 +0000 http://blog.slickedit.com/?p=1494 In the final video of the DiffZilla series we take a look at SlickEdit’s Backup History feature.

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

See part 1 here.

See part 2 here.

See part 3 here.


Things We Can’t Agree On… and a Few Decisions I’m Making to Solve Problems http://blog.slickedit.com/2012/12/things-we-cant-agree-on-and-a-few-decisions-im-making-to-solve-problems/ http://blog.slickedit.com/2012/12/things-we-cant-agree-on-and-a-few-decisions-im-making-to-solve-problems/#comments Thu, 13 Dec 2012 18:46:07 +0000 http://blog.slickedit.com/?p=1461 The following is a list of things that the world could not agree on:

  • The metric system is better than the English system we currently use (although I kind of like liquid measurements because it’s like they’re in powers of two).
  • We should drive on the right side of the road, from the left side of the car.
  • We can’t agree whether or not to have am and pm.  Here in the U.S. we tend to refer to 24-hour time as “military time”, but I believe this is the standard in much of Europe.
  • We can’t agree whether or not the day of the month, or the month itself comes first when listing the date.  Again, in the United States the military behaves differently than the civilian world, but other countries do it differently as well.
  • How to keep the music that was on a TV show in the actual TV show when it goes to DVD.  I have over dated myself here a bit, I was thinking more of Miami Vice, but it appears it was eventually released to DVD.  I never bought it, but those occasional Saturday afternoons when there’s a marathon of it on some basic cable channel, I enjoy several episodes while I procrastinate.

The things the world doesn’t agree on that annoy me, therefore making them by far the most annoying things the world does not agree on.

  • New line characters.  With the Mac’s “Unixification”, I believe we’ve moved from 3 formats to two, but WHY!?!?  I believe one standard is quite enough, and since it uses fewer characters, we shall use the Unix standard.  I’m fixing this, right now.  From here on, lines end with 0xA.  If you have old text files that wind up with extra characters, there are several things you can do.  I suggest that you CHANGE them.  Buy a copy of SlickEdit, and if you can’t figure out how to change them, one of the people in our support department will be proud to help you.
  • File system case sensitivity.  Case sensitive on UNIX, case insensitive/case preserving on Windows.  AND Mac.  And you could possibly have different file systems on UNIX that are case preserving, so that’s always a possibility.  I’ll make this decision too: case insensitive/case preserving.  OS and file system vendors, take note.  If you’re on UNIX and have separate files, one named “LS” and one as “ls”, I suggest that you CHANGE them first,  then comment on this post explaining why you would ever have done such a thing on purpose.
  • Indent levels.  Some people say 3.  Some people say 4.  Occasionally it’s 2.  I’ll make this very simple: it’s 3.  Make a note of it.  If you’re using a 2, 4, 5,  or some number other than 3, stop explaining why you prefer that number, and CHANGE it.
    • If the language you are using enforces a certain indent, I’m not talking to you.
      • If you are in your basement wearing a tinfoil hat developing another language that you think will solve the issues with all the ones available, and your language will enforce a certain indent level, make it 3.  That is now the standard.
        • Stop it.  There are 4,397,531 computer languages.  Yours will not solve all the other problems.  It will have it’s own share.
  • Tabs.  Some people like to use tabs to indent, and have them match the indent amount.  Some people like to set indent to one value (it had better be 3), and then set tabs to a larger number (maybe 8), so that it compresses the file somewhat.  So on a line that is indented four times, you get one tab and 4 spaces, thus saving 7 bytes.  So, when should you use tabs?  NEVER. Tabs have NO place in source code. You don’t need to save the space. Attempting to save space cost us a lot of time and money with the whole Y2K 2-digit year fiasco. Here is a 1TB hard drive for $60. Buy two and use all the spaces you need. If you need to compress the leading whitespace in your code, you’re doing it wrong.  SlickEdit it has a nifty feature to help you convert your tabs to spaces (Edit>Other>Tabs to Spaces).  Get to work.

If you’d like to wait until after the holidays to implement these changes, I understand.  If you’re waiting until after December 21st to see if you should waste your time in case the world ends because the Mayan calendar stopped there: they probably just stopped there.  They probably just took it out a couple thousand years and said “that’ll do”.

http://blog.slickedit.com/2012/12/things-we-cant-agree-on-and-a-few-decisions-im-making-to-solve-problems/feed/ 3
DiffZilla – Part 3 http://blog.slickedit.com/2012/11/diffzilla-part-3/ http://blog.slickedit.com/2012/11/diffzilla-part-3/#comments Wed, 28 Nov 2012 15:03:43 +0000 http://blog.slickedit.com/?p=1418

In the third installment of our series we cover using DiffZilla with version control systems, including:

  • Specifying a version control system
  • Accessing commands to display version history
  • Comparing the local working copy with a previous revision
  • Comparing two historical versions

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

See part 1 here.

See part 2 here.

http://blog.slickedit.com/2012/11/diffzilla-part-3/feed/ 2
SlickEdit tip #743 http://blog.slickedit.com/2012/11/slickedit-tip-743/ Mon, 26 Nov 2012 17:04:13 +0000 http://blog.slickedit.com/?p=1385 In my long tenure at SlickEdit, I’ve learned a few tips and tricks about using SlickEdit. You think faster than you type.  Why?  The brain has no moving parts.  There may be other reasons too, I’m not a doctor.

I believe the biggest time saver that SlickEdit offers is reducing the number of keystrokes you have to type.  Because you think faster than you type.  So the less time you spend typing, the less likely you are to lose your train of thought.

So SlickEdit tip #743 is as follows: try binding Ctrl/Alt shortcut keys for cursor movement so you do not have to your hands off of the main part of the keyboard.  I suggest the following:

Keystroke SlickEdit Command
Ctrl+I cursor-up
Ctrl+J cursor-left
Ctrl+Shift+J prev-word
Ctrl+K cursor-down
Ctrl+L cursor-right
Ctrl+Shift+L next-word
Ctrl+N page-down
Ctrl+P page-up


Depending on what emulations you’ve tried in SlickEdit, you might recognize a few of these already.  It takes some getting used to, but since have I adapted to using these key bindings, I believe they have saved me a lot of time.  Let me know what you think.

Tech Turkeys http://blog.slickedit.com/2012/11/tech-turkeys/ Mon, 19 Nov 2012 20:12:58 +0000 http://blog.slickedit.com/?p=1422 To mark this year’s Thanksgiving Day holiday, we offer up the following Turkeys. Sure, you can say it’s easy, or even fun to take pot-shots at failed technologies. But sometimes they result in painful trips down memory lane.

PacMan for Atari 2600My childhood recollection is that people awaited the arrival of this game with the same enthusiasm most 4 year olds reserve for December 25th. I don’t recall if the subsequent let-down resulted in any rioting in the streets, but I do remember learning some new vocabulary words from my older cousins the first time they played it.

E.T. for Atari 2600: See above. Downright heartbreaking that one of the best movies of all time should be sullied by this release. 1983 was a dark time indeed for the console faithful. This did at least leave us with a cool urban legend.

Apple iOS Maps: The much ballyhooed replacement for Google Maps on the iPhone most likely lead to the ouster of a long-time Apple executive, supposedly when he wouldn’t agree to sign a company apology. It’s still the subject of late-night talk show jokes.

The HD-DVD Format: Not quite a flop. More of the bloodied loser in the boxing match against BluRay. But Sony had lost the battle between BetaMax and VHS, and was determined not to suffer a repeat.

Ada: Despite having the best intentions, it did not make a dent outside the arena where it was required by law to be used.

SuperMan 64 for Nintendo 64: Our resident player/tester commented that “The only bright spot about that game was that I could turn it off at any point.”

Borland OWL (Object Windows Library): Intended to fulfill the role of the MFC libraries for those who chose to not use Microsoft developer tools. Whenever you see software where the Cancel or Exit button features a cartoon figure bolting for an exit door, blame OWL.

Lisp:  Proving that theoretically good ideas are seldom popular, and also that semicolons are easier to type than parens.

Virtual BoyThe best thing to come from the release of the Virtual Boy was not the headaches or nausea, but that if you actually bought one you now have a valuable collector’s item.

ClippyRemember the days of playing Whack-a-Mole with your word processor, clicking away every few minutes just to get that animated thing to disappear already? The sad part is that the user reaction to Clippy made software developers gun-shy in developing in-application assistants. I hesitate to categorize it as a Turkey. More akin to a Plague.

DiffZilla – Part 2 http://blog.slickedit.com/2012/11/diffzilla-part-2/ Tue, 13 Nov 2012 17:54:17 +0000 http://blog.slickedit.com/?p=1374 In this second video of our SlickEdit DiffZilla series we examine how you can use DiffZilla to preview changes made by quick refactorings and multi-file search and replace operations.

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

See part 1 here.


Misattribution of Quotes http://blog.slickedit.com/2012/11/misattribution-of-quotes/ http://blog.slickedit.com/2012/11/misattribution-of-quotes/#comments Tue, 06 Nov 2012 17:13:29 +0000 http://blog.slickedit.com/?p=1398 In observance of Election Day, we had planned to do a mock presidential debate between two competing technologies. Think Lloyd Bentsen debating Dan Quayle in the late 80s.

Moderator: The question back to you, Hg. What qualifies you to be the version control system of choice?
Mercurial: My implementation of distributed repositories is well regarded, and third party tool support is coming along nicely. If you look at my operating system support, you’ll see I support as many platforms as CVS did.
Subversion: Hg, I was born from CVS. My command syntax closely reflects that of CVS. I know CVS well as we have served side-by-side in datacenters across the globe. You sir are no CVS!

Or perhaps the classic Ronald Reagan and Jimmy Carter exchange

Java: Garbage collection, memory management, no pointers. These are the issues important to developers that compiled languages are typically against.
Moderator: C++?
C++: There you go again…

So as you can seen, politics and software technologies don’t really mix all that well. In fact, the results can be disastrous. We experimented with running a sophisticated source code indexing algorithm against internet-hosted code repositories. The indexing daemon was inadvertently pointed at site hosting political quotes. Behold the train wreck that ensued.









http://blog.slickedit.com/2012/11/misattribution-of-quotes/feed/ 1
Geek Costumes http://blog.slickedit.com/2012/10/geek-costumes/ Tue, 30 Oct 2012 17:04:30 +0000 http://blog.slickedit.com/?p=1377 While we very much enjoyed Wired Magazine’s recent Geek Dad list of Geeky Halloween Costumes, the list seemed to dominated by Sci-Fi movie and TV characters. We felt we could go a little nerdier.


The potential of using iPads (or any other tablet computer equipped with decent cameras) is exciting. However, the hardware costs may be a little more than you normally budget for costuming.

The Invisible Man : Strap one iPad to your front, and another to your back. Initiate a FaceTime session between the two tablets. The iPad in front will display what the rear one is displaying and vice-versa. The net effect on the adult wearer will appear to be a large hole through the chest, but small children can be rendered nearly invisible using this technique.

Indigestion : Requires only one tablet, mounted just above your belly button. Take several videos from antacid commercials and run them in a slideshow loop.

Infinity : Uses the same chest-mounted tablet. Attach a webcam to a long stick protruding from your shoulders and arrange it so the webcam points to the tablet. Display the webcam image fullscreen on the tablet.

Coding T-Shirts for Groups

A group of three could go as public, protected, and private. If you pick up a 4th wheel, they get the friend shirt.

Also for threes, make up shirts with <, =, and >. See how many relational operators you can construct. Extra candy for implementing (or having anyone recognize) the Perl spaceship operator.

For couples, go dressed as && and || and, in conversation, && disagrees with everyone as soon as he disagrees with one thing, and || agrees with everything anyone says once he’s heard on thing he agrees with. See if anyone catches on, or if everyone just eventually decides that && is a jerk.

Another idea for couples is to go as NULL and -> (alternative being * and 0). Stand close together and fall down (or freeze) whenever anyone addresses you.

Manifesto – Part B – Little Stuff Your Version Control System Should Do http://blog.slickedit.com/2012/10/manifesto-part-b-little-stuff-your-version-control-system-should-do/ Mon, 29 Oct 2012 15:42:53 +0000 http://blog.slickedit.com/?p=1222 So, you’re in your basement listening to Pink Floyd albums on vinyl, and wearing a tinfoil hat, and writing a version control system.  Your version control system is going to fix the problems of the 783,711 version control systems – free and commercial – that already exist.

Mathematically, it stands to reason that you are going to overlook something.  We have already established that there are 783,711 version control systems available, yet there you are with the same Pink Floyd album side playing over and over writing #783,712.  Because all of them didn’t do it right.  So the odds are you won’t get it exactly right either.  Maybe you’re not quite as clever as you think, or maybe your foil isn’t quite thick enough.  Or maybe you just overlooked something I find very important.  So here we go (in no particular order):

  • Under NO circumstances should the default check-in behavior be to delete the local file.  I’m going way back on this one… but this one bugs me.  When I have to write support for a version control system, I try to use it’s default options as much as possible.  And in this case I did too.  However, I found it such a terrible default it bears mentioning here.  Perhaps it made sense to somebody at a point in time when hard drive space was measured in megabytes.   But not to me.
  • Let us suppose your version control system supports separate repositories at a pre-specified location.  For example you set an environment variable:

If you allow multiple repositories (or modules, herds, gaggles or whatever you choose to call them) to be stored at TINFOIL1,port:80, I should be able to list them all.  There should be a command I can run to see all of them.  If your version control system uses a URL where only one thing can exist:


then this does not apply to you.  I do not have an opinion about which one is better, although the URL method seems to be more modern.  But if there is more than one thing, let me see it – do not make a colleague of mine and I sit and try things until we notice that there is a command that you can run that gives an error message for each module, and we can get it that way. I shouldn’t have to do something wrong in order to stumble across a correct answer.

  • Let me view all versions of a file  across branches.  I won’t go into detail here because I covered this in Manifesto – Part 1 – Branching.  But it is important enough it bears mentioning again.
  • Let me get a file, and put it where I want it.  Do not make me get the whole directory.  Do not make me get the whole directory structure, with just one file in it.  Let me get any version of any file, from any branch, and put it anywhere I please.
  • Let me run any command and specify the output in XML, or some other regular format.  I am adding support for this version control system to SlickEdit after all.  I don’t want to use your API.  I want regular output written to a file I specify, or that I can redirect to a file.
  • When running a version control command, a history or log command for example, let me refer to the file any way available to me.
    • If I am on Windows, let me refer to the local file, using a relative or absolute path, OR using the URL (or whatever the remote specifier is).
    • Do not make me use forward slashes in relative paths while I am working on Windows.
    • Do not make me change to a directory that was checked out and use a relative path.
      • I should be able to sit in “c:\temp” and run “tinfoilvcs history c:\src\project1\file1.cpp”.
  • Let me checkout multiple copies of the same branch/module/whatever.  Most recent version control systems do not have issues with this.  But I often find myself in a situation where I need to fix a bug, but my copy of the branch I am working on is “too dirty”.  So I checkout a new copy, fix the bug, check it in, delete the new copy, and update the other copy.

For extra credit:

  • Let a user plug in a 3rd party GUI diff on their own – so if they would like to run vsdiff.exe to view differences even if they run your version control’s diff command from the command line, they may do so.
  • In the above paragraph, replace “diff” with “3-way merge”.

Now go flip the record over.

Ode to Eclipse Bug 8009 http://blog.slickedit.com/2012/10/ode-to-eclipse-bug-8009/ http://blog.slickedit.com/2012/10/ode-to-eclipse-bug-8009/#comments Thu, 25 Oct 2012 15:45:34 +0000 http://blog.slickedit.com/?p=1319 Some people reading this post will already know about the bug of which I speak. For those of you who are unaware, I give you Eclipse bug 8009. This is the Eclipse Bugzilla entry for the absence of split editor windows in the popular IDE. The bug is now over 10 years old. The bug has a very rich history, and I encourage you to read through at least a portion of the thread. One of my favorite parts is at the very end of the comment history, where folks raise a glass to toast the 10 year anniversary of the bug. I also enjoyed the attempt to fill a virtual tip jar with money to bribe the developers to implement this feature. It looks like they raised at least $270.

I recently had the unfortunate experience of revisiting this bug (hadn’t seen the thread in a while) because of the newly released Eclipse 4.2 (Juno). At SlickEdit, we are currently working on our next version of the SlickEdit Core for Eclipse plugin, which will be built on Eclipse 4.2. In Eclipse 4.2, the split editor window problem has again become a major hurdle. I’ll refrain from voicing any dissenting opinion about the new UI released in Juno, though all the criticism seems to be warranted, and focus on the issue at hand. Several plugins, ours included, have implemented their own ways of providing split editor window capabilities within Eclipse. These implementations may have relied on internal APIs (bad practice), but there was no publicly available way to go about providing this feature. So we did what we had to do to provide what our customers wanted. Eclipse sure didn’t seem interested in actually providing a way to split an editor window in their IDE (remember, 10 years). And please don’t say, “Click and drag the window.”

Enter Juno, the new Eclipse workbench UI, and API changes which have broken these implementations. Of course there is no guarantee that internal Eclipse APIs will not change or break between releases, so this to no fault of Eclipse. Although maybe if the bug was addressed sometime in the last 10 years this wouldn’t be such a problem in the first place.

For now we are left searching for another workaround, and checking the status of this epic bug. The comment history has gone through a civil phase, a nasty phase, and then what seems to be phases of disbelief, and now acceptance. I really just wanted to share this thread to some who might not have seen it before. Maybe now you feel a little bit better about some of the long-standing bugs in your code. I hope we don’t ever have to toast them.

http://blog.slickedit.com/2012/10/ode-to-eclipse-bug-8009/feed/ 1
Introduction to DiffZilla http://blog.slickedit.com/2012/10/introduction-to-diffzilla/ Wed, 24 Oct 2012 16:02:39 +0000 http://blog.slickedit.com/?p=1259 In this first video on SlickEdit’s DiffZilla feature, we demonstrate comparing two source directories and show how to perform a quick file diff of two open documents.

In future videos we’ll cover more advanced usages of DiffZilla, including Backup History and version control history comparisons.

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

I WANNA KNOW WHAT DIRECTORY THINGS ARE IN!!!! http://blog.slickedit.com/2012/10/i-wanna-know-what-directory-things-are-in/ http://blog.slickedit.com/2012/10/i-wanna-know-what-directory-things-are-in/#comments Wed, 17 Oct 2012 14:58:04 +0000 http://blog.slickedit.com/?p=1238 “…I’ll answer the question. You want answers?”

I think I’m entitled.”

You want answers?!”

I want the truth!”

You can’t handle the truth! Son, we live in a world that has walls, and those walls have to be guarded by men with guns…”

The above comes from a very famous movie allegedly based on the life of a lawyer that runs those ads on TV now.  I don’t mean to imply that makes him better or worse than any other lawyer – people have to know you’re out there, and we don’t have yellow pages anymore.  It’s a great scene… I’m not going to mention the name of the movie… not because of any copyright or anything.  My premise started with the fact that the movie, and that scene in particular, are so famous that everybody will recognize it.  I’m sticking to that.

But right now,  want the truth – about the current directory of the tool I am in.  My responsibilities here at SlickEdit sometimes require me to use development tools that are not SlickEdit.  And whenever this happens, I find it difficult to figure out what directory I am in.   And this is not an indictment of a sole tool, although the one that prompted me to leave it and start this rant seems to be the worst offender.

Is the directory that my project is in a secret? Is there a dark piece of history surrounding the location of these files that have caused their family shame, and they don’t want me to know?  Do they think that I “can’t handle the truth”?  Am I the only user of these products in history to have to switch between two copies of the same project and try to figure out why one works and one does not?

I’m a big boy. I can handle it.  Just tell me.  And floating over a tab to show me where an open file came from is not good enough, because I don’t know if it is the one in that project or not.

For those of you who feel the same way, in SlickEdit you can go File>Change Directory to view (or change) the current directory.  You can also go to the SlickEdit command line (click on the status bar to the left of the Line indicator) and type “cd”.  Or if you speak UNIX you can type “pwd” if that makes you more comfortable… but typing “cd” by itself will not make the current directory of the editor your home directory.

Upon further review, I must admit the whole analogy falls apart somewhere around the part about “those walls have to be guarded by men with guns…”   But I love the line You can’t handle the truth!”.  But in this case, I can.  I just want to know what directory things are in.

http://blog.slickedit.com/2012/10/i-wanna-know-what-directory-things-are-in/feed/ 1
One size doesn’t fit all: iPhone vs Samsung Galaxy S3 http://blog.slickedit.com/2012/10/one-size-doesnt-fit-all-iphone-vs-samsung-galaxy-s3/ http://blog.slickedit.com/2012/10/one-size-doesnt-fit-all-iphone-vs-samsung-galaxy-s3/#comments Mon, 15 Oct 2012 19:47:51 +0000 http://blog.slickedit.com/?p=1282 I can’t be the only person who is very disappointed with the new iPhone 5 screen size. If you are too and are considering an alternative like the Samsung Galaxy S3, this article may help you.

After using an iPhone for about 3 years I decided to switch to the Samsung Galaxy S3. I loved my iPhone but the new iPhone 5 screen size simply is not wide enough for me. I couldn’t believe Apple wouldn’t make the screen wider. Choosing the right smart phone depends on what features are most important to you. For me, I was in desperate need of a bigger screen so I could read more on my phone and the S3 seemed like it would be worth the effort of switching.

The tasks I use my smart phone for

Most important:
email, phone calls, calendar, browsing

Some must haves:
camera, notes, weather, movie show times/reviews, stock quotes, stock trading, YouTube, Engadget (yep, I like to read about gadgets!)

Some nice to haves:
sports scores, live sports videos, TV Guide, calculator, poker with computer, black jack with computer

As you might have guessed, my smart phone is primarily used for work. I removed the Facebook app I had because there were too many notifications. I don’t have much time for games, something I suspect the iPhone is better at. While I listen to some music on YouTube, I haven’t purchased much music from iTunes. I did buy a ring tone as well as create one from a song I purchased. As far as apps go, I purchased two apps, one of which is now free. Hah, I’m not locked into Apple (“you will not assimilate me”).

Configuring the Samsung S3
I spent at least 12 hours configuring my phone. That should give you an idea of how bad I wanted to benefit from my new 4.8 inch screen. My time was spent finding and configuring apps, and learning how to be productive on my new S3. I wasted a lot of time getting my email to work well. Thankfully someone else took care of rooting my phone and installing CyanogenMod. I didn’t have to root my phone but I decided I wanted to be on the bleeding edge so I could have the latest greatest android features and fixes. I love the new default keyboard and the ability to configure my home screen icon grid to 5×5 instead of 4×4.

I highly recommend changing your font size and choosing something smaller if you have good eyes. I set the font size to “small” and this allows me to view more text in the apps that matter to me. If you don’t do this, you might as well be using an iPhone because the default fonts on the S3 are pretty large.

Email is not so great on android
The iPhone has one email app which works well with Yahoo email, Gmail, and Microsoft exchange (ActiveSync). The S3 and most android devices as of this article ship with two email apps. The Gmail app only supports Gmail. The Email app supports all the other typical providers including Gmail. Sounds good right? Here’s the catch, the Email app doesn’t support push notifications with Yahoo email (it does for Gmail if set up using Google Sync). For me, having push email for Yahoo was a requirement. That way I get my emails very shortly after they are sent and conserve battery life. After trying some other email apps, I liked MailDroid the best for providing push notifications for Yahoo mail and Gmail. Unfortunately, it doesn’t support ActiveSync yet due to Microsoft licensing issues so I have to run two email apps. The Email app looks ugly to me especially when writing an email (I won’t go into details here). It’s not a perfect solution but it gets the job done. I needed to tweak more settings than I expected for the Email and MailDroid apps to behave the way I wanted. In addition, I had to download Adobe reader for reading PDFs. The iPhone email app just works. For me, the iPhone email app is better than any combination of email apps on Android but I do like Androids ability to operate on multiple emails at once (say to delete several emails).

Advantages of S3 over the iPhone:
(keep in mind, this is based on my needs and not necessarily yours)

  • Big screen so you can read more. By far, this is the biggest benefit.
  • Pictures and Videos look better due to the larger screen.
  • More icons per home screen.
  • Back button at the bottom of the phone. The iPhone really needs this for better one handed phone use.
  • Widgets (like contacts and weather) can be placed on the home screen just like apps!
  • Menu button at the bottom. The iPhone needs this too but since many apps have buttons at the bottom, it’s not that big a deal.
  • Better keyboard enhancements. With CyanogenMod or the Swiftkey app, hold the period to get a menu of common punctuation characters.
  • Good support for multiple browsers or email apps.
  • Easier to configure home screens. I especially don’t like how iOS auto arranges icons!
  • Many more configuration options. I’m starting to really like this.
  • Easier to root phone. This provided me with a better keyboard and more icons on the home screen.

Advantages of iPhone over S3

  • Easier to use and configure. More things just worked for me with less or no configuring (visual voice mail, email, iCloud).
  • Security. Arguably better because apps go through an Apple review.
  • UI experience. More of the apps I’ve seen have a consistent look and feel with good looking graphics.
  • Apps. This will be very different for everyone. For me, the following apps are slightly better on iPhone: email, ScoreMobile, calendar, TV Guide, and WeatherBug. Although, Mobi Calculator Free is better than any iPhone calculator app I tried.
  • Touch screen. I find the iPhone screen slightly more accurate/responsive.
  • More pixels per inch so you can read smaller fonts. This is valuable when the browser displays something very small.  The whole Retina display thing has value but I’d rather have a larger screen so I can read more.
  • Cut/paste is slightly easier on iPhone because the popup is closer to your finger. There is also a problem on Android if you want to select and copy text from the first line of the screen (Yes, I ran into this problem).
  • Bluetooth for car just works. Like many, the S3’s Bluetooth for my car has problems.

This was my experience switching from the iPhone to the Samsung Galaxy S3; while it may not completely match your’s, there will probably be some overlap. If you’ve been using your iPhone for a long time, it will take you a while to make the switch. In general, the S3 is better suited for users interested in fine-tuning their environment and who do not mind spending the time to do it. Android has come a long way and I can definitely say that I’m enjoying my S3. Android needs to continue to improve the apps ease of use and automation (reducing setup time). For me, I would like the features for some of my favorite apps improved. Apple had better come out with a larger phone than the iPhone 5 soon because Android has a significant edge with so many form factors. Its a bit like TVs where a lot of the value comes from the size and quality of the screen. Like I said, one size doesn’t fit all.

http://blog.slickedit.com/2012/10/one-size-doesnt-fit-all-iphone-vs-samsung-galaxy-s3/feed/ 2
Manifesto – Part 1 – Branching http://blog.slickedit.com/2012/10/manifesto-part-1-branching/ Wed, 10 Oct 2012 15:30:54 +0000 http://blog.slickedit.com/?p=1155 In a previous article, I mentioned that you could contact me, that I’m always here working on my manifesto. One of you mentioned you would read a version control manifesto. So, while I wait for the coffee to soak in enough that I can code today, I thought I would work on it. Since manifestos, to my knowledge, are long rambling documents without a lot of structure, I figured I would just jump right into the middle, and discuss a topic as controversial as any political arguments we might have going on in our country at the moment. Obviously, I’m talking about branching.

Branching is a fantastic concept that allows you to split your code base when you need to create a complicated feature, or fix a complicated bug, but still have the benefit of version control.  When you are done, you can merge it back into the main branch (referred to as the “trunk” – I think it must be a pine tree, I’m not sure it works otherwise… it might be OK for oak, but it can’t be one of those trees that splits into branches and the trunk stops going in a straight line through the middle).

Different version control systems have handled this concept different ways.  Some (cough-sourcesafe-cough) just sort of didn’t do it.  This is how a lot of rock bands reacted to disco – they pretended it never happened and just kept doing what they always did.  Not all of them though.

If you’re not used to using branches, don’t be scared of it.  Branch the whole thing (don’t try just doing a few files, even if it is all you need).  But you do need to know how your version control system handles branching.  I will not be teaching you.  But I will mention what a couple of them did wrong, maybe yours (provided you are using CVS or Subversion).

CVS let you create branches with names – but unfortunately it created them with really confusing long numbers – the same way it did everything else.  Also the syntax to do this was bit of a pain – I honestly don’t remember it exactly – but you had to use the “tag” command with the “-b” option for branch, but not “-B” which meant something different (obviously) .  It was easy to look at a number and tell that it was a branch, but it was rather difficult to pair that number to the actual human readable name for the branch.  Sometimes you have to do this, particularly if you are writing support for CVS at a company that produces a programmer’s text editor.  But what it did right was make it easy to see all the versions of a given file, across branches.  So if you are looking for a fix that was in some version of /path2/path2/file17.cpp, but you then realize that fix might have been in a different branch, it was easy enough to look for.

If you knew enough command line options, you could merge two branches together.  I don’t remember how to do it, I’m not going to look it up.  I never completely trusted it.  I would check out both branches, use our multi-file diff to compare/merge them, and then commit.  It might have worked fine, but I found the options very confusing.  Also, learning to trust tools to perform complex operations for you is a process.

Subversion lets you create named branches that stay named (as far as we can tell).  Creating them is very intuitive, it has a “cp” command that we’re all used to (that’s the same as “copy” for the Unix impaired (for those of you who may be very young, it’s the same as right clicking on a folder and selecting “copy”, then “paste”, and then changing the name)).  So to create a branch all you have to do is type “svn cp http://svnRepos1/trunk http://svnRepos1/branches/branch13”.  Terrific, right?  No.  Actually not so much.  There are a few problems with this:

  1. Tags and branches are the same thing, which is nice because the one “cp” command covers everything.  The problem is that there is no difference between a branch and tag.
  2. The “Subversion people” (I forget the exact name of the consortium that runs this thing) suggest that you use the following layout for your repository so that you can tell the difference:
    1. http://svnRepos1/trunk/
    2. http://svnRepos1/branches/
    3. http://svnRepos1/tags/
  3. This layout works very well, we use it here.  It makes it easy to tell branches from tags.  Of course, it isn’t enforced at all.  Again the headache this causes is largely to a person – namely me – writing support for a system in a different product.  Also, because there’s no difference, and no enforcement of these directories, if you make a mistake putting one of these in the wrong place, nothing will detect it.  You’re thinking, “But Dan, you can just move it, no wonder you’re writing a manifesto you’re one of those idiots in your basement with a tin foil hat”.  But you’re wrong:
    1. I don’t have a basement.
    2. The real problem here is that unless you notice by accident nothing will tell you that you put the tag for your release version in the tags/ directory, and you will freak out when you try to check it out later and cannot find it.
    3. I’m not wearing a tin foil hat, I’m wearing a Cubs hat, and right now I’m pretty sure it makes more sense to wear a tin foil hat to block out signals from HAARP than it does to pull for the Cubs (motto:”Breaking hearts since before the triple bypass was invented”).
      1. This is a lie, I threw it in to try to be funny.  My son lost my Cubs hat while we were on vacation this summer.  I need to pick up a new one, along with another copy of Catcher in the Rye.
  4. It is very difficult to search for different versions of the same file across branches.  As newer versions of Subversion have been released, it has become possible, but still not easy.  SlickEdit’s Subversion History dialog does this.

Subversion’s merge command will merge another branch int0 your branch really well.  It provides a –dry-run command (CVS could do a dry run for anything with the global -n option, which Subversion does not have).  It works very well, except in a couple of mystery cases, where it does not work well at all.  The key is to merge often.  Here for example, development generally continues on the trunk.  If you are “out on a branch” working on a large feature that touches a lot of files, you will be much happier if you merge with the trunk often.  Eventually that feature branch will need to merge to the trunk, and that will be far easier if you continually merge the trunk into the feature branch.

Neither one of these provides a method to “cap” a branch.  To make a branch read-only so that it can be checked out – but no longer checked into.  This would be a good thing.

Finally, git and Mercurial provide an entirely different paradigm for version control – which means their branching works differently.  Their fans will tell you it’s better… I won’t draw a conclusion yet.

I will leave you with a final thought: If there are plugins available to augment the functionality I’ve complained about – I don’t care.  This is my manifesto, write your own.  Just kidding – I’d love to hear about them, but the truth is that I have to write support for these products, so I have to handle the way they behave out of the box.  So I can’t write support for history that shows branches across a file provided that a given plugin is installed.

I glanced at the preview – this is long, rambling, all text, no pictures, and spotty punctuation.  I think it qualifies as a manifesto.  Part 1 is a wrap.

P.S.: A colleague notes that I should mention that Clear Case did a fine job of branching over a decade ago.

Syntax Expansion, Dynamic Surround, and Surround-With Aliases http://blog.slickedit.com/2012/09/syntax-expansion-dynamic-surround-and-surround-with-aliases/ Tue, 25 Sep 2012 17:15:31 +0000 http://blog.slickedit.com/?p=1228 SlickEdit’s Syntax Expansion feature provides auto-completion support for common loop and conditional control structures in a variety of languages. Using Syntax Expansion with Dynamic Surround allows you to quickly rework existing code without having to manually insert braces or re-indent your source. Surround-With Aliases can be used in a similar fashion to refactor blocks of existing source.

Random observations from the implementation of the new C++ beautifier in SlickEdit 2012 http://blog.slickedit.com/2012/09/random-observations-from-the-implementation-of-the-new-c-beautifier-in-slickedit-2012/ Mon, 24 Sep 2012 19:50:53 +0000 http://blog.slickedit.com/?p=1167 Yes, parsing C++ is difficult. There are numerous web pages out there that detail the traps for the unwary, commemorate fallen projects, and offer up grammars in varying states of incompletion. While what we had to do for the beautifier’s parsing is many times simpler than what a compiler writer for C++ has to deal with, you still get some interesting issues that arise from trying to navigate the full C++ syntax without the benefit of the information available to a full fledged C++ parser.

There’s not a lot of literature on parsing C++ with incomplete information.

Which in hindsight, isn’t too surprising. It’s a messy problem that doesn’t have a clean “apply methodology X to problem Y, repeat” solution that you see in most publications. And unlike a compiler, the beautifier can’t afford to do a 100% accurate parse – that would require the beautifier’s parser to accept every grammar and dialect of every compiler product/version used by any of our customers, a tremendous effort on it’s own.

Since we don’t have the fully stocked symbol tables that most methods of resolving C++ grammar ambiguities require, we deal with them in other ways:

  • Some ambiguities don’t matter because resolving them wouldn’t effect any of the beautifier rules,so we ignore them.
  • More complicated resolution is handled by some parsing state that is refined as we parse through the source, that describes how sure we are of our parse. (i.e.: “in expression or declaration”, “definitely in a type decl”,”I do not recognize this place”).
  • When things get truly bad, we’ll rewind the token stream for a statement and restart the parse, using the information we gathered in the failed parse to guide the parse down another path. It’s a little bit expensive, and makes it hard to debug the parser, so this is a method of last resort.

Preprocessing makes everything more complicated.

As helpful as it may be for coding, preprocessing complicates the state handling in the beautifier substantially. Preprocessor conditionals can be tricky if different branches have wildly different pieces of code in them where braces don’t match up locally, or in cases where a single statement is spread across several branches of different conditionals. Unlike a compiler, we don’t just see the one path through the conditionals that the compiler gets from the preprocessing stage. We have to examine all of the branches, and we’d like to do something sane with all of them.

While simple macro expansions are less heinous, they can still be tricky for us when you consider we probably don’t know what the macro expands to.

You can always come up with a preprocessing trick that will trip up a parser, so the emphasis is more on minimizing the effects of the hiccups rather than assuming we can parse our way around all of them.

How you handle errors has a huge effect on your parsing strategy.

This is probably true for parsing in general, but differences in our strategy reemphasized the point for me.

For a compiler, you need errors to be informative, and you want to be conservative in how you pick restart points so you don’t flood the user with bogus cascading errors from an earlier syntax error.

For the beautifier, error handling is almost entirely dedicated to finding a good place further in the stream to restart the parse, while leaving bread crumbs for the output  pass of the beautifier so it doesn’t become completely lost. The remainder of the handling is for either:

  • Cases where we’ve obviously parsed ourselves into a corner, and need to rewind and reparse with a different assumption. (the assumption usually being either “declaration vs. expression” or “expression with a ‘<‘” vs “declaration with a template type in it”, etc…).
  • Cases where we’ve hit an EOF during the parse. This can be common when beautifying selections, and beautifying while editing. You have to take care not to lose partial parse information when this happens, even if you technically don’t have enough information to form a valid node in the parse tree.

In our favor, we are much less constrained than a compiler when it comes to picking restart points. If we trip up in the declaration of a function, and scan forwards to the first statement in the function, we’re certainly losing information, but not anything that’s going to be relevant for the configuration rules we need to apply.

And finally, related to error handling….

Don’t underestimate the value of good defaults.

It is guaranteed that there will be parse problems in the field. Vendor extensions, perverse use of macros, oddball syntax accepted by ancient compilers, etc… So when the inevitable occurs, what we don’t want to do is announce this to the user by switching to brace style 3 with double spacing in the section of code that was parsed incorrectly. And yes, early development versions did do things like this. It was horrifying to behold.

90% of the problem was fixed by just changing both the configuration and behavior defaults to have a sane behavior in the absence of parse information. The remaining issues we handle by doing a little bit of special handling in the output stage when we’re dealing with unparsed source, so we leave unparsed code with as few changes as possible.

SlickEdit Back to School Special for Students! http://blog.slickedit.com/2012/09/slickedit-back-to-school-special-for-students/ Thu, 13 Sep 2012 14:43:06 +0000 http://blog.slickedit.com/?p=1171 Attention all students focused on computer programming! We’ve got a great back to school deal for you! Now that it’s halfway through September and you have got your course load and your route through campus figured out, it’s time to make sure you have a fast, flexible editor at your finger tips to customize for all of your classes.

Designed by developers for developers, SlickEdit’s award-winning source code and text editor is respected for its rich set of coding tools and powerful time-saving programming features. A true cross-platform, multi-language editor, SlickEdit 2012 gives programmers the ability to code in over 40 languages on 9 platforms.

The SlickEdit Academic Multi-Platform license, which is valued at $649.00, is regularly available for $59.00, but can be purchased by students through October 31st for just $49.00.

To take advantage of this offer call 1-800-934-EDIT (3348) or email academic@slickedit.com and mention this offer. Proof of your current student status will need to be provided for eligibility.



Context Tagging and Auto-Completion in SlickEdit http://blog.slickedit.com/2012/08/context-tagging-and-auto-completion-in-slickedit/ Wed, 29 Aug 2012 16:25:47 +0000 http://blog.slickedit.com/?p=1145 This video completes the quick tour of SlickEdit’s Context Tagging-driven features.

The first video in the series can be found here.

This installment covers:

  • Auto-Completion
  • List Symbols
  • Parameter Info
  • The Preview tool window
  • The Defs tool window and the Current Context window

An Introduction to Code Navigation and Tagging in SlickEdit http://blog.slickedit.com/2012/08/an-introduction-to-code-navigation-and-tagging-in-slickedit/ Wed, 22 Aug 2012 14:07:26 +0000 http://blog.slickedit.com/?p=1138 SlickEdit’s Context Tagging is the engine behind many editor features, such as code navigation, symbol searching, and auto-completion. The first part of this video examines SlickEdit’s primary code navigation features, which are:

  • Go to Definition
    Bound to Ctrl+. to go to the definition of a symbol
  • Pop Bookmark
    Bound to Ctrl+, to return to the previous location
  • Find All References
    Bound to Ctrl+/ to display all references to a symbol

The middle portion of the video details how compiler, SDK, and Framework directories are tagged using the Auto Tag dialog.

The last minute shows quick demonstration of symbol searching.

Future videos in this series will examine other tagging-driven features like auto-completion.

Thoughts on Version Control in General, Mercurial, and a Couple of Closing Words From Bob Newhart http://blog.slickedit.com/2012/08/thoughts-on-version-control-in-general-mercurial-and-a-couple-of-closing-words-from-bob-newhart/ http://blog.slickedit.com/2012/08/thoughts-on-version-control-in-general-mercurial-and-a-couple-of-closing-words-from-bob-newhart/#comments Fri, 17 Aug 2012 13:15:29 +0000 http://blog.slickedit.com/?p=1091 I like to open with a joke.  I won’t this time, I’ll close with one.  And then I will let Bob Newhart make it funny.

I have spent my entire professional career at here at SlickEdit, and almost from the start, I have handled our version control support.  This means a couple of things:

  • I have only used (on a day-to-day basis) the version control systems that we have used here at SlickEdit.  In the early days we used our mutli-file diff feature.  I prefer to think of this as a testament to how good our diff feature is rather than what you are thinking – which is probably “that is pure insanity”.  In later years we used CVS.  Eventually we moved to Subversion.  A little sooner than we wanted because of how it handles branches – this is another story.
  • Because I have to handle supporting them in SlickEdit, I have tested most of the free and commercially available version control systems (and a few that are no longer commercially available) on small source bases.  I have not actually used all of them, I have some experience with them.  The technical term for this in our industry is, “I know enough to be dangerous”.

We have 3 kinds of version control support in SlickEdit:

  1. Basic “command line” support, where we will run your checkin command according to a specified command line where the file name is filled in.
  2. SCC support – For version control systems that have an SCC provider, we will communicate with it and provide the level of support that SCC allows for.  This can be frustrating because if an SCC system crashes, it will cause SlickEdit  to crash.  This happens occasionally because SCC providers tend to do their testing with Visual Studio, and not other systems.
  3. “Specialized Support” – This is what we provide for CVS, Subversion, git, and now Mercurial.  We provide a GUI for viewing what files you have modified, what files are out-of-date (where possible), and a nice history dialog, among other things.  Initially we did this sort of support for CVS because it was a different animal than the systems supported by 1 and 2.  CVS is more directory oriented, rather than file oriented.  This is true of all of the systems that have this kind of support.
Unfortunately, none of our support is a replacement for a basic level of understanding of  how to use your version control system.  This is increasingly true as time goes on.  If you do not understand how Mercurial works, even though we provide some nice GUI interfaces, using Mercurial through SlickEdit will still prove confusing at best.  For Mercurial specifically, I would recommend the Joel Spolsky tutorial, especially if you are an experienced Subversion user, as it is tailored for that.  Joel’s assertion is that Mercurial is better.  As of this writing, I still prefer Subversion, but he makes some interesting points.  Either way, it is an excellent introduction to Mercurial.

So, now SlickEdit supports Mercurial, which a little different from git, which is a little different from Subversion, which was a little different from CVS.  So, if you’re sitting at home in your basement (excuse me, “office”) writing a version control system that is going to solve the issues with Mercurial that weren’t solved in git, that weren’t solved in Subversion, that weren’t solved in CVS, I would like to say (politely):


Enough already.  The next version control system released needs to offer some real improvements over what is currently available.  Since I have to support it, I’ll be the judge of what is a real improvement.  Just contact me here… I’m easy to find.  I’ve been here my entire adult life, integrating version control systems, comparing files, and working on my manifesto (no, this isn’t it.  This doesn’t even scratch the surface).

P.S. The last couple of paragraphs are supposed to be funny.  I understand the differences/advantages of  these different systems, you don’t need to leave me nasty comments.

P.P.S. If you didn’t find any of what I wrote funny, take a few minutes and allow Bob Newhart to make you laugh.

If you don’t find this funny, I can’t help you.

http://blog.slickedit.com/2012/08/thoughts-on-version-control-in-general-mercurial-and-a-couple-of-closing-words-from-bob-newhart/feed/ 3
New feature: Beautify while typing. I use it every day. http://blog.slickedit.com/2012/08/new-feature-beautify-while-typing-i-use-it-every-day/ Thu, 16 Aug 2012 15:03:41 +0000 http://blog.slickedit.com/?p=1120 Hi Everyone,

I wanted to take the time to tell you about the new “Beautify while typing” feature for C++ and Objective-C that we added to SlickEdit 2012 (v17.0.2). This feature is off by default, which means many users won’t ever know this valuable feature exists. If you are editing C++ or Objective-C, I highly recommend you turn it on. I have this turned on by default and love it. Previously, my code was indented properly thanks to SlickEdit but I avoided putting in any extra spacing simply because it was too much manual work. This made my code less readable. Now I let SlickEdit beautify my code when I type a semicolon, open brace, or close brace.

Here is a quick sample clip of this feature:

To turn on this feature:

  • Edit a C++ or Objective-C file
  • Turn on Document>(C++/Objective-C) Options>General>Beautify while typing
  • Press OK
  • You can also turn on Document>(C++/Objective-C) Options>General>Beautify on paste or drag drop

It’s a good idea to create a beautifier profile customized in the style your company/project desires. Edit a C++ or Objective-C file and go to (Tools>Beautify>Options) to create and customize your own profile. The “Edit…” button allows you to modify the profile settings.

I hope you enjoy this feature as much as I do.

I welcome your thoughts on this exciting new feature in the SlickEdit Community Forums at http://community.slickedit.com



The Nine Billion Names of Search http://blog.slickedit.com/2012/07/the-nine-billion-names-of-search/ http://blog.slickedit.com/2012/07/the-nine-billion-names-of-search/#comments Tue, 31 Jul 2012 14:14:53 +0000 http://blog.slickedit.com/?p=1061 Arthur C. Clarke’s “The Nine Billion Names of God” is one of my all-time favorite Sci-Fi short stories. (Spoiler Alert) To oversimplify the plot, Tibetan monks hire some computer engineers to put together a system that will print out all the 9 billion names of God, speeding up centuries of effort. Their belief is that after this task is complete, mankind’s purpose on Earth will be fulfilled.

And while my goals are not quite so lofty, I felt it important to demonstrate all the varied ways you can perform searches in SlickEdit. No promises that it’ll save you centuries of effort, but you may learn a few new tricks.

Please note that SlickEdit is a multi-platform, multi-language editor. This recording was done on Mac OS X, which is only one of the 9 platforms options that SlickEdit offers. View all available platform options here

http://blog.slickedit.com/2012/07/the-nine-billion-names-of-search/feed/ 3
The Pale Blue Dot http://blog.slickedit.com/2012/07/the-pale-blue-dot/ http://blog.slickedit.com/2012/07/the-pale-blue-dot/#comments Tue, 24 Jul 2012 14:22:15 +0000 http://blog.slickedit.com/?p=1006 In 1979, when several members of the SlickEdit team were not yet born, I remember when Voyager 1 started sending back pictures of Jupiter.  The big thing I remember is that we learned Jupiter has rings.  I honestly don’t know if astronomers knew Jupiter had rings and we were just unable to see them from Earth, or if this was a complete shock – but it was big news in second grade science class, where the previous week’s lesson involved gluing macaroni to plates.  Or maybe that was vacation Bible school.  I seem to remember life before my tenth birthday involving a lot of pasta getting glued to plates, and then being spray painted gold by a qualified adult.  Either way, the Voyagers (there were two, but for reasons that will become only slightly clearer later, we are focusing on Voyager 1 here).

In 1990 Voyager 1 was leaving our solar system.  To show the Earth relative to the vastness of space, Carl Sagan convinced NASA to have the Voyager take a picture of the Earth from a distance (according to Wikipedia) of about 6 billion kilometers (to convert to kilometers to miles, I normally look at the little dial on my speedometer, but since it doesn’t go up to 6 billion I had to look it up – this is roughly 3,728,227,153 miles).  The photo, where the Earth is barely visible as about one pixel, became known as The Pale Blue Dot:

How does this tie into SlickEdit?  Poorly, to say the least.  Normally I try to open with a joke, but today it was the Pale Blue Dot.

SlickEdit will let you compare two URLs.  This isn’t a well known fact, so I figured it was an appropriate thing to blog about.  For example, if you wanted to compare two versions of a Wikipedia page, you could fill it out like this:

The output looks like this:

I realize, of course, that the Wikipedia has a built in facility for this, but I needed an example.

I hope this comes in handy for you someday, or maybe you’ll just go, “Wow, that’s kinda cool”.

And as you continue coding (with SlickEdit, I hope), try to remember that all the files in the world that ever needed to be compared,  all exist on that Pale Blue Dot.  Work hard – don’t forget to live hard too.

P.S.: I only want to hear comments about files that were compared in space on the ISS, space shuttle, etc, from people who actually wrote the software, or were in space doing the comparing.  If you were actually in space comparing files, you may use a MUCH higher level of sarcasm in your response.

P.P.S.: The ISS was not there when this picture was taken, but either way I imagine:

  • It would not be visible in the picture
  • The space where the ISS and other satellites exist would probably be covered by the same pixel or so.

If you did compare files on the ISS, Space Shutte, Skylab, or any of the Mercury, Gemini, or Apollo missions, please send us an autographed photo.

http://blog.slickedit.com/2012/07/the-pale-blue-dot/feed/ 1
Adding a New Compiler to SlickEdit http://blog.slickedit.com/2012/07/adding-a-new-compiler-to-slickedit/ Wed, 18 Jul 2012 14:49:10 +0000 http://blog.slickedit.com/?p=1022 SlickEdit supports several C, C++, and Java compilers out-of-the-box, and will attempt to locate your installed compilers at startup. For other languages, or for those cases where a compiler is not detected, you can configure SlickEdit to add support for the compiler. This video tutorial demonstrates how to configure support for the NQC (Not Quite C) compiler.

If you prefer to watch the videos directly on our YouTube channel, click here.

Video One

  • Creating a new compiler configuration
  • Specifying a compiler configuration header file
  • Tagging the compiler header directories

Video Two

  • Creating a starter project
  • Configuring the project to use a different compiler
  • Modifying build/compile commands
  • Adding new source files to the project

Video Three

  • Customizing SlickEdit’s error parsing to detect error messages in the build output
  • Using the Regex Evaluator to create and test a regular expression



Making a Difference with Software http://blog.slickedit.com/2012/07/making-a-difference-with-software/ Tue, 03 Jul 2012 16:07:40 +0000 http://blog.slickedit.com/?p=975 When I was first hired at SlickEdit, I remember going out to lunch with one of my fellow developers (Dennis, for those of you who are familiar with our language support guru) and having a conversation about how cool it was what some people get to accomplish every day, developing software. I think Dennis sensed that I might have been less than enamored with some of my daily tasks at SlickEdit, in terms of their positive impact in my world, and he was nice enough to express his personal feelings on the subject. When some people are writing code that is run on robots collecting data on Mars, and I am trying to implement some possibly-obscure set of commands for our Vim emulation, it is easy to look out the window and wonder what crazy-awesome project there is that I could be coding. Well as usual, Dennis hit the nail on the head and enlightened me that any feature I am working on for our editor could be saving hundreds of programmers valuable minutes (hours?) in their day. This, in turn, enables them to churn out more code, be much more productive, and lets us be at least a small part of all their great accomplishments. All was well in the jungle.

I recently came across a great local story about software making a huge difference in the lives of many children in our area. Just up the road in Wake Forest, NC, Melissa Matthews recently won the “Ikea Life Improvement Sabbatical Contest”. The award was a $100,000 grant to continue work on a project which will improve the lives of others in their community. Melissa is the mother of a child with down syndrome, and is well aware of the incredible work of software developers who are creating apps for special needs children. She is working with the Frankie Lemmon School right here in Raleigh, NC, to enhance their use of technology in furthering the education and development of their students.

If you check out the website born from this project/grant at http://frankielemmonschool.org/technologies, you can read all about the efforts of Melissa and the Frankie Lemmon school. One iPad app currently in use (DAF Assistant) helps students who have speech impediments by relaying delayed auditory feedback to them as they speak. It’s been well studied that this technique can make a big difference in their development. In true SlickEdit fashion, the app is very customizable and has received great ratings in the iTunes store :). There is a list of all apps for the iPhone and iPad being researched and used at http://www.kcdsg.org/files/content/24470331-iPhone-and-iPod-touch-Apps-for-Special-Education.pdf.

Of course, short of contacting any of these developers directly, I have no way of knowing that our editor was a part of the development of these pieces of software…but it sure is possible. At any rate, it’s always nice to hear about fellow coders who are working on special projects and making a difference. Maybe they are hardcore Vim users who just wish they had a nice graphical interface to organize their projects, while still being able to use their familiar Vim key bindings…

Running with Least Privilege: Software Vegetarianism http://blog.slickedit.com/2012/06/running-with-least-privilege-software-vegetarianism/ http://blog.slickedit.com/2012/06/running-with-least-privilege-software-vegetarianism/#comments Wed, 27 Jun 2012 16:03:05 +0000 http://blog.slickedit.com/?p=971 The term “Least Privilege” refers to the ideal of limiting a system to the bare minimum of resources it needs to function. As it applies to using a computer for work, it can mean using your computer while running under a user account that does not have full-time (or any) super-user or Administrator rights.

This has many benefits, chiefly limiting a system’s exposure to accidental changes or malware attacks. For software developers it has the added benefit of ensuring your software will install and function properly in such an environment. But developers frequently need those elevated rights for installing utilities, configuring the system for use-case testing, and using 3rd party tools that aren’t access rights savvy. So while many developers are aware of this practice, they aren’t inclined to work that way themselves.

I imagine that some least-privilege-resistant developers react to their more secure peers in a way very similar to how some people react to a person that is or claims to be a vegetarian.

Reaction #1: Quiet Admiration
Sure sounds like a good idea, and is probably good for you, but I don’t think I’ve go the discipline to do it myself.

Reaction #2: Suspicion of Dedication to the Ideal
We’ve all encountered folks who claim to be “mostly” vegetarian, but do allow themselves some animal sources. Is she really running that MacBook Pro under a Standard User account? I’m pretty sure I saw a “sudo” command in that Terminal window…

Reaction #3: A Cry for Attention
Are those who are claiming to run under least privilege just trying to score “I’m better than you” points? They’re just doing it so they can blog about it and feel superior.

Reaction #4: “I’ll Convince You that You’re Wrong
Some folks like to argue just to hear themselves talk. You know that guy gnawing on his 15th buffalo wing proclaiming that a vegetarian diet is incomplete and unhealthy? He’s the same one who’s certain that his un-patched Windows XP is just as safe as your system. And it runs faster, too.

Reaction #5: “It’s a Phase
The shine will wear off this fad pretty soon. You’ll be eating barbecue ribs and running Admin accounts with weak passwords by year’s end.

Do you run under least privilege, or have you tried it and given up?

http://blog.slickedit.com/2012/06/running-with-least-privilege-software-vegetarianism/feed/ 1
A Few of our Favorite Things http://blog.slickedit.com/2012/06/a-few-of-our-favorite-things/ http://blog.slickedit.com/2012/06/a-few-of-our-favorite-things/#comments Tue, 19 Jun 2012 16:21:04 +0000 http://blog.slickedit.com/?p=965 Whenever we’re putting together marketing materials, advertising copy, checklists of features to demo at trade shows, etc, a common start of the conversation is “What are the top features of SlickEdit”. Feature lists are all well and good, but just because we think a feature makes a Top Ten list doesn’t mean it resonates with every user. And features are usually spoken of in broad brush strokes, like “Version Control Integration” or “Configurable Keyboard Emulations”. But what really makes your editor an indispensable tool is the collection of small features and tricks that you use every day. And there is no Top Ten list that covers this, as everyone’s list is different.

We did a quick poll around the office to gather up some of the features that we use all the time. And yes, everyone’s list was quite different. So in no particular order, here are a few of our favorite things in SlickEdit.

Italic bold below denotes a Slick-C command, like complete-next, which can be executed from the SlickEdit command line or bound to a keyboard shortcut.

complete-next and complete-prev
Bound to Ctrl+Shift+> and Ctrl+Shift+< in most emulations. This searches for prefix matches in your current document. Very handy for completing words when you’re working in plain text or in a file format where Context Tagging is not able to provide symbol matches, or when you want to pick up non-symbol matches, like words found inside comments.

where-is, what-is, and bind-to-key
For those of you who like to keep your hands on the keyboard as much as possible, you need this. Sure this information is available on the menus and in the Options dialog, but why mouse around? Entering where-is on the SlickEdit command line will allow you to enter a Slick-C command to see if there’s a keyboard shortcut defined for it, while what-is lets you see the command name for a shortcut, or check if it’s free. Use bind-to-key to define a shortcut for something that’s currently not bound to one.

Aliases with %\n
If we had to list which features of SlickEdit we feel are underutilized outside our office walls, Aliases would be at the top of every list. Aliases simply allow you to type a short sequence which will be expanded, which is great for frequently used boilerplate text. They can be defined globally or on a per-language basis. We do provide some aliases out-of-the-box, but the real power is in creating your own. Go to the Tools > Options dialog, and search for “Aliases” to see where you can define them.
A common usage is generating “Caveman Debugging” statements. Here’s a sample alias for C.

printf(" %\n: %\c \n");

The SlickEdit alias facility has several escape sequences, and %\n is the sequence for “current function name”, and %\c positions the cursor for editing after the text expansion is made.

This feature originated as a macro written by one of our customers, which he shared on our community forums. It was so popular that we made it part of the product. It’s a great complement to comment-lines and comment-block.

Quick replacements from the command line
Doing a quick search and replace inside the current file is a snap using the c/old/new/ syntax on the command line. Even more power comes from using command modifiers after the trailing slash. For example, the ‘m’ modifier means ‘mark’ (our term for current selection), and ‘*’ means globally without confirmation prompting. So to change all instances of char to wchar_t in your current selection without a prompt, you would enter c/char/wchar_t/m* on the command line, and you’re done.

This is a super-quick way to compare your current file with the most recent version in version control, bypassing the version control history dialog. This currently supports CVS, Subversion, and Git. And if you’re using Subversion, and not currently able to connect to the repository, svn-diff-with-base performs a comparison with the ‘clean’ copy from your most recent update.

svn-get-annotated-buffer and cvs-get-annotated-buffer
A wrapper around the “blame” command for CVS and Subversion. Warning: May be habit-forming.

list-buffers and project-load
These bring up the Files tool window. Stop right there! You’re about to skip past this one because the word “Files” is pretty plain, and “bring up the Files tool window” sounds pretty dull. Do yourself a favor and try them out, and perhaps set up keyboard bindings for them. list-buffers will show you a searchable list of all the files you currently have open, allowing you to quickly switch to one without having to search through file tabs. Handy if you tend to leave a lot of files open in the editor. If you have a project open, the Project and Workspace tabs of the Files window allow you to find any file and open it from there. Very helpful for large projects.

Vim cursor keys
I hesitated to include this one initially. It’s not specific to SlickEdit, of course, and is only one of the 15 keyboard emulations we define. But if you’re a vi/vim adherent, having a high fidelity vim emulation built into your IDE is a big deal. It allows you to get all the benefits of the tools and features built into the environment without having to rewire you brain when you actually need to edit code. If you’ve ever accidently typed a stray ‘j’, ‘h’, or ‘dd’ or into an instant messaging client, you know exactly what I mean.

What feature(s) is/are highest on your list?

http://blog.slickedit.com/2012/06/a-few-of-our-favorite-things/feed/ 3
How to set up SlickEdit to manage LibreOffice source tree http://blog.slickedit.com/2012/05/how-to-set-up-slickedit-to-manage-libreoffice-source-tree/ Wed, 16 May 2012 15:03:12 +0000 http://blog.slickedit.com/?p=950 The recommended way to set up SlickEdit to manage LibreOffice is as follows.

Set up an empty workspace

Go to Project – New… and click on the Workspace tab. Select Blank Workspace, set a good workspace name (such as libreoffice-master), then set the path to the workspace to be the root of the libreoffice source tree + /slickedit. For instance, if your source tree is located in /home/foo/libo/master, then set the path to the workspace to be /home/foo/libo/master/slickedit. When the editor asks you to create a new directory because it doesn’t exist yet, select yes to create the directory. This will create a new workspace file (.vpw) under that directory.

Add projects to the workspace

Once you have an empty workspace set up, it’s time to add projects to this workspace. It’s best to use a single project to manage a single module i.e. have a project for sc, another project for svx, and another for sal, and so on.

To add a new project, have that empty workspace you’ve just created open, and go to Project – New…, check Add to current workspace check box on, type in the name of the module (sc, sal, sw etc) into the Project name box. In the Project Type window , select Other C/C++ as the project type. Make sure that you leave the “Create project directory from project name” check box unchecked, and that the location points to the same directory as your workspace. Then click OK to proceed.

It now asks you to add files to the project. To do it, click Add Tree to launch the “Add Tree” dialog. Set the path to the base project directory (for sc, it should be <root dir>/sc, and so on), specify the file types to include all used file extensions (*.c;*.cc;*.cpp;*.cp;*.cxx;*.h;*.hh;*.hpp;*.hxx;*.inl;*.xpm;*.hrc;*.src;*.xcu;*.xcs;*.hdl is a good one to use), make sure the Recursive check box is checked, then click OK. You will have to manually add several extensions that this project uses, such as *.hrc, *.src, *.hdl and so on which the default option doesn’t include.

Repeat the above process for all the modules you want to manage.

What projects to add to workspace

First off, you shouldn’t add all modules in the libreoffice source tree to the workspace, since that would overwhelm SlickEdit’s tag database, and will slow down the editor. Instead, we recommend that you only add modules that are relevant to the work you are doing.

For instance, if you are working on the Calc part of the code base, it’s sufficient to only add sc, formula, and sal. The sal module includes definitions to the rtl::OUString and rtl::OUStringBuffer classes as well as rtl::math functions, so it’s good to add that project to the workspace no matter which area you work in.

If you use UNO API’s a lot, then it’s a good idea to add solver as a project, but only add files that are under solver/<inpath>/inc/offapi and solver/<inpath>/inc/udkapi to enable auto completions of UNO structs, enums, constants and so on. Make sure you add *.hdl files as well as *.hpp files under these directories.

If you work on a wide range of areas, then it’s recommended that you set up multiple workspaces for different areas of focus. Switching between workspaces is very fast in SlickEdit, so this set up should not cause any loss of workflow efficiency.

How to update the workspace tag database

SlickEdit uses one tag database per workspace to allow context-sensitive source code navigation. The tag database file is named after the workspace name, located in the same directory where the worksapce file is, and it has a .vtg extension. It so happens that, when you update your git tree, the source code is updated, but your tag database isn’t. To update your tag database,

  1. Close the editor
  2. Remove the .vtg file under the workspace directory
  3. Re-open the editor

Once the editor sees the the tag file is missing for the workspace, it will re-tag the entire workspace.


This post was written by Kohei Yoshida and was reposted here with his permission. The original may be updated and/or extended and can be found here.

Philip’s Keyboard Guide to SlickEdit (with Vim emulation) http://blog.slickedit.com/2012/04/philips-keyboard-guide-to-slickedit-with-vim-emulation/ Thu, 12 Apr 2012 15:30:57 +0000 http://blog.slickedit.com/?p=943 One of our excellent community members who is new to SlickEdit took the time to make a great keyboard guide: Philip’s Keyboard Guide to SlickEdit (with Vim emulation).

He shared it with our community here. Check it out and share any comments you have to help him expand it for both beginners and experts!


GDC 2012 Post Show http://blog.slickedit.com/2012/03/gdc-2012-post-show/ Tue, 20 Mar 2012 16:21:27 +0000 http://blog.slickedit.com/?p=935 SlickEdit has exhibited at the Game Developers Conference (GDC) for the past several years. Despite the many benefits of social media, there’s no real substitute for being able to meet your current and future customers in person. So each year we shuffle off to San Francisco to show the flag for three days. It’s a great opportunity for us to show off our latest features and introduce our products to those who are new to software development. And we also enjoy the quick “thanks for a great tool” visits from current customers. The most satisfying thing to a software tools company is knowing that your customers are using your products to make really cool stuff. And the Game Developers Conference is packed to the rafters with really cool stuff.

But if all we accomplished was in-person advertising, we probably wouldn’t invest the time, money, and effort required to set up a 10’x10′ booth for three days on the other side of the country. What really makes exhibiting worthwhile is the ability to keep our fingers on the pulse of the industry. We find out firsthand what languages, tools, and platforms are trending. And we can gauge what types of features and functionality prospective customers are looking for, and what they like (and don’t like) about the current tools they’re using.

Some observations from this year’s show…

Unity buzz

Mobile gaming platforms have exploded in the past few years, and the tools to support creating games for those devices are riding a wave of popularity. Unity had a very large presence this year, and they generated a considerable amount of excitement at the show. Fortunately for us, the built-in source code editing tools for Unity, while free, leave quite a bit to be desired. (I will not name said editor out of respect to the feature-challenged.) It’s no exaggeration to say that 1/4 of the folks that wanted to demo SlickEdit were looking for a decent code editor for their Unity projects.

Teach your children well

Many of the attendees at the show are university students, taking courses in software development and in some cases game development specific curricula. Note that these are not your typical four-year college Comp-Sci majors, taking courses in compilers and data structures. Rather, these students are mostly in two-year degree or career oriented certificate programs. A few years ago it seemed that the vast majority of these two-year students were learning Java, and primarily using free tools like Eclipse. This year I was pleasantly surprised to find that students are not being fed a diet of 100% Java, but are also being exposed to C/C++, delving into scripting and utility languages like Python, Perl, and Bash, and are being introduced to version control systems as part of their coursework. I’m hoping some of these real-work-world skills are finding their way back into the four-year programs.

Why aren’t you people using version control?

One of our features that really resonates with SlickEdit first-timers is our Backup History, which keeps an incremental versioning history of your source files each time you save. We like to think of this facility as a safety net between version control check-ins. When demoing this feature I usually ask what version control system folks are using, and I am met with far too many blanks stares. For every chin-high steady-of-voice declaration of “I use Subversion”, or “We use Perforce at the office, and I use Git at home”, there are an equal number of sheepish shoulder shrugs, admitting that nothing is in place. Well, good luck to you…

Flash is alive and well

Despite Apple’s decision to banish Flash from iPhones and iPads, plenty of Flash-based games are being written. And that means plenty of developers need to edit and navigate ActionScript source. When we first added proper ActionScript support to SlickEdit a few years ago (again, due to demand we witnessed at GDC), we assumed that demand and usage would taper off and die in a couple years. That assumption was wrong.

The art of trade show swag is suffering

The past few years we’ve been bringing USB flash drives to the show, with all the installers for our products pre-loaded. But our “fun” giveaway hasn’t changed for the past 5 years. It’s what I refer to as the “bouncy spider”, or “octopus yo-yo”. It looks like a multi-colored sea anemone suspended from a bungee cord, and you bounce it up and down. It has no useful function (besides attracting folks to our booth), but it’s always the hit of the show amongst the giveaway goodie cognoscenti. Usually someone else at the show has an equally cool giveaway. But not this year. The monotony of an endless sea of t-shirts, notebooks, knit caps, logo-ed plastic bags, and ballpoint pens was disheartening.

Overall we had a great, successful trip and will definitely be venturing back to San Francisco at the end of March 2013 for the next GDC! What was your experience at GDC this year? Leave a comment below to share!

We’ll Be at GDC 2012! http://blog.slickedit.com/2012/03/well-be-at-gdc-2012/ Fri, 02 Mar 2012 16:25:47 +0000 http://blog.slickedit.com/?p=925 GDC 2012

We’re headed to the Game Developers Conference again this year! We’ll be in San Francisco from March 7 – 9 showing off our latest SlickEdit for Mac native Aqua interface version of SlickEdit as well as our newest features and improvements.

GDC is the world’s largest professionals-only game industry event. We’ll be there with hands-on demos of easy project set up, detailed back up history, context tagging, other productivity enhancing features, and of course our new Native Mac UI.

If you’re at the conference, stop by booth 815 to meet our team, learn about what we have in store for our customers in the near future, see our demos, and, of course, pick up some cool SlickEdit swag!

You can see what our booth looks like and also get an idea of what it’s like to be at the conference from this video that one of our developers made from GDC 2009.

Implementing an ODB Editor Suite Client http://blog.slickedit.com/2012/02/implementing-an-odb-editor-suite-client/ http://blog.slickedit.com/2012/02/implementing-an-odb-editor-suite-client/#comments Tue, 14 Feb 2012 16:13:28 +0000 http://blog.slickedit.com/?p=917 The ODB Editor Suite is an AppleEvent-based protocol published by BareBones Software. It allows for a Mac OS X application to request that another application edit a file, and report back when that file is modified or closed.

The documentation provided with the SDK does a good job explaining how a “Server” application (an application that needs some editing done) can send and receive the appropriate AppleEvents to an editor like BBEdit. Many third party applications now support the client side, but the “how to” is not documented very well. For those not intimately familiar with AppleEvents, getting started can be a bit daunting. This article, and the provided sample applications, aim to fill in that knowledge gap.

Sample Source

The sample zip for this article contains:
LilPad – A small text editor application, which implements the client side of the ODB Editor Suite.
ODBServer – A testbed application which can be used to invoke ODB client applications.
ODBSuite – A directory containing a stub for the ODBEditorSuite.h header file. This must be downloaded directly from BareBones Software.

Handling the ‘Open File’ AppleEvent

Most document-based applications are already set up to handle this event. Even if you aren’t explicitly adding a handler for the kCoreEventClass/kAEOpenDocuments AppleEvent, the Cocoa frameworks are set up to handle this via your NSDocument class, or the NSApplicationDelegate application:openFiles: message. The LilPad sample application does this in the override of the readFromURL:ofType:error: message (in MyDocument.m).

The AppleEvent sent by an ODB Server app will contain the extra ‘FSnd’ (keyFileSender) parameter. The client application must save this identifier in order to properly respond to the server app. A server app will also usually send an identifying token (keyFileSenderToken, ‘FTok’) and a “Custom Path” (keyFileCustomPath, ‘Burl’), which is usually used to specify a more friendly display name, rather than the full file path. A client app can safely ignore the keyFileCustomPath parameter, but should retain the reference to the token if one is provided.

If you’re authoring an NSDocument-based application, you can store the associated parameters right in the document object. Otherwise, you’ll need to set up a dictionary to hold the parameter values.

Notifying the Server

The code that demonstrates notifying the server application is found in the LilPad sample, in MyDocument.m. The [MyDocument saveDocument:] and [MyDocument close] messages override the NSDocument base implementation in order to inform the server application that changes were made. [MyDocument setFileURL:] is overridden in order to handle the “Save As” operation.

The client application must do the following.

  • Construct an AppleEvent with the class code of kODBEditorSuite.
    The eventID is either kAEModifiedFile, kAEClosedFile, or keyNewLocation.
    keyNewLocation is used when the client application performs a “Save As” operation.
  • Identify the target of the AppleEvent by the server application’s package signature. This is the ‘FSnd’ value of the “Open Files” event.
  • The keyDirectObject of the event should be set to the “file://path/to/doc.txt”-style URL of the modified/closed/renamed file, with a descriptor type of typeFileURL.
  • If the original “Open Files” event specified a token, this should be sent back as the keySenderToken parameter. Simply provide the reference to the NSAppleEventDescriptor that was retained earlier from the keyFileSenderToken param.

Give it a spin

The ODBServer application can be used to test your ODB Client application. Simply replace the hard-coded reference to the LilPad bundle id (com.slickedit.lilpad) with that of your own application.

http://blog.slickedit.com/2012/02/implementing-an-odb-editor-suite-client/feed/ 2
Dr. StrangeUnix Or: How I Learned to Stop Worrying and Love the Mac http://blog.slickedit.com/2012/01/dr-strangeunix-or-how-i-learned-to-stop-worrying-and-love-the-mac/ Wed, 25 Jan 2012 15:25:19 +0000 http://blog.slickedit.com/?p=262 Early in the last decade, the number of requests we got for a Mac version started to increase dramatically.  One of our developers at the time was particularly afraid he would be chosen to do this work because he had some Mac experience – but he really didn’t want to.  Naturally, he came in one morning to discover on his desk an old Mac SE30 that used to be used for something around here (I believe it was used to print out labels for floppy disks) sitting on his desk with a Mac OSX CD hanging out of the floppy disk drive and a note that read “[Developer name changed to protect their identity] – see me – Clark”.  (Note to our new users: SlickEdit has been around long enough that it used to ship on floppy disks) (Note to users under 30 – USB sticks did not always exist).

The prevailing wisdom at the time was that it would be easy for us to do a Mac version, “because it’s just UNIX now, and you guys are UNIX already – it’ll just be another port”.  I remember hearing this over and over at trade shows in between requests for Ruby support, and “Do you guys have any free t-shirts?” (Right now, there’s a guy in his basement inventing a new scripting language, convinced his will be the one that will take over the world, obsoleting all other scripting languages.  I really wish somebody would stop him, because it won’t take over and obsolete all other scripting languages, but it will become just popular enough we will have to support it.  When I say “stop him”, I don’t mean hurt him or anything – just take him out to dinner or introduce him to a woman).

It turns out the “It’s just UNIX now” logic is a bit, what’s the word I’m looking for…. wrong.  There is UNIX under there, and obviously that was a good place to start when they revamped MacOS.  Plus, I can get a console window which was always my complaint about Macs “back in the day” (yes, I know you could install something, I maintain it should just be there).  But what the fact that “It’s just UNIX now” got us was the ability to create an X11 application that would run on the Mac.  So we did that – and customers loved it.  Well, that isn’t exactly true.  They acted more like we gave them a new BMW but first used it for one of those things you see at the county fair where you pay a dollar and get to hit a car with a sledgehammer (granted they usually do this with demolition derby cars, not new BMWs).  It was SlickEdit – it worked, but it just didn’t look or feel like people expected it to. Hardcore SlickEdit fans were happy… ish.  They were happy to have SlickEdit, but they missed all the Mac-isms, and were a little perturbed by SlickEdit’s menu being attached right to the top of the application window.

So, starting sometime in 2010 our CTO began the process of exploring how to get us a native version on the Mac – and the GUI overhaul that ensued stayed largely in his office until sometime this past spring when different team members began to have certain controls assigned to them to port to our new GUI framework (I’m not going into which one here, the evidence is “out there”).  I was able to be part of this process, and it was very interesting work.  It is an exciting time to work here at SlickEdit.

We had a nice long beta test – a little longer than we planned. I would like to take a moment to say that our beta testers were some of the best we’ve ever dealt with.  Even when there were problems, the comments almost always went something like “It crashed, but thanks for doing a native Mac version, great work, looking forward to the next version!”.  The beta testers this time were aces – some of them old SlickEdit fans we’ve known for a while, and I believe we made some new friends too.  Thanks guys.

So, our native Mac version is “out there” now.  We hope everybody likes it.  Typically I haven’t been a big Mac fan, but I’m learning to appreciate the things that it does well.  I only wish I could get a few people to join me in an Indiana Jones like quest to track down the eleven remaining single button mice on the planet and then Ctrl+Click could work properly.

If you bought any of our X11 versions on the Mac you can get the new version for free. Here’s the link,or you can give our sales team a call at (919) 473-0070.

Last Minute Gift Ideas for the Programmer in your Life http://blog.slickedit.com/2011/12/last-minute-gift-ideas-for-the-programmer-in-your-life/ http://blog.slickedit.com/2011/12/last-minute-gift-ideas-for-the-programmer-in-your-life/#comments Thu, 22 Dec 2011 17:41:38 +0000 http://blog.slickedit.com/?p=883 If you’re in need of one last gift for the techie on your holiday shopping list, we suggest the following.

Caffeinated Soap
No, we’re not making this up. http://www.thinkgeek.com/interests/giftsunder10/5a65/ 
Between end-of-year project deadlines, gift shopping, and other holiday preparations, a coder can get really squeezed for time. And you don’t want to back a programmer into a corner where they have to choose between sufficient caffeination and personal hygiene. This should avoid any such unpleasantness.

A Blunt Instrument
There are situations in which you simply cannot improve upon a large hammer.  This is the reason that the B-52 has had such a long lifespan. This orange beauty will allow your beloved techie to vent frustration upon keyboards, desks, recalcitrant Solaris machines, etc without the risk of forehead or hand injury.

A “Come home for dinner late” card
It’s surprising how many bugs are found just after the “I’ll be home by 6:15 for dinner” phone call. Your programmer is now torn between a promise to loved ones and a dedication to hunting down that crash before calling it a day. Give them a Monopoly-style “Get out of dinner, free” card so that at least once this year week, they can arrive late without guilt.

A USB-chargeable flashlight
A USB flashlight is insidious in its irresistible blend of techie-seducing features. First off, it’s a USB device. *Anything* USB (and to a lesser extent FireWire) is worthy of investigation. Secondly, it’s the size and shape of most trade show trinkets, which programmers are wired at birth to hoard. Thirdly, it has a genuinely useful function, which all but ensures your coder will make every effort to rationalize this gadget’s place in the laptop bag for years to come.

Carpal Tunnel Therapy
Because sometimes you gotta play hurt.
(Not yet verified, but I think this thing can also make homemade ravioli…)

Yoga Gear
Not only is this great for relieving the tension of long hours frozen at the keyboard, it appears to also be a crafty way of furthering ones career.

http://blog.slickedit.com/2011/12/last-minute-gift-ideas-for-the-programmer-in-your-life/feed/ 1
Setting up new file types with the SlickEdit Core plugin http://blog.slickedit.com/2011/12/setting-up-new-file-types-with-the-slickedit-core-plugin/ Fri, 16 Dec 2011 16:52:32 +0000 http://blog.slickedit.com/?p=856 Many developers work with source code which resides in files with “non-standard” extensions. By a standard extension, I am referring to something like .cpp or .java. By a non-standard extension, I am talking about .ryan, or .data. I will show you how to quickly and easily set up your SlickEdit Core editor in Eclipse to handle these files the way you want them handled.

Let’s assume you have some file extension which is not already set up accurately in the default SlickEdit Core configuration. It might be something your company only uses internally. Let’s use .data for this example.

I have a workspace created which includes some .data files, and what I first see in the Navigator view is this:

When I go to open one of these files, Eclipse will use the standard Text Editor because it does not know better:

Not terribly useful…clearly the SlickEdit editor has not been opened, and we have no language support whatsoever. These appear to be COBOL files…so we should set up Eclipse to recognize them as such, and also tell SlickEdit that these files should be treated as COBOL code.

The first step is to go to Window > Preferences > Editors > File Associations and add *.data as a “New File Type”. Then select *.data in the list and click the Add button in the “Associated Editors” pane. Now select “SlickEdit Editor”. Make sure you mark “SlickEdit Editor” as the “Default” editor for this file type. Now we have told Eclipse to open all .data files with the SlickEdit Editor.

We are not quite finished yet. Now we need to tell SlickEdit to treat these files as COBOL. So, go to Window > SlickEdit Preferences > Languages > File Extension Manager and create a new extension for data (just data…not *.data), and assign the language to be Cobol 85. Click “OK”, and then click “OK” on the SlickEdit Preferences dialog. Now when you open up one of these .data files, you will see the correct editor opened with the correct language support.

SlickEdit Core for Mainframe Developers http://blog.slickedit.com/2011/12/slickedit-core-for-mainframe-developers/ Tue, 06 Dec 2011 15:07:44 +0000 http://blog.slickedit.com/?p=798 The problem of retiring mainframe developers has been well publicized in recent years. Mainframe systems are not going anywhere, and programmers now expect to be working within the comforts of a modern IDE, rather than on a simple terminal. Eclipse-based front ends have become great solutions for this new generation of programmers working on mainframe systems.

Since the Eclipse IDE has become so popular for mainframe developers, we have been dedicating more and more resources to our mainframe language support. The SlickEdit editor is even now integrated into the Compuware Workbench:

Supports a vast array of programming languages for source code editing, powered by SlickEdit.

PL/I is one of the mainframe languages that got a major support upgrade in the newly released SlickEdit Core v3.7.1. The SlickEdit editor now has full support for parsing structures, includes, and even statement level tagging for PL/I code.

SlickEdit Core also has great support for COBOL, JCL, REXX, and other languages. If you are a mainframe developer coding in an Eclipse-based environment, try out the latest version of the SlickEdit Core plugin for free.

SlickEdit for Mac doesn’t look like iTunes http://blog.slickedit.com/2011/12/slickedit-for-mac-doesnt-look-like-itunes/ Mon, 05 Dec 2011 17:15:16 +0000 http://blog.slickedit.com/?p=786 Last week we released our first public beta of SlickEdit v16.1 for Mac. This version replaces our previous iterations that used the X11 windowing system. Although we are using a cross-platform UI library which uses Cocoa for UI, and we’re writing quite a bit of our own Cocoa code for other Mac features like the Services menu, it doesn’t look like every other Mac application. And there are reasons for that.

SlickEdit is an MDI application
While there are some very well known applications that support a multiple document interface on the Mac, there is no real standard for how they should look and feel. Each application has a slightly different interpretation. As such we have chosen to keep our MDI implementation very close to what we have used in recent versions.

SlickEdit does a lot
This mostly affects how we present our application configuration options. Most Mac applications have a relatively small Preferences pane, perhaps with half a dozen categories, and a half-page screen of options for each category. But SlickEdit has 20+ years worth of features and configuration settings. Developers come to SlickEdit from a wide variety of editing environments, and our users want to be able to mold the application to their tastes.

SlickEdit is not just for the Mac
Like all multi-platform software, we have to make trade-offs between what might look best for a particular operating system, and what makes the most sense for a feature that needs to work on all of the supported platforms. There is also quite a bit of bias toward keeping functionality and appearance consistent with what long-time customers want and expect. SlickEdit has always placed a premium on letting you work with multiple languages on disparate platforms without having to retrain your brain and fingers. When implementing and tweaking features, we are constantly evaluating what a Mac user would expect, and what a SlickEdit user (regardless of platform) would expect.

SlickEdit will continue to evolve
While we do want to keep our product familiar across platforms, we aren’t going to be sitting stock still. While our immediate focus for the Mac is improvements to Objective-C language support, and better interoperability with Xcode project formats, we are looking forward to changes we can make in the user interface to improve effectiveness and efficiency. Getting this first non-X11 release ready was a big effort. And now that it’s almost done, we’re looking forward to making it the best it can be. We’re excited, and we hope that you will be too.

If you haven’t yet taken a look at SlickEdit 2011 for Mac, we invite you download our most recent beta version.

Macros Challenge Winner Selected! http://blog.slickedit.com/2011/11/macros-challenge-winner-selected/ Mon, 07 Nov 2011 17:22:19 +0000 http://blog.slickedit.com/?p=781 Thank you for all of your entries to our Macros Challenge! We received many excellent submissions and choosing a winner was not an easy task. Our entire development team carefully evaluated each entry for originality, usefulness, engineering difficulty, ease of use, and overall code quality. The macro that did best overall was at5dapa1’s Synchronization between Visual Studio 2010 and SlickEdit 2010.


It’s the Last Week of the Macros Challenge! http://blog.slickedit.com/2011/10/its-the-last-week-of-the-macros-challenge/ Mon, 24 Oct 2011 14:23:34 +0000 http://blog.slickedit.com/?p=774 Don’t forget to enter your macro to the SlickEdit Macros challenge for your chance to win an iPad 2.
You can enter now through October 31, 2011, so there is still time to put your best macro together and submit it for your chance to win! Click here for contest rules and how to enter.