Re: [O] "git describe" in version of info file with "make info_git_describe"
Michael Brand writes: > Is it possible with your current "make info" to get an info file > without git describe for a release like ELPA when made from within a > git repo Why should the git-describe info not be part of the ELPA tarball? If there is a good reason not to include it (I think it is useful to know which commit the ELPA archive was built on) one could alter the include file before rolling the tar ball of course. > and also for Emacs when building Emacs from a bzr-mirroring > git repo? Emacs does have its own build system. So there's be two possibilities: a) just copy over git-decribe.texi as is or b) alter it and put in any information that's deemed more appropriate before it gets copied over to bzr. It might even be useful to actually include the information back into the org.texi file to have a single file. Once it is decided how this should be handled, it can all become part of the makefile of course. Please note that the name "git-describe.texi" is only a suggestion and should probably be changed later on to something like "version.texi". >> Anyway, I've implemented the requested functionality into my Makefile >> fork, please test. > > Thank you for this implementation. Since my patch discussed here is > now superseded by your branch I thought it would be cleaner to put my > comments to the sub-thread "Makefile restructuring" starting here: > http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg00680.html Thank you. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Outline and org-mode don't insert text into folded sections logically
> - This patch covers only one of many ways to make unwanted changes > in an invisible area. Others would be delete, backspace, > kill-region, yank, kill-line, and an arbitrarily long list of > less obvious other commands. Full protection could only be > done with pre-change-hooks or so, but would then prevent ^^^ ^^^ May be you were referring to `before-change-functions' here? I see the use of the above hook already in Org. (Strangely this hook ends with "functions" and has no has no hook in it.) , | (org-add-hook 'before-change-functions 'org-before-change-function nil | 'local) ` > also programmed changes - something that would not be useful. > `org-self-insert-command' is probably only ever used in an > interactive way, so the patch as you have written it may very > well function correctly.
Re: [O] Makefile restructuring
Michael Brand writes:
> I have looked into your branch only now. I think it is uncommon for
> Makefiles how clean they look now and I appreciate how the Makefile
> has been split up plus one is in doc/ and one in lisp/, that there are
> no explicit xy.el any more and so on. Thank you for this work.
Thank you for your comments.
> Some comments:
>
> There is no @value{DATE}, missing already on master. Would it be ok to
> remove setting the DATE or to include it in org.texi like the commit
> message subject anticipates?
I don't know why the DATE is currently unused, it looks like it never
was as long as the git repository existed. I expect that when the
Makefile starts to take care of it, it will become more useful. I did
not yet change org.texi to keep the changeset minimal.
> In the latter case it could be labeled
> "build date" and optionally when available be enriched with "release
> date", looked up from the git tag when make is running in a git repo
> not dirty and if git is installed. Maybe "release date" could also
> become visible in org-version when running from .el in a git repo not
> dirty and if git is installed or when running from .elc built with the
> same git requirement. Both would help users to be aware of how
> outdated their version is and more. These are only suggestions, else
> I'm fine with removing DATE.
Right now git-describe.texi is re-built when org.texi changes, but the
date recorded and the git-describe are of the build time/version. I
need to figure out how to get the actual date of the last change plus
the git describe for that. If that doesn't work I will just change it
to always record the build date and version, just like org-version.
> I would prefer the file/target name variables.texi instead of
> git-describe.texi as git describe is not necessarily involved and must
> not be a requirement.
Sure, this is just a first suggestion to demonstrate how it might work.
> Did you check this?:
> - make info when not in a git repo
No, and currently it probably breaks. But it isn't too difficult to
keep the old file in that case.
> - make info when in a git repo but git is not installed
Ditto.
> In case the errors are confirmed: My guess is that again you have a
> better solution than me and I don't propose a patch yet. (org-version)
> uses (file-exists-p (expand-file-name ".git" dir)) and
> (executable-find "git") for this.
You are talking about org-version here? That code is not mine (I only
added another defconst to be able to record the version string during
install). I have never tried what happens when not installed and no git
is present... so please if that does indeed break put a patch to master,
as the problem should already be present there. AFAIK the code should
just drop down to no appending the description string.
> The default make target has been changed from "all" to "targets help".
> Is this standard? I assume that you considered that this can break the
> target "org-mode" of some upper level Makefile from users (and
> Emacs?).
GNU Makefile standards ask that a help target be available and that make
without arguments should show the help rather than freak you out with
starting to do something you may not have wanted to do. One could
certainly decide on a different standard if there's a good reason for
that. Again, Emacs has its own, totally unrelated build system.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] Outline and org-mode don't insert text into folded sections logically
On 30.10.2011, at 08:30, Jambunathan K wrote: > >> - This patch covers only one of many ways to make unwanted changes >> in an invisible area. Others would be delete, backspace, >> kill-region, yank, kill-line, and an arbitrarily long list of >> less obvious other commands. Full protection could only be >> done with pre-change-hooks or so, but would then prevent > ^^^ > ^^^ > May be you were referring to `before-change-functions' here? Yes, my mistake. - Carsten > > I see the use of the above hook already in Org. (Strangely this hook > ends with "functions" and has no has no hook in it.) > > , > | (org-add-hook 'before-change-functions 'org-before-change-function nil > | 'local) > ` > >> also programmed changes - something that would not be useful. >> `org-self-insert-command' is probably only ever used in an >> interactive way, so the patch as you have written it may very >> well function correctly. >
Re: [O] Tags included in subtree export title despite tags:nil in header
Hi Nick, On Sat, 29 Oct 2011 21:07:27 -0400 Nick Dokos wrote: > Suvayu Ali wrote: > > > In the attached patch, I use the variable org-export-with-tags to > > check whether tags should be included or skipped in the export > > title. However irrespective of the export options I get the value > > not-in-toc. As a result, the tags are not included even if tags:t > > is set. > > > > Is my use of org-export-with-tags incorrect? Is there something > > else I need to do before I can use it? > > > > Try changing the test to just > > + (setq title (if org-export-with-tags > + (format "%s\t%s" (match-string 3) > (match-string 4)) > + (match-string 3))) > > This checks whether org-export-with-tags is non-nil, rather than > checking that it is exactly t. In general, checking for nil or > non-nil is probably a better way to go, unless there are specific > reasons to be more specific. > That was my original attempt. But I went with the eq test since I thought tags:not-in-toc would also imply the user doesn't want the tags to be included in the export title. That said, the problem I am facing is org-export-with-tags evaluates to not-in-toc irrespective of what is set by the tags: option (see for example the test file earlier in the thread). So effectively the test is not checking what it is supposed to check. So I was wondering whether I missed something I should be doing. > Nick -- Suvayu Open source is the future. It sets us free.
Re: [O] Tags included in subtree export title despite tags:nil in header
Hi Suvayu, Suvayu Ali writes: > That said, the problem I am facing is org-export-with-tags evaluates to > not-in-toc irrespective of what is set by the tags: option (see for > example the test file earlier in the thread). So effectively the test > is not checking what it is supposed to check. So I was wondering > whether I missed something I should be doing. The problem is that `org-export-with-tags' is a global option, storing the default value for any buffer (and _a fortiori_ any subtree) -- while you want to check local options, which may be different at export time. Local options are stored in a `org-export-opt-plist'. You get the value of the "tags:" option by checking the property list like this: (plist-get org-export-opt-plist :tags)) Hence the patch below, which you can try to make sure it does what you want. Thanks! diff --git a/lisp/org-exp.el b/lisp/org-exp.el index fa54242..b4f6338 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -2160,20 +2160,24 @@ can work correctly." (defun org-export-get-title-from-subtree () "Return subtree title and exclude it from export." (let ((rbeg (region-beginning)) (rend (region-end)) - (inhibit-read-only t) title) + (inhibit-read-only t) + (tags (plist-get org-export-opt-plist :tags)) + title) (save-excursion (goto-char rbeg) (when (and (org-at-heading-p) (>= (org-end-of-subtree t t) rend)) ;; This is a subtree, we take the title from the first heading (goto-char rbeg) - (looking-at org-todo-line-regexp) - (setq title (match-string 3)) + (looking-at org-todo-line-tags-regexp) + (setq title (if (eq tags t) + (format "%s\t%s" (match-string 3) (match-string 4)) + (match-string 3))) (org-unmodified (add-text-properties (point) (1+ (point-at-eol)) (list :org-license-to-kill t))) - (setq title (or (org-entry-get nil "EXPORT_TITLE") title -title)) + (setq title (or (org-entry-get nil "EXPORT_TITLE") title)) +title (defun org-solidify-link-text (s &optional alist) "Take link text and make a safe target out of it." -- Bastien
Re: [O] Outline and org-mode don't insert text into folded sections logically
Hi Carsten, Carsten Dominik writes: > - This patch covers only one of many ways to make unwanted changes > in an invisible area. Others would be delete, backspace, > kill-region, yank, kill-line, and an arbitrarily long list of > less obvious other commands. Full protection could only be > done with pre-change-hooks or so, but would then prevent > also programmed changes - something that would not be useful. Yes, I don't want programmed changes to be affected by this feature. But having such a warning for `org-delete' would also be useful IMHO. > `org-self-insert-command' is probably only ever used in an > interactive way, so the patch as you have written it may very > well function correctly. > > - All the code in org-self-insert-command is executed for each > keypress, so one needs to be careful to have this function > carry as little overhead as possible. I actually think there should be a user option `org-edit-invisible-send-warning' defaulting to nil. The request "don't let me shoot in my foot" is a common one, and this option would let people set this to `t'. > - Currently this chokes at the beginning of the buffer because > the invisibility test is also run at (1- (point)). Fixed, thanks. > - I am not sure if I understand the positioning code: >> (if (or (eq invisible-before-point 'outline) >> (eq invisible-before-point 'org-hide-block)) >> (goto-char (previous-overlay-change (point >> (org-cycle) >> (if (or (eq invisible-before-point 'outline) >> (eq invisible-before-point 'org-hide-block)) >> (forward-char 1)) > > So when I happen to be somewhere in the middle of invisible > text and press a character, it seems to me that the character > will be inserted at the beginning of the invisible text, and > not where the cursor was. > > Maybe a better solution would be to save point, unfold, > go back to point, throw and error and not insert the pressed > character. I am not sure, though. Throwing an error and not inserting the text was what my first patch did. I thought it was too restrictive, though. With an option `org-edit-invisible-send-warning', we could have both: `t' would just throw a warning, 'prevent would throw an error. > Maybe you can explain your reasoning? My reasoning is that, when in the "middle" of an invisible region, the user does not know where the point is, hence he doesn't really know where he wants to insert characters. In this case, I assume insert at the beginning of the invisible region is a reasonable default. Thanks for the feedback -- let's continue brainstorming, I think this feature is important. Best, -- Bastien
Re: [O] "git describe" in version of info file with "make info_git_describe"
Hi Achim On Sun, Oct 30, 2011 at 08:01, Achim Gratz wrote: > Why should the git-describe info not be part of the ELPA tarball? If > there is a good reason not to include it (I think it is useful > to know which commit the ELPA archive was built on) one could alter the > include file before rolling the tar ball of course. Now I see. No need for that, I didn't take into account that git describe is not used to _replace_ "7.7" any more as my simpler implementation did but is just _added_. Again the cleaner solution, without the need for different behaviors. Michael
Re: [O] Makefile restructuring
Hi Achim On Sun, Oct 30, 2011 at 08:33, Achim Gratz wrote: >> In case the errors are confirmed: My guess is that again you have a >> better solution than me and I don't propose a patch yet. (org-version) >> uses (file-exists-p (expand-file-name ".git" dir)) and >> (executable-find "git") for this. > > You are talking about org-version here? I don't consider org-version to be used in the Makefile but assume that the same tests have to be made there. > That code is not mine (I only > added another defconst to be able to record the version string during > install). I have never tried what happens when not installed and no git > is present... so please if that does indeed break put a patch to master, > as the problem should already be present there. AFAIK the code should > just drop down to no appending the description string. No worry, org-version gets along with that. > GNU Makefile standards ask that a help target be available and that make > without arguments should show the help rather than freak you out with > starting to do something you may not have wanted to do. Good to know. I prefer the standard and like that the GNU Makefile default target is standardized this way. Michael
Re: [O] Outline and org-mode don't insert text into folded sections logically
On 30.10.2011, at 10:04, Bastien wrote: > Hi Carsten, > > Carsten Dominik writes: > >> - This patch covers only one of many ways to make unwanted changes >> in an invisible area. Others would be delete, backspace, >> kill-region, yank, kill-line, and an arbitrarily long list of >> less obvious other commands. Full protection could only be >> done with pre-change-hooks or so, but would then prevent >> also programmed changes - something that would not be useful. > > Yes, I don't want programmed changes to be affected by this feature. > > But having such a warning for `org-delete' would also be useful IMHO. I guess you mean, org-delete-char and org-delete-backward-char > >> `org-self-insert-command' is probably only ever used in an >> interactive way, so the patch as you have written it may very >> well function correctly. >> >> - All the code in org-self-insert-command is executed for each >> keypress, so one needs to be careful to have this function >> carry as little overhead as possible. > > I actually think there should be a user option > `org-edit-invisible-send-warning' defaulting to nil. +1 > > The request "don't let me shoot in my foot" is a common > one, and this option would let people set this to `t'. > >> - Currently this chokes at the beginning of the buffer because >> the invisibility test is also run at (1- (point)). > > Fixed, thanks. > >> - I am not sure if I understand the positioning code: >>> (if (or (eq invisible-before-point 'outline) >>> (eq invisible-before-point 'org-hide-block)) >>>(goto-char (previous-overlay-change (point >>> (org-cycle) >>> (if (or (eq invisible-before-point 'outline) >>> (eq invisible-before-point 'org-hide-block)) >>>(forward-char 1)) >> >> So when I happen to be somewhere in the middle of invisible >> text and press a character, it seems to me that the character >> will be inserted at the beginning of the invisible text, and >> not where the cursor was. >> >> Maybe a better solution would be to save point, unfold, >> go back to point, throw and error and not insert the pressed >> character. I am not sure, though. > > Throwing an error and not inserting the text was what my first > patch did. I thought it was too restrictive, though. > > With an option `org-edit-invisible-send-warning', we could have both: > `t' would just throw a warning, 'prevent would throw an error. I like that. > >> Maybe you can explain your reasoning? > > My reasoning is that, when in the "middle" of an invisible region, > the user does not know where the point is, hence he doesn't really > know where he wants to insert characters. In this case, I assume > insert at the beginning of the invisible region is a reasonable > default. I have to admit that it does work well at the end of a folded headline, and delete-backward-char there would also work fine. I would think, when the cursor is in the middle of an invisble regions, the change should always be denied. Cheers - Carsten > > Thanks for the feedback -- let's continue brainstorming, I think > this feature is important. > > Best, > > -- > Bastien
Re: [O] OT: collage of scripts
Nick Dokos writes: > [I hope you'll forgive me the off-topic ruminations] > > Jambunathan K wrote: > >> If you do a >> >> C-h C-\ RET tamil-itrans RET >> >> you will see a nicely aligned table which gives translation table for >> tamil characters - (OK, Tamil is the language I speak) - which look like >> >> http://debbugs.gnu.org/cgi/bugreport.cgi?msg=56;filename=temp.png;att=1;bug=9336 >> > > Jambunathan's mention of Tamil brought to mind a picture that > I had seen long ago and found mysterious, beautiful and fascinating. > It is Fig. 40, p. 168, in Hofstadter's "Gödel, Escher, Bach": I looked > for a copy on the web, but I only found the complete book. > > The picture is a collage of scripts, from the undeciphered (at least > in 1980, the time of publication) script of Easter Island to Tamil > to Assyrian cuneiform. > > I have no idea what each snippet says - yet there are people around > today (and in some cases, perhaps, there *were* people some time ago, > but no longer) who can (or could) extract meaning from each of these > snippets. Conversely, there are scripts that I can extract meaning from, > that other people find mysterious. I can't help the feeling that there > is something deep going on here, I just don't know *what*! > > Nick > > > Hi Nick, A book by David Bellos, Is That a Fish in Your Ear? Translation and the Meaning of Everything, got a good review in the NYT Book Review this week. I'm not sure from the review if it gets to the heart of your rumination, but the author's proposal that translation "provides for some community an acceptable match for an utterance made in a foreign language" made me think of your post. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [odt] equation labels
Myles English writes:
> Hello {Jambunathan},
>
> I have found that Equations become labelled as Figures in the version I
> am using:
>
> emacs 23.3.1
> org-mode from git commit 71f1c1be (Oct 26)
> The test equations in latex-mathml.org in this message:
>
> http://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00198.html
>
> are labelled as "Equation" in the odt files but when I export it fresh I get
> "Figure".
This was a regression. I pushed a fix few moments ago. Could you please
pull again?
> (?I'm not sure if it is the most recent version of contrib/org-odt as
> the README.org says "This release is is as good as org-20110613" etc)
I have not updated README.org for a while and please ignore whatever it
claims. You are using the right version of odt. So no worries.
> Thank you for the recent MathML stuff by the way.
>
> Myles
>
>
--
