From: Nick Dokos <nicholas.dokos@hp.com>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>,
nicholas.dokos@hp.com, emacs-orgmode@gnu.org,
"Jambunathan K" <kjambunathan@gmail.com>
Subject: Re: Re: Internal links in LaTeX export
Date: Thu, 28 Oct 2010 18:35:08 -0400 [thread overview]
Message-ID: <18647.1288305308@alphaville.usa.hp.com> (raw)
In-Reply-To: Message from "Thomas S. Dye" <tsd@tsdye.com> of "Thu, 28 Oct 2010 11:19:19 -1000." <CBDAFEC4-22B1-4685-94D8-403230D7F4AF@tsdye.com>
Thomas S. Dye <tsd@tsdye.com> wrote:
> On Oct 28, 2010, at 11:01 AM, Jambunathan K wrote:
>
>
> This is a regression. release-7.01h is good. HEAD is bad. I get the
> following line with release-7.01h.
>
> Links to \hyperref[sec-1]{Heading1}
>
> Jambunathan K.
>
> Aloha Jambunathan K.,
>
> Very many thanks for this information. I have Org-mode version 7.01trans
> (release_7.01h.880.g7531f). I take it the problem I'm having is due to a relatively recent change
> to Org-mode. If there is anything I can do to help isolate the problem, please let me know.
>
Tom,
If you have the time and the inclination, you might try bisecting your
way through. Bisecting org-mode problems is actually a very good way to
practice because the turnaround time is very small.
Prerequisites:
* you have a clone of the org-mode git repository.
* you have an org test file.
Steps:
* [optional, but it makes me feel a little safer] create a test branch
and switch to it:
git checkout -b test-branch master
* I clean out all the compiled files while doing a bisection: it's quicker
than regenerating them every time and I don't have to worry (much) about
emacs loading a wayward .elc file:
make clean
* start the bisection and tell git which commit is known good and which is known bad:
git bisect start
# current version is bad
git bisect bad
# release_7.01h was good - I got the name with ``git tag''
git bisect good release_7.01h
That checks out a revision half-way in between the bad and good commits: since
there are about 900 commits in between, you'll be at approx the 450-mark and it
should take about 10 bisections to get it down to a single commit.
* LOOP Now all you have to do is repeat the following steps:
# since you did ``make clean'' you don't have to worry about .elc files
# just reload all the .el files.
M-x org-reload
visit your org test file, export to LaTeX, check for \href/\hyperref (or
whatever other telltale sign shows badness/goodness).
# tell git about it
git bisect good *OR* git bisect bad
This last step will check out another revision and in about 10 repetitions
of the loop, you are done.
* Tell git you are done, so it can clean up:
git bisect reset
Theoretically, you could do all of this in your master branch without
creating a test-branch and this last step will reset everything to the
way it was before ``git start''.
* Post the offending commit to the list.
* Get back to your master branch:
git checkout master
* If you created a test-branch, clean it out:
git branch -d test-branch
* [Optional] Recreate your .elc files and reload them:
make
M-x org-reload
And that's it: a half-hour of fun and games. Unless of course, you
hit upon a revision that is neither good nor bad (in the above restricted
sense): you might get some other problem that prevents you from being
able to answer. That might or might not be easy to resolve, so I'll
leave that as an advanced topic (truth be told, I came up against this
situation a couple of days ago and I didn't know how to proceed: so
it's ignorance more than anything else that prevents me from saying
anything more).
If you want to try, I'd be happy to answer questions - I might try the
bisection later on tonight myself in any case. And btw, this is of
course archeology of a different (and much easier) kind, so I imagine
you'll take to it like a fish in water :-)
HTH,
Nick
next prev parent reply other threads:[~2010-10-28 22:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-28 20:06 Internal links in LaTeX export Thomas S. Dye
2010-10-28 20:18 ` Sébastien Vauban
2010-10-28 20:44 ` Thomas S. Dye
2010-10-28 21:01 ` Jambunathan K
2010-10-28 21:19 ` Thomas S. Dye
2010-10-28 22:35 ` Nick Dokos [this message]
2010-10-29 0:20 ` Thomas S. Dye
2010-10-29 1:30 ` Jambunathan K
2010-10-29 2:04 ` Thomas S. Dye
2010-10-29 3:22 ` [SOLVED] " Jambunathan K
2010-10-29 3:58 ` Carsten Dominik
2010-10-29 5:01 ` Noorul Islam K M
2010-10-29 6:38 ` Tom Dye
2010-10-29 7:20 ` Nick Dokos
2010-10-29 7:51 ` Noorul Islam
2010-10-29 8:34 ` Nick Dokos
2010-11-13 5:55 ` [Accepted] " Carsten Dominik
2010-10-29 3:28 ` Nick Dokos
2010-10-29 5:46 ` Nick Dokos
2010-10-29 10:17 ` Jambunathan K
2010-10-30 19:56 ` suvayu ali
2010-11-02 7:35 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18647.1288305308@alphaville.usa.hp.com \
--to=nicholas.dokos@hp.com \
--cc=emacs-orgmode@gnu.org \
--cc=kjambunathan@gmail.com \
--cc=tsd@tsdye.com \
--cc=wxhgmqzgwmuf@spammotel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.