Nicolas Goaziou writes:
> Is your issue solved?
I can confirm the issue is solved. Thanks again.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Nicolas Goaziou writes:
> I fixed the issue by extending `org-at-timestamp-p' optional argument
> while preserving backward-compatibility.
Thanks. That seems like a much better soultion than what we've had
before and some of what we've discussed before getting there.
> Is your issue solved?
I'l
Hello,
Achim Gratz writes:
> Yes, put the cursor on the date or time of one of the timestamps and
> press S-Up or S-Down. It should increase or decrease the corresponding
> element of the timestamp, but instead you'll get an error message:
>
> org-clocktable-shift: Line needs a :block definitio
Nicolas Goaziou writes:
> OK. I inserted it in a fresh Org buffer. Is there any command to call on
> it now?
Yes, put the cursor on the date or time of one of the timestamps and
press S-Up or S-Down. It should increase or decrease the corresponding
element of the timestamp, but instead you'll get
Hello,
Achim Gratz writes:
> I've told you from the beginning that it was a file at work and that it
> would take some time to dig down to the problem since it did work at
> home when I tried to create said ECM.
I know, but I was hoping a few weeks would be enough, since the
resolution of the i
> As I asked 5 weeks ago (!), could you provide an ECM demonstrating the
> issue so that I can fix it, in the light of our discussion?
I've told you from the beginning that it was a file at work and that it
would take some time to dig down to the problem since it did work at
home when I tried to c
Hello,
Achim Gratz writes:
> No, I meant context of application, rather than context in the
> syntactical sense. Org-element-* deals with syntax, nothing else.
> Whether you need strict syntactical interpretation or something else
> gets decided someplace else.
OK. Then we agree here.
> Whate
Nicolas Goaziou writes:
>> I'd say anything org-element-* should exclusively return syntactical
>> things. Context dependence needs to be dealt with elsewhere.
>
> I'm not sure to understand this. Syntactical things are all about
> context dependence in Org. Do you mean /context independance/ need
Hello,
Achim Gratz writes:
> Well, taking a further setp back, before Org started to have a formal
> syntax anything that looked like a timestamp was treated as one. The
> different categories of timestamps really arise from the fact that we
> now have syntactical timestamps and non-syntactical
Nicolas Goaziou writes:
> Sadly, what a "timestamp" is depends on what function is asking. AFAICT,
> there are three categories of "timestamps".
Well, taking a further setp back, before Org started to have a formal
syntax anything that looked like a timestamp was treated as one. The
different cat
Hello,
Achim Gratz writes:
> That's what I've been asking the whole time: when you changed that
> predicate, you've basically cut off some of its consumers. It looks
> like bad factoring to me to then splitting the same predicate based on
> some argument. I'd rather pull out the old sloppy mat
Nicolas Goaziou writes:
> Another idea is to add an optional argument to `org-at-timestamp-p' to
> allow "sloppy" matching (or strict matching, it doesn't really matter)
> and skip checks when it is required. So all functions requiring this
> predicate can make use of it, as long as they call it pr
Achim Gratz writes:
> and org-at-block-p only matches in the first line of a dynamic block,
[...]
> N.B.: The regex used in org-at-block-p is overbroad since it matches the
> whole block, I think it should use org-at-dblock-start-re instead.
This old and buggy function has nothing to do with t
Nicolas Goaziou writes:
#+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend
"<2006-08-10 Thu 12:00>"
#+END: clocktable
>
> These are not timestamps. Even though they look like timestamps, you
> wouldn't want them to appear in the agenda. So `org-at-timestamp-p'
Achim Gratz writes:
> Achim Gratz writes:
>> Nicolas Goaziou writes:
>>> At the moment, I cannot reproduce it. I tried M-up in the following
>>> document:
>>>
>>> #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend
>>> "<2006-08-10 Thu 12:00>"
>>> #+END: clocktable
These are no
Achim Gratz writes:
> Nicolas Goaziou writes:
>> At the moment, I cannot reproduce it. I tried M-up in the following
>> document:
>>
>> #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10
>> Thu 12:00>"
>> #+END: clocktable
>
> The breakage happens in this clause in o
Nicolas Goaziou writes:
> At the moment, I cannot reproduce it. I tried M-up in the following
> document:
>
> #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10
> Thu 12:00>"
> #+END: clocktable
The breakage happens in this clause in org-at-timestamp-p:
--8<---
Hello,
Achim Gratz writes:
> I've just noticed that in my the clocktables at work I can't adjust the
> start and end ranges anymore with up/down. Apparently the timestamps
> are not recognized anymore and the it falls through to some code that
> tries to adjust the :block argument (which is not
I've just noticed that in my the clocktables at work I can't adjust the
start and end ranges anymore with up/down. Apparently the timestamps
are not recognized anymore and the it falls through to some code that
tries to adjust the :block argument (which is not present in that table
since it's usi
Hello,
Sébastien Le Maguer writes:
> I did a mini-patch to capture completely the key in bibtex export. For
> example for the following key, in the bibtex2html produced file:
>
> Balestri et al., 1999
>
> only Balestri will be captured instead of Balestri et al., 1999
>
> As it is 3 characters,
Dear All,
I did a mini-patch to capture completely the key in bibtex export. For example
for the following key, in the bibtex2html produced file:
Balestri et al., 1999
only Balestri will be captured instead of Balestri et al., 1999
As it is 3 characters, I just submit the patch here and hope i
Sharon Kimble writes:
> How many indexes can you have in an org-mode document exported to latex?
> My experience shows 2! So how can I have 3, or more please?
>
> This is the relevant part, I think, of my preamble of my file -
>
> #+latex_header: \usepackage{imakeidx}
> #+latex_header: \makeindex
How many indexes can you have in an org-mode document exported to latex?
My experience shows 2! So how can I have 3, or more please?
This is the relevant part, I think, of my preamble of my file -
--8<---cut here---start->8---
#+latex_header: \usepackage{imake
>> On export the in-text citations are transformed to unique text blobs,
>> e.g. uuids, and the document exported. The only important features of
>> these blobs is that they do not get changed on export, and they are
>> unique because we replace them later.
>>
>> The strings in the bibliography en
Hi John,
John Kitchin writes:
> Thanks.
>
> Its an interesting jam. You want to have multiple outputs as a
> possibility, but there isn't a robust markup that readily works across
> all backends.
Yes, indeed.
> On export the in-text citations are transformed to unique text blobs,
> e.g. uuid
Richard Lawrence writes:
> Hi John,
>
> John Kitchin writes:
>
>> Hi all,
>>
>> This is mostly for the people working on citations in org-mode.
>>
>> I have been reading about CSL more this weekend. IIRC, one of the
>> reasons to develop the new citation syntax was to get the ability to
>> have
Thanks.
Its an interesting jam. You want to have multiple outputs as a
possibility, but there isn't a robust markup that readily works across
all backends.
What about this. For now consider a bibliography database with
org-formatting in the entries, e.g. subscripts, superscripts, etc...
(but not
Richard Lawrence writes:
>> IIUC, the current aim is to get a citeproc that will do the following on
>> export:
>> 1. replace in-text citation syntax with org-formatted replacements
>> 2. Insert an org-formatted bibliography somewhere in the document
>> 3. proceed with org-to-something export, wi
Hi John,
John Kitchin writes:
> Hi all,
>
> This is mostly for the people working on citations in org-mode.
>
> I have been reading about CSL more this weekend. IIRC, one of the
> reasons to develop the new citation syntax was to get the ability to
> have pre/post text in citations more convenie
Hi all,
This is mostly for the people working on citations in org-mode.
I have been reading about CSL more this weekend. IIRC, one of the
reasons to develop the new citation syntax was to get the ability to
have pre/post text in citations more conveniently than what is currently
possible.
I have
Dear John,
On Fri, 26-06-2015, at 22:58, John Kitchin wrote:
> You could have multiple file fields I suppose, and adapt [1] to give you
> a choice of which one to open.
That is an intriguing suggestion. I'll try to play with it.
>
> Personally, I have one pdf per bibtex entry, named by the key
You could have multiple file fields I suppose, and adapt [1] to give you
a choice of which one to open.
Personally, I have one pdf per bibtex entry, named by the key of the
entry, in a directory called bibtex-pdfs somewhere defined by
org-ref-pdf-directory. There are ~1300 pdfs in there now. I alw
Dear All,
(I am not sure this is the appropriate place, but this is neither a bug
report nor an feature request about helm-bibtex or org-ref, but a question
from ignorance and I am learning quite a bit from the other helm-bibtex
questions).
How do people deal with multiple files that are logical
Hello,
"Allen S. Rout" writes:
> I'm trying to accomplish a custom export task which I'd hoped to be
> pretty simple: something like:
>
>
> In each status section, only export the first child headline.
>
>
> After several dumb ideas, I decided that doing it with a filter was
> probably the Righ
I'm trying to accomplish a custom export task which I'd hoped to be
pretty simple: something like:
In each status section, only export the first child headline.
After several dumb ideas, I decided that doing it with a filter was
probably the Right Place. I built a filter intended to be used
Here is a more advanced function that works on your agenda files: You
run the second one:
M-x helm-query-agenda
and enter your search query in org syntax, e.g. TODO="PREPARATION" will
give you a helm menu of headlines with that TODO state.
I am not that sophisticated a user of org queries like th
Hi John,
thank you for the fast response! That's more than I had hoped for, I'm
sure I'll get through now. I'll report back when something tangible is
there.
Cheers,
Simon
On 01/19/2015 04:57 PM, John Kitchin wrote:
You can do something like this to get just the TODO headlines in the
curre
You can do something like this to get just the TODO headlines in the
current buffer. If you make the helm-todo-candidates map over all the
files in (org-agenda-files) you can make it give all the TODO
headings. You can change the match criteria in org-map-entries to be
more selective.
#+BEGIN_SRC
Hi all,
I recently updated my helm install so it includes
helm-org-agenda-headings which is just AWESOME (to me at least). A bit
like org-goto but across all agenda files at once, with goto, refile,
linking built in. If you haven't tried it, I definitely recommend to do so.
Yet I'm missing
Hi again.
So I've got a few repetitive tasks, for example
* TODO machine backups
** TODO machine 1
*** TODO create backup
*** TODO copy backup to DVD
** TODO machine 2
*** TODO create backup
*** TODO copy backup to DVD
** TODO machine 3
*** TODO create backup
*** TODO copy backup to DVD
** TODO m
Steven Arntson writes:
> I'm still a little mystified about using org markup in the context of
> the lilypond file, but maybe now I can do a little more experimenting.
Have you seen this?
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
There are some example org-mode f
t...@tsdye.com (Thomas S. Dye) writes:
> Aloha Steven,
>
> Steven Arntson writes:
>
>> The reason I'm excited to use org with lilypond files is the foldable
>> headers *, **, *** etc, as well as drawers and tables. However, that's
>> available only in an "org-mode" buffer, and I'm also wanting to
Aloha Steven,
Steven Arntson writes:
> The reason I'm excited to use org with lilypond files is the foldable
> headers *, **, *** etc, as well as drawers and tables. However, that's
> available only in an "org-mode" buffer, and I'm also wanting to use
> lilypond-mode, which gives excellent color
I'm trying to get going with org-babel and lilypond music markup. I have
the system basically functioning, but there's an elementary issue I
can't seem to wrap my brain around.
The reason I'm excited to use org with lilypond files is the foldable
headers *, **, *** etc, as well as drawers and tabl
On Tue, 24 Dec 2013 18:28:49 +0530
Puneeth Chaganti wrote:
> On Tue, Dec 24, 2013 at 6:24 PM, Sharon Kimble
> wrote:
> > I'm publishing a rather long org-mode document and want it to break
> > after the first paragraph so that you have to explicitly click the
> > document title to get it all to
On Tue, Dec 24, 2013 at 6:24 PM, Sharon Kimble wrote:
> I'm publishing a rather long org-mode document and want it to break
> after the first paragraph so that you have to explicitly click the
> document title to get it all to show. In WordPress its done with
> '--more--' but what is it done with
I'm publishing a rather long org-mode document and want it to break
after the first paragraph so that you have to explicitly click the
document title to get it all to show. In WordPress its done with
'--more--' but what is it done with in org-mode please? I've been
looking at the org-mode 'org man
James Harkins writes:
> According to [1], "#+OPTIONS: subject:nil" should suppress printing
> the #+TITLE at the top of the letter. It seems that the previous bug
> prevents the expected line "\KOMAoption{subject}{untitled}" from being
> generated.
I cannot reproduce.
> Okay... so, what if I se
According to [1], "#+OPTIONS: subject:nil" should suppress printing the
#+TITLE at the top of the letter. It seems that the previous bug prevents
the expected line "\KOMAoption{subject}{untitled}" from being generated.
Okay... so, what if I set "#+OPTIONS: subject:untitled"? Then I get
somethi
Hi Christian,
On Fri, Apr 12, 2013 at 03:08:17PM +0200, Christian Egli wrote:
> Buddy Butterfly writes:
> > Here I would suggest that one can place this data inbetween
> >
> > #+BEGIN_TASKJUGGLER
> > #+END_TASKJUGGLER
>
> This is something I'd like to add support for. I just never got around
>
Hi Buddy
Buddy Butterfly writes:
> I would like propose the following for taskjuggler export
> as base for a discussion to change export functionality.
Thanks for your detailed proposal. It's been a few years since I wrote
the taskjuggler exporter and I don't remember all the design decisions.
Hi,
I would like propose the following for taskjuggler export
as base for a discussion to change export functionality.
Here I will refer to the example project of taskjuggler 3.
Pre-requesites:
- Functionality of tj should be kept in tj as much as possible
- org export should be as generic as pos
Hi Ken,
Ken Williams writes:
> Would this be helpful to include by default? Patch attached.
I committed something deeply inspired by your patch,
but slightly different. Please have a look (from master)
and let me know if you think this is okay.
Thanks for this idea!
--
Bastien
Gunnar Wolf dijo [Wed, Jan 23, 2013 at 11:25:43AM -0600]:
> > When exporting to HTML I always add some extra CSS to my org-mode
> > config, for the purpose of identifying which chunks are input
> > vs. output, and for identifying the language of the code in code
> > chunks. Language is identified
Hi Ken,
Ken Williams writes:
> Hi all,
>
> When exporting to HTML I always add some extra CSS to my org-mode config,
> for the purpose of identifying which chunks are input vs. output, and for
> identifying the language of the code in code chunks. Language is
> identified by a little label on t
Ken Williams dijo [Wed, Jan 23, 2013 at 04:26:54PM +]:
> Hi all,
>
> When exporting to HTML I always add some extra CSS to my org-mode
> config, for the purpose of identifying which chunks are input
> vs. output, and for identifying the language of the code in code
> chunks. Language is ident
Hi all,
When exporting to HTML I always add some extra CSS to my org-mode config, for
the purpose of identifying which chunks are input vs. output, and for
identifying the language of the code in code chunks. Language is identified by
a little label on the box, and input/output is identified b
Re-dl'ed and works fine. Sorry about that.
On Tue, Aug 7, 2012 at 7:18 PM, Bastien wrote:
> Hi Jeffrey,
>
> Jeffrey Spencer writes:
>
> > Just gave this a go and seems to work well but still forgot to add I
> > believe:
> >
> > TYP_TODO
> > and
> > ATTR_LATEX
>
> The two words above are already
Hi Jeffrey,
Jeffrey Spencer writes:
> Just gave this a go and seems to work well but still forgot to add I
> believe:
>
> TYP_TODO
> and
> ATTR_LATEX
The two words above are already skipped for me.
--
Bastien
Just gave this a go and seems to work well but still forgot to add I
believe:
TYP_TODO
and
ATTR_LATEX
Cheers,
Jeff
On Wed, Aug 1, 2012 at 1:32 AM, Bastien wrote:
>
>
> "Sebastien Vauban"
> writes:
>
> > I would allow fly-prog-mode in the listins, as one normally does for
> plain
> > code, no?
"Sebastien Vauban"
writes:
> I would allow fly-prog-mode in the listins, as one normally does for plain
> code, no?
This is indeed the case right now.
--
Bastien
Bjarte Johansen writes:
> It seems to not work for #+LATEX_CLASS_OPTIONS, maybe because of the
> two _ ?
It works for me when I use M-x flyspell-mode RET.
Can you provide a step-by-step way of reproducing the problem?
--
Bastien
On 31 Jul, 2012, at 17:32 , Bastien wrote:
> Bjarte Johansen writes:
>
>> On 30 Jul, 2012, at 13:03 , Bastien wrote:
>>
>>> I've pushed a fix which should let flyspell ignore more commonly
>>> used Org keywords. Please test it.
>>
>> This works great. You forgot #+LATEX_CLASS_OPTIONS: tho
Bjarte Johansen writes:
> On 30 Jul, 2012, at 13:03 , Bastien wrote:
>
>> I've pushed a fix which should let flyspell ignore more commonly
>> used Org keywords. Please test it.
>
> This works great. You forgot #+LATEX_CLASS_OPTIONS: though.
Nope.
`org-additional-option-like-keywords-for-fl
Hi Bjarte,
Bjarte Johansen wrote:
> So I won't be able to work on this before next weekend, but in the mean time
> (unless someone else has the time) I suggest that we make a list of places
> where we would like to remove flyspell overlays from. I'll start.
>
> #+STARTUP
> #+OPTIONS
> #+LATEX_CLAS
I don't have any problem with natbib cite commands including \ref, \cite,
\citet, \citep, etc
Maybe your version of flyspell?? But it should act exactly as it does in
auctex or your latex mode of emacs. I would check in there if it works
properly because should parse the same way if not maybe
On 30 Jul, 2012, at 13:03 , Bastien wrote:
> I've pushed a fix which should let flyspell ignore more commonly
> used Org keywords. Please test it.
This works great. You forgot #+LATEX_CLASS_OPTIONS: though.
On 30 Jul, 2012, at 13:13 , Jeffrey Spencer wrote:
> Will give it a test later in
Will give it a test later in the week and let you know.
Also you can add this hook to make it act like the fly-spell mode in auctex
(if familiar with that) which skips most tex based commands (trips up
though if you have only one $ because assumes another $ sign later so won't
check spelling in th
I've pushed a fix which should let flyspell ignore more commonly
used Org keywords. Please test it.
Thanks!
--
Bastien
On 29 Jul, 2012, at 10:35 , Jeffrey Spencer wrote:
> I was also thinking about this recently but hadn't gotten as far as writing a
> patch.
>
> I was thinking some tags you know you want to remove the fly-spell overlays
> but for example caption you might or might not want the flyspell overla
I was also thinking about this recently but hadn't gotten as far as writing
a patch.
I was thinking some tags you know you want to remove the fly-spell overlays
but for example caption you might or might not want the flyspell overlays
removed. If there was a variable that could be set to choose so
On 28 Jul, 2012, at 11:27 , Bastien wrote:
> I cannot apply it because it adds keywords at the wrong place.
> For example you cannot add "startup:" in the first (cond ((...)))
> because "startup:" is not a "backend specific content." And some
> other discrepencies.
OK, I understand. I should
Hi Bjarte,
Bjarte Johansen writes:
> I made a patch to remove some more flyspell-overlays in #-blocks. The
> reason for no : in the latex_header is that for some reason the : does
> not get captured in dc1. flyspell is also removed for the full
> verbatim, lstlisting and src blocks.
>
> I hope y
Hi -
I made a patch to remove some more flyspell-overlays in #-blocks. The reason
for no : in the latex_header is that for some reason the : does not get
captured in dc1. flyspell is also removed for the full verbatim, lstlisting and
src blocks.
I hope you guys can use the patch.
Regards,
Bja
Hi Sébastien,
perhaps the problem with filladapt was specific to Thorsten's
installation, it's hard to guess.
IMHO the real question is: what do you need filladapt for?
You wouldn't install a new software called Emacs-For-The-Real-Men just
because it advertizes itself as "Make a better job th
Hi,
Bastien wrote:
> Eric S Fraga writes:
>>
>> I have emacs-goodies.el installed. What is it about this package that
>> causes problems?
>
> This package contains filladapt.el and filladapt.el _overwrites_ some
> fundamental variables about filling. Even if you are not using filladapt.el,
> it f
Hi Eric,
Eric S Fraga writes:
> Thorsten Jolitz writes:
>
> [...]
>
>> What I mainly did was updating from the git repo and changing the order
>> of hooks (orgstruct++-mode last). And I had to get rid of
>> emacs-goodies-el too, but that was probably my specific configuration.
>
> Ahh, interes
Thorsten Jolitz writes:
[...]
> What I mainly did was updating from the git repo and changing the order
> of hooks (orgstruct++-mode last). And I had to get rid of
> emacs-goodies-el too, but that was probably my specific configuration.
Ahh, interesting data point. I have emacs-goodies.el ins
Bernt Hansen writes:
> Bastien writes:
>
>> Hi Bernt,
>>
>> Bernt Hansen writes:
>>
>>> Auto-fill wrapping has stopped working correctly lately.
>>
>> It seems you're behind latest git HEAD by ~55 commits and
>> there has been bug fixes in this area.
>>
>> Please pull again (even temporarily)
Hi Bernt,
Bernt Hansen writes:
> Bastien writes:
>
>> Hi Bernt,
>>
>> Bernt Hansen writes:
>>
>>> Auto-fill wrapping has stopped working correctly lately.
>>
>> It seems you're behind latest git HEAD by ~55 commits and
>> there has been bug fixes in this area.
>>
>> Please pull again (even te
Bastien writes:
> Hi Bernt,
>
> Bernt Hansen writes:
>
>> Auto-fill wrapping has stopped working correctly lately.
>
> It seems you're behind latest git HEAD by ~55 commits and
> there has been bug fixes in this area.
>
> Please pull again (even temporarily) and let me know if this
> happens ag
Hi Bernt,
Bernt Hansen writes:
> Auto-fill wrapping has stopped working correctly lately.
It seems you're behind latest git HEAD by ~55 commits and
there has been bug fixes in this area.
Please pull again (even temporarily) and let me know if this
happens again with your configuration.
> I h
Bernt Hansen writes:
Hi Bernt,
> Auto-fill wrapping has stopped working correctly lately.
I had exactly the same problem you describe (no wonder because I just
copied your configuration) and solved it with Bastiens help.
You can search for subject "Strange indentation in message-mode" in the
Bernt Hansen writes:
> For now I've dropped orgstruct++-mode from my message-mode hook but
> I'm going to miss this for lists in my emails.
orgstruct-mode/orgtbl-mode work fine and do not break anything.
Christopher
Hi Bastien,
Auto-fill wrapping has stopped working correctly lately.
I have orgstruct++-mode added to my message mode hook as
--8<---cut here---start->8---
(add-hook 'message-mode-hook 'orgstruct++-mode 'append)
(add-hook 'message-mode-hook 'turn-on-auto-fill
Hi Sebastien
"Sebastien Vauban"
writes:
> Hello,
>
> I'd like to have a couple of different (column) views in my Org file, for
> example:
>
> - one (public) view with the estimated time only
> - another one (private, I mean "not exported") with the real clocked time
My previous patch and this p
Hi Sebastien,
"Sebastien Vauban"
writes:
> Hello,
>
> I'd like to have a couple of different (column) views in my Org file
How about trying this patch which lets you have another format in column
view?
After applying this patch, try this at the Tasks tree in your example.
M-: (org-columns "%6
Hi Sebastien,
"Sebastien Vauban"
writes:
> I'd like to have a couple of different (column) views in my Org file
How about trying this patch which let you have another format in column
view?
After applying this patch, try this.
M-: (org-columns "%66ITEM(Task) %6Effort(Estim.){:}")
Best,
IP
>
Hi Johnny,
Johnny writes:
> "Sebastien Vauban" writes:
>
>> Bastien wrote:
>>> "Sebastien Vauban" writes:
>>>
I'd like to have a couple of different (column) views in my Org file
>>>
>>> This is currently not possible and would require a lot of work.
>
> This is something I have been look
"Sebastien Vauban" writes:
> Bastien wrote:
>> "Sebastien Vauban" writes:
>>
>>> I'd like to have a couple of different (column) views in my Org file
>>
>> This is currently not possible and would require a lot of work.
This is something I have been looking for as well and it would be a
great f
Hi Bastien,
Bastien wrote:
> "Sebastien Vauban" writes:
>
>> I'd like to have a couple of different (column) views in my Org file
>
> This is currently not possible and would require a lot of work.
A pity, but I completely conceive it was not clear that it could have be more
promising this way (
Hi Sébastien,
"Sebastien Vauban" writes:
> I'd like to have a couple of different (column) views in my Org file
This is currently not possible and would require a lot of work.
Best,
--
Bastien
Hello,
I'd like to have a couple of different (column) views in my Org file, for
example:
- one (public) view with the estimated time only
- another one (private, I mean "not exported") with the real clocked time
I thought about setting the columns I wish to display in the corresponding
sections
Niels Giesen wrote:
> Ken Williams writes:
>
>
> [...]
>
> > Would it be possible for the export process to define various classes
> > that default to being exactly like 'verbatim', but could be
> > customized? After that, a next step might be to provide nice defaults
> > that do things like
Ken Williams writes:
[...]
> Would it be possible for the export process to define various classes
> that default to being exactly like 'verbatim', but could be
> customized? After that, a next step might be to provide nice defaults
> that do things like syntax-highlighting (through the 'minted
If I export the following code to LaTeX:
--
#+begin_src R
CV.t.hat <- rowMeans(loss)[m]
CV.t.hat
#+end_src
#+results:
: [1] 1.135857
--
, then it looks like this in the *.tex file:
--
\begin{verbatim}
CV.t.hat <- rowMeans(l
Hi David,
David Maus writes:
> I just pushed a commit to master that adds edebug specifications to
> all macros defined by Org mode.
This answers questions I've been asking myself for very long!
> With these specifications in place it
> is now possible to step through macros with edebug like
David Maus wrote:
> I just pushed a commit to master that adds edebug specifications to
> all macros defined by Org mode. With these specifications in place it
> is now possible to step through macros with edebug like a normal
> function call.
>
> Information about instrumenting macro calls can
I just pushed a commit to master that adds edebug specifications to
all macros defined by Org mode. With these specifications in place it
is now possible to step through macros with edebug like a normal
function call.
Information about instrumenting macro calls can be found here:
http://www.gnu.o
99 matches
Mail list logo
