Re: [O] Org-agenda - show content outline from multiple org files

[Avner Moshkovitz]

Hi Bernt,

Sorry for the long delay - I couldn't find a way to edit the post (I don't have 
an account).

Yes, this is what I was looking for.
I also added the functions below to step through the headings and open them in 
different buffer

Thanks for the help.

Avner

-

(defun org-agenda-show1 (&optional full-entry)
  "Display the Org-mode file which contains the item at point.
With prefix argument FULL-ENTRY, make the entire entry visible
if it was hidden in the outline."
  (interactive "P")
  (let ((win (selected-window)))
(if full-entry
(let ((org-show-entry-below t))
  (org-agenda-goto1 t))
  (org-agenda-goto1 t))
)
  )

(defun org-agenda-goto1 (&optional highlight)
  "Go to the Org-mode file which contains the item at point."
  (interactive)
  (let* ((marker (or (org-get-at-bol 'org-marker)
 (org-agenda-error)))
 (buffer (marker-buffer marker))
 (pos (marker-position marker)))
(other-frame 1)
(switch-to-buffer buffer)
(widen)
(goto-char pos)
(when (org-mode-p)
  (org-show-context 'agenda)
  (save-excursion
(and (outline-next-heading)
 (org-flag-heading nil ; show the next heading
(recenter (/ (window-height) 2))
(run-hooks 'org-agenda-after-show-hook)
(and highlight (org-highlight (point-at-bol) (point-at-eol)


(defun org-next-agenda-item2 ()
  (interactive)
  (setq display-buffer-reuse-frames t)
  (pop-to-buffer "*Org Agenda* headings")
  (next-line-nomark)
  (org-agenda-show1)
  (pop-to-buffer "*Org Agenda* headings")
  )

(defun org-prev-agenda-item2 ()
  (interactive)
  (setq display-buffer-reuse-frames t)
  (pop-to-buffer "*Org Agenda* headings")
  (previous-line-nomark)
  (org-agenda-show1)
  (pop-to-buffer "*Org Agenda* headings")
  )

(global-set-key [C-f11] 'org-next-agenda-item2)
(global-set-key [C-S-f11] 'org-prev-agenda-item2)



-Original Message-
From: Bernt Hansen [mailto:be...@norang.ca]
Sent: June 26, 2012 6:25 PM
To: Avner
Cc: emacs-orgmode@gnu.org; Avner Moshkovitz
Subject: Re: Org-agenda - show content outline from multiple org files

"Avner"  writes:

> I have a list of org files associated with org-agenda.
>
> In the Org-Agenda buffer, I want to have a outline content view that
> shows the headings from all the files.
>
> In org-agenda, I can apply "search for keywords" (s) and "Multi-occur"
> (/) to present all the headings, which I can then visit in the org
> file buffer
>
> However, these headings are shown as regular strings. What I'm looking
> for, is a way to present them in color, and indentation according to
> the heading level, similar to the "contents" presentation in the org
> file itself.

Hi Avner,

Maybe this is close to what you are looking for?

(setq org-tags-match-list-sublevels t)
C-c a m LEVEL<4 RET

should show levels 1-3 in all files with sublevels indented.  Sorting by 
priorities and things is going to mess up the order in the list.

For me only the TODO keywords are coloured and indentation is done with leading 
dots in the agenda view but you can visit and modify the headings directly from 
the agenda.

HTH.

Regards,
Bernt

This e-mail may contain information that is privileged, confidential or 
otherwise exempt from disclosure under applicable laws. Unauthorized use, 
reproduction or dissemination of the e-mail is strictly prohibited. If you have 
received this e-mail in error, please contact the sender immediately. 
[11EABB509DF]

[O] [Assistance Needed] View only prioritized items that have a deadline or or scheduled

[Andre Powell]

I was wondering if someone could help me out with the following. I am
trying to create a custom agenda view that shows me items that have a
priority and either a scheduled date or deadline. This is what I have tried
but it does not seem to work.

("x" "Daily Scheduled Task" tags-todo "+PRIORITY={A\\|B\\|C}"
((org-agenda-skip-function (quote (org-agenda-skip-entry-if (quote
notscheduled) (quote notdeadline))


The ideal situation would be to have task show up  that are scheduled to
begin either today or before today.


Thanks in advance for any assistance provided.
-- 
Andre

Re: [O] org-table not wrapped in table

[Thomas S. Dye]

Aloha Bjarte,

Did you add a #+CAPTION: and #+LABEL: to your table?

See
http://orgmode.org/manual/Tables-in-LaTeX-export.html#Tables-in-LaTeX-export

If that doesn't work for you, please provide an ECM (Minimal Complete
Example).  

All the best,
Tom

Bjarte Johansen  writes:

> Is there a reason the org-table does not get wrapped in a
> \begin{table}[ht] in latex and only tabular? For scientific papers it
> is usually nice to be able to add label and caption to the table in
> the same way images/figures have.
>
>
> Right now I just wrapped it in #+BEGIN_table myself and added \caption 
> \label. 
> --
> Bjarte
>

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Export to Texinfo

[Jonathan Leech-Pepin]

On 31 July 2012 18:35, Jonathan Leech-Pepin
 wrote:
> On Tue, Jul 31, 2012 at 5:18 PM, Nicolas Goaziou  wrote:
>> Hello,
>>
>> Jonathan Leech-Pepin  writes:
>>
>>> I've done some further work on the org-e-texinfo exporter and have
>>> gotten it to a point where it should be usable with only a few
>>> shortcomings.
>>
>> Thanks for your work. I hope that you will get feedback on it.
>>
>>> - Two-column tables are restricted to a single "indicating" command,
>>>   defined by ~org-e-texinfo-def-table-markup~.  I'm not sure how to
>>>   get around these limitations since they are created from description
>>>   lists (which do not recognize #+attr lines).
>>
>> What makes you think they don't?  Plain lists accept affiliated
>> keywords, items don't.
>>
> I thought I'd tested them against a plain list when trying to find a
> way around that limitation.  I'll have to try again tomorrow so that I
> can eliminate the limitations still present regarding descriptive
> lists.

I've just added changes to make use of #+attr_texinfo: with
descriptive lists.  Thank you for making me revisit this.  It accepts
two attributes at the moment:

- :table-type :: This accepts one of the following: "table" "ftable"
"vtable".  If the value is not one of these it will default to "table"
- :indic :: This is the markup to be used on the first column of the
table.  It requires the "@" prefix to the command to be used.

>>> Prior to exporting the following must be evaluated:
>>>
>>>   (add-to-list 'org-export-snippet-translation-alist
>>>'("info" . "e-texinfo"))
>>
>> Again, this is an user-oriented variable. You don't need it to accept
>> @@info:...@@ export snippets and you shouldn't require the user to set
>> it.
>>
> Usually no, but the sample (orgguide.org) document uses @@info:...@@
> to create @kbd, @key and @samp output, without it the document will
> fail to export correctly (especially since @ is used for texinfo
> commands).
>
> I suppose I should have clarified that those two commands were
> required prior to exporting that specific document (for testing and
> demonstration purposes).
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>
> Regards,
>
> Jon
>

Regards,

Jon

Re: [O] Emacs23 on Ubuntu recognizes 'remember', not 'capture'

[Olaf Meeuwissen]

Bastien  writes:

> Hi Rian,
>
> Rian Murphy  writes:
>
>> Would I have to somehow uninstall emacs 23 and install emacs 22? 
>> Any other ideas?  
>
> My simple suggestion is to install GNU Emacs 24.1 in all your computers.

Or install Ubuntu's separately packaged org-mode package.  The emacs23
package on Ubuntu and Debian ships with the bundled org-mode version
(6.33, IIRC).  The org-mode package is significantly newer, 7.x.  The
only glitch I've encountered is with accessing the info pages, but you
can work around that by modifying Info-directory-list.

> It contains a more recent Org (> 7.8), which lets you use `org-capture'
> everywhere.

The org-mode package supports org-capture just fine.

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962   Help support software freedom
 http://www.fsf.org/jf?referrer=1962

Re: [O] org-fill-paragraph invoked on column 0

[Nicolas Goaziou]

Hello,

Michael Brand  writes:

> In my override my-org-fill-paragraph, improved over the one in an
> earlier post I use
>
> #+BEGIN_SRC emacs-lisp
>   (save-excursion
> (org-end-of-item)
> (re-search-backward "[^[:space:]]")
> ;; [...]
> #+END_SRC
>
> to achieve this.

It doesn't work as you expect. Try it with the following example:

--8<---cut here---start->8---
- line 1
  line 2

  line 3
  line 4
--8<---cut here---end--->8---


Regards,

-- 
Nicolas Goaziou

Re: [O] Export to Texinfo

[Jonathan Leech-Pepin]

On Tue, Jul 31, 2012 at 5:18 PM, Nicolas Goaziou  wrote:
> Hello,
>
> Jonathan Leech-Pepin  writes:
>
>> I've done some further work on the org-e-texinfo exporter and have
>> gotten it to a point where it should be usable with only a few
>> shortcomings.
>
> Thanks for your work. I hope that you will get feedback on it.
>
>> - Two-column tables are restricted to a single "indicating" command,
>>   defined by ~org-e-texinfo-def-table-markup~.  I'm not sure how to
>>   get around these limitations since they are created from description
>>   lists (which do not recognize #+attr lines).
>
> What makes you think they don't?  Plain lists accept affiliated
> keywords, items don't.
>
I thought I'd tested them against a plain list when trying to find a
way around that limitation.  I'll have to try again tomorrow so that I
can eliminate the limitations still present regarding descriptive
lists.

>> Prior to exporting the following must be evaluated:
>>
>>   (add-to-list 'org-export-snippet-translation-alist
>>'("info" . "e-texinfo"))
>
> Again, this is an user-oriented variable. You don't need it to accept
> @@info:...@@ export snippets and you shouldn't require the user to set
> it.
>
Usually no, but the sample (orgguide.org) document uses @@info:...@@
to create @kbd, @key and @samp output, without it the document will
fail to export correctly (especially since @ is used for texinfo
commands).

I suppose I should have clarified that those two commands were
required prior to exporting that specific document (for testing and
demonstration purposes).
>
> Regards,
>
> --
> Nicolas Goaziou

Regards,

Jon

Re: [O] org-fill-paragraph invoked on column 0

[Nicolas Goaziou]

Hello,

Michael Brand  writes:

> Thanks. It works except for description list. My requirement is that
> it works even with unusually placed "::" which work already when point
> is within the item body:
>
>   - cmd --log-level=wrn -o DST SRC ::
>   description
>for long term

This is a very special case. Trying to handle this would change the
simple convenience patch into larger machinery. I don't think it's worth
it since all it costs is a C-n before the M-q.


>   - cmd --log-level=wrn -o DST SRC
>:: description
>for long term

This isn't even valid syntax.  At the moment, Org assumes the double
colons are on the same line as the bullet.


Regards,

-- 
Nicolas Goaziou

Re: [O] Export to Texinfo

[Nicolas Goaziou]

Hello,

Jonathan Leech-Pepin  writes:

> I've done some further work on the org-e-texinfo exporter and have
> gotten it to a point where it should be usable with only a few
> shortcomings.

Thanks for your work. I hope that you will get feedback on it.

> - Two-column tables are restricted to a single "indicating" command,
>   defined by ~org-e-texinfo-def-table-markup~.  I'm not sure how to
>   get around these limitations since they are created from description
>   lists (which do not recognize #+attr lines).

What makes you think they don't?  Plain lists accept affiliated
keywords, items don't.

> Prior to exporting the following must be evaluated:
>
>   (add-to-list 'org-export-snippet-translation-alist
>'("info" . "e-texinfo"))

Again, this is an user-oriented variable. You don't need it to accept
@@info:...@@ export snippets and you shouldn't require the user to set
it.


Regards,

-- 
Nicolas Goaziou

Re: [O] Wrapping text in org-table

[Jude DaShiell]

Probably doing a table of links with the links going to multi-line text 
and having links to return the user to the table itself would work. On 
Tue, 31 Jul 2012, Giovanni Ridolfi wrote:

> Hi, Marvin
> 
> 
> Da: Marvin Doyley 
> Inviato: Marted? 31 Luglio 2012 16:17
> 
> > is there a way to wrap long text in org table ?  works to some degree, 
> > but it chop off the text.
> 
> 
> this questionis quite similar to a faq [1]
> "Will there ever be support for multiple lines in a table field?
> No. 
> You can embed tables created with the table.el package in org-mode buffers, 
> with mixed success when it comes to export and publishing." 
> 
> [1] http://orgmode.org/worg/org-faq.html#table-multiline-fields
> 
> 
> cheers,
> Giovanni
> 
> 
> 


Hardware eventually fails; software eventually works, no amount of band
width can fix poor design

Jude 

[O] org-table not wrapped in table

[Bjarte Johansen]

Is there a reason the org-table does not get wrapped in a \begin{table}[ht]  in 
latex and only tabular? For scientific papers it is usually nice to be able to 
add label and caption to the table in the same way images/figures have.


Right now I just wrapped it in #+BEGIN_table myself and added \caption \label. 
--
Bjarte

Re: [O] org-fill-paragraph invoked on column 0

[Michael Brand]

Hi Nicolas

On Tue, Jul 31, 2012 at 9:39 PM, Michael Brand
 wrote:
> Thanks. It works except for description list. My requirement is that
> it works even with unusually placed "::" which work already when point
> is within the item body:

In my override my-org-fill-paragraph, improved over the one in an
earlier post I use

#+BEGIN_SRC emacs-lisp
  (save-excursion
(org-end-of-item)
(re-search-backward "[^[:space:]]")
;; [...]
#+END_SRC

to achieve this. May I suggest to use the same instead of the current

#+BEGIN_SRC emacs-lisp
  (save-excursion
(end-of-line)
;; [...]
#+END_SRC

in org-fill-paragraph?

Michael

Re: [O] org-fill-paragraph invoked on column 0

[Michael Brand]

Hi Nicolas

On Tue, Jul 31, 2012 at 8:59 PM, Nicolas Goaziou  wrote:
> It will probably be a common request, so I've pushed a convenience
> patch: when point is at an item or a footnote definition, the function
> will try to fill the first paragraph within.

Thanks. It works except for description list. My requirement is that
it works even with unusually placed "::" which work already when point
is within the item body:

  - cmd --log-level=wrn -o DST SRC ::
  description
   for long term
  - cmd --log-level=wrn -o DST SRC
   :: description
   for long term

Michael

Re: [O] org-fill-paragraph invoked on column 0

[Nicolas Goaziou]

Hello,

Michael Brand  writes:

> Because I need to fill list items so often and when I am on column 0
> of the bullet line, I start to override M-q at least until maybe the
> community decides that this old behaviour of M-q should be restored:

It will probably be a common request, so I've pushed a convenience
patch: when point is at an item or a footnote definition, the function
will try to fill the first paragraph within.


Regards,

-- 
Nicolas Goaziou

Re: [O] More flyspell-overlays removed

[Bastien]

"Sebastien Vauban"
 writes:

> I would allow fly-prog-mode in the listins, as one normally does for plain
> code, no?

This is indeed the case right now.

-- 
 Bastien

Re: [O] org-ibuffer

[Bastien]

Neil Smithline  writes:

> Just a few lines in a Gist to provide `ibuffer' functionality for
> org-mode' buffers.
>
> https://gist.github.com/3126257

Nice!  I added this to worg/org-hacks.org.

Thanks Neil,

-- 
 Bastien

Re: [O] Emacs23 on Ubuntu recognizes 'remember', not 'capture'

[Bastien]

Hi Rian,

Rian Murphy  writes:

> Would I have to somehow uninstall emacs 23 and install emacs 22? 
> Any other ideas?  

My simple suggestion is to install GNU Emacs 24.1 in all your computers.

It contains a more recent Org (> 7.8), which lets you use `org-capture'
everywhere.

Best,

-- 
 Bastien

Re: [O] [PATCH] org version under Windows 7

[Bastien]

Hi Achim,

Achim Gratz  writes:

> Bastien writes:
>> The snapshot is created by gitweb on the fly.
>
> I'm not talking about those — yes, they should be what's in Git's index,
> nothing more or less.  I was thinking of org-latest.{zip,tar.gz}, which
> might usefully include the autoload files or even byte-compiled
> sources.  

I agree org-latest.* should contain org-version.el and org-install.el.

I don't think it should contain the byte-compiled files, though, as some
users might prefer to use uncompiled code, and the archive would nearly
double in size if we include the byte-compiled files.

I will also include org-install.el and org-version.el in the next
release.

> FWIW, I think the download page should explicitly mention ELPA, now that
> Emacs 24.1 is out, as another low-maintenance alternative for folks who
> want to keep current, but not necessarily develop.  

I just added a mention to GNU ELPA, thanks!

-- 
 Bastien

Re: [O] More flyspell-overlays removed

[Bastien]

Bjarte Johansen  writes:

> It seems to not work for #+LATEX_CLASS_OPTIONS, maybe because of the
> two _ ?

It works for me when I use M-x flyspell-mode RET.

Can you provide a step-by-step way of reproducing the problem?

-- 
 Bastien

Re: [O] More flyspell-overlays removed

[Bjarte Johansen]

On 31 Jul, 2012, at 17:32 , Bastien  wrote:

> Bjarte Johansen  writes:
> 
>> On 30 Jul, 2012, at 13:03 , Bastien  wrote:
>> 
>>> I've pushed a fix which should let flyspell ignore more commonly 
>>> used Org keywords.  Please test it.
>> 
>> This works great. You forgot #+LATEX_CLASS_OPTIONS: though.
> 
> Nope.  
> 
> `org-additional-option-like-keywords-for-flyspell' contains instances
> of LATEX, CLASS and OPTIONS, and those words are ont flagged by flyspell.
> 
> Can you check this?
> 
> -- 
> Bastien

It seems to not work for #+LATEX_CLASS_OPTIONS, maybe because of the two _ ?

Re: [O] Missing files in mobileorg-android when syncing using Windows and cygwin

[Bastien]

Hi Mathias,

Mathias Kegelmann  writes:

> thanks for pointing out that the version is missing. I am running:
>
> ELISP> (emacs-version)
> "GNU Emacs 23.2.1 (i386-mingw-nt6.1.7601)\n of 2010-05-08 on G41R2F1"
>
> The issue with shell-quote is as follows:
>
> ELISP> (shell-quote-argument "c:/org/test")
> "c\\:/org/test"

This is also the output for current Emacs (24.1.50.1).

> The problem is the backslash before the colon as quoting colons
> doesn't seem to be legal in Cygwin.

Mh.. I'm don't really know anything about Cygwin, so perhaps it's safer
to ask this on the emacs-devel@ mailing list.  IIUC, the question is
whether Cygwin requires something else than 'shell-quote-argument in
such cases.

Thanks,

-- 
 Bastien

Re: [O] org-fill-paragraph invoked on column 0

[Michael Brand]

Hi Nicolas

On Mon, Jul 30, 2012 at 11:49 PM, Nicolas Goaziou  wrote:
> Yes. It's all about document's structure. First paragraph starts after
> bullet. Before, it's the item. Since you want to fill the first
> paragraph, you have to move into it.

Thank you for the explanations. I appreciate your improvements in
correctness of parsing and interpreting the Org structure.

Oh, and only now I see that, as your improvements exclude the item
bullet from filling, C-c and M-q (org-fill-paragraph) now leave the
manual alignment of the description in description lists untouched.
This is nice, it helps me as shown in my new post here:

"alignment of description list in Org and export old and new"
http://thread.gmane.org/gmane.emacs.orgmode/56631/focus=58222

> You can use navigation functions, move to the end of line, which is
> quicker, or to the beginning of the next line, even at column 0.

Because I need to fill list items so often and when I am on column 0
of the bullet line, I start to override M-q at least until maybe the
community decides that this old behaviour of M-q should be restored:

#+BEGIN_SRC emacs-lisp
  (add-hook 'org-mode-hook 'my-org-bind-M-q)
  (defun my-org-bind-M-q ()
(define-key org-mode-map "\M-q" 'my-org-fill-paragraph))
  (defun my-org-fill-paragraph ()
(interactive)
(if (and (org-in-item-p) (not mark-active))
(save-excursion
  ;; must deal also with:
  ;;   - cmd --log-level=wrn -o DST SRC ::
  ;;   description
  ;;for long term
  ;; or:
  ;;   - cmd --log-level=wrn -o DST SRC
  ;;:: description
  ;;for long term
  (org-end-of-item)
  (backward-char)
  (org-fill-paragraph))
  (org-fill-paragraph)))
#+END_SRC

Michael

Re: [O] org-protocol and server.el

[Bastien]

Hi Fabrice,

Fabrice Popineau  writes:

> @@ -1137,7 +1135,8 @@
>                   (let ((file (pop args-left)))
>                     (if coding-system
>                         (setq file (decode-coding-string file
> coding-system)))
> -                   (setq file (expand-file-name file dir))
> +                   (unless (string-match "^[^/]+:/" file)
> +                     (setq file (expand-file-name file dir)))
>                     (push (cons file filepos) files)
>                     (server-log (format "New file: %s %s"
>                                         file (or filepos "")) proc))

I suggest you send this to the emacs-devel@ mailing list or fill a bug
report M-x report-emacs-bug RET.

Thanks,

-- 
 Bastien

Re: [O] alignment of description list in Org and export old and new

[Michael Brand]

2012/6/2 Michael Brand :
> Is there a way to have automatic alignments in the Org buffer with M-q
> (fill-paragraph) and C-c C-c like:
[...]
>   - cmd ::short term + short descr
>   - cmd -o   :: short term + short descr
[...]
> Alternatives for the long items could be:
>
>   - cmd --log-level=err -o   ::
>   long term + short descr
>   - cmd --create-file ::  short term + long descr bla bla bla bla
>bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
>bla bla bla
>   - cmd --log-level=wrn -o   ::
>   long term + long descr bla bla bla bla
>bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
>bla bla bla
[...]
>   - cmd --log-level=dbg -o   ::
>   - term descr 1
>   - term descr 2
>
> instead of the default (shown below)?
[...]
> The default alignment is:
>
>   - cmd :: short term + short descr
>   - cmd -o   :: short term + short descr
>   - cmd --log-level=err -o   :: long term + short descr
>   - cmd --create-file :: short term + long descr bla bla bla bla bla
>bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
>bla bla
>   - cmd --log-level=wrn -o   :: long term + long descr bla
>bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
>bla bla bla bla bla bla
>   - cmd --log-level=dbg -o   ::
> - term descr 1
> - term descr 2

Since release_7.8.11-282-gb04f9e3 the commands C-c and M-q
(org-fill-paragraph) leave the manual alignment of descr untouched
which is perfect for what I want to achieve:

  - cmd ::short term + short descr
  - cmd -o   :: short term + short descr
  - cmd --log-level=err -o   ::
  long term + short descr
  - cmd --create-file ::  short term + long descr bla bla bla bla
   bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
   bla bla bla
  - cmd --log-level=wrn -o   ::
  long term + long descr bla bla bla bla
   bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
   bla bla bla
  - cmd --log-level=dbg -o   ::
- term descr 1
- term descr 2

Most of the time lists with only short terms:

  - cmd:: short term + short descr
  - cmd -o   :: short term + short descr
  - cmd --create-file  :: short term + long descr bla bla bla bla bla
   bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
   bla bla

Michael

Re: [O] More flyspell-overlays removed

[Bastien]

Bjarte Johansen  writes:

> On 30 Jul, 2012, at 13:03 , Bastien  wrote:
>
>> I've pushed a fix which should let flyspell ignore more commonly 
>> used Org keywords.  Please test it.
>
> This works great. You forgot #+LATEX_CLASS_OPTIONS: though.

Nope.  

`org-additional-option-like-keywords-for-flyspell' contains instances
of LATEX, CLASS and OPTIONS, and those words are ont flagged by flyspell.

Can you check this?

-- 
 Bastien

Re: [O] flet / my-filt problem

[Bastien]

Eric Schulte  writes:

> Regardless, I've just pushed up a fix which
> replaces the named function with an anonymous lambda-expression.  I've
> also pushed up a test case which exercises this function.  Everything
> now seems to be working.

Thanks!

-- 
 Bastien

Re: [O] More flyspell-overlays removed

[Sebastien Vauban]

Hi Bjarte,

Bjarte Johansen wrote:
> So I won't be able to work on this before next weekend, but in the mean time
> (unless someone else has the time) I suggest that we make a list of places
> where we would like to remove flyspell overlays from. I'll start.
>
> #+STARTUP
> #+OPTIONS
> #+LATEX_CLASS
> #+LATEX_CLASS_OPTIONS
> #+LATEX_HEADER
> #+BEGIN_lstlisting
> #+END_lstlisting
> Body of lstlisting
> #+BEGIN_verbatim
> #+END_verbatim
> body of verbatim
> #+LABEL
>
> These are for the #+ blocks I can think of now. I would also like to remove
> them from \nocite{} \cite{} and \ref{} commands or make a way to cite
> without using latex commands.

I would allow fly-prog-mode in the listins, as one normally does for plain
code, no?

Best regards,
  Seb

--
Sebastien Vauban

Re: [O] flet / my-filt problem

[Eric Schulte]

Bastien  writes:

> Hi Eric,
>
> Eric Schulte  writes:
>
>> Does the attached patch resolve this bad behavior?
>
> Can't we just get rid of org-flet in this case?
>
> With simply let-defining the temporary function?
>
> (let ((f (lambda(x) (message x
>   (funcall f "Hello!"))

This is exactly the tact taken by my previous patch, I'm still not sure
why it didn't work.  Regardless, I've just pushed up a fix which
replaces the named function with an anonymous lambda-expression.  I've
also pushed up a test case which exercises this function.  Everything
now seems to be working.

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] Wrapping text in org-table

[Giovanni Ridolfi]

Hi, Marvin


Da: Marvin Doyley 
Inviato: Martedì 31 Luglio 2012 16:17

> is there a way to wrap long text in org table ?  works to some degree, but 
> it chop off the text.


this questionis quite similar to a faq [1]
"Will there ever be support for multiple lines in a table field?
No. 
You can embed tables created with the table.el package in org-mode buffers, 
with mixed success when it comes to export and publishing." 

[1] http://orgmode.org/worg/org-faq.html#table-multiline-fields


cheers,
Giovanni

[O] Wrapping text in org-table

[Marvin Doyley]

Hi there,

is there a way to wrap long text in org table ?  works to some degree,
but it chop off the text.

thanks
M

Re: [O] More flyspell-overlays removed

[Jeffrey Spencer]

I don't have any problem with natbib cite commands including \ref, \cite,
\citet, \citep, etc

Maybe your version of flyspell?? But it should act exactly as it does in
auctex or your latex mode of emacs. I would check in there if it works
properly because should parse the same way if not maybe debug from there.

Cheers,
Jeff

On Mon, Jul 30, 2012 at 9:44 PM, Bjarte Johansen wrote:

>
> On 30 Jul, 2012, at 13:03 , Bastien  wrote:
>
> > I've pushed a fix which should let flyspell ignore more commonly
> > used Org keywords.  Please test it.
>
> This works great. You forgot #+LATEX_CLASS_OPTIONS: though.
>
>
> On 30 Jul, 2012, at 13:13 , Jeffrey Spencer 
> wrote:
>
> > Will give it a test later in the week and let you know.
> >
> > Also you can add this hook to make it act like the fly-spell mode in
> auctex (if familiar with that) which skips most tex based commands (trips
> up though if you have only one $ because assumes another $ sign later so
> won't check spelling in that block. I would just do \$ if you need a single
> dollar sign. This is the only really limitation I have found to adding this
> that I have noticed thus far.
> > (add-hook 'org-mode-hook (lambda () (setq ispell-parser 'tex)))
>
> I tried this and it does work for most things, but for some reason it
> doesn't like the natbib \cite commands.

Re: [O] are super-hidden technical blocks required?

[Torsten Wagner]

Hi Robert,

Please see my follow up post with a more detailed description and a
(as I find) already better solution.
In summary, it is about providing a way to store data in org-mode
which is not intended to be read/modified by humans.
Your idea would be one part of it and I was thinking of that too.
> I could see a use for a "blob" property.  Suppose I have a JPEG of
> someone's portrait that I want to incorporate into a contact's
> properties.  Some mechanism to indicate:
Unfortunately, I notice that Emacs and org-mode can easily slow down
for large documents (I noticed, e.g. by using  thousand lines of
(collapsed) code blocks) . I frighten that an JPEG or PNG which would
easily fill hundreds or thousands of (hidden) lines might slow down
org-mode. That is, if there would be such a function, one would have
to make sure it does not influence the performance.

Torsten

Re: [O] are super-hidden technical blocks required?

[Robert Horn]

Jonathan Leech-Pepin  writes:

> Hi,
>>> This blocks could be hidden under all normal means unlike
>>> really someone want to see them and hit a special
>>> key-combo.
>>
>> Hmm, personally I'd rather have it visible but clearly
>> labeled. Transparency is nearly always a good thing.
>>
>
I agree.  The real use needs more clarification.  Things like ID are
already well hidden as :PROPERTIES: until the user explicitly opens the
drawer for viewing.  I don't understand the need to hide those further, so
a better explanation of why is needed.

I could see a use for a "blob" property.  Suppose I have a JPEG of
someone's portrait that I want to incorporate into a contact's
properties.  Some mechanism to indicate:

:PROPERTIES:
:Portrait: blob-flag application/jpeg alternate-text="Joe's picture" 
<>
:END:

with a third level of lisp-function that will open the blob contents as
ugly encoded text or with a decoding/viewing function instead of the
text "<>".  I could see this being useful for both
textual items like S-exprs, XML, JSON, etc. and for binary things like
JPEG, PDF, etc.  It could be similar to the current embedding done for
literate programming with a way to separate blob content from org
content.

Right now the link capabilities are available for blob-like uses, but
links don't work if I need to move the org-mode files between machines,
etc.

R Horn
rjh...@alum.mit.edu

Re: [O] Embed images in formats best suited for HTML and LaTeX export and inline viewing

[Brett Viren]

Hi,

I'm back wanting to specify per-export image formats again.

I learned about macros in org-mode and I have found a half-solution:


#+MACRO: himg #+HTML:  $3
#+MACRO: limg #+LATEX: 
\begin{figure}\label{$1}\includegraphics[width=\textwidth]{$2.pdf}\caption{$3}\end{figure}


I then call each macro explicitly:


{{{limg(fig:overview,dataflow,Overview of the data flow.)}}}
{{{himg(fig-overview,dataflow,Overview of the data flow.)}}}


It works but has a few warts:

0) It totally subverts org-mode's figure markup.

1) So far I think I must use two macro calls thus annoyingly repeating
data.  Can macros be nested?  Can they have newlines?

2) I prefer "fig:label" type labels in LaTeX but the HTML export
apparently forms the link translating ":" to "-".  So, this must be
taken into account when the macros are called.


Any other ideas?


Thanks,
-Brett.



pgpm463BDDm42.pgp
Description: PGP signature

Re: [O] comment bug

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> For years we had subtle bugs with commenting and filling.  That got
> fixed, but now
> comment-start is nil.

I just committed a complete implementation of comments, compatible with
`comment-dwim'.  Does it behave as expected?


Regards,

-- 
Nicolas Goaziou

Re: [O] Extending org-koma-letter.el

[Luis Anaya]

Nicolas Goaziou  writes:

Hi:

>> Thanks.  It's wonderful writing letters with the new latex exporter.
>> You should consider adding it to org_contrib.

> On the other hand, I think that Org deserves a serious letter
> package. If you want to maintain and improve it, I'm all for adding it
> to contrib directory.

Nicolas, I would like to take a look at the code. I've been raking my
brain on how to add support for the .LO/.LT Groff macros being that they
break convention to covers and memorandum types. 



>> * my-encl:appendix:
>> #+latex:\encl{
>> - doc 1
>> - doc 2
>> #+latex:}
>> #+end_src


>
> The #+latex: ... parts are ugly. You may implement
> an #+attr_koma: :enclosure t syntax, for example.

This one I can use to enclose the .NS calls (that's how enclosures are
marked in Groff). Right now there's support for Closure and Signature, but
enclosures or carbon copy  marks need to be added using Groff code.  


>
> #+begin_src emacs-lisp
> (org-element-map
>   (plist-get info :parse-tree) 'headline
>   (lambda (h) 
> (and (member "appendix" (org-export-get-tags h info))
>  h))
>   info)
> #+end_src
>

Oh, so that's the magic trick :).  I was wondering for a good way to do
implement abstracts, but I should be able to use it to use it
for addresses as well. 

Thanks for sharing. 

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: [O] tags searching

[Richard Riley]

Giovanni Ridolfi  writes:

> Da: Richard Riley 
> Inviato: Lunedì 30 Luglio 2012 11:15
>
> Hi, Richard,
>
>>,
>>| org-agenda-files is a variable defined in `org.el'.
>>| Its value is ("~/.orgfiles" "~/webs/.orgfiles")
>>| Original value was nil
>>`
>
>> C-h a m visa
>
>> does not find a heading in ~/.orgfiles/other.org where the top level for
>> an entry is as follows:-
>
>> ,
>> | * cards                       :creditcards:mbna:amazon:visa:girocard:ec
>> `
>
> here:
> org-agenda-files is a variable defined in `org.el'.
> Its value is ("~/todo.txt" "~/org.txt" "~/" )
> Original value was nil
>
> ~/test.org
> 
> * cards  
> :creditcards:mbna:amazon:visa:girocard:NOTSEMICOLONec
> as in Richard's email, see above
>
> * cards  :creditcards:mbna:amazon:visa:girocard:ec:
> -
>
> (I have a sicky Agenda)
> Headlines with TAGS match: visa  
> Press `C-u r' to search again with new search string
>   test:   cards   
> :creditcards:mbna:amazon:visa:girocard:ec:
>
>> Something obviously wrong?
> 1. the semicolon at the end of the headline?

bingo!!! Simple as that. The missing semi colon caused the error. Hmm.

Thanks!

I should have spotted that, but possibly the tag matching code could be
a little more robust for the tag string.

Re: [O] flet / my-filt problem

[Bastien]

Hi Eric,

Eric Schulte  writes:

> Does the attached patch resolve this bad behavior?

Can't we just get rid of org-flet in this case?

With simply let-defining the temporary function?

(let ((f (lambda(x) (message x
  (funcall f "Hello!"))

-- 
 Bastien

Re: [O] flet / my-filt problem

[Andreas Leha]

Eric Schulte  writes:

> Andreas Leha  writes:
>
>> Eric Schulte  writes:
>>
>>> Andreas Leha  writes:
>>>
 Hi all,

 with the current HEAD (commit 0202adb1c02908a75a7845438381e40d811fd99a)
 from master I get an error during the export of
 one of my files complaining about an undefined my-filt function.

 Replacing org-flet with flet in ob-comint.el (line 78) introduces a
 compiler warning, but solves the problem.

 I am on emacs 24.1.50.1.

>>>
>>> Hi Andreas,
>>>
>>> Does replacing `org-flet' in line 78 of ob-comint.el with `org-labels'
>>> solve this problem?
>>>
>>> Thanks,
>>
>> Hi Eric,
>>
>> thanks for the quick response.  But org-labels does not solve the
>> problems for me.
>>
>> Backtrace is attached.  Don't know if this is interesting...
>>
>
> Ugh, I wish Emacs wouldn't replace an existing function with a new
> function which not only has a different name, but also has different
> functionality.
>
> Does the attached patch resolve this bad behavior?
>

No, it does not, unfortunately.  Same thing:
,
| (void-function my-filt)
|   my-filt("")
|   run-hook-with-args(my-filt "")
|   comint-send-input()
|   inferior-ess-send-input()
|   
`

Regards,
Andreas