Re: [O] Release 8.2

[Mike McLean]

On Sep 19, 2013, at 4:27 PM, Carsten Dominik  wrote:

> Microsoft Outlook support has been added to /org-mac-link.el/
> ~
> 
>  Thanks to Marc McLean for this patch.
> 


Probably way to late now, but “Mike McLean” (not Marc)

No worries.

[O] exporting to beamer error: "org-beamer--normalize-argument: Wrong type argument: stringp, nil"

[Rob Stewart]

Hi,

 I have followed this tutorial to export from org to beamer frames.
http://orgmode.org/worg/exporters/beamer/ox-beamer.html .
Unfortunately, the frames are not created for 2nd level headings.
Instead, subsections are used. I am using org-mode from the git
repository, pulled today using commit f871fb6 . I have tried both
org-export-to-pdf and org-beamer-export-to-pdf . The first is not
effective (LaTeX output below). The latter throws an error
"org-beamer--normalize-argument: Wrong type argument: stringp, nil" .

%% ORG FILE %
#+TITLE: Example Presentation
#+AUTHOR: Joe Bloggs
#+LATEX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: Madrid
#+OPTIONS: H:2

* First Section

** Frame 1

** Frame 2
%%%

STEP 2: M-x org-export-to-pdf

%% GENERATES %%
% Created 2013-10-02 Wed 23:24
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{amssymb}
\usepackage{hyperref}
\tolerance=1000
\author{Joe Bloggs}
\date{\today}
\title{Example Presentation}
\hypersetup{
  pdfkeywords={},
  pdfsubject={},
  pdfcreator={Emacs 24.3.1 (Org mode 8.2.1)}}
\begin{document}

\maketitle
\tableofcontents


\section{First Section}
\label{sec-1}

\subsection{Frame 1}
\label{sec-1-1}

\subsection{Frame 2}
\label{sec-1-2}
% Emacs 24.3.1 (Org mode 8.2.1)
\end{document}
%%%

Re: [O] Bug: dates in heading break beamer export

[Suvayu Ali]

On Wed, Oct 02, 2013 at 05:55:44PM +0200, Nicolas Goaziou wrote:
> Daniele Pizzolli  writes:
> 
> > Yes, I think is fair to drop the markup.
> 
> OK.
> 
> > I would also think that this is safe default when nested markup is
> > bad.
> 
> Do you have an exhaustive list of such cases?
> 
> > Maybe the exporter can emit a notice/warning.
> 
> That it dropped the markup?
> 
> > Yes, sorry, I mixed two not-so-related problem. The beamer exporter do
> > not work with this code:
> >
> > #+OPTIONS: H:3
> > * title test[fn:1]
> > ** section
> > *** subsection
> >
> > [fn:1] text
> 
> Of course, that's a similar problem: footnotes are not allowed in
> headlines. Though, in this case, it isn't possible to drop the markup.
> What LaTeX code do you suggest?

Strange, it seems to work for me.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Difficulties Accessing git Repository

[Suvayu Ali]

On Wed, Oct 02, 2013 at 01:50:45PM -0700, Josiah Schwab wrote:
> Hi orgmode.org overlords,
> 
> I just tried to pull from the main org-mode git repository.  I
> encountered the following failure.
> 
> ,
> | monolith:(stable) org-mode$ git pull 
> | fatal: read error: Connection reset by peer
> `
> 
> I checked and I am able to pull from worg.
> 
> ,
> | monolith:(master) worg$ git pull
> | Already up-to-date.
> `
> 
> The most conspicuous difference between the two is that my org-mode repo
> uses the git protocol while my worg repo uses the ssh protocol.  Since
> the issue appears to just affect the git protocol, developers may be
> less likely to notice.  Just wanted to bring it to your attention.

I can confirm this issue.  I successfully pulled earlier today though.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Yet another question about email and org-mode

[Suvayu Ali]

On Wed, Oct 02, 2013 at 11:24:18AM -0700, Josiah Schwab wrote:
> Hi Alan,
> 
> > I am happy to use native emacs mail, for sending email.  What I want to be
> > able to do is keep a copy of my email in an org-mode file.
> 
> Taking a step back, is there a reason that you want to keep a copy of
> the email contents in the org file, as opposed to including a link to
> the email message?

I would ask the same question.  Specially when Org supports so many URI
schemes for emails: gnus, mhe, rmail, notmuch, vm, vm-imap, wl.  Even
simple file links to maildirs would work too.  If you like the Gmail web
interface, linking to that is also possible!

-- 
Suvayu

Open source is the future. It sets us free.

[O] Difficulties Accessing git Repository

[Josiah Schwab]

Hi orgmode.org overlords,

I just tried to pull from the main org-mode git repository.  I
encountered the following failure.

,
| monolith:(stable) org-mode$ git pull 
| fatal: read error: Connection reset by peer
`

I checked and I am able to pull from worg.

,
| monolith:(master) worg$ git pull
| Already up-to-date.
`

The most conspicuous difference between the two is that my org-mode repo
uses the git protocol while my worg repo uses the ssh protocol.  Since
the issue appears to just affect the git protocol, developers may be
less likely to notice.  Just wanted to bring it to your attention.

Best,
Josiah

Re: [O] Bug: dates in heading break beamer export

[Marcin Borkowski]

Dnia 2013-10-02, o godz. 18:10:57
Daniele Pizzolli  napisał(a):

> > Of course, that's a similar problem: footnotes are not allowed in
> > headlines. Though, in this case, it isn't possible to drop the
> > markup. What LaTeX code do you suggest?
> 
> Mmm, I think you are asking to the wrong person.  I do not know enough
> about latex and its error reporting capabilities...

Well, LaTeX's error reporting capabilities are not very impressive...

> I would appreciate if the exporter does not break and/or a
> notification to the user of the problem in and understandable
> language, even for newcomers.
> 
> I know when latex do not know how to resolve some references put some
> question marks... but I do not really know if this is the case to
> follow this convention.

Well, this is something different: it basically means that either (a)
you need another run or (b) you messed up with the references.

> Regards,
> Daniele

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] AUCTeX key bindings within Org documents

[Marcin Borkowski]

Dnia 2013-10-02, o godz. 13:36:22
Nicolas Richard  napisał(a):

> Marcin Borkowski  writes:
> > C-c C-c was my idea - but now I've read this, I agree, this might be
> > not a brilliant one.  OTOH, C-c C-e got rebound to
> > org-auckeys-environment...  Dunno.
> 
> Could trigger export in org-ctrl-c-ctrl-c-final-hook, i.e. if nothing
> else worked.

This /seems/ to me a very good idea!

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

[O] Bug: org-open-at-point bug for radio targets [8.2 (8.2-6-gd745cd-elpa @ /home/ben/.emacs.d/elpa/org-20130930/)]

[ben]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


When I click on a radio target link I get the following error:

and: Wrong type argument: stringp, nil

I managed to fix the problem by changing this:

(and (string-match "^id:" link)
 (or (featurep 'org-id) (require 'org-id))
 (progn 
   (funcall (nth 1 (assoc "id" org-link-protocols))
(substring path 3))
   t))

to this:

(and link
 (string-match "^id:" link)
 (or (featurep 'org-id) (require 'org-id))
 (progn
   (funcall (nth 1 (assoc "id" org-link-protocols))
(substring path 3))
   t))

towards the end of the org-open-at-point function.
   
Emacs  : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2013-08-22 on louvi, modified by Debian
Package: Org-mode version 8.2 (8.2-6-gd745cd-elpa @ 
/home/ben/.emacs.d/elpa/org-20130930/)

Re: [O] Different OPTIONS according to export format

[Pascal Quesseveur]

  Thank you. So it is one reason to upgrade.


-- 
Pascal Quesseveur
pques...@gmail.com

Re: [O] Yet another question about email and org-mode

[Josiah Schwab]

Hi Alan,

> I am happy to use native emacs mail, for sending email.  What I want to be
> able to do is keep a copy of my email in an org-mode file.

Taking a step back, is there a reason that you want to keep a copy of
the email contents in the org file, as opposed to including a link to
the email message?

Best,
Josiah

Re: [O] Org Tutorials need more structure

[Alan E. Davis]

To be brief, the tutorials and other parts of the worg webpages could do
with some updating.   Org-mode has been through a good amount of evolution.


One isolated example is the "remember" tutorials.  These could, at the
least, be marked with a paragraph inset at the top of the file: a statement
that this feature has been supplanted by the "Capture" feature, but that
the tutorial is still useful for basic usage ideas.

IMHO

Alan


On Tue, Oct 1, 2013 at 6:10 PM, M  wrote:

> Hi Carsten & all,
>
> thanks for this good idea and the resulting discussion here!
>
> my 2 cents about the tutorials page:
> yes, I agree, that especially for absolute beginners (new to Emacs and new
> to org-mode) it would be helpful to have a very basic step by step
> tutorial.
> The list of "General introductions" is very long and quite confusing.
>
> How I came to using org-mode?
>
> I am a newby (at least I still feel like one, although I'm working with
> Emacs org-mode now for more than 1.5 years), so maybe my experience might
> help here.
>
> I was a GTD user at first using other "GUI oriented" GTD software like
> Thinking Rock, iGTD. iGTD had some problems and was not updated any more,
> so
> I started searching for a new tool  and found Charles Cave's GTD tutorials
> [1] (nearly 3 years ago, it seems!) and then started using org-mode since
> Jan 2012.
> I then found Bernt Hansen's excellent site and used his setup [2] for my
> first steps with org-mode, but it was very hard to adapt the agendas and
> settings to my needs (and I'm still struggling).
> Furthermore, Sacha Chua's blog is very interesting and I'm often looking at
> the worg tutorials page.
>
> So my first interest was todo/task/project management, but I quickly became
> interested in note-taking, exporting, attachments, dired, bookmarks,
> linking, ...
>
> My problems were (and still are):
> a) I am one of those users, which have never been really working with Emacs
> before, so at the beginning, it's very hard to understand the concept and
> basic commands.
> Many tutorials take for granted a lot of knowledge.
>
> b) I'm using two different OS's (Windows 7 at work and OS X 10.6 at home),
> each one has its own problems when setting up advanced features.
> It is especially difficult, to set up an efficient workflow to integrate MS
> Outlook (Mails/Calendar) and Emacs org-mode...
>
> c) I'm only an engineer, not a professional programmer. My knowledge about
> programming in general and elisp and Emacs configuration is still very
> limited, unfortunately. see a)
>
> [1] http://members.optusnet.com.au/~charles57/GTD/gtd_workflow.html
> [2] http://doc.norang.ca/org-mode.html
>
> Nevertheless thank you for this great tool and all the work you all put in
> maintaining, extending, documenting and helping!
> Org-mode changed my way of working and I never was so close to having a
> good
> and efficient system as I am now with org-mode. (as soon as long as I don't
> have to search for the solution of a problem :( )
>
> Kind regards
>
> Martin
>
>
> Carsten Dominik  gmail.com> writes:
>
> > and came away with the feeling that that this page has become
> > somewhat useless for people who are really new to Org.
> >
> > Can we have a discussion here on how this path should look like?
> > When you came to Org-mode as a newby, what were the three resources
> > that really made an impression on by being accessible and
> > providing feel and promise for digging deeper?
>
>
>
>
>

[O] Yet another question about email and org-mode

[Alan E. Davis]

I am happy to use native emacs mail, for sending email.  What I want to be
able to do is keep a copy of my email in an org-mode file.  This file could
be in datebook format, or just a  list, especially if I can tag each email
using org-mode tags.

The solutions I have seen for using org-mode for email seem convoluted,
complicated. I don't need any complicated html mail, just to start up a
mail buffer from org-mode---say, from a todo item, write the email, and
automatically leave a copy of the email behind when I am done.  Perhaps a
capture method would be useful, referring to bbdb for a lookup, although
that's another layer of complexity.

The beauty of org-mode is simplicity: simple text files.

Am I missing something?

Alan

Re: [O] Summary Blocks Time

[Eric S Fraga]

Carsten Dominik  writes:

[...]

>> This got me last week as well for clock reports.  Carsten's response was
>> to set
>> 
>> (setq org-time-clocksum-format "%d:%02d")
>
> So this is new behavior that broke with an earlier setting?  When did it 
> change, with 8.0?

Carsten,

I have no idea.  The last time I used clocking was probably two years
ago now...  and I don't use time in any of my non-clocking tables.

normally, I don't have to keep track of time but every now and again we
have to give a breakdown of how we spend our time at our
university... and org is ideal for that!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2-20-gc5f370

Re: [O] Bug: dates in heading break beamer export

[Daniele Pizzolli]

On 10/02/2013 05:55 PM, Nicolas Goaziou wrote:

Daniele Pizzolli writes:


Yes, I think is fair to drop the markup.


OK.


I would also think that this is safe default when nested markup is
bad.


Do you have an exhaustive list of such cases?


No, not really but I try to report them as soon I found them.  I do
want to replace latex entirely with org, so I will use it extensively
in the near future.


Maybe the exporter can emit a notice/warning.


That it dropped the markup?


Yes, I do not know if there is already a standard in reporting back
but I would go for something like "Latex-exporter: Warning: dropped
code markup at line XX of originalorgfile.org because it is not
supported by this exporter. More info at ..." or even a shorter one
can be fine to me.


Yes, sorry, I mixed two not-so-related problem. The beamer exporter do
not work with this code:

#+OPTIONS: H:3
* title test[fn:1]
** section
*** subsection

[fn:1] text


Of course, that's a similar problem: footnotes are not allowed in
headlines. Though, in this case, it isn't possible to drop the markup.
What LaTeX code do you suggest?


Mmm, I think you are asking to the wrong person.  I do not know enough
about latex and its error reporting capabilities...

I would appreciate if the exporter does not break and/or a
notification to the user of the problem in and understandable
language, even for newcomers.

I know when latex do not know how to resolve some references put some
question marks... but I do not really know if this is the case to
follow this convention.

Regards,
Daniele

Re: [O] Bug: dates in heading break beamer export

[Nicolas Goaziou]

Daniele Pizzolli  writes:

> Yes, I think is fair to drop the markup.

OK.

> I would also think that this is safe default when nested markup is
> bad.

Do you have an exhaustive list of such cases?

> Maybe the exporter can emit a notice/warning.

That it dropped the markup?

> Yes, sorry, I mixed two not-so-related problem. The beamer exporter do
> not work with this code:
>
> #+OPTIONS: H:3
> * title test[fn:1]
> ** section
> *** subsection
>
> [fn:1] text

Of course, that's a similar problem: footnotes are not allowed in
headlines. Though, in this case, it isn't possible to drop the markup.
What LaTeX code do you suggest?


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: dates in heading break beamer export

[Daniele Pizzolli]

On 10/02/2013 03:45 PM, Nicolas Goaziou wrote:

Hello,

Daniele Pizzolli writes:


In fact I use org-mode primarily to stay away from *tex
nuisances... and I think that I am not the only one.  I know enough
latex to find a workaround myself (not enough to offer a general
reliable solution) but I do not think that this will be a pleasant
experience for a newcomer or to somebody that choose org-mode for the
latex export capability.


Fair enough. What, exactly, do you suggest as generated LaTeX code?


Thanks Nicolas for following my arguments.


IIUC, you want to drop any markup for timestamps when located in
a headline, ignoring `org-latex-active-timestamp-format' and al. Am
I missing something else?


Yes, I think is fair to drop the markup.  I would also think that this
is safe default when nested markup is bad.
Maybe the exporter can emit a notice/warning.


BTW, the =verbatim=[fn:1] case is unrelated to export. See
`org-emphasis-regexp-components'.


Yes, sorry, I mixed two not-so-related problem.  The beamer exporter do not
work with this code:

#+OPTIONS: H:3
* title test[fn:1]
** section
*** subsection

[fn:1] text


The output is:
org-latex-compile: PDF file ./beamer-bug-footnote.pdf wasn't produced: 
[undefined control sequence] Runaway argument

The =verbatim=[fn:1] problem was discovered trying to find a
workaround for the footnotes in the headers...

Oh, in fact searching emphasis + footnote lead to some results.
The question hit this list periodically... so maybe it’s worth
documenting it better.  I will try found a general answer and
propose a patch for the docs.

It seems that I am going to drop latex nuisances to go into elisp
ones ;-)

Thanks again,
Daniele

Re: [O] Bug: dates in heading break beamer export

[Nicolas Goaziou]

Hello,

Daniele Pizzolli  writes:

> In fact I use org-mode primarily to stay away from *tex
> nuisances... and I think that I am not the only one.  I know enough
> latex to find a workaround myself (not enough to offer a general
> reliable solution) but I do not think that this will be a pleasant
> experience for a newcomer or to somebody that choose org-mode for the
> latex export capability.

Fair enough. What, exactly, do you suggest as generated LaTeX code?

IIUC, you want to drop any markup for timestamps when located in
a headline, ignoring `org-latex-active-timestamp-format' and al. Am
I missing something else?

BTW, the =verbatim=[fn:1] case is unrelated to export. See
`org-emphasis-regexp-components'.


Regards,

-- 
Nicolas Goaziou

Re: [O] Restore raw output in LaTeX export from in-line code block

[Eric Schulte]

Liam Healy  writes:

> On Sun, Sep 29, 2013 at 3:46 PM, Eric Schulte  wrote:
>> Liam Healy  writes:
>>
>>> I noticed that raw results from in-line code blocks were disappearing in
>>> the new LaTeX exporter, and bisected the repo to the change 7117ad4f92. I
>>> have created the attached patch to fix the problem and restore the previous
>>> behavior.
>>>
>>> example file
>>>   * Test
>>> 1. Inline common lisp raw: src_lisp[:results raw]{(+ 2 2)}, should
>>> say 4.
>>>
>>>
>>> Desired output, restored by patch
>>>   \item Inline common lisp raw: 4, should say 4.
>>> Output without patch
>>>\item Inline common lisp raw: , should say 4.
>>>
>>> If this looks right, please apply.
>>>
>>> Liam
>>>
>>
>> Hi Liam,
>>
>> You're actually noticing a symptom of an error in the way lisp code
>> blocks were handling results (conflating the output/results and the
>> scalar/vector distinction).  I've just pushed up a fix, please let me
>> know if you continue to see these types of errors.
>>
>> Best,
>>
>> --
>> Eric Schulte
>> https://cs.unm.edu/~eschulte
>> PGP: 0x614CA05D
>
> Thanks Eric. Indeed, your patches work to produce the correct output
> for that case. Now I have another problem. I'm really not interested
> in producing "4" of course, what I do is use lisp to produce LaTeX.
> For example,
>
> + Inline common lisp raw: $src_lisp[:results raw]{(format nil
> "\\sqrt{2~c" (code-char 125))}$, should say "$\sqrt{2}$".
>
> Which used to produce (Org-mode version 7.9.4) the right thing,
> \item Inline common lisp raw: $\sqrt{2}$, should say ``$\sqrt{2}$".
> and now (Org-mode version 8.2.1) doesn't evaluate the lisp,
> \item Inline common lisp raw: $src_lisp[:results raw]{(format nil
> "\\sqrt{2~c" (code-char 125))}$, should say "$\sqrt{2}$".
>
> Is this a bug? How do I restore the evaluation of the src_lisp in this 
> context?
>

When I export a file such as the following,

#+Options: ^:{}

inline src_lisp[:results raw]{(format nil "\\sqrt{2~c" (code-char 125))} works

I do find that inline code blocks are evaluated on export resulting in
the following.


 EXAMPLE-W-LISP



Table of Contents
─




inline "\\sqrt{2}" works

Are you able to interactively execute inline code blocks?

I'm not sure what the issue could be.

Best,

>
> Thanks.
> Liam

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] [Babel] :colnames "no" no longer default for Emacs Lisp [Was] Lisp error: (wrong-type-argument listp hline)

[Eric Schulte]

t...@tsdye.com (Thomas S. Dye) writes:

> Hi Eric,
>
> I think this breaks Marc-Oliver Ihm's lob-table-operations.org.
>
> I use these a lot with #+call: lines.
>
> Any tips on how to get the old behavior back?

You could add the following to your configuration which would replace
the previous default.

(add-to-list 'org-babel-default-header-args:emacs-lisp
 '(:colnames . "no"))
(add-to-list 'org-babel-default-header-args:emacs-lisp
 '(:hlines . "yes"))

You could also change the default emacs lisp header arguments for
certain files with property lines.

Best,

> I tried :colnames no with one of Marc-Oliver's code blocks, (and kept
> :colnames yes with my #+call: line) but this didn't seem to change
> anything. Instead of the column names from the original tables, which
> I used to get, I now get names like "t1c2".
>
> All the best,
> Tom
>
> Eric Schulte  writes:
>
>>>
>>> I always wondered why emacs-lisp is the _only_ language with ":colnames no" 
>>> as
>>> its default. Is there a reason therefore?  If no really good reason, could 
>>> we
>>> suppress that?
>>>
>>
>> This seemed to make sense early on because Emacs Lisp could easily
>> process hlines itself, but at this point it adds more confusion than it
>> is worth.  I've reverted this default for elisp, hopefully it doesn't
>> break too many peoples existing Org-mode files.
>>
>> Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] Summary Blocks Time

[Carsten Dominik]

On Oct 2, 2013, at 2:52 PM, Eric S Fraga  wrote:

> Gustav Wikström  writes:
> 
>>> Esben Stien  writes:
>>> 
 Any pointers as to how I can do this?
>>> 
>>> Got it;)
>>> 
>>> (setq org-time-clocksum-format '(:hours "%d" :require-hours t
>>> :minutes ":%02d" :require-minutes t))
>> 
>> Good find Esben!
>> 
>> Actually, this recent change to how clocksum is formated also brings
>> another problem. And that is when doing calculations with time. We have the
>> flags "t" and "T" to be able to do calculations in tables on times, but
>> with the new format presenting days calculations are no longer returning
>> the correct values.
>> 
>> Best regards
>> Gustav
> 
> This got me last week as well for clock reports.  Carsten's response was
> to set
> 
> (setq org-time-clocksum-format "%d:%02d")

So this is new behavior that broke with an earlier setting?  When did it 
change, with 8.0?

- Carsten

> 
> 
> -- 
> : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2-20-gc5f370
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Summary Blocks Time

[Eric S Fraga]

Gustav Wikström  writes:

>> Esben Stien  writes:
>>
>> > Any pointers as to how I can do this?
>>
>> Got it;)
>>
>> (setq org-time-clocksum-format '(:hours "%d" :require-hours t
>>  :minutes ":%02d" :require-minutes t))
>
> Good find Esben!
>
> Actually, this recent change to how clocksum is formated also brings
> another problem. And that is when doing calculations with time. We have the
> flags "t" and "T" to be able to do calculations in tables on times, but
> with the new format presenting days calculations are no longer returning
> the correct values.
>
> Best regards
> Gustav

This got me last week as well for clock reports.  Carsten's response was
to set

(setq org-time-clocksum-format "%d:%02d")


-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2-20-gc5f370

Re: [O] Org mode issue tracker

[Michael Albinus]

Brett Viren  writes:

> Hi,

Hi Brett,

>>   * TODO Subject  :emacs_ver:org_ver:org_module:
> ...
>> Emacs version ends up as a tag:
>>
>> * TODO  .   :24.3:
>
> Or, if I add an Org version:
>
>  * TODO  .   :24.3:8.0.3:
>
> These bare numbers seem a bit too anonymous to me.  I think it's
> unlikely that Org will reach versions in the 20's anytime soon so
> collision won't happen for a while but eventually (hackers willing!) it
> will.
>
> So, I suggest simply qualifying the versions like:
>
>   * TODO  .  :emacs_24.3:org_8.0.3:

>From the metadata retrieved from debbugs.gnu.org, we have just a list of
version strings. There is no indication about the meaning:

 (found_versions "24.3")

One could teach people to use also package names but mere version
numbers, but that's up to the package maintainer's will. So up to now
the strings provided by found_versions will be used as tags, until
there's a better rule for matching.

> I can also see a desire to list other software and their versions that
> might be implicated in the bug being reported.  Listing their bare
> versions as tags is, I think, obviously no good.  They could just
> include this info in an ad-hoc manner in the body of their report, but
> maybe it would be good to define a property to explicitly list them
> following the same _ pattern of the tags.
>
>   * TODO  .  :emacs_24.3:org_8.0.3:
> :PROPERTIES:
> :IMPLICATED_SOFTWARE: texlive_2012.20120611-5 beamer_3.10-2

The debbugs server returns also a list like

 (found
  (item
   (key . 24.3)
   (value)))

Maybe this could go the direction we want. Obviously, in this example
"key" should be Emacs, and "value" should be 24.3. Then we might also
get something like (if set properly by submitter or maintainer)

 (found
  (item
   (key . "emacs")
   (value . 24.3))
  (item
   (key . "org")
   (value . 8.0.3)))

The IMPLICATED_SOFTWARE property proposed by you could be derived from the

 (affects)

entry. But I haven't seen ever that somebody uses this attribute. It's
always empty, as shown in this example.

> -Brett.

Best regards, Michael.

Re: [O] org-debbugs.el

[Suvayu Ali]

On Wed, Oct 02, 2013 at 01:47:33PM +0200, Michael Albinus wrote:
> Michael Albinus  writes:
> 
> >> I tried to test by looking for a specific bug.  This is what I tried:
> >>
> >> - search phrase: emacsclient
> >> - submitter: fatkasuvayu (that is leading part of my email address)
> >> - status: done or nothing
> >>
> >> But then I get an empty "*Org Bugs*" buffer.
> >
> > Hmm, yes. But this seems to be a server side problem. If you apply the
> > same search via its web interface, you get the same empty result:
> >
> > 
> >
> > I'll investigate.
> 
> PS: You could bypass this restriction using the search phrase
> "emacsclient AND fatkasuvayu" (without quotes).

Okay, this works as expected.  :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] org-debbugs.el

[Suvayu Ali]

On Wed, Oct 02, 2013 at 01:44:36PM +0200, Michael Albinus wrote:
> Suvayu Ali  writes:
> 
> > A small problem though, calling org-debbugs-search or org-debbugs-bugs
> > from an "*Org Bugs*" buffer gives me the following backtraces:
> 
> Oops. Fixed, patch appended.

Problem fixed, confirmed :).

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] org-debbugs.el

[Michael Albinus]

Michael Albinus  writes:

>> I tried to test by looking for a specific bug.  This is what I tried:
>>
>> - search phrase: emacsclient
>> - submitter: fatkasuvayu (that is leading part of my email address)
>> - status: done or nothing
>>
>> But then I get an empty "*Org Bugs*" buffer.
>
> Hmm, yes. But this seems to be a server side problem. If you apply the
> same search via its web interface, you get the same empty result:
>
> 
>
> I'll investigate.

PS: You could bypass this restriction using the search phrase
"emacsclient AND fatkasuvayu" (without quotes).

Best regards, Michael.

Re: [O] org-debbugs.el

[Michael Albinus]

Suvayu Ali  writes:

> Hi Michael,

Hi Suvayu,

> I tried to test by looking for a specific bug.  This is what I tried:
>
> - search phrase: emacsclient
> - submitter: fatkasuvayu (that is leading part of my email address)
> - status: done or nothing
>
> But then I get an empty "*Org Bugs*" buffer.

Hmm, yes. But this seems to be a server side problem. If you apply the
same search via its web interface, you get the same empty result:



I'll investigate.

> A small problem though, calling org-debbugs-search or org-debbugs-bugs
> from an "*Org Bugs*" buffer gives me the following backtraces:

Oops. Fixed, patch appended.

Best regards, Michael.

>From c0214b63bc7a5e532a1c0fe06ebe3bb50f1a9b49 Mon Sep 17 00:00:00 2001
From: Michael Albinus 
Date: Wed, 2 Oct 2013 13:36:20 +0200
Subject: [PATCH] * org-debbugs.el (org-debbugs-mode-map): Move docstring where
 it belongs to.

---
 contrib/lisp/org-debbugs.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-debbugs.el b/contrib/lisp/org-debbugs.el
index 9c31b2b..fe5430e 100644
--- a/contrib/lisp/org-debbugs.el
+++ b/contrib/lisp/org-debbugs.el
@@ -409,11 +409,11 @@ returned."
 	  hits))
 
 (defconst org-debbugs-mode-map
-  "Keymap for the `org-debbugs-mode' minor mode."
   (let ((map (make-sparse-keymap)))
 (define-key map (kbd "C-c # c") 'debbugs-gnu-send-control-message)
 (define-key map (kbd "C-c # d") 'debbugs-gnu-display-status)
-map))
+map)
+  "Keymap for the `org-debbugs-mode' minor mode.")
 
 ;; Make byte-compiler quiet.
 (defvar gnus-posting-styles)
-- 
1.8.1.2

Re: [O] AUCTeX key bindings within Org documents

[Nicolas Richard]

Marcin Borkowski  writes:
> C-c C-c was my idea - but now I've read this, I agree, this might be
> not a brilliant one.  OTOH, C-c C-e got rebound to
> org-auckeys-environment...  Dunno.

Could trigger export in org-ctrl-c-ctrl-c-final-hook, i.e. if nothing
else worked.

-- 
Nico.

Re: [O] [BUG] in org-property-drawer-re?

[Thorsten Jolitz]

Nicolas Goaziou  writes:

Hello,

> Carsten Dominik  writes:
>
>> This is just a cheep way to match any character at all, because \000 should
>> not be part of any string (in C it indicates the end of a string).
>> In principle you could put any character you are sure will not turn up,
>> but \000 seems to be the safest choice.  It is
>> faster (I think) than "\\(.\\|\n\\)*" because the first will
>> just run fast and streight with a table lookup while the
>> latter need to always alternate between two alternatives.
>> I have not timed it, though.
>
> On that topic, I would add that "^\000" must be used with care, as it
> can lead to a stack overflow in regexp matcher error quite easily. In
> particular, it may be safe to use it to match a property drawer, which
> will not be very large, but I think it's wrong to use it to match
> regular blocks or drawers, which can have arbitrary long size.
>
> For example a regexp like "[^\000]\\." will fail when matching around
> 500 lines (72 characters long). Of course, constructs like
> "\\(.\\|\n\\)*\\." will also fail, but my point is that it is tempting
> to use "^\000" even though a regexp may not be the correct answer to the
> problem.

Conceptually it looks perfect(ly simple) to me, and I'm happy that I
discovered the pattern now by accident (better late than never), but
stack overflow is of course an important point.

Reminds me of my little [[https://github.com/tj64/org-hlc][org-hlc.el]]
library (hidden lines cookies)

,---
| org-hlc.el implements hidden-lines-cookies for Org-mode
|
| hidden-lines-cookies (hlc) are small cookies at the end of each folded (and
| visible) headline in an Org-mode buffer that show the number of hidden lines
| before the next visible headline.
|
| hidden-lines-cookies can be handled with three user commands:
| org-hlc-show-hidden-lines-cookies, org-hlc-hide-hidden-lines-cookies, and the
| convenience command org-hlc-toggle-hidden-lines-cookies that toggles between
| the two other commands conditional on the last one executed.
|
| The appearance of the cookies can be customized by changing the values of four
| customizable variables: org-hlc-hidden-lines-cookie-left-delimiter (with
| default value "["), org-hlc-hidden-lines-cookie-right-delimiter (with default
| value "]"), org-hlc-hidden-lines-cookie-left-signal-char (with default value
| "#") and org-hlc-hidden-lines-cookie-right-signal-char (with default value
| "").
|
| Thus an exemplary folded headline with 165 hidden lines before the next
| visible headline might look like this when hidden-lines-cookies are shown:
|
| ,- | *** Headline [#165] `-
|
`---

that was conceptually all 'wrong':

 - the cookies are written in the original buffer (but that could easily be
   changed to a temporary indirect buffer)
 - cookies are only shown/updated with explicit user commands

but it works even in 7000 lines .el or .org files. 

The other attempt to 'do it right' based on a library by Francois
Pinard, [[https://github.com/tj64/org-weights][org-weights.el]], uses
overlays and dynamic updates of the tree-weights via change hooks - much
better in theory - but somehow overwhelms Emacs capacities in big files
so that user experience is affected.

--
cheers,
Thorsten

Re: [O] [BUG] in org-property-drawer-re?

[Carsten Dominik]

On Oct 2, 2013, at 1:14 PM, Nicolas Goaziou  wrote:

> Carsten Dominik  writes:
> 
>> This is why the real matching Org does is first looking for a begin
>> line, and then for the END line, in two independent searches.
> 
> Not always: see `org-block-regexp' and `org-babel-src-block-regexp', for
> example.

I see.  Well, I guess so far we have not run into trouble, so we can save 
changing this of another time.

- Carsten

> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] AUCTeX key bindings within Org documents

[Nicolas Richard]

AW  writes:
> How can I get it switched on in every org-buffer automagically?

You can do this :
(add-hook 'org-mode-hook 'org-auctex-keys-minor-mode)

-- 
Nico.

Re: [O] multiple indirect buffers, and limiting to a drawer

[Thorsten Jolitz]

Matt Price  writes:

>> Although navigation inside the Org-modes buffers is quite convenient, its
>> somehow even more convenient to have a splitted screen and switch to the
>> read-only navi-buffer and use 1-key bindings for navigation, visibility
>> changes, all kinds of buffer views, and even a kind of remote control for
>> common copy, edit and search commands.
>>
>
> Wow, that is very cool.  I had never seen navi-mode before.  I  am
> looking at it and hoping I might be able to modify
> navi-narrow-to-subtree in a way that allows me to add a third window
> which will contain an indirect buffer, itself narrowed to the
> properties drawer for the current headline.  It seems like that might
> be possible?  I would need to figure out how navi-mode manages the
> window layouts, which I haven't looked at yet.


navi-mode only sets "twin-markers" in the code/org buffer and the navi-buffer
for quick buffer-switching. Its based on occur (i.e. replace.el), and there I
find something like: 

#+begin_src emacs-lisp
  (win (or (get-buffer-window buf)
   (display-buffer buf
   '(nil (inhibit-same-window . t)
 (inhibit-switch-frame . t)
#+end_src

and thats how its behaves: navi-buffer is not displayed in another frame, and
not in the same window as the code/org buffer. 

maybe my (constant) gnus window config (stolen somewhere) is helpful for you?


#+begin_src emacs-lisp
  ;  3 part window for Gnus
  (gnus-add-configuration '(article (horizontal 1.0 (vertical
  65 (group 1.0) ) (vertical 1.0 (summary 0.15 point) (article 1.0)
  
  
  (gnus-add-configuration '(summary (horizontal 1.0 (vertical
  65 (group 1.0) ) (vertical 1.0 (summary 1.0 point) 
#+end_src

`gnus-add-configuration' is defined in gnus-win.el. 

Here is what C-1 a (in *Navi-buffer*) shows me about this library, I
guess there are quite a lot of things to copy/reuse for you:

,-
|   1:;;; gnus-win.el --- window configuration functions for Gnus
|  23:;;; Commentary:
|  25:;;; Code:
|  32:(defgroup gnus-windows nil
|  36:(defcustom gnus-use-full-window t
|  41:(defcustom gnus-window-min-width 2
|  46:(defcustom gnus-window-min-height 1
|  51:(defcustom gnus-always-force-window-configuration nil
|  56:(defcustom gnus-use-frames-on-any-display nil
|  64:(defvar gnus-buffer-configuration
| 173:(defvar gnus-window-to-buffer
| 197:(defcustom gnus-configure-windows-hook nil
| 203:;;; Internal variables.
| 205:(defvar gnus-current-window-configuration nil
| 208:(defvar gnus-created-frames nil)
| 209:(defvar gnus-window-frame-focus nil)
| 211:(defun gnus-kill-gnus-frames ()
| 222:(defun gnus-add-configuration (conf)
| 228:(defvar gnus-frame-list nil)
| 230:(defun gnus-window-to-buffer-helper (obj)
| 240:(defun gnus-configure-frame (split &optional window)
| 358:(defvar gnus-frame-split-p nil)
| 360:(defun gnus-configure-windows (setting &optional force)
| 420:(defun gnus-delete-windows-in-gnusey-frames ()
| 438:(defun gnus-all-windows-visible-p (split)
| 479:(defun gnus-window-top-edge (&optional window)
| 483:(defun gnus-remove-some-windows ()
| 507:(defalias 'gnus-frames-on-display-list 'frames-on-display-list))
| 509:(defun gnus-frames-on-display-list ()
| 512:(defalias 'gnus-frames-on-display-list 'frame-list
| 514:(defun gnus-get-buffer-window (buffer &optional frame)
| 527:;;; gnus-win.el ends here
`-


-- 
cheers,
Thorsten

Re: [O] [BUG] in org-property-drawer-re?

[Nicolas Goaziou]

Carsten Dominik  writes:

> This is why the real matching Org does is first looking for a begin
> line, and then for the END line, in two independent searches.

Not always: see `org-block-regexp' and `org-babel-src-block-regexp', for
example.


Regards,

-- 
Nicolas Goaziou

Re: [O] [BUG] in org-property-drawer-re?

[Carsten Dominik]

On Oct 2, 2013, at 11:55 AM, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  writes:
> 
>> This is just a cheep way to match any character at all, because \000 should
>> not be part of any string (in C it indicates the end of a string).
>> In principle you could put any character you are sure will not turn up,
>> but \000 seems to be the safest choice.  It is
>> faster (I think) than "\\(.\\|\n\\)*" because the first will
>> just run fast and streight with a table lookup while the
>> latter need to always alternate between two alternatives.
>> I have not timed it, though.
> 
> On that topic, I would add that "^\000" must be used with care, as it
> can lead to a stack overflow in regexp matcher error quite easily. In
> particular, it may be safe to use it to match a property drawer, which
> will not be very large, but I think it's wrong to use it to match
> regular blocks or drawers, which can have arbitrary long size.
> 
> For example a regexp like "[^\000]\\." will fail when matching around
> 500 lines (72 characters long). Of course, constructs like
> "\\(.\\|\n\\)*\\." will also fail, but my point is that it is tempting
> to use "^\000" even though a regexp may not be the correct answer to the
> problem.

Yes, I agree.  This is why the real matching Org does is first looking for
 a begin line, and then for the END line, in two independent searches.
Much better and safer.

- Carsten


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Using Variable Width Fonts for org-mode and Fixed WidthforTablesss

[Ian Barton]

On 02/10/13 10:10, Alan Schmitt wrote:

Hi Ian,

li...@wilkesley.net writes:
ur help.

That sort of works. The fonts in org-table, etc are fixed pitch as
expected. However, I seem unable to set a variable width font using
text-mode-hook. Whatever font I choose Emacs ends up using DejaVu Sans
Mono.


Is it because the "variable-pitch-mode" is not set, or because the face
associated with it is not applied? What happens when you do a "M-x
variable-pitch-mode"?

Alan



Aha! As you suggest variable-pitch-mode isn't being set. Doing an "M-x 
variable-pitch-mode" sets the font correctly. So either text-mode-hook 
isn't being called, or something is resetting it.


[Time passes...]
Just had a look through my .emacs and I was using text-mode-hook later 
on to turn on autofill. So problem solved, thanks very much for your help.


Ian.

Re: [O] multiple indirect buffers, and limiting to a drawer

[Matt Price]

On Tue, Oct 1, 2013 at 1:19 PM, Thorsten Jolitz  wrote:
> Matt Price  writes:
>
> Hi,
>
>> (1) in a narrow window on the left, an outline of the whole org-file,
>> which I take to represent a major writing project
>>
>> (2) in the main window, a heading element in an indirect buffer
>>
>>
>> (3) in the right-hand panel, I'd like  to just show the properties
>> drawer of the currently active heading.
>>
>>
>> Can someone suggest the best way to create that third buffer (or more
>> precisely, that second indirect buffer)?  I guess I don't know the
>> best way to limit to a drawer, nor do I really understand how to make
>> multiple indirect buffers ( from what I can see,
>> org-tree-to-indirect-buffer will only permit one indirect buffer at a
>> time to be crate, which is fine, but which takes away the only tool I
>> sort of understand).
>>
>>
>> Another question: does emacs allow indirect buffers to have different
>> modes than their parents If so, I would like to write some trivial
>> minor modes that remap keybindings in each of the three windows, and
>> .e.g I would like to prohibit full unfolding of the outline in the
>> left-hand window if that's possible.
>
> Much of this is possible with
> [[https://github.com/tj64/navi][navi-mode.el]] (see screencast on
> [[http://www.youtube.com/watch?v%3DII-xYw5VGFM:][youtube]]), although
> you won't have 3 buffers, just 2: the Org file and the associated
> *Navi-buffer*, but the latter is very flexibel: with one key commands
> you can switch rapidly between multiple views of your Org file, change
> the visibility of the Org buffer, and more 'remote-control' like stuff.
>
> Just to give you an example using Bernt Hansen org-mode.org tutorial:
>
> 1. M-s n  -> fire up navi buffer showing level 1 headlines:
>
> ,
> | 19 matches for "^\* " in buffer: org-mode.org
> |  39:* Getting Started
> | 411:* Tasks and States
> | 566:* Adding New Tasks Quickly with Org Capture
> | 712:* Refiling Tasks ...
> `
>
> 2. move up and down with n an p, narrow and widen subtrees with r and w,
>change visibility of headline at point (whole buffer) with TAB (BACKTAB).
>use d to see the element at point in the Org-buffer, o (or s) to switch to
>it. use M-s M-s to switch back from Org-buffer to the navi-buffer.
>
> 3. type 2 or 3 to see headlines up to level 2 (3)
>
> ,--
> | 122 matches for "^\*\*? " in buffer: org-mode.org
> |  39:* Getting Started
> |  42:** Org-Mode Setup
> | 130:** Organizing Your Life Into Org Files
> | 184:** Agenda Setup
> | 233:** Org File Structure
> | 291:** Key bindings
> | 411:* Tasks and States
> | 425:** TODO keywords
> | 510:** Fast Todo Selection
> | 533:** TODO state triggers
> `--
>
> 4. type h to see all (currently) possible keyword-searches (and q to quit the
>help page)
>
> ,
> | [KEY] : [SEARCH]
> | 
> | b : srcblock
> | x : time
> | I : inline-srcblock
> | W : srcname-w-name
> | M : multilineheader
> | Y : priority
> | T : target
> | R : radiotarget
> | D : drawer
> | S : timestamp
> | N : srcname
> | U : result
> | Z : result-w-name
> | O : options
> | P : propertydrawer
> | A : deadline
> | H : scheduled-time-hour
> `
>
> 5. play around with the keyword searches, e.g. type b
>
> ,-
> |  51:#+begin_src emacs-lisp :tangle no
> |  65:#+begin_src emacs-lisp :tangle yes :exports none
> |  86:#+begin_src emacs-lisp :tangle yes
> | 103:#+begin_src emacs-lisp :tangle yes
> | 190:#+begin_src emacs-lisp :tangle no
> `-
>
>   type S
>
>,
>| 2130:  , SCHEDULED: <2009-05-18 Mon ++1w>
>| 3771:  ,   DEADLINE: <2009-07-01 Wed +1m -0d>
>| 3843:  ,  SCHEDULED: <2009-06-16 Tue +1w>
>| 4081:  ,  DEADLINE: <2009-07-01 Wed +1m -0d>
>| 4265:  ,   SCHEDULED: <2009-11-21 Sat .+7d/30d>
>`
>
>   and - for your use case - type P:
>
> ,
> |  43::PROPERTIES:
> |::CUSTOM_ID: Setup
> |::END:
> | 131::PROPERTIES:
> |::CUSTOM_ID: OrgFiles
> |::END:
> | 185::PROPERTIES:
> |   

Re: [O] org-debbugs.el

[Suvayu Ali]

Hi Michael,

On Wed, Oct 02, 2013 at 09:46:08AM +0200, Michael Albinus wrote:
> Michael Albinus  writes:
> 
> Hi,
> 
> > I have produced a very first shot of org-debbugs.el. It shows you bug
> > reports from debbugs.gnu.org as TODO items. It needs the debbugs package
> > from the GNU ELPA repository.
> 
> Well, there hasn't been too much response for this. I have completed the
> work anyway. Maybe it is worth to say, that the package does not show
> org-mode bugs only. It could show any bug located on debbugs.gnu.org as
> TODO item.

I was wondering about the response myself.  The traffic has been high
lately, maybe people just overlooked.

> Compared with the first version, this package uses now tags similar to
> the proposal by Suvayu. It also shows archived bugs, if desired.
> 
> There is a new minor mode org-debbugs-mode, which allows to send control
> messages directly to debbugs.gnu.org. This simplifies handling of bugs.
> 
> There are also two new commands: `org-debbugs-search' allows full text
> search on debbugs.gnu.org. `org-debbugs-bugs' shows bugs according to
> their number. Read the Commentary section for details.

I tried to test by looking for a specific bug.  This is what I tried:

- search phrase: emacsclient
- submitter: fatkasuvayu (that is leading part of my email address)
- status: done or nothing

But then I get an empty "*Org Bugs*" buffer.

I was expecting this: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15222

Calling org-debbugs-bugs with 15222 works great.

A small problem though, calling org-debbugs-search or org-debbugs-bugs
from an "*Org Bugs*" buffer gives me the following backtraces:

Debugger entered--Lisp error: (wrong-type-argument keymapp "Keymap for the 
`org-debbugs-mode' minor mode.")
  where-is-internal(org-debbugs-search nil t)
  execute-extended-command(nil "org-debbugs-search")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Debugger entered--Lisp error: (wrong-type-argument keymapp "Keymap for the 
`org-debbugs-mode' minor mode.")
  where-is-internal(org-debbugs-bugs nil t)
  execute-extended-command(nil "org-debbugs-bugs")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

> If the org-mode maintainers find this package useful, it could be added
> to the contrib directory. A respective patch is appended. I'm pretty
> sure that org-mode aficionados could improve the handling of TODO items;
> I'm rather a rookie wrt org-mode. If there are questions wrt to the
> gnus.debbugs.org interface I'll be happy to help.

I think this is a great addition to contrib.

:)

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] [BUG] in org-property-drawer-re?

[Nicolas Goaziou]

Hello,

Carsten Dominik  writes:

> This is just a cheep way to match any character at all, because \000 should
> not be part of any string (in C it indicates the end of a string).
> In principle you could put any character you are sure will not turn up,
> but \000 seems to be the safest choice.  It is
> faster (I think) than "\\(.\\|\n\\)*" because the first will
> just run fast and streight with a table lookup while the
> latter need to always alternate between two alternatives.
> I have not timed it, though.

On that topic, I would add that "^\000" must be used with care, as it
can lead to a stack overflow in regexp matcher error quite easily. In
particular, it may be safe to use it to match a property drawer, which
will not be very large, but I think it's wrong to use it to match
regular blocks or drawers, which can have arbitrary long size.

For example a regexp like "[^\000]\\." will fail when matching around
500 lines (72 characters long). Of course, constructs like
"\\(.\\|\n\\)*\\." will also fail, but my point is that it is tempting
to use "^\000" even though a regexp may not be the correct answer to the
problem.


Regards,

-- 
Nicolas Goaziou

Re: [O] multiple indirect buffers, and limiting to a drawer

[Matt Price]

On Tue, Oct 1, 2013 at 5:37 PM, Myles English  wrote:
>
> Hi Matt,
>
> mopto...@gmail.com writes:
>
>> (3) in the right-hand panel, I'd like  to just show the properties
>> drawer of the currently active heading.
>>
>>
>> Can someone suggest the best way to create that third buffer (or more
>> precisely, that second indirect buffer)?
>
> I can't, but your description of a windowed layout sounds like
> workgroups ( https://github.com/tlh/workgroups.el ), may be you can
> reuse some code?

that looks interesting and certainly more sophisticateed than what I
had put together, I'll check it out.
>
> Myles
>
>

Re: [O] multiple indirect buffers, and limiting to a drawer

[Matt Price]

On Tue, Oct 1, 2013 at 3:28 PM, Bob Newell  wrote:
> Aloha Matt,
>
> For some while I've been also working on my "writer-mode" for org-mode,
> and run into similar problems. (However, I don't think I ever intend
> writer-mode for general release; it will probably just remain something
> I use myself.)
>
> I ran into similar problems, trying to emulate Scrivener and others. I
> only seem to be able to figure out a thin nav panel on the left and a
> bigger text panel on the right. I didn't get around the problem with
> virtual buffers having the same modal properties as the main buffer. In
> particular, buffer-local key bindings carry over from the index buffer
> to the main buffer, which is A Royal Pain.

This in particular is something I wish could be solved.  Just reading
the documentation it looks as though using "mike-indirect-buffer"
instead of "clone-indirect-buffer" will permit one to set all the
modal properties of the new buffer independently, though it may be
frustrating to address the indirect bufffer in a function called from
the first buffer (maybe not, though?).  cf.
http://www.gnu.org/software/emacs/manual/html_node/elisp/Indirect-Buffers.html
and http://www.emacswiki.org/emacs/IndirectBuffers
>
> But perhaps I'm looking for different features than you are. Mainly, I
> wanted a template system for scenes, characters, etc. (easy enough), a
> lot of statistics, both global and per-story (not conceptually difficult
> but took much time), and a good darkroom mode (much more of a challenge
> than I expected, and seems to vary among environments/releases, etc.;
> that is to say, most of the published emacs darkroom code didn't work
> for me).
>
> I've also got some fluff such as typing sounds, word frequency analysis,
> a name generator, etc.
>
> It's nothing special but I use it every day. However, I'm more than
> willing to throw it over and use your code once it's developed! I'm sure
> you're coding it much, much better and with concepts that are better
> thought through.

That sounds pretty great, actually.  So, I would love to see what you have.

>
> A hui hou,
>
> --
> Bob Newell
> Honolulu, Hawai`i
lucky!

Re: [O] Using Variable Width Fonts for org-mode and Fixed WidthforTablesss

[Alan Schmitt]

Hi Ian,

li...@wilkesley.net writes:

> That sort of works. The fonts in org-table, etc are fixed pitch as 
> expected. However, I seem unable to set a variable width font using 
> text-mode-hook. Whatever font I choose Emacs ends up using DejaVu Sans 
> Mono.

Is it because the "variable-pitch-mode" is not set, or because the face
associated with it is not applied? What happens when you do a "M-x
variable-pitch-mode"?

Alan

Re: [O] Using Variable Width Fonts for org-mode and Fixed Width forTabless

[Ian Barton]

On 27/09/13 08:19, Alan Schmitt wrote:

Hi Ian,

li...@wilkesley.net writes:


I am struggling to get this to work. In my init files I have:

(set-default-font "DejaVu Serif Italic")

I have followed the advice on StackOverflow
http://stackoverflow.com/questions/3758139/variable-pitch-for-org-mode-fixed-pitch-for-tables
and customized my Init file to include:

(set-face-attribute 'org-table nil :inherit 'fixed-pitch)

However, table formatting is still screwed up. C-u C-x = shows

  xft:-unknown-IM FELL DW
Pica-normal-italic-normal-*-15-*-*-*-*-0-iso10646-1 (#x29)

Character code properties: customize what to show
name: LATIN CAPITAL LETTER F
general-category: Lu (Letter, Uppercase)
decomposition: (70) ('F')

There are text properties here:
face org-table
fontifiedt
line-prefix  [Show]
wrap-prefix  [Show]

I have tried setting the font for org-table using Emacs Customize
Interface, but without any success. Ideally I want tables to use a
monospace font like Inconsolata or DejaVu mono. Can anyone provide an
example of how to set org-table to use a specified fixed width font.


I've played a little with this, and here is what I have (straight from
my config file).

First, I set up the font for variable pitch, and I tell emacs to use it
for text modes.

** setup
#+BEGIN_SRC emacs-lisp
   (set-face-attribute 'variable-pitch nil :family "Ubuntu")
   (set-face-attribute 'variable-pitch nil :height 140)

   (add-hook 'text-mode-hook 'variable-pitch-mode)
#+END_SRC

Then I set up exceptions for some faces in some modes. I have exceptions
for info, mu4e, and org mode. Here are the ones for org mode.

** org
from 
http://yoo2080.wordpress.com/2013/05/30/monospace-font-in-tables-and-source-code-blocks-in-org-mode-proportional-font-in-other-parts/

#+BEGIN_SRC emacs-lisp
   (defun my-adjoin-to-list-or-symbol (element list-or-symbol)
 (let ((list (if (not (listp list-or-symbol))
 (list list-or-symbol)
   list-or-symbol)))
   (require 'cl-lib)
   (cl-adjoin element list)))

   (mapc
(lambda (face)
  (set-face-attribute
   face nil
   :inherit
   (my-adjoin-to-list-or-symbol
'fixed-pitch
(face-attribute face :inherit
(list 'org-code 'org-block 'org-table 'org-block-background 'org-date 
'org-link 'org-footnote))
#+END_SRC

What this says is: use fixed-pitch for the faces in the list at the
end. I have to include dates, links, and footnotes because I use them in
tables and I don't know how to conditionally change a face (i.e., use
fixed-pitch for links in tables but not for links in other places).

Hopefully this will work for you.

Alan


Hi Alan,

That sort of works. The fonts in org-table, etc are fixed pitch as 
expected. However, I seem unable to set a variable width font using 
text-mode-hook. Whatever font I choose Emacs ends up using DejaVu Sans 
Mono. I have tried several fonts that Emacs should be able to use by 
listing them with (print (font-family-list)).


If I set the font instead using set-default-font org-table, etc claim 
they are using a fixed pitch font, but they don't look as though they are.


Ian.

Re: [O] org-debbugs.el

[Michael Albinus]

Michael Albinus  writes:

Hi,

> I have produced a very first shot of org-debbugs.el. It shows you bug
> reports from debbugs.gnu.org as TODO items. It needs the debbugs package
> from the GNU ELPA repository.

Well, there hasn't been too much response for this. I have completed the
work anyway. Maybe it is worth to say, that the package does not show
org-mode bugs only. It could show any bug located on debbugs.gnu.org as
TODO item.

Compared with the first version, this package uses now tags similar to
the proposal by Suvayu. It also shows archived bugs, if desired.

There is a new minor mode org-debbugs-mode, which allows to send control
messages directly to debbugs.gnu.org. This simplifies handling of bugs.

There are also two new commands: `org-debbugs-search' allows full text
search on debbugs.gnu.org. `org-debbugs-bugs' shows bugs according to
their number. Read the Commentary section for details.

If the org-mode maintainers find this package useful, it could be added
to the contrib directory. A respective patch is appended. I'm pretty
sure that org-mode aficionados could improve the handling of TODO items;
I'm rather a rookie wrt org-mode. If there are questions wrt to the
gnus.debbugs.org interface I'll be happy to help.

Best regards, Michael.

>From 6f002a1da1835625cd7451da2aaa4699254a6372 Mon Sep 17 00:00:00 2001
From: Michael Albinus 
Date: Wed, 2 Oct 2013 09:28:50 +0200
Subject: [PATCH] Add org-debbugs.el.

---
 contrib/README  |   1 +
 contrib/lisp/org-debbugs.el | 455 
 2 files changed, 456 insertions(+)
 create mode 100644 contrib/lisp/org-debbugs.el

diff --git a/contrib/README b/contrib/README
index bdbdb47..6aba0d6 100644
--- a/contrib/README
+++ b/contrib/README
@@ -22,6 +22,7 @@ org-collector.el --- Collect properties into tables
 org-colview-xemacs.el	 --- Column View in Org-mode, XEmacs-specific version
 org-contacts.el  --- Contacts management
 org-contribdir.el--- Dummy file to mark the org contrib Lisp directory
+org-debbugs.el   --- Org-mode interface for the GNU bug tracker
 org-depend.el--- TODO dependencies for Org-mode
 org-drill.el --- Self-testing with org-learn
 org-element.el   --- Parser and applications for Org syntax
diff --git a/contrib/lisp/org-debbugs.el b/contrib/lisp/org-debbugs.el
new file mode 100644
index 000..9c31b2b
--- /dev/null
+++ b/contrib/lisp/org-debbugs.el
@@ -0,0 +1,455 @@
+;;; org-debbugs.el --- Org-mode interface for the GNU bug tracker
+
+;; Copyright (C) 2013 Free Software Foundation, Inc.
+
+;; Author: Michael Albinus 
+;; Keywords: comm, hypermedia, maint, outlines
+
+;; This file is not part of GNU Emacs.
+
+;; This program is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see .
+
+;;; Commentary:
+
+;; This package provides an interface to bug reports which are located
+;; on the GNU bug tracker debbugs.gnu.org.  Its main purpose is to
+;; show and manipulate bug reports as org-mode TODO items.
+
+;; If you have `org-debbugs.el' in your load-path, you could enable
+;; the bug tracker commands by the following lines in your ~/.emacs
+;;
+;;   (autoload 'org-debbugs "org-debbugs" "" 'interactive)
+;;   (autoload 'org-debbugs-search "org-debbugs" "" 'interactive)
+;;   (autoload 'org-debbugs-bugs "org-debbugs" "" 'interactive)
+
+;; The bug tracker is called interactively by
+;;
+;;   M-x org-debbugs
+
+;; It asks for the severities, for which bugs shall be shown. This can
+;; be either just one severity, or a list of severities, separated by
+;; comma.  Valid severities are "serious", "important", "normal",
+;; "minor" or "wishlist".  Severities "critical" and "grave" are not
+;; used, although configured on the GNU bug tracker.  If no severity
+;; is given, all bugs are selected.
+
+;; If a prefix is given to the command, more search parameters are
+;; asked for, like packages (also a comma separated list, "org-mode" is
+;; the default), or whether archived bugs shall be shown.
+
+;; Another command is
+;;
+;;   M-x org-debbugs-search
+
+;; It behaves like `org-debbugs', but asks at the beginning for a
+;; search phrase to be used for full text search.  Additionally, it
+;; asks for key-value pairs to filter bugs.  Keys are as described in
+;; `debbugs-get-status', the corresponding value must be a regular
+;; expression to match for.  The other parameter

Re: [O] Needing help on org-gnus + LaTeX export -

[Joseph Vidal-Rosset]

2013/10/2 Suvayu Ali 

> These variables are from the old exporter.  See:
>
>   
>   
>   
>
> or the manual.
>

Many thanks. It works fine now. Org-mode is really amazing !!!

I am very happy and enthusiastic with these first results !

Best wishes,

Jo.