Re: [PATCH] org-table: Add mode flag to enable Calc units simplification mode
Daniele Nicolodi writes: > Hello, > > I don't think this is what is holding up review of these patches, but, I > recently completed the paperwork for copyright assignment to the FSF. Thanks for this series (and thanks to Eric for the feedback in the previous thread). I'm sorry for the slow response. Quickly scanning through and playing around with it, it looks nicely done. I'll put aside some time this weekend to give it a closer review.
Re: [bug] Export to latex truncates long subsections (WE attached)
Vladimir Nikishkin writes:
> So what is the status of this story?
>
> I believe that if one exports an org file with sufficiently many empty
> TODO headings (to me, it seems a perfectly valid use case of org,
> printing lists of TODOs), they won't fit on a single page, and latex
> will drop them. Would the latex snippet in this thread be a good
> candidate for inclusion into org as a canned trick?
>
> On Tue, 27 Aug 2019 at 14:57, Vladimir Nikishkin wrote:
>>
>> I have indeed investigated the issue, and this is the link:
>> https://latex.org/forum/viewtopic.php?f=47=32788
>>
>> To make the long story short, the folowing trick is needed to allow
>> page breaks after headings (which is a completely standard case in
>> -org).
>>
>> #+begin_src latex
>> \usepackage{xpatch}
>> \makeatletter
>> % This is not recommended, because it can break several things
>> \xpatchcmd{\@afterheading}{\@nobreaktrue}{\@nobreakfalse}{%
>> \typeout{WARNING: \string\@afterheading\space broken}%
>> }{%
>> \@latexerr{ERROR: Cannot patch \string\@afterheading}\@ehd%
>> }
>> \makeatother
>> #+end_src
>>
>> Shall this trick be considered for inclusion in 'org' officially?
>> I mean, having lists of empty headings is a perfectly standard use case for
>> org.
>>
What are the implications of doing this? In particular, the comment
>> % This is not recommended, because it can break several things
Many people have quite complex environments for generating Latex and we
would need to be certain that adding this package doesn't 'break several
things'.
At the very least, something should probably be put on worg so that
anyone who is running into the page breaking issue can add the snippet
using file header lines.
--
Tim Cross
Re: bug#7506: Replacement for 'htmlize-region-for-past using htmlfontify?
Lennart Borgman writes: > On Sun, Nov 28, 2010 at 8:01 PM, Stefan Monnier > wrote: >>> Could we please add a replacement for 'htmlize-region-for-past using >>> htmlfontify? >> >> I don't know what is "htmlize-region-for-past(e?)". Care to give us >> some context? > > I have never used it, but it is used by org-mode when it exports code > fragment in an org-mode file to html. That will show the syntax > coloring (make by font-lock) in the exported html code. > > Unfortunately it is a little bit of work to implement this in > htmlfontify if I remember correctly (I am addinng Vivek to the > recievers of this message). Htmlfontify always puts the css code in > the header, i.e. it produces a full html file. The above feature request for `org-html-htmlize-region-for-paste' has been sitting in the Emacs bug tracker for 10 years. It seems like no one on our side has taken an interest in it. I am now closing this bug in our tracker with a copy to the Org-mode mailing list, in the hope that someone there will be able to determine what, if anything, should be done about this. I hope this doesn't waste any time for the Org-mode maintainers or anyone else; please feel free to just ignore this email if it is not of interest. Thanks.
Re: Changed list indentation behavior: how to revert?
Hi all,
I've just caught up with this conversation after feeling similar
friction to others since the 'electric-indent' change.
When it happened, I spent time trying to figure out how to revert the
change (thinking I had introduced the bug myself in my configuration
somehow) and ended up setting 'org-adapt-indentation' to 'nil', which
solved some of my inconvenience while typing headlines, lists, etc.,
but not source blocks.
Source blocks
=
After the change, it became extremely inconvenient to edit them inline,
as the level of indentation for the whole block changed constantly in
unexpected and unpredictable ways (when I pressed TAB, but maybe also in
other cases?).
In the end, the only solution has been to use {C-c'} any time I want to
modify one. While I understand that editing the source block in a
separate buffer is probably the "correct(TM)" way, I often make small
changes while looking at another buffer on a split screen, and {C-c'}
always pops up in a new buffer and forces me to reconfigure my buffers
to continue (I realize I can change 'org-src-window-setup', but
sometimes I still just want to edit the code in the actual Org document
itself).
---
I understand why the change was introduced, but it has really caused
some friction in my day-to-day work. I am very happy to find out today
how to undo this upgrade: I disliked and resented the rigitidy it
introduced into my interactions with Org. Looking back, I wish I'd spent
more time investigating the cause.
Best regards,
Marcel
On Mon, 16 Nov 2020 08:21:53 -0300
Gustavo Barros wrote:
> Hi Tim,
> Hi All,
>
> On Mon, 16 Nov 2020 at 18:15, Tim Cross wrote:
>
> > Tim Cross writes:
> >
> >>
> >> Thanks for clarifying this Kyle.
> >>
> >> So essentially, this change has been made to make org-mode
> >> consistent with the rest of emacs which enabled electric-indent by
> >> default in Emacs 24. this is a good thing. Org should be
> >> consistent with other modes. Any differences are likely to be the
> >> source of confusion and bug reports.
> >>
> >> I am a little confused about the purpose of org-adapt-indentation
> >> though. According to the org news file, to get back the old
> >> behaviour, it says to explicity disable electric-indent mode using
> >> org-mode-hook. There is no mention of org-adapt-indentation.
> >>
> >> Is this just an artefact from before and in effect, we have two
> >> methods to disable the indentation behaviour? Is there anything
> >> functionally different between disabling electric-indent by calling
> >> electric-indent-local-mode -1 or setting org-adapt-indent to nil
> >> or is the result functionally equivalent?
> >>
> >
> > Following up to my own question. The two are NOT functionally
> > equivalent in that org-adapt-indentation supports other values than
> > t or nil. You can use this variable to tweak how the adaptive
> > indentation works. While setting it to nil may be equivalent to
> > turning of electric-indent mode, it can be used to adjust how
> > adaptive indentation works as well.
> >
> > Tim
> >
> > --
> > Tim Cross
>
> I think I might chime in again, as perhaps I have a point to add, and
> Tim's formulation here is a good hook for that. Setting
> `org-adapt-indentation' to nil is not equivalent to disabling
> `electric-indent-mode' not because there are more values than t or nil
> for the first, but because they are conceptually different.
> `org-adapt-indentation' controls how the indentation should be done by
> Org, `electric-indent-mode' just applies this setting when you hit
> RET. If you have `electric-indent-mode' off, but
> `org-adapt-indentation' set to t, type a heading hit RET, than TAB,
> you will get the same indentation up to the heading stars level.
>
> But the point of interest here, is not this difference by itself, but
> in some of its implications, and why so many people were unaware of
> `org-adapt-indentation'. I think this is the case because, with
> `electric-indent-mode' off, it is easy to slip through the right
> indentation, and get to believe things are working as expected, when
> they are actually just doing so by coincidence.
>
> Suppose you are in the status quo before 9.4, that is
> `org-adapt-indentation' set to its default value of true, and
> `electric-indent-mode' off, and you start to type a little document.
>
> If you type it always hitting TAB after RET, you will get:
>
> #+begin_src org
> ,** Foo
>First line
>Second line
> #+end_src
>
> (Indentation appears off, but that's just the escape comma).
>
> If, instead, you just type RET, you get what many people surprised by
> the change in this thread expect:
>
> #+begin_src org
> ,** Foo
> First line
> Second line
> #+end_src
>
> Now, the point is that, if you just miss the TAB on the first line,
> even if you hit TAB to indent on the subsequent ones, they will still
> not indent and be kept on the left margin. So things *appear* to be
> working as expected, but
Re: patch to add mention of org-table-transpose-table-at-point to doc
Greg Minshall writes:
> hi. this adds the minimal mention of transpose. cheers.
Thanks. Could you add a commit message to the patch (using
git-format-patch)?
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index 040fccc21..33d32b8f5 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -1649,6 +1649,12 @@ you, configure the option ~org-table-auto-blank-field~.
>the buffer. You can activate this minor mode by default by setting
>the option ~org-table-header-line-p~ to ~t~.
>
> +- {{{kbd(M-x org-table-transpose-table-at-point)}}} ::
> +
> + #+findex: org-table-header-line-mode
> + #+vindex: org-table-header-line-p
It looks like the last two lines are leftover from pasting the previous
entry. s/header-line-mode/transpose-table-at-point/ and drop the
org-table-header-line-p line?
> + Transpose the table at point and eliminate hlines.
> +
Re: patch to change org-adapt-indentation customization documentation
Greg Minshall writes: > hi, Robert, > > thanks. given that the docstring already talks about nil, t, > 'headline-data ... Not related to your main point, but if you're improving the docstring anyway: 'headline-data (which is a relatively recent addition) should instead be written as `headline-data' for consistency and to avoid worrying about needing to protect it from being confusingly rendered as "’headline-data" (depending on text-quoting-style). > should i eliminate those, just leaving "three" choices? > >> "Adapt indentation for all lines" >> "Adapt indentation for headline data lines" >> "Do not adapt indentation at all" > > or, leave mention of nil, t, 'headline-data, while trying to make > clearer the binding of the longer descriptions in the docstring to the > above short descriptions? > > i guess i see lots of emacs docstrings that talk of t, nil, etc. so, > maybe it's not inappropriate for them to be in the docstring. Please leave the values in the docstring. But any rewording of docstring that you think makes the customization labels easier to link to the docstring is welcome. > (but, in which case, then i wonder, why not mention them also in the > choices?) I'm sympathetic to Robert's "you shouldn't have to worry about what the actual lisp value is" stance. But I don't actually use the customize interface, so maybe that preference just comes from my impression that I never see the value in tag labels in source code. Crude grepping in the Emacs repo suggests it's rare (at least for nil): $ git grep 'const :tag ".*nil.*" nil' '*.el' lisp/bindings.el: (const :tag "nil: No offset is displayed" nil) lisp/comint.el: :type '(choice (const :tag "nil" nil) lisp/help.el: :type '(choice (const :tag "never (nil)" nil) lisp/ps-mule.el: (const bdf-font-except-latin) (const :tag "nil" nil)) lisp/ps-print.el:(const control) (const :tag "nil" nil)) lisp/ps-print.el:(const :tag "nil" nil)) lisp/scroll-bar.el: :type '(choice (const :tag "none (nil)" nil) lisp/so-long.el:(const :tag "nil: Call so-long as normal" nil) lisp/so-long.el:(const :tag "nil: Use so-long-function as normal" nil) lisp/textmodes/tex-mode.el: :type '(radio (const :tag "Interactive (nil)" nil) $ git grep 'const :tag ".*" nil' '*.el' | wc -l 1064
Re: [PATCH] Remove redundant 'function's around lambda
Kyle Meyer writes: > All these look good to me except this unrelated whitespace change, which > actually touches the change ported from your 61dca6e92a (Don't quote > lambdas in several places, 2020-11-14) in the Emacs repo. I must have included that part by mistake, sorry about that. > Org files don't use a consistent style, despite Org's .dir-locals.el > setting indent-tabs-mode to t, which should probably be changed to match > Emacs's nil value. At any rate, I've dropped this hunk since it's not > actually making the advertised change, and pushed the rest with > 1a480e01a. Thanks!
Re: [bug] Export to latex truncates long subsections (WE attached)
So what is the status of this story?
I believe that if one exports an org file with sufficiently many empty
TODO headings (to me, it seems a perfectly valid use case of org,
printing lists of TODOs), they won't fit on a single page, and latex
will drop them. Would the latex snippet in this thread be a good
candidate for inclusion into org as a canned trick?
On Tue, 27 Aug 2019 at 14:57, Vladimir Nikishkin wrote:
>
> I have indeed investigated the issue, and this is the link:
> https://latex.org/forum/viewtopic.php?f=47=32788
>
> To make the long story short, the folowing trick is needed to allow
> page breaks after headings (which is a completely standard case in
> -org).
>
> #+begin_src latex
> \usepackage{xpatch}
> \makeatletter
> % This is not recommended, because it can break several things
> \xpatchcmd{\@afterheading}{\@nobreaktrue}{\@nobreakfalse}{%
> \typeout{WARNING: \string\@afterheading\space broken}%
> }{%
> \@latexerr{ERROR: Cannot patch \string\@afterheading}\@ehd%
> }
> \makeatother
> #+end_src
>
> Shall this trick be considered for inclusion in 'org' officially?
> I mean, having lists of empty headings is a perfectly standard use case for
> org.
>
> пн, 26 авг. 2019 г. в 17:47, Nicolas Goaziou :
> >
> > Hello,
> >
> > Vladimir Nikishkin writes:
> >
> > > I have a problem in that when I try to export an .org file into latex/pdf,
> > > long sections are not wrapped to the next page, but are truncated instead.
> > >
> > > The result is on the picture (points 10.34 to 10.37 missing), and the
> > > (not)working example is attached to this email.
> >
> > The LaTeX code generated by Org looks correct.
> >
> > I tried to remove all \label{...}, all \href{...} from the ".tex" file,
> > but the problem is still the same.
> >
> > It may be a LaTeX issue, not an Org one. You may want to investigate in
> > this direction.
> >
> > HTH,
> >
> > Regards,
> >
> > --
> > Nicolas Goaziou
>
>
>
> --
> Yours sincerely, Vladimir Nikishkin
--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)
Re: [PATCH] Remove redundant 'function's around lambda
Stefan Kangas writes: > I've been working on removing redundant `function' around `lambda' in > Emacs core, so here is a patch which does the same for Org-mode. Thanks. > Subject: [PATCH] Remove redundant 'function's around lambda [...] > diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el > index 4a0cca612..da351ef82 100644 > --- a/lisp/ox-odt.el > +++ b/lisp/ox-odt.el > @@ -2200,10 +2200,10 @@ SHORT-CAPTION are strings." > (defun org-odt--image-size >(file info user-width user-height scale dpi embed-as) >(let* ((--pixels-to-cms > - (lambda (pixels dpi) > -(let ((cms-per-inch 2.54) > - (inches (/ pixels dpi))) > - (* cms-per-inch inches > + (lambda (pixels dpi) > + (let ((cms-per-inch 2.54) > + (inches (/ pixels dpi))) > + (* cms-per-inch inches All these look good to me except this unrelated whitespace change, which actually touches the change ported from your 61dca6e92a (Don't quote lambdas in several places, 2020-11-14) in the Emacs repo. Org files don't use a consistent style, despite Org's .dir-locals.el setting indent-tabs-mode to t, which should probably be changed to match Emacs's nil value. At any rate, I've dropped this hunk since it's not actually making the advertised change, and pushed the rest with 1a480e01a. Thanks again.
Re: problem with org-highest-priority
joa...@verona.se writes: > Kyle Meyer writes: > >> The change in behavior you describe came with 4f98694bf (Allow numeric >> values for priorities, 2020-01-30). Based on quickly skimming that >> commit, I think the issue boils down to intentionally not supporting a >> mix of numbers and letters. I'm out of time tonight to look at it too >> closely, but I think support for your use case could be restored with >> something like the lightly tested patch below. > > Thanks, I tested your patch, and it helps a little bit. > > - m-x org-priority works, I can set any priority from 0 to Z > - org-priority-down and org-priority-down doesn't work as expected, as > they worked previously. I dont step through all the priority cookies, > instead I quickly wind up in prio 0, then I'm stuck there, for lack of > better description. Thanks for testing it out. I haven't really reloaded the issue into my head yet, but perhaps there's just a bit more to tweak then. > I'm not sure how to proceed. It seems I'm the only org-user affected by > this change? Hard to say, though I'd bet not (especially if we consider users that aren't on v9.4 yet). As for proceeding, with your feedback, I'll plan to take another look, but it won't be right away, so anyone is welcome to beat me to an updated patch. Even if your formerly working approach wasn't actually envisioned (*), I think it'd make sense to bring back support (along with tests) if it doesn't add much complication. (*) Again, I haven't refreshed on this issue, and I'm a very boring user of A, B, and C priorities. > Should I maintain a local patch to get the behaviour I > want? What is the recomended way to do that? I usually run > org-plus-contrib from elpa. I'm perhaps not the best person to answer this as a non-ELPA user, though I'd imagine your two main options are 1) defining org-priority in your local config to override the builtin version, either with a pure redefinition or with advice-add's :override. 2) cloning the Org repo and keeping a branch with the patch on top of the maint branch For maintaining a local variant over a longer period, the latter is the better way to go because you'll be alerted when the patched version conflicts. But let's see...
Re: problem with org-highest-priority
Kyle Meyer writes: > joa...@verona.se writes: > >> This used to work: >> (defun jv-org-priorities () >> (setq org-highest-priority ?0 ;; 64 @ 48 0, bugs start happening if you >> have higher prios tnan 0, like '!' >> org-lowest-priority ?E ;; E >> org-default-priority ?0 ;; 0 >> org-priority-regexp ".*?\\(\\[#\\([;:<=>?@A-Z0-9]\\)\\] ?\\)" >> )) >> >> I could then have priority cookies from [#0] to [#E]. >> >> With the current org I get [#48] instead of [#0]. >> >> Is there any way to restore the previous behaviour? > > The change in behavior you describe came with 4f98694bf (Allow numeric > values for priorities, 2020-01-30). Based on quickly skimming that > commit, I think the issue boils down to intentionally not supporting a > mix of numbers and letters. I'm out of time tonight to look at it too > closely, but I think support for your use case could be restored with > something like the lightly tested patch below. Thanks, I tested your patch, and it helps a little bit. - m-x org-priority works, I can set any priority from 0 to Z - org-priority-down and org-priority-down doesn't work as expected, as they worked previously. I dont step through all the priority cookies, instead I quickly wind up in prio 0, then I'm stuck there, for lack of better description. - sorting of priorities still work with or withouth the patch, that is prio 0 is highest prio, prio Z is lowest prio. I would like to mention that in my case the characters between letters and numbers are also priority cookies, @ is a cookie as well as 0 and z. Limiting to just letters and numbers would be fine for me though, I dont use the in-between prios much. Because the sorting still works, I have been able to work around this new behaviour, by writing the cookie by hand. I'm not sure how to proceed. It seems I'm the only org-user affected by this change? Should I maintain a local patch to get the behaviour I want? What is the recomended way to do that? I usually run org-plus-contrib from elpa. > > diff --git a/lisp/org.el b/lisp/org.el > index 425e9391b..8237f39f6 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -11166,8 +11166,7 @@ (defun org-priority ( action show) > (unless org-priority-enable-commands >(user-error "Priority commands are disabled")) > (setq action (or action 'set)) > -(let ((nump (< org-priority-lowest 65)) > - current new news have remove) > +(let (current new news have remove) >(save-excursion > (org-back-to-heading t) > (when (looking-at org-priority-regexp) > @@ -11181,27 +11180,18 @@ (defun org-priority ( action show) > (integerp action)) > (if (not (eq action 'set)) > (setq new action) > - (setq > - new > - (if nump > - (string-to-number > - (read-string (format "Priority %s-%s, SPC to remove: " > -(number-to-string org-priority-highest) > -(number-to-string org-priority-lowest > -(progn (message "Priority %c-%c, SPC to remove: " > - org-priority-highest org-priority-lowest) > - (save-match-data > - (setq new (read-char-exclusive))) > + (setq new > + (progn (message "Priority %c-%c, SPC to remove: " > + org-priority-highest org-priority-lowest) > + (save-match-data > +(setq new (read-char-exclusive)) > (when (and (= (upcase org-priority-highest) org-priority-highest) >(= (upcase org-priority-lowest) org-priority-lowest)) > (setq new (upcase new))) > (cond ((equal new ?\s) (setq remove t)) > ((or (< (upcase new) org-priority-highest) (> (upcase new) > org-priority-lowest)) > - (user-error > - (if nump > - "Priority must be between `%s' and `%s'" > - "Priority must be between `%c' and `%c'") > - org-priority-highest org-priority-lowest > + (user-error "Priority must be between `%c' and `%c'" > + org-priority-highest org-priority-lowest >((eq action 'up) > (setq new (if have > (1- current) ; normal cycling > @@ -11235,7 +11225,7 @@ (defun org-priority ( action show) > (setq remove t))) > ;; Numerical priorities are limited to 64, beyond that number, > ;; assume the priority cookie is a character. > - (setq news (if (> new 64) (format "%c" new) (format "%s" new))) > + (setq news (format "%c" new)) > (if have > (if remove > (replace-match "" t t nil 1) > > -- Joakim Verona joa...@verona.se
Re: [PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation
On 11/18/20 2:42 PM, TEC wrote: I have 2c on the use of "interpolated". 1. I tend to think of "interpolated" in terms of it's mathematical meaning 2. The other denotations relate to insertion and renewing, which simply doesn't fit. I appreciate that other people may have used this too, but as I see it that just means that other people have engaged in strange word choices. Suggested alternatives: Substituted, transpiled, or translated. Timothy. - For context, here's the definition, etymology, and symonyms. Definition Intransitive Verb 1. To renew; to carry on with intermission. [Obs.] 2. To alter or corrupt by the insertion of new or foreign matter; especially, to change, as a book or text, by the insertion of matter that is new, or foreign to the purpose of the author. 3. (Mathematics) To fill up intermediate terms of, as of a series, according to the law of the series; to introduce, as a number or quantity, in a partial series, according to the law of that part of the series. Adjective 1. Inserted in, or added to, the original; introduced; foisted in; changed by the insertion of new or spurious matter. 2. (Math.) (a) Provided with necessary interpolations; as, an interpolated table. (b) Introduced or determined by interpolation; as, interpolated quantities or numbers. Etymology interpolate verb 1610s, "to alter or enlarge (a writing) by inserting new material," from Latin interpolatus, past participle of interpolare "alter, freshen up, polish;" of writing, "falsify," from inter "among, between" (see inter-) + polare, which is related to polire "to smoothe, polish," from PIE root *pel- ( 5) "to thrust, strike, drive," the connecting notion being "to full cloth" [Watkins]. Sense evolved in Latin from "refurbish," to "alter appearance of," to "falsify (especially by adding new material)." Middle English had interpolen (early 15c.) in a similar sense. Related: Interpolated; interpolating. Synonyms verb adjective 1. Insert (wrongfully), foist in. 2. (Math .) Introduce, intercalate (terms to complete a series). Tim Cross writes: Daniele Nicolodi writes: On 16/11/2020 11:25, Eric S Fraga wrote: Daniele, this looks good. One minor pedantic point: I think you mean "interpreted" when you say "interpolated" (several times in the text). Otherwise, this is a very useful addition to the manual. Thank you for reading and for the comment. "interpolated" looks strange to me in this context too, but it is the word that is currently used in the manual. I decided to stick to this term for consistency, however, I haven't check if it is used with the same meaning elsewhere. I don't think it is wrong to use "interpolated", but if you thing it should be changed I can change it and check the manual for consistency. However, I don't think "interpreted" is the right word either. Probably "replaced" or "substituted" are better choices in this context. I agree. Interpolated is consistent with manuals for other programming languages which have similar functionality. However, org is also used by a more diverse community than typical programming languages, so perhaps 'replaced' or 'substituted' would be a better choice? Just my 2 cents, not being a programmer so I see one way that interpolate may be correct Are the cell references actually inserted into the lisp form when the formula is evaluated Please note that the word "the" is used not an indefinite 'a", i.e. Cell table +references are interpolated into the Lisp form before execution as opposed to Cell table +references are interpolated into a lisp form before execution Charlie Millar
Re: [PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation
I have 2c on the use of "interpolated". 1. I tend to think of "interpolated" in terms of it's mathematical meaning 2. The other denotations relate to insertion and renewing, which simply doesn't fit. I appreciate that other people may have used this too, but as I see it that just means that other people have engaged in strange word choices. Suggested alternatives: Substituted, transpiled, or translated. Timothy. - For context, here's the definition, etymology, and symonyms. Definition Intransitive Verb 1. To renew; to carry on with intermission. [Obs.] 2. To alter or corrupt by the insertion of new or foreign matter; especially, to change, as a book or text, by the insertion of matter that is new, or foreign to the purpose of the author. 3. (Mathematics) To fill up intermediate terms of, as of a series, according to the law of the series; to introduce, as a number or quantity, in a partial series, according to the law of that part of the series. Adjective 1. Inserted in, or added to, the original; introduced; foisted in; changed by the insertion of new or spurious matter. 2. (Math.) (a) Provided with necessary interpolations; as, an interpolated table. (b) Introduced or determined by interpolation; as, interpolated quantities or numbers. Etymology interpolate verb 1610s, "to alter or enlarge (a writing) by inserting new material," from Latin interpolatus, past participle of interpolare "alter, freshen up, polish;" of writing, "falsify," from inter "among, between" (see inter-) + polare, which is related to polire "to smoothe, polish," from PIE root *pel- ( 5) "to thrust, strike, drive," the connecting notion being "to full cloth" [Watkins]. Sense evolved in Latin from "refurbish," to "alter appearance of," to "falsify (especially by adding new material)." Middle English had interpolen (early 15c.) in a similar sense. Related: Interpolated; interpolating. Synonyms verb adjective 1. Insert (wrongfully), foist in. 2. (Math .) Introduce, intercalate (terms to complete a series). Tim Cross writes: Daniele Nicolodi writes: On 16/11/2020 11:25, Eric S Fraga wrote: Daniele, this looks good. One minor pedantic point: I think you mean "interpreted" when you say "interpolated" (several times in the text). Otherwise, this is a very useful addition to the manual. Thank you for reading and for the comment. "interpolated" looks strange to me in this context too, but it is the word that is currently used in the manual. I decided to stick to this term for consistency, however, I haven't check if it is used with the same meaning elsewhere. I don't think it is wrong to use "interpolated", but if you thing it should be changed I can change it and check the manual for consistency. However, I don't think "interpreted" is the right word either. Probably "replaced" or "substituted" are better choices in this context. I agree. Interpolated is consistent with manuals for other programming languages which have similar functionality. However, org is also used by a more diverse community than typical programming languages, so perhaps 'replaced' or 'substituted' would be a better choice?
Bug: Parentheses matching in org-babel code blocks [9.3.6 (9.3.6-elpa @ /home/pholi/.emacs.d/elpa/org-9.3.6/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. Some parentheses matching doesn't work properly in the elisp code blocks in org-babel. How to reproduce this bug: 1. Start emacs in quiet mode to disable all custom settings (emacs -q). 2. Enable parentheses matching (M-x show-paren-mode). 3. In the *scratch* buffer, enter the following (parentheses match correctly): (if (< x 2)) 4. Create an org file test.org and enter the following org-babel code block (parentheses do not match correctly): #+BEGIN_SRC emacs-lisp (if (< x 2)) #+END_SRC Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3) of 2020-08-28 Package: Org mode version 9.3.6 (9.3.6-elpa @ /home/pholi/.emacs.d/elpa/org-9.3.6/)
Variables not set during tangle of sh code (org 9.5)
Hi, in OrgMode 9.5 it seems that the variables during the tangling of sh aren't set/initialized. For example the block below: #+begin_src sh :var str="Hello World" :tangle helloworld.sh echo $str #+end_src Gets tangled into: echo $str Which means the str="Hello World" line is missing. I tried this with an emacs block and that seemed to be working. The following block: #+begin_src emacs-lisp :var data1=8 data2=16 :tangle test.lsp (message "data1:%S, data2:%S" data1 data2) #+end_src Was tangled to: (let ((data1 '8) (data2 '16)) (message "data1:%S, data2:%S" data1 data2) ) This leads me to believe that there is a bug in ob-shell.el. -- Best regards, Robby Kiggen | Essential IT
Re: patch to change org-adapt-indentation customization documentation
hi, Robert, thanks. given that the docstring already talks about nil, t, 'headline-data ... should i eliminate those, just leaving "three" choices? > "Adapt indentation for all lines" > "Adapt indentation for headline data lines" > "Do not adapt indentation at all" or, leave mention of nil, t, 'headline-data, while trying to make clearer the binding of the longer descriptions in the docstring to the above short descriptions? i guess i see lots of emacs docstrings that talk of t, nil, etc. so, maybe it's not inappropriate for them to be in the docstring. (but, in which case, then i wonder, why not mention them also in the choices?) i'm happy to do the docstring thing. but, just wanted this clarification. cheers, Greg
Re: patch to change org-adapt-indentation customization documentation
Greg Minshall writes: > Robert, > >> The whole point of customize is that you shouldn't have to worry about >> what the actual lisp value is. The actual lisp value only matters if >> you directly set the value without using customize. > > thanks for the response. i've included the documentation for > org-adapt-indentation below. since the documentation talks about values > and associated behaviors, it might be helpful to mention the values in > the customization dialog. an alternative maybe would be to re-do the > documentation to highlight the three customization phrases: > > "Adapt indentation for all lines" > "Adapt indentation for headline data lines" > "Do not adapt indentation at all" > > and not change the customization dialog? > Yes, I think that would be better. > i, anyway, was very uncertain, even after several rounds, as to which > customization option would give me the behavior i had read about in the > documentation. That means the docstring is probably the thing that needs adjusting. Robert
Re: Archiving repeated tasks under corresponding date tree for each repeated item
Indeed. I will try to work on it in my spare time, it will take maybe up to a year, but as soon as I have it, I will let the maillist know in case it's of interest. Again, thanks for all your help. GM El mié., 18 nov. 2020 a las 7:37, Ihor Radchenko () escribió: > > So from now on, all the DONE tasks would be archived straight away on the > > day they are DONE. > > Not all the tasks, but all the tasks with repeater. > > > Is there a way to do the same with all the logged items under the > :LOGBOOK: > > that have been DONE before? > > It is certainly possible, but require more complicated function. > > Best, > Ihor > > Gerardo Moro writes: > > > Thank you! Ok, now it works. I had to restart my Emacs, probably that was > > the problem. > > > > So from now on, all the DONE tasks would be archived straight away on the > > day they are DONE. What about the previously LOGGED tasks? > > Is there a way to do the same with all the logged items under the > :LOGBOOK: > > that have been DONE before? > > > > I have thousands of such instances, and I wonder if a function would find > > all those items inside the LOGBOOKS and archive them individually under > > their own DONE date in the org archive file. Maybe too much to ask! :) > > GM > > > > > > El mar., 17 nov. 2020 a las 18:00, Ihor Radchenko () > > escribió: > > > >> > Now I get the error: "wrong number of arguments..." :D > >> > >> It does not happen in my Emacs. It would be helpful if you shared the > >> whole error message. > >> > >> I used the following code for testing: > >> > >> (defun my/org-archive-without-delete () > >> "Archive item at point, but do not actually delete it." > >> (cl-letf (((symbol-function 'org-cut-subtree) (lambda () nil))) > >> (org-archive-subtree))) > >> > >> (defun org-archive-repeated-task (arg) > >> "Add a copy of the recurring task marked DONE to archive." > >> (when (and (eq (plist-get arg :type) 'todo-state-change) > >> (string= (plist-get arg :to) "DONE")) ;; The state is > changed > >> to DONE > >> (let* ((pos (plist-get arg :position)) > >>(repeater (org-with-point-at pos (org-get-repeat > >> (when repeater ;; Only consider tasks with repeater timestamp > >> anywhere in the task body > >> (my/org-archive-without-delete) > >> > >> (add-hook 'org-trigger-hook #'org-archive-repeated-task) > >> > >> Best, > >> Ihor > >> > >> Gerardo Moro writes: > >> > >> > Now I get the error: "wrong number of arguments..." :D > >> > > >> > El mar., 17 nov. 2020 a las 15:13, Ihor Radchenko (< > yanta...@gmail.com>) > >> > escribió: > >> > > >> >> > I tried this but I get: "symbol's function definition is void: > >> >> > org-trigger-doing" > >> >> > >> >> Oops. That's the old function name. Should be > >> >> > >> >> (add-hook 'org-trigger-hook #'org-archive-repeated-task) > >> >> > >> >> Best, > >> >> Ihor > >> >> > >> >> > >> >> Gerardo Moro writes: > >> >> > >> >> > Thanks for the prompt reply! > >> >> > I tried this but I get: "symbol's function definition is void: > >> >> > org-trigger-doing" > >> >> > > >> >> > El mar., 17 nov. 2020 a las 14:32, Ihor Radchenko (< > >> yanta...@gmail.com>) > >> >> > escribió: > >> >> > > >> >> >> > Thanks, I don't know how to go about doing that, so I would > have to > >> >> rely > >> >> >> on > >> >> >> > others wanting to help me if they consider this to be also > useful > >> to > >> >> them > >> >> >> > (which I definitely think it is!). > >> >> >> > >> >> >> Try the following code. It should archive any repeated task once > it > >> is > >> >> >> marked DONE. > >> >> >> > >> >> >> (defun org-archive-repeated-task (arg) > >> >> >> "Add a copy of the recurring task marked DONE to archive." > >> >> >> (when (and (eq (plist-get arg :type) 'todo-state-change) > >> >> >> (string= (plist-get arg :to) "DONE")) ;; The state is > >> >> changed > >> >> >> to DONE > >> >> >> (let* ((pos (plist-get arg :position)) > >> >> >>(repeater (org-with-point-at pos (org-get-repeat > >> >> >> (when repeater ;; Only consider tasks with repeater > timestamp > >> >> >> anywhere in the task body > >> >> >> (my/org-archive-without-delete) > >> >> >> (add-hook 'org-trigger-hook #'org-trigger-doing) > >> >> >> > >> >> >> Best, > >> >> >> Ihor > >> >> >> > >> >> > >> >
