Cute trick to snarf Windows dialog box text

I have long been frustrated when trying to report bugs in Windows, because I could not easily snarf the text of a dialog box, etc., to stuff into the bug report.

Well, it turns out there is a way:

http://stackoverflow.com/questions/158151/how-can-i-save-a-screenshot-directly-to-a-file-in-windows

PhiLho:

Little known fact: in most standard Windows (XP) dialogs, you can hit Ctrl+C to have a textual copy of the content of the dialog. 

Example: open a file in Notepad, hit space, close the window, hit Ctrl+C on the Confirm Exit dialog, cancel, paste in Notepad the text of the dialog.

Well, I have wasted lots of time not knowing this...

O)f course, I would learn about it after I get into the habit of using tools like SnagIt and Windows 7's Snipping Tool to snip bitmaps by default, and paste those into... email, OneNote.

Heck, yesterday I got a primitive ability to paste images into GNU EMACS "text" files.
      (Basically, I am making such text files be directories, and using my-org-screenshot (found all over, e.g. http://pastebin.com/QfLb9ZBr) to put the screenshot into a file that EMACS' org-mode can reference. Currently using directories, am modifying EMACS' tar mode to allow the new file to be written. Following my dictum that "UNIX already has all of the support needed for structured files: directories. Archives of directories, to make them convenient to move around.")

Heck, I think the biggest change in my usage patterns over the last three years has been to start blithely throwing bitmaps around.  Basically, to treat bitmaps as a first class data type.

Especially useful when you have tools like Microsoft OneNote that can OCR a bitmap.  Abd can therefore do a pretty good job of searching notes composed out of bitmap files.

Centralized Notification Ringtone/Sound Management

Android allows me to have different sounds (ringtones) for different notification events.  This is good.

However, each seems to be managed in isolation. This is bad.

The most important thing about sound notifications is that they be distinct, so that you can remember which is for what. Best if there is some natural connection - like the sound of mail dropping through a slot for incoming email. (Although I get so much email... this is the only natural one I can think of.)

But distinct.  Not good to have the same sound for incoming email (low priority), as for the reminder to get in the car and drive across town to an appointment you don't want to miss.

Manged in isolation, need to jump to each notifying app and change.

Want cenralised management, where I can see a list of all the different types of notifications I use, and can hear their sounds back to back.

I think Blackberry had this.  But "all the differet typs of notifications I use".  *I* *USE*.  I recall the Blackberry list had all the notifications on the phone, includng many I had no idea about.  Wasted time setting distinct notificaions, n one case thinking that incoming mssages meant incoming SMS text messages, not some other service.

--

Want different notifications for calendar items.  E.g. different notifications for the "Leave now, drive 1 hour across town", and the "Pick up the phone for a meeting".

Version control over multiple paths

Changes that are logically associated are often interleaved:

E.g instead of

v0--(big change a (a1) (a2))-->va--(big change b (b1) (b2))-->vab

we often see

v0--(a1)-->va1--(b1)-->va1b1--(a2)-->va12b1--(b2)-->va12b12

now, some people like to rewrite history, to get the all a before b change. I don't want to rewrte history. But I do want to create a more easily understood version of history.

Why can we not have multiple paths to the same end result? E.g.

v0--(a1)-->va1--(b1)-->va1b1--(a2)-->va12b1--(b2)-->va12b12
  \                  ||                                                                     ||
   o--(a1)-->va1--(a2)-->va12'--(b1)-->va12b1'--(b2)-->va12b12

What are the chances of this formatting working? The diagram probably is messed up.

Anyway, this depicts an alternate history.  va1 and va12b12 correspond to exactly the same file contents as the original history.  But va12' and va12b1' do not.

We can imagine allowing the user to "check out" va12' and va12b1', but warning that it never occurred in the original history, and may not have been tested as well.

We can also imagine back annoating, ti say that these versions were okay. Tests passed.

For that matter, we could also have

v0--(a1)-->va1--(b1)-->va1b1--(a2)-->va12b1--(b2)-->va12b12
  \\                  ||                                                                     ||
   o--(a1)-->va1--(a2)-->va12'--(b1)-->va12b1'--(b2)-->va12b12 

   ||                                                                                       ||

   o--(b1)-->vb1'--(b2)-->v12'--(a1)-->va1b12''--(a2)-->va12b12

and, overall, between any two points we may have an indication of what chagesets may be grouped, and which are commutative.  as well as recording which intermediate points in the possible histories have been tested.

DVCS branches

If branches are a first class concept in a DVCS, then it should be possible to rename them.

If branches are just a "tag", then it should be possible to rename.

I don't want to lose history.  I just want to revise it - preservingtheoriginal.

Email with a friend about Mercurial

A friend:

Reading a hg tutorial now. They make a big deal out of having your own local repo that you can commit to and push to a shared repo when ready. That is essentially how I use branches in Svn.  But branches are a pain when you have many trees. Trying to keep track of them all...  

Urg.  So many brain damaged DVCS people say that a private repo is a branch.

Maybe so ... but it is a dead branch that has fallen off the trunk,

and is lying on the floor of the forest waiting to rot, get chippered, or catch fire.

Or maybe, just maybe, get grafted back.  

Ok, analogy too far.

But...  Mercurial does have real branches.  Just like svn, just like cvs, just like ...

First you clone a repo.

Then you make braches in your local repo.

You can check in to the branch in your local repo.

You can push your local repos changes to the master repo.

You can push the local brach, but they warn you about this - real branches were added late

to Mercurial, and many people are scared of them.

(Git, on the other hand, treats braches much more naturally.)

You can merge from the trunk to your branch, in your local repo (you always work in your local repo).

Test that worked.

When it does, merge from that back to the trunk 

(the trunk in Mercurial is called -rdefault)

Finally push that from your local repo back to the master repo.

Here:

hg clone master-repo local-repo
cd local-repo
hg update -r default
hg branch task-branch
..make edits
hg ci -m 'my-edits' // on task branch
hg push master-repo // push, just to save in master repo. don't merge yet.
hg pull master-repo // probably updates the trunk, -r default, and maybe branches opther than what you are working on
hg merge -r default  // merge from the trubk into your task-branch
..test
..fix
hg ci -m 'merging from trunk (default branch)'
...make more edits
hg ci -m 'more edits on task-branch'
hg pull master-repo
hg merge -r default
... test
hg ci -m 'second tracking merge from master / default onto task-branch'
hg update -r default  // I find this confusing: "hg update" is what you use to switch branches
hg merge -r task-branch
hg ci -m 'merged from task-branch back into default trunk'
hg diff -r task-branch -r default // should be udentical wrt data, although hg's history checksum makes them different
hg push master-repo

One project you know and loved? has a multi-GB git repo now.  Checking out a new tree is very time consuming... Maybe there is a way to limit the past? Someone checks in a binary and you lug it around forever--all versions of that binary... That seems like one small advantage for Svn.  You check out what is current....  Maybe hg has help here??

hg is a bit better than git.  it keeps checkpoints, so doesn't apply diffs.

but, all of these silly DVCSes carry around all history. Stupid.

OK to have all history in a master repo,

but I want my workspace repo to have a subset of the history - recent stuff.

I have tried to do this with Mercurial, but no joy.

There are many tools that allow you to edit history.  But I don't want to edit history.  I just want to subset it.

E.g. all 6 volumes of Gibbon in the library.  But only 1 in my backpack.  Yes, even on a Kindle...

--

By the way, you can configure HG so that several working trees share a repo.

Notifications when changeGROUPs are pushed

The Mercurial mailing list archived at http://mercurial.808500.n3.nabble.com/hgext-notify-as-a-changegroup-hook-generates-a-diff-between-wrong-versions-td3988885.html (and elsewhere, ncluding Google groups) has recently discussed what hgext.notify should provide.

I have been annoyed by this, because currently it diffs tip.  And hg tip may not be on the default branch.  So if I check in stuff on a branch, the next changegroup after me will see hgext.notify diff against my changes.

I'm not ready to jump into the Mercurial mailing list.  Not enough context.  But let's think about it:

A changegroup - a set of changes being pushed together - is not necessarily connected.  It is possible that, e.g. there may be some changes on the default branch (i.e. the trunk), and some on other branches.

e.g.

old             changegroup 1  changegroup 2
---1d---3d---   ----6d-------  ---8d---
    \
     2b--4b--   --5b-----7b--

Currently, I believe hgext.ntify diffs 8d against 7b. Whereas it probably "should" be diffed against 6d. Similarly, 6d should be diffed against 3d. Moreover, in changegroup 1 there are two diffs of interest: 5b agauinst 4b, and 6d against 3d. By the way, I think that we are soon going to see a semantic split: (a) changegroup, a set of related changes, bersus something like pushgroup, a set of changes pushed together. A pushgroup might contain multiple changegroups. But this doesn't matter too much... Even with this distinction, a changehgroup may have multiple ancestors. The graph between old stuff and a changehroup may have more than one arc across it. So, what should you do? Hypothesis: if handling not changegroups, put individual revisions, (1.1) the default diff should be against the parent on the same branch. Mercurial has anonymous branches, so there might be too parents on the same branch. Need then to figure out which is most useful. I would say (1.2) if there is only one parent on the same brach that is in the old set, prior to the changegroup, use that. (1.3) if there is more than one parent on the same brach that is in the old set, prior to the changegroup, use the most recent. Or possibly the one that has the most/fewest diffs. Note that I am prioritizing to the same branch. If a changeset has parents on other branches, don't diff against them - unless they are the only branches. (which can happen when a branch morphs - since Mercurial dos not allow branches to be renamed retroactively). So, what about changegroups? The changegroup may be multiheaded, or not. If the changegroup only has a single head, you probably want to diff against the rev on the same branch as the head, in the old set, prior to the changegroup. Using the same prioritizations as above. If the changegroup has multiple heads, (a) you may want to diff each, or (b) you may want to select a most interesting head. E.g. the most recent. Or the most recent on the trunk.

hg --close-branch updates tip :-(

Here's something joyful: when you close a branch in Mercurial, e.g. via

  hg update -C branch-to-be-closed
  hg commit --close-branch -m 'branch to be closed'

it becomes the "tip" - the most recent changest.

Many tools confuse "tip" with something like "the tip of the default branch".  And do stuff like checking out or diffstat'ing with tip.

Which probably is not what you want for a closed branch.