Re: [O] [OT] Gnus mail tutorial?
John Hendy writes: > On May 24, 2013 6:01 PM, "Marcin Borkowski" wrote: >> >> Hi list, >> >> sorry for an off-topic question, but I'm sure someone here will be >> able to help me with this: I'm thinking about using Emacs as my email >> client, and I'm considering using Gnus for that. The Gnus manual is a >> bit intimidating; is there any newbie-friendly tutorial which might help >> get me started, taking into account that I do /not/ want to use Gmail, >> but another (IMAP-aware) mail service? >> > > Seconded. I tried following the tutorials that *do* exist once and just > gave up. Something tried and known to work and be complete would be > awesome. and I know there's a lot of gnus users on the list :) > I know the OP explicitly does not want to use gmail, however this gmail solution is *very* concise and should be easily adapted to work with a non-gmail imap service. http://www.emacswiki.org/emacs/GnusGmail#toc2 Just replace the gmail urls and ports with those of the service you want to use. Also, note that in blocks like the following (setq gnus-select-method '(nnimap "gmail" (nnimap-address "imap.gmail.com") (nnimap-server-port 993) (nnimap-stream ssl))) in the 'nnimap "gmail"' portion the "gmail" is just a name, not something special, and it can be replaced with any arbitrary string. The starter-kit-gnus page of my starter kit may be helpful, however, it doesn't provide much new information beyond that available at the previous emacs wiki page. http://eschulte.github.io/emacs24-starter-kit/starter-kit-gnus.html https://raw.github.com/eschulte/emacs24-starter-kit/master/starter-kit-gnus.org Hope this helps, > > John > >> Regards, >> >> -- >> Marcin Borkowski >> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski >> Adam Mickiewicz University >> -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [OT] Gnus mail tutorial?
Marcin Borkowski writes: > I'm thinking about using Emacs as my email client, and I'm considering > using Gnus for that. If it is Emacs rather than Gnus itself that attracts you, then you might consider notmuch or mu4e. Both have a Xapian-based core, and include an Emacs interface.
Re: [O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])
Hi,
FWIW, from a users view it would be nice if:
- Use Author/Email information from org file
- If not present use information from LCO file
- if neither org file nor LCO file has any information use
user-full-name and user-email-address
Could this be solved by having several e.g. `setkomavar{fromname}'
and so on in the tex file, so is created as follows:
if no #+AUTHOR in org-file and user-full-name is set:
add user-full-name
if #+LCO(s) in org-file:
add LCO file(s)
if #+AUTHOR in org-file:
add \setkomavar{fromname}{#+AUTHOR}
same for email
add \setkomavar{signature}{\usekomavar{fromname}}
so the result tex file may have:
\setkomavar{fromname}{Hans Wurst}
\setkomavar{fromemail}{hans_wu...@example.com}
...
\setkomavar{fromname}{Reiner Zufall}
\setkomavar{fromemail}{reiner_zuf...@example.com}
\setkomavar{signature}{\usekomavar{fromname}}
This probably isn't a `clean' solution, but should work without a need
to grep LCO files.
Best regards
Robert
On 05/23/2013 12:06 AM, Viktor Rosenfeld wrote:
> Hi Rasmus,
>
> Viktor Rosenfeld wrote:
>
>> Hi Rasmus,
>>
>> Rasmus wrote:
>>
>>> Viktor Rosenfeld writes:
>>>
Or 5, keep the change from SENDER to AUTHOR but revert the default
values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
lines could be removed because they duplicate the derived latex
backend.)
>>>
>>> I once had a teacher who talked about the optimal degree of
>>> conservatism (as well speaking positively about being in the infamoues
>>> ivory tower). 5. is fine with me. So I guess the deal is
>>> 1. default value is the same as in ox-latex.
>>> 2. . . . but it's kept in a seperete variable ox-kl variable.
>>>
I think that switching from SENDER to AUTHOR, keeping the
`org-koma-letter-{author,email}' variables in the KOMA backend, but
setting them per default to `user-full-name' and `user-mail-address',
would solve both your problems and let me keep LCO files. I would then
simply set these `org-koma-letter-*' variables to `nil' and document
this setup in the docstring. I'll see tomorrow if this is feasable.
>>>
>>> Does the attached patch work for you (also with ps tags?)
>>
>> It works, but I noticed the following problem: According to the Emacs
>> documentation `user-mail-address' is only set by Emacs after the
>> initialization process has completed and if it is not explicitly set
>> during initialization [1]. So, the defcustom of org-koma-letter-email
>> does not work as expected if the user has not set `user-mail-address'
>> before. Instead it is set to the empty string, which according to the
>> code setting `user-mail-address' means "not set yet."
>>
>> This can be taking care of by using `after-init-hook' as in the example
>> below. It has the added advantage that the value of `user-mail-address'
>> will be picked up regardless of whether it is set before or after
>> require'ing ox-koma-letter.
>>
>> Note that this creates a slight inconsistency with regard to
>> `user-full-name' which is only picked up correctly if it is set before
>> require'ing ox-koma-letter. I've fixed this by a slightly complicated
>> defcustom definition of `org-koma-letter-author' and another
>> after-init-hook.
>>
>> I've also changed the docstring to indicate what are the default values
>> and added the :group and :type flags again.
>
> I've put my changes into a patch against the current master (commit
> 06cdb2d2). Could you check it with your setup?
>
> Cheers,
> Viktor
>
Re: [O] [OT] Gnus mail tutorial?
On May 24, 2013 6:01 PM, "Marcin Borkowski" wrote: > > Hi list, > > sorry for an off-topic question, but I'm sure someone here will be > able to help me with this: I'm thinking about using Emacs as my email > client, and I'm considering using Gnus for that. The Gnus manual is a > bit intimidating; is there any newbie-friendly tutorial which might help > get me started, taking into account that I do /not/ want to use Gmail, > but another (IMAP-aware) mail service? > Seconded. I tried following the tutorials that *do* exist once and just gave up. Something tried and known to work and be complete would be awesome. and I know there's a lot of gnus users on the list :) John > Regards, > > -- > Marcin Borkowski > http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski > Adam Mickiewicz University >
[O] [OT] Gnus mail tutorial?
Hi list, sorry for an off-topic question, but I'm sure someone here will be able to help me with this: I'm thinking about using Emacs as my email client, and I'm considering using Gnus for that. The Gnus manual is a bit intimidating; is there any newbie-friendly tutorial which might help get me started, taking into account that I do /not/ want to use Gmail, but another (IMAP-aware) mail service? Regards, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] Updated syntax for #+bind and no LaTeX \maketitle command?
Hi John, John Hendy wrote: > On Fri, May 24, 2013 at 1:36 AM, Nick Dokos wrote: >> Check the value of org-export-allow-bind-keywords. If nil, then >> BIND keywords seem to be ignored silently. > > Thanks all! Not knowing about the org-export-allow-bind-keywords was > my issue, and setting it to =t= fixed it. Out of curiosity, what's the > difference between org-export-allow-BIND and > org-export-allow-bind-keywords? They M-x help on them sounds very > similar. One is used in Org < 8, the other in Org 8 and future versions. Best regards, Seb -- Sebastien Vauban
Re: [O] Indentation of code blocks within lists
Hello Nicolas, Nicolas Goaziou wrote: > "Sebastien Vauban" writes: > >> That won't help you, but I've already sent questions on this problem, last >> year (Org < 8). See my post on >> http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. >> >> Though, it's (for me) still unfixed as of today. >> >> The good news is that Nicolas seemed OK to look at it, and find a solution >> for >> it... > > AFAICS, your problem was solved. Could you point to what is still wrong? > > I also cannot reproduce OP's problem. It may be related to > `org-src-preserve-indentation' value. Indeed. I have as well `org-src-preserve-indentation' set to `t', for the same reason as pointed out: if I don't use it that way, then my code blocks which have different relative depths are exported (in HTML) on the same level, as if there was no indentation to respect. So, yes, it does work if you don't need to preserve indentation, you're well right. But, if not, the indentation is lost on export (and on source editing with C-c '). Best regards, Seb -- Sebastien Vauban
Re: [O] Importing all files into .org document source blocks
Hi Rainer,
Rainer M. Krug writes:
> Is there a way of importing all files in a directory
> (/etc/apt/sources/list.d/) into an org document, with each being in a
> separate code block?
Maybe this?:
for i in `find . -maxdepth 1 -type f`; do
echo "#+BEGIN_SRC :tangle /this/dir/${i}" >> afile.org
cat "${i}" >> afile.org
echo "#+END_SRC\n" >> afile.org
done
(this kind of reply is becoming a theme of mine)
Myles
Re: [O] Status fix for "Regression in fill-paragraph behavior"?
"Wagemans, Peter" writes: > Nicolas Goaziou wrote: > >> Then try editing your text in a block like: >> >> #+BEGIN_SRC message >> > ... >> #+END_SRC > > Or with fundamental or text mode. Possible but more cumbersome. Normal > text paragraph fill used to "just work". No, it didn't "just work". It mixed Org keywords, ignored line breaks... which are part of Org syntax, unlike to mail citation markup. Fixing it broke a side-effect you used. I understand this is annoying, but it is all about priority. > Maybe it wasn't defined, but it used to work up to 7.8.11 (at least). > For me it is very useful and often used functionality and even > fundamental and text mode offer it. And rst mode doesn't. Some major modes have such a feature, some others don't. Also, you have to admit that Org is a bit more complex than Text mode (or Fundamental mode), and may have different requirements. > Could org-mode perhaps delegate text paragraph fill to the functions > used by those modes (from Emacs fill.el I presume), so that the > standard Emacs "Adaptive Fill" functionality remains available? Again, what you call standard "Adaptive Fill" is not standard, since it depends on the major mode. I think external packages (filladapt.el?) might provide the functionality you're after, assuming you configure them to play nicely with Org. Regards, -- Nicolas Goaziou
Re: [O] Error with \usepackage{amsmath} due to \iint already being defined
Hello, Marcin Borkowski writes: > Also, taking into account the number of problems with wasysym's > conflicts, I'd suggest dropping it (and maybe several other packages) > from it. That would break, among other things, previewing of LaTeX snippets. On the other hand, it's probably safe to remove "longtable" package since we don't provide other table packages supported by the latex export back-end. Also, we may pass the "nointegrals" option by default to wasysym. > Further, this seems to be a bit of work - I can't promise > anything /now/ - but I'll try to look into it and check which package > is needed for which entity; loading a big package for a few commands > might be an overkill. IIRC it has been done already. The document is somewhere in Worg. > Would it be possible for the LaTeX exporter to include some packages > only if they are really needed, i.e., if some entity is actually used > in the document? This would both speed up compilation time and (maybe > more importantly) reduce the risk of such conflicts. (Not to mention > the inelegance of a large preamble consisting of loading unnecessary > packages - as a person responsible for converting LaTeX files sent to > a journal by people into something usable/compilable/good-looking, > I can say that one of the first things I usually do is to delete /all > \usepackage's/ from the preamble, and see if it compiles correctly. In > more than 50% cases, it does... It has been suggested on this list already. Aaron Ecay even provided a patch. I think this is calling for problems as it cannot be totally reliable (and the time necessary to do this would probably defeat the compilation gain). On the other hand, you can define your own optimized preamble with `org-latex-classes' while the default setup still provides a (somewhat) smooth experience for the casual LaTeX user. Regards, -- Nicolas Goaziou
Re: [O] Status fix for "Regression in fill-paragraph behavior"?
Nicolas Goaziou wrote: > Then try editing your text in a block like: > > #+BEGIN_SRC message > > ... > #+END_SRC Or with fundamental or text mode. Possible but more cumbersome. Normal text paragraph fill used to "just work". > I wouldn't call it a regression since this behaviour never was defined > as a feature in the first place. Maybe it wasn't defined, but it used to work up to 7.8.11 (at least). For me it is very useful and often used functionality and even fundamental and text mode offer it. So why break that? Could org-mode perhaps delegate text paragraph fill to the functions used by those modes (from Emacs fill.el I presume), so that the standard Emacs "Adaptive Fill" functionality remains available? Regards, Peter Wagemans
Re: [O] Error with \usepackage{amsmath} due to \iint already being defined
Dnia 2013-05-24, o godz. 14:38:42
Nick Dokos napisał(a):
> John Hendy writes:
>
> > On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara
> > wrote:
> >>
> >> Hi,
> >>
> >>> I tracked down an error about \iint already being defined to a
> >>> clash between wasysym and amsmath. I brought in amsmath, but it
> >>> appears that wasysym is an Org LaTeX export default package.
> >>
> >> Just put this in the LaTeX header before you load amsmath:
> >>
> >> \usepackage{savesym}
> >> \savesymbol{iint}
> >> \savesymbol{iiint}
> >>
> >
> > Does this savewasysym's definition if iint instead of amsmath's? In
> > the case that I actually use \iint (super unlikely, but not
> > impossible), which package's is preferred?
> >
>
> The wasysym docs say that there should be no conflict, but that seems
> to be wrong: ISTR multiple instances of this conflict.
>
> If you prefer the amsmath integral signs over the wasysym ones, then
> probably the best thing to do is to load wasysym with the
> ``nointegrals'' option:
>
>\usepackage[nointegrals]{wasysym}
>
> This can be done permanently by customizing
> org-latex-default-packages-alist and adding the option to the wasysym
> entry.
Nick: good to know about org-latex-default-packages-alist!
Carsten/Bastien (I forward to both of you, since I don't know who is
to gitblame for that:P): looking at its docstring, I guess there are
two minor bugs here: first, it is not technically an alist, but a
"normal" list, second, apparently the docstring doesn't mention that an
element of this list might be a string (inserted then verbatim into
preamble) and not a list.
Also, taking into account the number of problems with wasysym's
conflicts, I'd suggest dropping it (and maybe several other packages)
from it.
Further, this seems to be a bit of work - I can't promise
anything /now/ - but I'll try to look into it and check which package
is needed for which entity; loading a big package for a few commands
might be an overkill. Would it be possible for the LaTeX exporter to
include some packages only if they are really needed, i.e., if some
entity is actually used in the document? This would both speed up
compilation time and (maybe more importantly) reduce the risk of such
conflicts. (Not to mention the inelegance of a large preamble
consisting of loading unnecessary packages - as a person responsible
for converting LaTeX files sent to a journal by people into something
usable/compilable/good-looking, I can say that one of the first things
I usually do is to delete /all \usepackage's/ from the preamble, and
see if it compiles correctly. In more than 50% cases, it does...
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] LaTeX appears not to like default Org tag export format (\hfill)?
John Hendy writes:
> I'm getting errors on tag export:
>
> Package hyperref Warning: Token not allowed in a PDF string (PDFDocEncoding):
> (hyperref)removing `\hfill' on input line 1706.
>
> The tags get converted to this:
>
> \subsection{Headline title\hfill{}\textsc{tag}}
>
> It looks like LaTeX doesn't like that.
LaTeX has no problem with it: it's hyperref that does not like it.
>
> Any suggestions?
>
It's a warning, not an error, so unless it causes a real problem,
I'd ignore it.
Nick
Re: [O] Error with \usepackage{amsmath} due to \iint already being defined
John Hendy writes:
> On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara
> wrote:
>>
>> Hi,
>>
>>> I tracked down an error about \iint already being defined to a clash
>>> between wasysym and amsmath. I brought in amsmath, but it appears that
>>> wasysym is an Org LaTeX export default package.
>>
>> Just put this in the LaTeX header before you load amsmath:
>>
>> \usepackage{savesym}
>> \savesymbol{iint}
>> \savesymbol{iiint}
>>
>
> Does this savewasysym's definition if iint instead of amsmath's? In
> the case that I actually use \iint (super unlikely, but not
> impossible), which package's is preferred?
>
The wasysym docs say that there should be no conflict, but that seems
to be wrong: ISTR multiple instances of this conflict.
If you prefer the amsmath integral signs over the wasysym ones, then
probably the best thing to do is to load wasysym with the
``nointegrals'' option:
\usepackage[nointegrals]{wasysym}
This can be done permanently by customizing
org-latex-default-packages-alist and adding the option to the wasysym
entry.
--
Nick
Re: [O] LaTeX appears not to like default Org tag export format (\hfill)?
Dnia 2013-05-24, o godz. 12:07:55
John Hendy napisał(a):
> I'm getting errors on tag export:
>
> Package hyperref Warning: Token not allowed in a PDF string
> (PDFDocEncoding): (hyperref)removing `\hfill' on
> input line 1706.
>
> The tags get converted to this:
>
> \subsection{Headline title\hfill{}\textsc{tag}}
>
> It looks like LaTeX doesn't like that.
>
> Any suggestions?
First: I can't resist telling a joke.
A guy is standing on the corner of the street smoking one cigarette
after another. A lady walking by notices him and says "Hey, don't you
know that those things can kill you? I mean, didn't you see the giant
warning on the box?!" "That's OK" says the guy, puffing casually "I'm a
computer programmer" "So? What's that got to do with anything?" "We
don't care about warnings. We only care about errors."
Now, to the point: indeed, this is only a warning and you don't have to
worry about it. If you really do not like this warning, try putting
this into your preamble (untested, but should work):
\pdfstringdefDisableCommands{\def\hfill{ }}
Explanation: it is not LaTeX which dislikes \hfill (though it's a
plain TeX macro, not a LaTeX one), but hyperref. More precisely, the
argument to \section lands not only in the ToC, but also in the pdf
bookmarks, and what can go there is seemingly quite restricted (I
don't know/care much about the exact details, frankly speaking). The
above spell tells hyperref to (temporarily) change \hfill to a space in
that context. (See hyperref's docs and/or source for more info.)
> John
HTH,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] Error with \usepackage{amsmath} due to \iint already being defined
Dnia 2013-05-24, o godz. 12:35:59
John Hendy napisał(a):
> On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara
> wrote:
> >
> > Hi,
> >
> >> I tracked down an error about \iint already being defined to a
> >> clash between wasysym and amsmath. I brought in amsmath, but it
> >> appears that wasysym is an Org LaTeX export default package.
> >
> > Just put this in the LaTeX header before you load amsmath:
> >
> > \usepackage{savesym}
> > \savesymbol{iint}
> > \savesymbol{iiint}
> >
>
> Does this savewasysym's definition if iint instead of amsmath's? In
> the case that I actually use \iint (super unlikely, but not
> impossible), which package's is preferred?
See http://www.ctan.org/pkg/savesym - it saves wasysym's \iint
as\origiint. (BTW: nice package this savesym: not complicated, but
handy. Thanks for the pointer, Vincent!)
And you can always use a "poor man's savesym", that is,
\let\iint\relax
> Thanks,
> John
Regards,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] org-element
Daimrod writes: > Nicolas Goaziou writes: > >> See `org-element-put-property' and friends. > > I've tried to use `org-element-put-property' but it only modifies the > object in memory, not the element in the file. Is there a way to write > the object into a file? I misread your question. "org-element.el" doesn't provide functions to modify the buffer, but you may use `org-element-interpret-data' to create Org syntax from an object. You may also want to have a look at org-sync.el. Regards, -- Nicolas Goaziou
[O] [PATCH] org-mouse: Fix incorrect replacement for checkbox lists
Hi, I have prepared patch which fixes incorrect replacement with org-mouse popup function for checkbox lists: "All Set" and "All Clear". Please, check it. See attachment. -- *Илья Зонов* (*Ilya Zonov*) aka *puzan* Нижний Новгород, Россия (Nizhny Novgorod, Russia) 0001-org-mouse-Fix-incorrect-replacement-for-checkbox-lis.patch Description: Binary data
Re: [O] Rendering of source code on worg
Hi Bastien, Bastien writes: > Hi Guido, > > Guido Van Hoecke writes: > >> I think that the default rendering of source code on the worg side was >> closely resmbling the default rendering on emacs. >> >> I have the impression that somehow this is no longer the case, as >> visible a.o. at >> http://orgmode.org/worg/org-configs/org-config-examples.html >> >> Is this a deliberate choice? > > The .emacs.el on orgmode.org contains: > > (set-face-foreground 'font-lock-keyword-face "DeepSkyBlue1") > (set-face-foreground 'font-lock-string-face "Goldenrod") > > This is used when publishing Worg files on the server. > > If you can find better colors, please submit some. I never intended to comment nor judge the specific colors used. I was under the impression that the elisp fragments on the website used to have exactly the same font and faces as in stock emacs elisp buffers. Apparently this is not the case, and I still don't know where I got that wrong idea. Anyhow, sorry for the noise, Guido -- The problems of business administration in general, and database management in particular are much too difficult for people that think in IBMese, compounded with sloppy English. -- Edsger W. Dijkstra
Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode
François Pinard writes: Hi Francios, > You're quite generous when you say "full fledged" :-). There are many > details in which I find org-weights.el unsatisfactory, but as it is > sufficient as it stands for my day-to-day usage, I'm not overly pushing > on it (the pun is purely accidental). > >> | * Header 1 *2 + 1... > >> | ## * Header 1 [#1] > > I find the "*2 + 1" far too verbose, in that it uses too much horizontal > space, I much prefer the compact aspect of "[#1]". The weights are a bit heavy, and I had to move them to column 65 to make them fit in a vertically splitted screen. But they carry more information of course, the question is if one can process this information quickly enough, or if one single number is not enough to give an impression of the subtrees 'weight'. Or maybe ,-- | * Header 1 [2/1]... `-- is easier on the eyes than ,--- | * Header 1 *2 + 1... `--- > What would be ideal, but I do not know if it can be organized, would > keep the weights or hidden-lines information always glued to the > ellipsis, and not hiding any underlying text as org-weights currently > does. On the other hand, there are some virtue to the vertical > alignment of weight information. Sigh! Nothing is perfect... It would be easy to make the position of the weight/cookie a user option - either direcctly behind the headline text, or aligned at a certain column. >> [...] shows the overlay-info for *all* headlines except the one where >> point is on. > > That exception is a sad and questionable workaround, for being able to > edit the current line. When, in normal and standard Org mode, I edit a > line which has an ellipsis at the end, I may edit the line like any > other one without seeing undesired effects. org-weights should be > equally capable, and there should be no reason (ideally) to hide the > information for the line where the point is, merely for editing to work. I would still like to have my original idea (which was actually a user request for outshine.el by Jonas Bernoulli): show the number of hidden lines only when the headline is folded, and update with every visibility change. >> one problem I hit is that a visibility change does not uptdate all >> cookies/weights at once, they are only updated headline per headline >> when point is moved up and down. Is that for performance reasons? > > See the Caveats section at the end of org-weights documentation. > Normally, the information to be updated may be minimized to the header > above the line holding point, and then, recursively up. But there is a > bug in this optimization when a header is demoted (as explained in > Caveats). Another performance-related detail is the quadratic behaviour > which may be seen in big, deeply nested Org files: it could be avoided > by cleverly saving (in a hidden way) information on computations already > done, and reusing it instead of recomputing it many times. But as usual > with most cached optimization, it is difficult to get fully right. This task seems to bring Emacs to its limits, at least in 5000+ lines outshine buffers (e.g. my init.el). So maybe its not that suited for a visibility-change hook, but rather for occasional activation by an explicit user command? -- cheers, Thorsten
Re: [O] Rendering of source code on worg
Hi Guido, Guido Van Hoecke writes: > I think that the default rendering of source code on the worg side was > closely resmbling the default rendering on emacs. > > I have the impression that somehow this is no longer the case, as > visible a.o. at > http://orgmode.org/worg/org-configs/org-config-examples.html > > Is this a deliberate choice? The .emacs.el on orgmode.org contains: (set-face-foreground 'font-lock-keyword-face "DeepSkyBlue1") (set-face-foreground 'font-lock-string-face "Goldenrod") This is used when publishing Worg files on the server. If you can find better colors, please submit some. Thanks, -- Bastien
Re: [O] Error with \usepackage{amsmath} due to \iint already being defined
On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara wrote:
>
> Hi,
>
>> I tracked down an error about \iint already being defined to a clash
>> between wasysym and amsmath. I brought in amsmath, but it appears that
>> wasysym is an Org LaTeX export default package.
>
> Just put this in the LaTeX header before you load amsmath:
>
> \usepackage{savesym}
> \savesymbol{iint}
> \savesymbol{iiint}
>
Does this savewasysym's definition if iint instead of amsmath's? In
the case that I actually use \iint (super unlikely, but not
impossible), which package's is preferred?
Thanks,
John
> HTH,
> /v
>
> --
> Vincent Beffara
>
>
Re: [O] Per file ID
Hi Klaus-Dieter, Klaus-Dieter Bauer writes: > I found that the ID mechanism is quite robust for linking across > files, but most of the time I'd like to link to a file, not a heading > in that file, by ID. Is that possible in org-mode? Well, no, sorry! -- Bastien
Re: [O] Org sources and PDF files on Worg
Hi Rasmus, Rasmus writes: > Couldn't we just compare input and output? Or is that not safe > enough? E.g. in an over-simplistic form obtain dead pages via > something like this: If you can write a general function that will work for any defined publishing project, that'd be cool. Maybe as an addition for worg/org-hacks.org. -- Bastien
Re: [O] Bad formatting in documentation
Hi Alexis,
Alexis Praga writes:
> I just stumbled upon a bad formatting on the website (
> http://orgmode.org/worg/org-faq.html ).
> In "Why doesn't C-c a call the agenda? Why don't some org keybindings
> work?", we can see
>
> #+BEGIN_SRC emacs-lisp ;; The following lines are always needed. Choose
> your own keys. (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
> (global-set-key "\C-cl" 'org-store-link) (global-set-key "\C-ca"
> 'org-agenda) (global-set-key "\C-cb" 'org-iswitchb) #+END_SRC
> emacs-lisp
Fixed, thanks.
--
Bastien
Re: [O] Status fix for "Regression in fill-paragraph behavior"?
On 5/24/13, Wagemans, Peter wrote: > In org 7.8.11 with emacs 24.2 fill-paragraph used to recognize > paragraph fill prefixes as usual for mail citations. This seems to be > no longer the case (which I noticed first with org 7.9.3 with emacs > 24.3). Apparently this has been noticed before and a bug reported, > according to filladapt.el works. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] Error with \usepackage{amsmath} due to \iint already being defined
Hi,
> I tracked down an error about \iint already being defined to a clash
> between wasysym and amsmath. I brought in amsmath, but it appears that
> wasysym is an Org LaTeX export default package.
Just put this in the LaTeX header before you load amsmath:
\usepackage{savesym}
\savesymbol{iint}
\savesymbol{iiint}
HTH,
/v
--
Vincent Beffara
[O] LaTeX appears not to like default Org tag export format (\hfill)?
I'm getting errors on tag export:
Package hyperref Warning: Token not allowed in a PDF string (PDFDocEncoding):
(hyperref)removing `\hfill' on input line 1706.
The tags get converted to this:
\subsection{Headline title\hfill{}\textsc{tag}}
It looks like LaTeX doesn't like that.
Any suggestions?
John
[O] Error with \usepackage{amsmath} due to \iint already being defined
I tracked down an error about \iint already being defined to a clash
between wasysym and amsmath. I brought in amsmath, but it appears that
wasysym is an Org LaTeX export default package.
What is it's purpose? Is there a better way round this than just
commenting out the wasysym package in the .tex file manually?
I forget exactly what I use from amsmath, but I do use it a reasonable
amount through my documents so I keep #+latex_header:
\usepackage{amsmath} in my setupfile.
This doesn't appear to be a major problem with respect to export, but
it does trigger [LaTeX error] in the minibuffer, so I have to check to
see if it was something to care about or not.
John
Re: [O] org-element
Nicolas Goaziou writes: > Hello, Hello Nicolas, > Daimrod writes: > >> I'm playing a bit with org-element for org-contacts and I wanted to know >> what is the prefered way to change an element. >> >> For example, ATM, when I want to change an element property to add a new >> value, I do: >> >> #+BEGIN_SRC emacs-lisp >> (org-entry-put nil property >> (concat (org-entry-get nil property) >> " " new-value)) >> #+END_SRC > > See `org-element-put-property' and friends. I've tried to use `org-element-put-property' but it only modifies the object in memory, not the element in the file. Is there a way to write the object into a file? > Regards, -- Daimrod/Greg pgpx5qxLaG4B3.pgp Description: PGP signature
Re: [O] Updated syntax for #+bind and no LaTeX \maketitle command?
On Fri, May 24, 2013 at 1:36 AM, Nick Dokos wrote: > Nick Dokos writes: > >>> #+bind: org-latex-title-command "" >>> >>> This is still generating a \maketitle line in my .tex file. >>> >>> What's the proper way to do this on Org 8.0? >>> >>> >> >> I suspect this is the same problem as the one discussed in the following: >> >>http://thread.gmane.org/gmane.emacs.orgmode/72085 >> >> Nicolas suggested using a file local variable for that problem and I've >> verified that that solution also works for this one. Just add >> >> # Local Variables: >> # org-latex-title-command: "" >> # End: >> >> at the end of your file. > > No, I'm wrong: it's not the same problem. And using BIND should > work in this case, assuming that it is allowed. > > Check the value of org-export-allow-bind-keywords. If nil, then > BIND keywords seem to be ignored silently. Thanks all! Not knowing about the org-export-allow-bind-keywords was my issue, and setting it to =t= fixed it. Out of curiosity, what's the difference between org-export-allow-BIND and org-export-allow-bind-keywords? They M-x help on them sounds very similar. #+begin_help org-export-allow-bind-keywords Documentation: Non-nil means BIND keywords can define local variable values. This is a potential security risk, which is why the default value is nil. You can also allow them through local buffer variables. #+end_help #+begin_help org-export-allow-BIND Documentation: Non-nil means allow #+BIND to define local variable values for export. This is a potential security risk, which is why the user must confirm the use of these lines. #+end_help Ah, nevermind. Based on the customize-variable menu option, I'm thinking the latter is how org should automatically accept #+bind settings, and the former is whether to allow #+bind settings at all. Oddly, my value for org-export-allow-bind is set to "confirm" but I just tested things and didn't get asked... John > > -- > Nick > >
Re: [O] Org-mode styled beamer presentations
Dnia 2013-05-24, o godz. 11:41:49 Eric S Fraga napisał(a): > Eric S Fraga writes: > > > Marcin Borkowski writes: > > > >> > >> > >> Hi list, > >> > >> many of you use Org-mode to create Beamer presentations. How > >> about the other way round? I wrote an Org-mode styled Beamer > >> theme. Please use, enjoy and report bugs and feature requests! > >> > >> https://twitter.com/marcin_mbork/status/335890494980767746 > >> http://mbork.pl/2013-05-18_A_presentation_on_LaTeX_editing_%28en%29 > >> https://github.com/mbork/beamerorgtheme > >> > >> > >> > >> Best, > > > > Very cute! I like it. Thanks! > > Now I just need to customise it so that it matches my usual colour > > theme in Emacs which has a black background! Ahh, a perfect excuse > > to not get any more work done today ;-) > > > > thanks, > > eric > > Well, that was too easy... see attached for a slightly different > version of your colour theme which gives black background with > yellowish-white foreground and red highlighting... Yep, modifying beamer color themes is usually rather easy: often you just give a few "basic" (as in "basis" of a linear space) colors and the rest are just linear (or even convex) combinations of those. > I guess I have to get back to work now! ;-) > > In fact, I have a talk to prepare for next week. I think I'll use > this style! The audience should be sufficiently geeky to appreciate > it for once. Great! My audience was also quite geeky; in fact, one colleague asked me for the source of this theme, so that he could learn to make a Vim Beamer theme;)... > Thanks again, > eric Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode
Thorsten Jolitz writes: > it happened again [...]- François Pinard already had a fully fledged > implementation of my "new" org-mode feature: 'org-weights.el' You're quite generous when you say "full fledged" :-). There are many details in which I find org-weights.el unsatisfactory, but as it is sufficient as it stands for my day-to-day usage, I'm not overly pushing on it (the pun is purely accidental). > | * Header 1 *2 + 1... > | ## * Header 1 [#1] I find the "*2 + 1" far too verbose, in that it uses too much horizontal space, I much prefer the compact aspect of "[#1]". What would be ideal, but I do not know if it can be organized, would keep the weights or hidden-lines information always glued to the ellipsis, and not hiding any underlying text as org-weights currently does. On the other hand, there are some virtue to the vertical alignment of weight information. Sigh! Nothing is perfect... > [...] shows the overlay-info for *all* headlines except the one where > point is on. That exception is a sad and questionable workaround, for being able to edit the current line. When, in normal and standard Org mode, I edit a line which has an ellipsis at the end, I may edit the line like any other one without seeing undesired effects. org-weights should be equally capable, and there should be no reason (ideally) to hide the information for the line where the point is, merely for editing to work. > one problem I hit is that a visibility change does not uptdate all > cookies/weights at once, they are only updated headline per headline > when point is moved up and down. Is that for performance reasons? See the Caveats section at the end of org-weights documentation. Normally, the information to be updated may be minimized to the header above the line holding point, and then, recursively up. But there is a bug in this optimization when a header is demoted (as explained in Caveats). Another performance-related detail is the quadratic behaviour which may be seen in big, deeply nested Org files: it could be avoided by cleverly saving (in a hidden way) information on computations already done, and reusing it instead of recomputing it many times. But as usual with most cached optimization, it is difficult to get fully right. François
[O] [BUG] org-agenda-open-link does not open bbdb links
The function org-agenda-open-link does not open bbdb links. The reason is that bbdb agenda lines contain links that are not found in the entry. Because the agenda line is added to the strings scanned by org-offer-links-in-entry, it is added to the list of links (lk). I.e., both buffer and lk are defined, which triggers the first cond statement. The function then proceeds to search for this link in the buffer. It does not find it, since a bbdb-anniversary entry typically looks like this: * Anniversaries :PROPERTIES: :CATEGORY: anniv :END: %%(org-bbdb-anniversaries) But as a result, the function org-offer-links-in-entry never gets to the second cond statement, which would indeed open the link found in the agenda buffer. It seems to me that feeding the agenda line as a "prefix" to org-offer-links-in-entry is redundant, since the second cond statement explicitly looks for links in the agenda line. The following change fixes the problem, but before I submit it as a properly formatted patch, I want to make sure that it does not interfere with some other functionality. Best, Matt --8<---cut here---start->8--- diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index c615b58..1cc1c28 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8449,8 +8449,7 @@ It also looks at the text of the entry itself." (let* ((marker (or (org-get-at-bol 'org-hd-marker) (org-get-at-bol 'org-marker))) (buffer (and marker (marker-buffer marker))) -(prefix (buffer-substring (point-at-bol) (point-at-eol))) -(lkall (org-offer-links-in-entry buffer marker arg prefix)) +(lkall (org-offer-links-in-entry buffer marker arg)) (lk0 (car lkall)) (lk (if (stringp lk0) (list lk0) lk0)) (lkend (cdr lkall)) --8<---cut here---end--->8---
Re: [O] Indentation of code blocks within lists
Hi Nicolas, > I also cannot reproduce OP's problem. It may be related to > `org-src-preserve-indentation' value. Thanks for your answer. I checked the `org-src-preserve-indentation' variable and saw that it was non `nil'. Setting this variable to `nil' fixes the demonstrated issue. But, even then, I still have an indentation problem. In the following example (with `org-src-preserve-indentation' set to `nil'): - in the first headline, I have a code block in a list which is correctly exported ignoring the spaces due to the indentation of the Org list; - in the second headline, I have the same source code but it is split in several code blocks in order to better document it. The last 2 blocks are not correctly exported as *all spaces before the code* (even those I manually added) are ignored. --8<---cut here---start->8--- * First situation My list: - Example which works #+begin_src emacs-lisp (if complex-condition then-block else-block) #+end_src * Second situation My list: - Example which does not work anymore #+begin_src emacs-lisp (if complex-condition #+end_src The "then" block does this: #+begin_src emacs-lisp then-block #+end_src The else-block does that: #+begin_src emacs-lisp else-block) #+end_src --8<---cut here---end--->8--- I think that only the spaces due to the Org indentation (here the number of spaces before the `#' which delimits the source block, hence 2 spaces) should be ignored. IOW, just the "margin" should be removed, and the margin is (IMO) defined as the spaces from column 0 up to the `#' character. Thanks for your help. Regards, Francesco
Re: [O] Fwd: File local variables not being processed
"Daniel." writes:
> Hi, I have a todo.org file with some local variables, here is the file content
>
> # Local Variables:
> # eval: (setq org-todo-keyword-faces
> # '(("TOSTART" . "red")
> # ("PLANING" . "yellow")
> # ("DOING" . "yellow")
> # ("CHECKING" . "yellow")
> # ("WAITING" . "green")
> # ("DOCUMENTING" . "yellow")))
> # End:
>
> #+TODO: TOSTART PLANING DOING CHECKING WAITING DOCUMENTING RELEASE
>
> * TOSTART DO SOMETHING
>
> And here is the snippet of my .emacs
>
> ;; TODO file:
> (defvar todo-file "~/todo.org"
> "My todo list!")
> (setq enable-local-variables :all)
> (setq enable-local-eval t)
> (find-file todo-file)
>
> Still I don't get the org-mode colors specified on local variables.. If I put
> the same sexp on my .emacs it works..
>
No ideas about what's wrong with your setup (unless you are testing on a
file different from the short one you posted - see below), but it works
fine here. You can always check whether the setup was effective, using
C-h v org-todo-keyword-faces RET.
One thing that you want to change is to put the local variable section
at the end of the file: emacs starts looking at the end and looks back a
certain distance - 3000 characters by default - and only within the last
"page" of the file, i.e. not above a ^L (formfeed) character.
It should still work for a short enough file like the one you posted,
but once you start adding entries, the local variable section will
soon become invisible to emacs.
--
Nick
[O] Per file ID
Hello! I intend to use org-mode for organizing my research notes; I prefer however a "wiki" style with many files rather than one big file. I found that the ID mechanism is quite robust for linking across files, but most of the time I'd like to link to a file, not a heading in that file, by ID. Is that possible in org-mode? As a workaround I'll use toplevel headings instead of the title. kind regards, Klaus
[O] Fwd: File local variables not being processed
Hi, I have a todo.org file with some local variables, here is the file
content
# Local Variables:
# eval: (setq org-todo-keyword-faces
# '(("TOSTART" . "red")
#("PLANING" . "yellow")
#("DOING" . "yellow")
#("CHECKING" . "yellow")
#("WAITING" . "green")
#("DOCUMENTING" . "yellow")))
# End:
#+TODO: TOSTART PLANING DOING CHECKING WAITING DOCUMENTING RELEASE
* TOSTART DO SOMETHING
And here is the snippet of my .emacs
;; TODO file:
(defvar todo-file "~/todo.org"
"My todo list!")
(setq enable-local-variables :all)
(setq enable-local-eval t)
(find-file todo-file)
Still I don't get the org-mode colors specified on local variables.. If I
put the same sexp on my .emacs it works..
Any ideias?
--
*"Do or do not. There is no try"*
* **Yoda Master*
--
*"Do or do not. There is no try"*
* **Yoda Master*
[O] Bad formatting in documentation
Hi,
I just stumbled upon a bad formatting on the website (
http://orgmode.org/worg/org-faq.html ).
In "Why doesn't C-c a call the agenda? Why don't some org keybindings
work?", we can see
#+BEGIN_SRC emacs-lisp ;; The following lines are always needed. Choose
your own keys. (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
(global-set-key "\C-cl" 'org-store-link) (global-set-key "\C-ca"
'org-agenda) (global-set-key "\C-cb" 'org-iswitchb) #+END_SRC emacs-lisp
--
Alexis Praga
___
Ph.D Student
CERFACS
alexis.pr...@gmail.com
Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode
Nick Dokos writes: > Thorsten Jolitz writes: > >>> , and it should be hooked somehow into the folding/unfolding routines >>> to auto-update. >> >> Thats what I thought too, but I ran into a problem I could not solve so >> far, so this user-command based implementation (show the cookies on >> demand) is kind of the second-best solution (better then nothing). >> >> Here is a thread related to the problem mentioned, unfortunately with no >> posts except my own so far: >> >> ,--- >> | http://lists.gnu.org/archive/html/help-gnu-emacs/2013-05/msg00511.html >> `--- > > You can try increasing max-specpdl-size: read the doc for it. If you are > asking for a bounded amount of resources but that amount is bigger than > what emacs is willing to give you, then increasing the size should work. > OTOH, if you are asking for unlimited resources (e.g. you have an > infinite recursion somewhere), then increasing the limit will only allow > you to go a little further before blowing up again. > > So try making it 10 or even 100 times bigger and see what you get (and > try it on a throwaway emacs instance, not the working instance). If it > still blows up, you'll have to look at your code carefully: chances are > there is a programming error. I read about that, but I did not simply want to increase the limit because looking at my code I thought it should not use so much bindings. However, the problem is more or less obsolete now since I switched to a completely different implementation using overlays - see my post with regards to 'org-weights.el'. Thanks for the info anyway. -- cheers, Thorsten
Re: [O] Status fix for "Regression in fill-paragraph behavior"?
"Wagemans, Peter" writes: > Nicolas Goaziou wrote: > >> You can wrap your mail citation within a Verse block (or an example >> block). > > That appears to inhibit paragraph filling. The desired and previously > existing functionality is paragraph filling that preserves the > paragraph citation prefix. Then try editing your text in a block like: #+BEGIN_SRC message > ... #+END_SRC You can edit the message with C-c ' and benefit from Message mode's filling mechanism. Org recognizes its own prefixes and cannot cope with other modes'. > Also, I often compose complete text mail bodies including citations in > an org-mode document and then you don't want org-mode block directives > in the mail text. I think you want to edit your message in Message mode, not in Org mode, then. > Does the above reply mean that the regression hasn't been fixed yet? > Is it still being worked on? I wouldn't call it a regression since this behaviour never was defined as a feature in the first place. Recognizing citation prefix means recognizing a new type of data in Org syntax. I don't think it's worth it considering Org is not to replace Message. Regards, -- Nicolas Goaziou
Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode
Carsten Dominik writes: Hi Carsten, Hi List, > , > | Behind every folded headline, a little 'cookie' shows the number of > | hidden lines till the next visible headline. > ` > However, I don't think the implementation is the right > one. it happened again - François Pinard already had a fully fledged implementation of my "new" org-mode feature: 'org-weights.el' ,-- | https://github.com/pinard/org-weights `-- But this time I was saved from implementing a completely independent version of the same idea (see 'outorg.el' vs 'poporg.el') but rather forked his library on github and merged my ideas/code with his: , | https://github.com/tj64/org-weights ` Although the details are still a bit buggy, the general mechanism already works. 1. 'org-weights' works with Org-mode as well as with outshine buffers now (including Emacs Lisp files with conventional headers (^;;;+ ). It might even work with plain outline buffers. 2. 'org-weights' now offers to display the headline-weights (number of subtrees and number of paragraphs) or hidden-lines-cookies (the number of (hidden) lines till the next visible headline. Here are a few examples (don't bother about the numbers, they are made up, since I cannot copy overlays): 1. Org-mode/subtree-weights: ,--- | * Header 1 *2 + 1... | ** Header 2a ** 1 | | text text text text text | text text text text text | | ** Header 2b ** 1 `--- 2. Outshine Emacs Lisp/subtree-weights: ,-- | ;; * Header 1 *2 + 1... | ;; ** Header 2a ** 1 | | text text text text text | text text text text text | | ;; ** Header 2b ** 1 | `-- 3. Conventional Emacs-Lisp/hidden-lines-cookies , | ;;; Header 1 [#1] | Header 2a [#4] | | text text text text text | text text text text text | | Header 2b [#2] | ` 4. Outshine PicoLisp/hidden-lines-cookies , | ## * Header 1 [#1] | ## ** Header 2a [#4] | | text text text text text | text text text text text | | ## ** Header 2b [#2] | ` 'org-weights' is implemented with overlays, so the files are not touched. Command 'org-weights-mode' toggles activation, and 'org-weights-or-cookies' switches between subtree-weights and hidden-lines-cookies. Actually the hidden-lines-cookies are not really about hidden-lines anymore in this implementation, because I adapted to the semantics of 'org-weights' that shows the overlay-info for *all* headlines except the one where point is on. Besides the still buggy details for outshine buffers (the calculated numbers are not always quite right), one problem I hit is that a visibility change does not uptdate all cookies/weights at once, they are only updated headline per headline when point is moved up and down. Is that for performance reasons? -- cheers, Thorsten
Re: [O] Status fix for "Regression in fill-paragraph behavior"?
Nicolas Goaziou wrote: > You can wrap your mail citation within a Verse block (or an example > block). That appears to inhibit paragraph filling. The desired and previously existing functionality is paragraph filling that preserves the paragraph citation prefix. Also, I often compose complete text mail bodies including citations in an org-mode document and then you don't want org-mode block directives in the mail text. Does the above reply mean that the regression hasn't been fixed yet? Is it still being worked on? Regards, Peter Wagemans
Re: [O] Indentation of code blocks within lists
Hello, "Sebastien Vauban" writes: > That won't help you, but I've already sent questions on this problem, last > year (Org < 8). See my post on > http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. > > Though, it's (for me) still unfixed as of today. > > The good news is that Nicolas seemed OK to look at it, and find a solution for > it... AFAICS, your problem was solved. Could you point to what is still wrong? I also cannot reproduce OP's problem. It may be related to `org-src-preserve-indentation' value. Regards, -- Nicolas Goaziou
Re: [O] org-blog 0.9 release
Matt Price writes: > On Wed, May 1, 2013 at 7:04 AM, Puneeth Chaganti wrote: >> On Wed, May 1, 2013 at 4:18 PM, Michael Alan Dorman >>> If you don't mind, I will start looking at the org2blog code and seeing >>> how cleanly I can implement these additional capabilities as handlers or >>> filters for the exporter---and then maybe we could look for that >>> back-end to live in contrib, and both our codebases could take advantage >>> of it? >> >> That seems like a good plan. I've been meaning to get this going for >> some time, but have been quite busy off-late. I'll try to make some >> time for it, soon. > > Was there ever any progress on this? I code so slowly I'd not likely > be much help with the actual implementation but would be happy to pull > from git and do some testing if that's of any use. Well, it's not an ex-parrot---which is to say, I still have the intention to work on it---but 1) my $DAYJOB has gotten busy, and 2) with many of the additional features being Wordpress-specific, it demands that I do some significant refactoring of my code for me to do it in a way that doesn't tie the whole thing to Wordpress. That said: Puneeth, it seems like most of your additional features are currently implemented as post-processing bits---could you just grab the new-exporter-based code that I have now and use that? It's not an all-singing, all-dancing solution, but it might get your users able to use 8.0 sooner. Mike.
Re: [O] Status fix for "Regression in fill-paragraph behavior"?
Hello, "Wagemans, Peter" writes: > In org 7.8.11 with emacs 24.2 fill-paragraph used to recognize > paragraph fill prefixes as usual for mail citations. This seems to be > no longer the case (which I noticed first with org 7.9.3 with emacs > 24.3). Apparently this has been noticed before and a bug reported, > according to > > > http://list-archives.org/2013/03/13/emacs-orgmode-gnu-org/o-regression-in-%60fill-paragraph-behavior/f/2446639327 > > On this page, Bastien says it has been fixed, to be included in 8.0. > However, in my setup 8.0.3 still doesn't do fill-paragraph as expected > for mail citations. Is the fix present in 8.0.3? If yes, is some > configuration needed in the new version to restore this functionality? > If no, is the fix available elsewhere? You can wrap your mail citation within a Verse block (or an example block). Regards, -- Nicolas Goaziou
Re: [O] org-element
Hello, Daimrod writes: > I'm playing a bit with org-element for org-contacts and I wanted to know > what is the prefered way to change an element. > > For example, ATM, when I want to change an element property to add a new > value, I do: > > #+BEGIN_SRC emacs-lisp > (org-entry-put nil property > (concat (org-entry-get nil property) > " " new-value)) > #+END_SRC See `org-element-put-property' and friends. Regards, -- Nicolas Goaziou
[O] Importing all files into .org document source blocks
Hi I would like to import all files in a directory into an org document, and each file should be in one source block, so that tangling the document, will result in all files created. My reasoning: I am using org-mode to keep track of installations on my machine (apt-get as well as other installs) to make it easier to re-install a new version of the Linux when necessary. Now apart from the installation commands, I also have to keep track of the installation sources. I was thinking of having them in the document, where each source (i.e. each file in /etc/apt/sources.list.d/.) has it's own source block, so that I can easily change the Ubuntu version and tangle the document to obtain the new sources. Now I am lazy, and adding each file manually is prone to errors (i.e. forgetting one). Therefore my question: Is there a way of importing all files in a directory (/etc/apt/sources/list.d/) into an org document, with each being in a separate code block? Thanks, Rainer -- Rainer M. Krug pgpMRzmiCTRVr.pgp Description: PGP signature
Re: [O] Org-mode styled beamer presentations
Eric S Fraga writes:
> Marcin Borkowski writes:
>
>>
>>
>> Hi list,
>>
>> many of you use Org-mode to create Beamer presentations. How about the
>> other way round? I wrote an Org-mode styled Beamer theme. Please use,
>> enjoy and report bugs and feature requests!
>>
>> https://twitter.com/marcin_mbork/status/335890494980767746
>> http://mbork.pl/2013-05-18_A_presentation_on_LaTeX_editing_%28en%29
>> https://github.com/mbork/beamerorgtheme
>>
>>
>>
>> Best,
>
> Very cute! I like it.
>
> Now I just need to customise it so that it matches my usual colour theme
> in Emacs which has a black background! Ahh, a perfect excuse to not get
> any more work done today ;-)
>
> thanks,
> eric
Well, that was too easy... see attached for a slightly different version
of your colour theme which gives black background with yellowish-white
foreground and red highlighting...
I guess I have to get back to work now! ;-)
In fact, I have a talk to prepare for next week. I think I'll use this
style! The audience should be sufficiently geeky to appreciate it for
once.
Thanks again,
eric
--
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.3-148-g36848f
%% beamercolorthemeorg.sty
%%
%% Copyright 2007 by Till Tantau and 2013 by Marcin Borkowski
%%
%% This beamer theme is based on Till Tantau's default Beamer theme,
%% with modifications by Marcin Borkowski.
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, version 1.3c,
% found in the file lppl.txt.
%
% This work has the LPPL maintenance status `maintained'.
%
% The Current Maintainer of this work is Marcin Borkowski .
%
% This work consists of the files:
% beamercolorthemeorg.sty
% beamerfontthemeorg.sty
% beamerinnerthemeorg.sty
% beamerouterthemeorg.sty
% beamerthemeorg.sty
% beamerthemeorg-demo.tex
\ProvidesPackage{beamercolorthemeorg}[2013/05/18 Org-inspired color theme for Beamer]
\mode
\usecolortheme{rose}
\definecolor{progressbar@oz}{rgb}{0.7765,0.2431,0.1882} % colour from the UCL Australia logo background
\setbeamercolor{background canvas}{bg=black,fg=white}
\usebeamercolor[fg]{background canvas}
\setbeamercolor*{normal text}{fg=yellow!20!white,bg=black}
\setbeamercolor*{alerted text}{fg=progressbar@oz}
\setbeamercolor{structure}{bg=black,fg=progressbar@oz}
\setbeamercolor{org keywords}{use=structure,fg=structure.fg!40!bg}
\setbeamercolor{org keywords dimmed}{use=structure,fg=structure.fg!80!bg}
\setbeamercolor{framesubtitle}{use=structure,fg=structure.fg!70!bg}
\setbeamercolor{dimmed text}{use=structure,fg=structure.fg!40!bg}
\setbeamercolor{alerted text}{use=palette secondary,fg=palette secondary.fg}
\newcommand<>{\dimmed}[1]{{\usebeamercolor{dimmed text}\color{fg}#1}}
\mode
Emacs food
% Local Variables:
% TeX-command-default: "LaTeX"
% TeX-master: "beamer-test.tex"
% End:
Re: [O] Org-mode styled beamer presentations
Marcin Borkowski writes: > > > Hi list, > > many of you use Org-mode to create Beamer presentations. How about the > other way round? I wrote an Org-mode styled Beamer theme. Please use, > enjoy and report bugs and feature requests! > > https://twitter.com/marcin_mbork/status/335890494980767746 > http://mbork.pl/2013-05-18_A_presentation_on_LaTeX_editing_%28en%29 > https://github.com/mbork/beamerorgtheme > > > > Best, Very cute! I like it. Now I just need to customise it so that it matches my usual colour theme in Emacs which has a black background! Ahh, a perfect excuse to not get any more work done today ;-) thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.3-148-g36848f
[O] Status fix for "Regression in fill-paragraph behavior"?
In org 7.8.11 with emacs 24.2 fill-paragraph used to recognize paragraph fill prefixes as usual for mail citations. This seems to be no longer the case (which I noticed first with org 7.9.3 with emacs 24.3). Apparently this has been noticed before and a bug reported, according to http://list-archives.org/2013/03/13/emacs-orgmode-gnu-org/o-regression-in-%60fill-paragraph-behavior/f/2446639327 On this page, Bastien says it has been fixed, to be included in 8.0. However, in my setup 8.0.3 still doesn't do fill-paragraph as expected for mail citations. Is the fix present in 8.0.3? If yes, is some configuration needed in the new version to restore this functionality? If no, is the fix available elsewhere? Regards, Peter Wagemans
Re: [O] (Potential) new feature for Org-mode: "hidden-lines cookies"
Hi Suvayu, Suvayu Ali wrote: > On Thu, May 23, 2013 at 10:39:03AM +0200, Sebastien Vauban wrote: >> Suvayu Ali wrote: >> >> Now I wonder if such a feature already exists in Org-mode (I would not >> >> be surprised, but I'm not aware of it) and if anybody would be >> >> interested in having such a feature? >> > >> > As per my understanding, there is no such feature; and as a user, I >> > would love it! >> >> It does exist in the "Org-mode clone for Vim", but not yet in Org... > > VimOrganizer although really cool, Never used it, but it looks like it's cool (on Vimeo)... > is not Emacs Org-mode ;). ... Yes, that's why that feature deserves to be in Emacs Org-mode as well! ;-) Best regards, Seb -- Sebastien Vauban
Re: [O] Using org to create a TOC for a compilation of separate PDF documents
Am Donnerstag, 23. Mai 2013, 23:48:03 schrieb Marcin Borkowski:
> Dnia 2013-05-23, o godz. 15:21:56
>
> John Hendy napisał(a):
> > I have a use case and am not sure if Org would help or not. I've
> > downloaded a bunch of technical data sheets on various materials from
> > a vendor. I'd like to create a "booklet" of them with a cover page
> > table of contents.
> >
> > I can create the booklet very easily with Stapler (or similar), but am
> > not sure on the best way to generate a clickable linked PDF of the
> > individual materials contained in the compiled document.[1] What I'm
> > not sure on is how to create a table of contents.
> >
> > Ideally, I could do something like generate a page count of each
> > document and then use this to create the page numbers I'd use to
> > create links to, which I thought I could do with Org. Even better
> > would be to have [back to top] links as well, since this will end up
> > being a multi-hundred page booklet (~100 documents of 2-4 pages each).
> >
> > Any thoughts on this?
> >
> > Is it easier to just generate a list of files and use Org to "include"
> > them somehow via LaTeX instead of using Stapler to combine them?
>
> I'd just use LaTeX's pdfpages package, possibly with hyperref. (If you
> encounter any problems, email me - I've done similar things before, so
> I guess I could help you.)
>
You don't have to do that manually. Some time ago members of the German TEX-D-
List put together a bash script, which takes all the PDFs recursivly and
creates a *.tex file:
#+begin_src bash
#!/bin/bash
#
# pdfdir OUTPUT_FILE
#
# produces one big PDF file of all PDF files in .
#
if [ $# -ne 1 ] || [ -z "$1" ]; then
echo "Syntax: pdfdir OUTPUT_FILE"
exit 1
fi
FILE="$(echo "$1"|sed -e 's/\.\(pdf\|tex\)$//')"
for F in "$FILE" "$FILE.tex" "$FILE.pdf" "$FILE.aux" "$FILE.log" ; do
if [ -e "$F" ]; then
echo "$F already exists."
exit 2
fi
done
cat >"$FILE.tex" /dev/null | sort
}
list_pdf_files () {
# " around filenames:
find -L "$1" -maxdepth 1 -mindepth 1 -name \*.pdf -o -name \*.PDF -type f
2>/dev/null | sort | \
sed -e 's/^/\\includepdf[pages=-]{"/; s/$/"}%/'
# without " around filenames:
# find -L "$1" -maxdepth 1 -mindepth 1 -name \*.pdf -o -name \*.PDF -type f
2>/dev/null | sort | \
# sed -e 's/^/\\includepdf[pages=-]{/; s/$/}%/'
}
tex_headline () {
echo "$1" | sed -e 's/_/\\_/g'
}
# folder level were we are (level 0):
list_pdf_files . >>"$FILE.tex"
# level 1:
list_directories . | while read -r DIR1; do
# Are there PDF files a level down?
exist_pdf_files "$DIR1" || continue
# Yes...
tex_headline "\section{${DIR1##*/}}%"
# ... those are ...:
list_pdf_files "$DIR1"
# Level 2:
list_directories "$DIR1" | while read -r DIR2; do
exist_pdf_files "$DIR2" || continue
tex_headline "\subsection{${DIR2##*/}}%"
list_pdf_files "$DIR2"
# Level 3:
list_directories "$DIR2" | while read -r DIR3; do
exist_pdf_files "$DIR3" || continue
tex_headline "\subsubsection{${DIR3##*/}}%"
list_pdf_files "$DIR3"
# Level 4:
list_directories "$DIR3" | while read -r DIR4; do
exist_pdf_files "$DIR4" || continue
tex_headline "\paragraph{${DIR4##*/}}%"
list_pdf_files "$DIR4"
# Level 5:
list_directories "$DIR4" | while read -r DIR5; do
exist_pdf_files "$DIR5" || continue
tex_headline "\subparagraph{${DIR5##*/}}%"
list_pdf_files "$DIR5"
done
done
done
done
done >>"$FILE.tex"
echo "\end{document}%" >>"$FILE.tex"
echo "Compile source now? [J/n]"
read -r ANSWER
case "$ANSWER" in
[JjYy]) ;;
*) exit 0 ;;
esac
pdflatex "$FILE"
[ $? -eq 0 ] && rm -f "$FILE.aux" "$FILE.log" "$FILE.tex"
#+end_src
I found that very helpfull, but I did not use it recently.
Regards,
Alexander
> > Thanks for any suggestions!
> > John
>
> Best,
book-from-PDF.sh
Description: application/shellscript
[O] Rendering of source code on worg
Hi, I think that the default rendering of source code on the worg side was closely resmbling the default rendering on emacs. I have the impression that somehow this is no longer the case, as visible a.o. at http://orgmode.org/worg/org-configs/org-config-examples.html Is this a deliberate choice? Guido -- Machine-independent program: A program that will not run on any machine.
Re: [O] [bug] org-capture fails with undefined org-time-was-given variable
Dear Nick & Bastien, Thanks for your responses. Both of you indicated that you don't have the problem with Emacs -Q. I don't either. Sorry, I should have tried a minimal example before posting. In any case, I have tracked down the offending line in my customisation that leads to the error: (setq org-popup-calendar-for-date-prompt nil) The default is t which allows my capture to work but I don't want a calendar popup. Note that there is a new name for this variable, org-read-date-popup-calendar but it makes no difference which name I use. I have tried tracing this through but have failed to figure out why the setting of this variable makes a difference. See below. > Org-mode version 8.0.3 (release_8.0.3-144-gbd09fe @ > /home/nick/elisp/org-mode/lisp/) > > That includes a bunch of private commits, but when I look at git history > I don't find the commit you mention in your org version, f1b99a, so > maybe you have your own bunch of private commits and one or more of them > broke something? Maybe try a vanilla org? My org *is* vanilla! I try to keep it as such. I live dangerously enough by tracking the development version on a relative frequent basis ... :-) It's very strange that you could not find the commit. But I have updated org since then unfortunately so cannot reproduce the situation. I am sending this email from a different system so it has a different org version (long story). > The variable is indeed not to be set by you: it's a dynamically scoped > variable, so somebody binds it at some level and then every callee > (direct or indirect) can access it. Stepping through > org-capture-set-location shows that it is unbound up until the call to > org-read-date (line 907-909 in org-capture.el) and it is bound on return > from that function, at least in my case. Yes. The only place I can find where the variable is actually given a value is in org-data-analyze (sic) but I can't figure out the trail that leads to this happening (it involves org-end-time-was-given). I may try later to see if I can figure this out. In any case, this is not mission critical in any sense! I was just surprised when the error happened. Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-101-gce5988
