[BUG] org-element-cache error using org-store-link file [9.6.1 (9.6.1-g44e1cb @ c:/users/scott/.emacs.d/straight/build/org/)]

[Scott Otterson]

When I run org-store-link inside a .bib file, I get the cache error below.

If somebody's interested, I can send the log separately in a zip file.
It's too big for my email client to send uncompressed, and I believe I
can't send compressed files to this list.

This is using:

Emacs  : GNU Emacs 29.0.60 (build 1, x86_64-w64-mingw32) of 2023-03-10
Package: Org mode version 9.6.1 (9.6.1-g44e1cb @
c:/users/scott/.emacs.d/straight/build/org/)

Thanks,

Scott


--- Warning


 ■  Warning (org-element-cache): org-element--cache: Org parser error in
energy.bib::761517. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
 ■  Warning (org-element-cache): org-element--cache: Org parser error in
energy.bib::761517. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report).

Re: [BUG] org-element--cache: Unregistered buffer [9.5.3 (9.5.3-g4dda0d @ c:/Users/scott/.emacs.d/straight/build/org/)]

[Scott Otterson]

Hi Ihor,

With straight.el, it's Org mode version 9.5.3.

If I open the file with emacs -Q, I'm surprised to see that I get a
different warning message:

File mode specification error: (void-variable org-fold-core-style)

This is on emacs 28.1, which uses Org mode version 9.5.2

On Mon, May 30, 2022 at 10:09 PM Ihor Radchenko  wrote:

> Scott Otterson  writes:
>
> > Having just updated to emacs 28.1, I'm seeing the warning
> >
> > org-element--cache: Unregistered buffer
> >
> > every time I open a .org file.  I also notice that org-superstar no
> longer
> > works.
> >
> > These problems persist if I delete my .emacs.d and let straight.el
> rebuild
> > everything.
>
> Thanks for reporting! You appear to use straight.el. Can you please
> share the output of M-x org-version? straight.el is known to create
> problems when Org is loaded late in you config.
> See https://github.com/radian-software/straight.el/issues/947
>
> Also, can you try to open the problematic files using bare Emacs
> starting from emacs -Q? See https://orgmode.org/manual/Feedback.html
>
> Best,
> Ihor
>

Re: Bug: xxx [9.3 (9.3-8-geab7c4-elpa @ c:/Users/Scott/.emacs.d/elpa/org-20191209/)]

[Scott Otterson]

Hi Nicolas,

Thanks for the help.

Scott

On Mon, Dec 16, 2019 at 8:22 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Scott Otterson  writes:
>
> > A function I wrote a few months ago is now failing because it's unable
> > to find the org function "org-at-target-p". I think this was
> > originally in org.el but I can't find it there now.
>
> It was removed because its implementation was buggy and not necessary.
>
> > If this function was removed intentionally could someone suggest a new
> > function that can do the same thing? org-at-target-p used to return
> > true if the cursor is on a dedicated target.
>
> You can use Org parser:
>
>   (memq (org-element-type (org-element-context)) '(target radio-target))
>
> or
>
>   (org-element-lineage (org-element-context) '(target radio-target) t)
>
> Regards,
>
> --
> Nicolas Goaziou
>

where is org-at-target-p ?

[Scott Otterson]

For years, I've used the function, org-at-target-p to detect when the
cursor is on a dedicated target.  Recently, org-at-target-p disappeared
from elpa -- for example, it's not in the org.el included in
org-plus-contrib-20191209.

Was its removal intentional, and if so, is there a new function with
equivalent behavior?

Thanks,

Scott

Re: [O] org-open-at-point fails on internal links

[Scott Otterson]

This morning, I updated my packages (Options -> Manage Emacs Packages -> U
->X) and now, internal links work perfectly.

For the record, the updated packages were:

dash-20171009.105
flycheck-20171009-1145
helm-20171009.221
kaolin-theme-20171009.1130
org-20171009
org-plus-contrib-20171009
org-ref-20171009.2019
python mode-20171005.1620


I'll let you know if the error returns.

Scott




On Mon, Oct 9, 2017 at 8:38 PM, Kyle Meyer <k...@kyleam.com> wrote:

> [Forwarding because the list was dropped earlier in the thread but I
>  didn't notice.  Scott, please don't drop the list in your replies.]
>
>
>
> -- Forwarded message --
> From: Kyle Meyer <k...@kyleam.com>
> To: Scott Otterson <sco...@sharpleaf.org>, Nicolas Goaziou <
> m...@nicolasgoaziou.fr>
> Cc:
> Bcc:
> Date: Mon, 09 Oct 2017 14:32:00 -0400
> Subject: Re: org-open-at-point fails on internal links
> Scott Otterson <sco...@sharpleaf.org> writes:
>
> >   org-backward-paragraph()
> >   org-inside-LaTeX-fragment-p()
> >   org-footnote-in-valid-context-p()
> >   org-footnote-at-reference-p()
> >   ad-Advice-org-open-at-point
>
> [...]
>
> > org-mouse.el  (line 907) adds code to org-mode-hook, and that code adds
> > advice to org-open-at-point, and that advice calls
> > org-footnote-at-reference-p
>
> Thanks for digging further.  Indeed org-mouse.el's advice would result
> in the org-footnote-at-reference-p path being executed.
>
> After loading org-mouse and using your example, I'm still not able to
> trigger the error.  Could you debug org-backward-paragraph to find out
> where the error is occurring?  You can do that by calling C-u C-M-x on
> org-backward-paragraph or by evaluating
>
> (edebug-instrument-function 'org-backward-paragraph)
>
> --
> Kyle
>
>

Re: [O] org-open-at-point fails on internal links

[Scott Otterson]

> Scott Otterson <sco...@sharpleaf.org> writes:
>
>> When I click on an internal link to an anchor, I get the error message:
>>
>> "Wrong type argument: number-or-marker-p"

The problem has something do do with org-mouse.el --  if I go to Emacs
customize "Org Modules" and uncheck:

"mouse:   Additional mouse support"

then links work and there's no error message.

Things seem to go wrong at org-mouse.el, which adds code to org-mode-hook,
and that code adds advice to org-open-at-point; the advice calls
org-footnote-at-reference-p, where the problem starts.

I don't know if the call to org-footnote-at-reference-p should be removed
from the advice, or if org-footnote-at-reference-p should be fixed.

Scott

On Sat, Oct 7, 2017 at 5:04 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Kyle Meyer <k...@kyleam.com> writes:
>
> > Hello,
> >
> > Scott Otterson <sco...@sharpleaf.org> writes:
> >
> >> When I click on an internal link to an anchor, I get the error message:
> >>
> >> "Wrong type argument: number-or-marker-p"
> >>
> >> The same happens if I type C-c C-o on the link.  This is mapped
> >> to org-open-at-point, which should handle internal links.
> >
> > [...]
> >
> >> This behavior is new, I believe since the last org package update.  I'm
> >> currently on org mode version 9.1.2.
> >>
> >> -- Example Org File ---
> >>
> >> * headline 1
> >>   <>
> >> * headline 2
> >> *** [[Anchor 1]]  CLICK ON THIS
> >
> > FWIW I'm not able to reproduce this with 9.1.2.
>
> Ditto. Maybe a backtrace would help.
>
> Regards,
>
> --
> Nicolas Goaziou
>

[O] org-open-at-point fails on internal links

[Scott Otterson]

When I click on an internal link to an anchor, I get the error message:

"Wrong type argument: number-or-marker-p"

The same happens if I type C-c C-o on the link.  This is mapped
to org-open-at-point, which should handle internal links.

However, if I type C-c o on the link, then the cursor goes to the anchor.
This is mapped to org-open-at-point-global, which the org info help says is
undefined on internal links.

This behavior is new, I believe since the last org package update.  I'm
currently on org mode version 9.1.2.

-- Example Org File ---

* headline 1
  <>
* headline 2
*** [[Anchor 1]]  CLICK ON THIS

Re: [O] How do you store web pages for reference?

[Scott Otterson]

I use Evernote, which has handy annotation, tagging, and search functions.

The offline desktop client also has a "Copy URL" button, which puts the
Evernote server location where you stored the page into your clipboard.  I
paste that into an org-mode link.  If you're on Linux, you can copy the URL
from your browser.

Scott

[O] Heading named "Footnotes" is deleted from export

[Scott Otterson]

This is interesting.  A heading named "Footnotes" will be deleted from the
export result (html, latex,...).

--- example.org:  Do "C-c C-e h o" or whatever on it --
* Heading 1
* Footnotes
* Heading 3
---

--- my setup
--
Emacs  : GNU Emacs 25.1.1 (i686-w64-mingw32)
 of 2016-09-17
Package: Org mode version 9.0.2 (9.0.2-elpaplus @
c:/Users/scott/OneDrive/scotto/.emacs.d/elpa/org-plus-contrib-20161214/)
---

Re: [O] Multiple underscores crash org latex export; other exporters survive

[Scott Otterson]

Thanks to Nicolas and Scott for your painstaking efforts.  At least for me,
a fine stopgap measure is to simply avoid Latex crashes for orgmode
contents that are not explicitly Latex.  Sometime after that, it would be
ideal to produce similar output for all export types, insofar as that's
possible.

I thought I'd see what ox-pandoc does.  As I'm sure you know, pandoc
converts all input formats to a master markup language, and then converts
that to whatever output format is desired -- a design that makes output
uniformity easier to obtain.  Orgmode is already halfway there, since the
master markup language is orgmode itself.

Here's what pandoc does in the three cases I've recently posted about:

1.) *Multiple underscores* (the subject of this thread):  Pandoc doesn't
crash and it exports the same thing for either html or latex: everything
after the first underscore is subscripted and all underscores are deleted.
I don't love that behavior but it's consistent.

2.) *Plain lists with more than four sublevels*: For html export, pandoc
and orgmode do what you'd expect: produce a deeply nested html list.  For
(Windows) latex export, pandoc and orgmode also do the same thing: crash.
Ideally, pandoc would have generated valid Latex for deep list nesting, but
at least it's not completely ornery; it snips out the part of the original
Latex error message that points to the cause.

Perhaps pandoc latex export wouldn't crash in Linux, just as orgmode latex
export doesn't crash in Linux (from Nicolas).  This is still a mystery.
Nicolas's Linux-produced tex file is essentially the same as the one I got
in Windows, and it crashes Windows latexmk just like mine does.  *Nicolas*,
could it be that you're not running latexmk on your exports?

3.) *Web link with a '#' in the URL*: Pandoc never crashes and it exports
nearly the same thing for html or latex pdf:  In either case, clicking on
the link sends you to the right web page, and the only difference is that,
in the output pdf, the link text isn't highlighted; instead there's a
tooltip popup.

The reason pandoc latex export doesn't crash but orgmode does (in Windows)
is that pandoc escapes the '#'.  In the example I posted last week, orgmode
does this:

\section{Some section  \href{http://orgmode.org/manual/Column-groups.html#
Column-groups}{A random link}}


while pandoc does this:

\section{\texorpdfstring{Some section \href{http://orgmode.org/
manual/Column-groups.html\#Column-groups}{A random link}}{Some section A
random link}}


I don't understand why the escape prevents Windows crashes but doesn't
appear to be needed for Linux.  Nevertheless, it looks like pandoc does
something special to prevent this crash.

Scott

>
>

Re: [O] Multiple underscores crash org latex export; other exporters survive

[Scott Otterson]

Yes, there's a general question of how to escape multiple underscores.

But there's a bigger question too:  Should an org-doc that runs fine in
other exporters cause a messy-to-debug crash when it's exported to Latex?
Is that the Pandoc-like behavior that orgmode seems to be aiming for?

I love org-mode.  For years, I've used it as a project organizer,
brainstorming tool, and extremely versatile notekeeper.  I've already got a
big investment in it, so I'll spend the time to track down this kind of
problem.

But I'd guess that such unexpected Latex crashes have driven new users back
to Word or whatever.

On Sun, Dec 4, 2016 at 11:13 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Scott Randby  writes:
>
> > There is an interesting issue here. I sometimes want to use ~ in a code
> > snippet, so I can't use ~code snippet~. Yet,
>
> Indeed, this was discussed in this ML. We need some escape character in
> Org. A general escape character is a bit ambitious, and not necessarily
> useful, but we could introduce one specifically for verbatim and code
> markers, much like in macros and verbatim blocks, e.g.
>
>   ~some\~code\=with special\\ characters~
>
> There is a design decision involved: what character can be escaped? It
> could be anything, or limit to "~" for code and "=" for verbatim
> markers. For example macros limit escape-able characters to "," and "\".
> This makes the contents easier to read, but the rule is inconsistent.
>
> Thoughts?
>
> > Org code: \verb@a_variable_deleteThisAndItWorks@
> >
> > Exported LaTeX: \verb@a\(_{\text{variable}}_{\
> text{deleteThisAndItWorks}}\)@
> >
> > The exported LaTeX is not what we want. Instead,
> >
> > Org code: #+latex:\verb@a_variable_deleteThisAndItWorks@
> >
> > Alternative: @@latex:\verb@a_variable_deleteThisAndItWorks@@@
> >
> > Exported LaTeX: \verb@a_variable_deleteThisAndItWorks@
> >
> > I've wondered why \verb isn't exported correctly without specifying it
> > as literal LaTeX,
>
> It's because Org recognize LaTeX commands only if they are followed by
> a blank character, the end of buffer, or "{}", which is not the case
> with \verb@...@.
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

Re: [O] Latex export fails for plain lists deeper than four, works for html

[Scott Otterson]

Hi Nicolas, thanks for trying to replicate this on Linux.  What happens for
you if it doesn't crash?  Does the latex export just work and produce a pdf
with a set of properly nested lists?

Would you be willing to sent me .tex your latex export produces?  It seems
unlikely, but maybe org use a different/additional latex library on Linux
than it does in Windows.  Or alternatively, TexLive installs different/more
libraries on Windows.  Anyway, it would be nice to figure it out.

I googled quickly for the hint you mentioned but couldn't find it.

On Sat, Dec 3, 2016 at 10:10 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Scott Otterson <sco...@sharpleaf.org> writes:
>
> > If a plain list has more than four levels, org-mode will produce latex
> that
> > crashes.  See attached.  On the other hand, html export works fine, even
> > for much deeper lists.
> >
> > In a large org file, this export error is pretty time consuming for a
> naive
> > user (me) to isolate, so I'd like to suggest that, before crashing
> latexmk,
> > org-mode should at least print a human-readable warning -- especially
> since
> > deep list export works for other export types.
> >
> > Better yet, would be deeper latex lists.  There are ways:
> >
> > http://tex.stackexchange.com/questions/41408/a-five-level-deep-list
> > 1. level 1.1
> >1. level 2.1
> >   1. level 3.1
> >  1. level 4.1
> > 1. level 5.1 (works if this level is deleted)
> > 2. level 5.2 (works if this level is deleted)
> >  2. level 4.2
> >   2. level 3.2
> >2. level 2.2
> > 2. level 1.2
>
> Again, this doesn't crash here.
>
> Also, the manual already gives hint about how to support more than four
> levels of nesting for lists.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Bug: Latex export fails with link in headline

[Scott Otterson]

Huh, the mystery deepens.  Does TexLive really behave differently on Linux?

Anyway, I'd argue that Org should do the minimum to prevent Latex crashes.
It seems that org is aiming to be a generic document format, which can be
exported to other formats without modification.

But with the current behavior, that's not possible.  If I modify the org
doc to avoid latex crashes (escaping the '#' in the URL), then the same
document exported to html will not work; click on the html link and you'll
get a 404 error.

On Sat, Dec 3, 2016 at 10:03 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Scott Otterson <sco...@sharpleaf.org> writes:
>
> > Could you please check the .tex output you got when exported my .org file
> > example (attached again)?  In the .tex I get (also attached), it's clear
> > that org-mode has forgotten to escape the '#' in the URL.  In
> headlink.tex,
> > if I replace '#' with ''\#', then latexmk can successfully make a pdf.
> >
> > Do you see something different?
>
> I do. While I get the same .tex output, compiling the file to a pdf
> doesn't crash. I also use Texlive, but on GNU/Linux.
>
> Besides, Org mode doesn't escape anything. It calles `url-encode-url' on
> the link instead.
>
> Regards,
>
> --
> Nicolas Goaziou
>

[O] Multiple underscores crash org latex export; other exporters survive

[Scott Otterson]

When an org file contains a string with more than one underscore, the
orgmode export result will crash latex (example attached).   On the other
hand, the org html export does finish successfully, and while result is
odd, it's odd in a way that makes the problem visible and easy to identify.

Many people have orgfiles with heavily underscored code snippets buried
deep inside.  To them, the latex crashes are probably as mysterious as they
were to me.  So I'd like to suggest that the org latex exporter adopt
something like the org html exporter behavior.


multiple_underscores.org
Description: Binary data

[O] Latex export fails for plain lists deeper than four, works for html

[Scott Otterson]

If a plain list has more than four levels, org-mode will produce latex that
crashes.  See attached.  On the other hand, html export works fine, even
for much deeper lists.

In a large org file, this export error is pretty time consuming for a naive
user (me) to isolate, so I'd like to suggest that, before crashing latexmk,
org-mode should at least print a human-readable warning -- especially since
deep list export works for other export types.

Better yet, would be deeper latex lists.  There are ways:

http://tex.stackexchange.com/questions/41408/a-five-level-deep-list


only4plainListLevels.org
Description: Binary data

Re: [O] Bug: Latex export fails with link in headline

[Scott Otterson]

Hi Nicolas,

Could you please check the .tex output you got when exported my .org file
example (attached again)?  In the .tex I get (also attached), it's clear
that org-mode has forgotten to escape the '#' in the URL.  In headlink.tex,
if I replace '#' with ''\#', then latexmk can successfully make a pdf.

Do you see something different?

Thanks,

Scott

On Tue, Nov 29, 2016 at 1:57 PM, Scott Otterson <sco...@sharpleaf.org>
wrote:

> Very strange.  I moved to a different Windows machine, totally reinstalled
> elpa/melpa, and the tmp.org file that emailed the list still failed.  I
> even copied tmp.org out of my email to be sure we're looking at the same
> thing.
>
> Could it be something like you're running Linux and I'm running Windows,
> or like I'm running TexLive and you're running MikTex?  I've attached the
> output of M-x report-emacs-bug so you can see my whole setup.
>
> I've also attached a different oddly crashing org file, and the latex
> error buffer I get after typing C-c C-e l o
>
> Scott
>
> On Mon, Nov 28, 2016 at 12:26 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
> wrote:
>
>> Hello,
>>
>> Scott Otterson <sco...@sharpleaf.org> writes:
>>
>> > Latex export sometimes fails when I put a link in a headline  Usually,
>> > links in headlines work fine but below is an example that doesn't (error
>> > message in emacs buffer attached); If I remove the link, the export is
>> > successful.
>> >
>> > -- tmp.org 
>> -
>> >
>> > * Some section  [[
>> > http://orgmode.org/manual/Column-groups.html#Column-groups][A random
>> link]]
>> >
>> >   - Item A
>> >   - Item B
>> >   - Item C
>>
>> FWIW I cannot reproduce it.
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>


headlink.org
Description: Binary data


headlink.tex
Description: TeX document

Re: [O] Bug: Latex preview overlay scaling not consistent across PPI

[Scott Otterson]

Thanks Nicolas,

I'd like to test your fix but I'm a github newbie (*).  Where did you check
it in?  I don't know if it's melpa or elpa, or if the fix is in a personal
account or something official.  Is there a standard way everybody
contributes their fixes?

Scott

(*) For the same reason, I still haven't been able to test the other dvips
customization fix you recently made.

[O] Bug: Latex preview overlay scaling not consistent across PPI

[Scott Otterson]

The size of the latex preview overlay scaling is inconsistent across
screens with different pixel densities.

I've set my customization to use dvipng for the latex previews I see when I
type C-c C-x C-l.  Dvipng is customized as follows:

[image: Inline image 1]

The "Value" is set to (1.0 . 1.0), which I would think means that the font
size in the preview overlay is scaled the same as the font size org
buffer's normal text.

This is more or less true for a Windows 7 machine connected to a 24",
1920x1080 pixel monitor:

[image: Inline image 2]

However, on a Windows 10 machine with a 12.3", 2736x1824 pixel monitor, the
same customization looks like this:

[image: Inline image 3]

On the second computer (a Surface Pro 4) the previews are tiny because the
screen has a much higher pixel density; the normal text is scaled
appropriately but the overlays aren't scaled to match.

I'd like keep the same .emacs file across all the machines I have to use,
so it would be best if the preview scaling was consistent.

Possibly the overlay scaling calculation is done using the function
window-text-width without the *pixelwise *argument, which would return a
width in characters.  To avoid changing the calculation too much, you could
use window-max-chars-per-line, which considers font size and some things
that would be missed by window-text-width even if *pixelwise* was used.

-- my setup
--
Emacs  : GNU Emacs 25.1.1 (i686-w64-mingw32)
 of 2016-09-17
Package: Org mode version 9.0.1 (9.0.1-elpaplus @
c:/Users/sotterson/home/.emacs.d/elpa/org-plus-contrib-20161118/)

[O] Bug: Latex export fails with link in headline

[Scott Otterson]

Latex export sometimes fails when I put a link in a headline  Usually,
links in headlines work fine but below is an example that doesn't (error
message in emacs buffer attached); If I remove the link, the export is
successful.

-- tmp.org -

* Some section  [[
http://orgmode.org/manual/Column-groups.html#Column-groups][A random link]]

  - Item A
  - Item B
  - Item C

--- My setup --
Emacs  : GNU Emacs 25.1.1 (i686-w64-mingw32)
 of 2016-09-17
Package: Org mode version 9.0.1 (9.0.1-elpa @
c:/Users/scott/OneDrive/scotto/.emacs.d/elpa/org-20161118/)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LC_COLLATE = "C",
LC_CTYPE = "C",
LC_NUMERIC = "C",
LANG = "ENU"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Latexmk: This is Latexmk, John Collins, 5 Sep. 2016, version: 4.48.
Rule 'pdflatex': Rules & subrules not known to be previously run:
   pdflatex
Rule 'pdflatex': The following rules & subrules became out-of-date:
  'pdflatex'

Run number 1 of rule 'pdflatex'


Running 'pdflatex  -recorder -output-directory="./"  "./tmp.tex"'

Latexmk: applying rule 'pdflatex'...
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/W32TeX) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(.//./tmp.tex
LaTeX2e <2016/03/31> patch level 3
Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.
(c:/texlive/2016/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(c:/texlive/2016/texmf-dist/tex/latex/base/size11.clo))
(c:/texlive/2016/texmf-dist/tex/latex/base/inputenc.sty
(c:/texlive/2016/texmf-dist/tex/latex/base/utf8.def
(c:/texlive/2016/texmf-dist/tex/latex/base/t1enc.dfu)
(c:/texlive/2016/texmf-dist/tex/latex/base/ot1enc.dfu)
(c:/texlive/2016/texmf-dist/tex/latex/base/omsenc.dfu)))
(c:/texlive/2016/texmf-dist/tex/latex/base/fontenc.sty
(c:/texlive/2016/texmf-dist/tex/latex/base/t1enc.def))
(c:/texlive/2016/texmf-dist/tex/latex/graphics/graphicx.sty
(c:/texlive/2016/texmf-dist/tex/latex/graphics/keyval.sty)
(c:/texlive/2016/texmf-dist/tex/latex/graphics/graphics.sty
(c:/texlive/2016/texmf-dist/tex/latex/graphics/trig.sty)
(c:/texlive/2016/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(c:/texlive/2016/texmf-dist/tex/latex/graphics-def/pdftex.def
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
(c:/texlive/2016/texmf-dist/tex/latex/oberdiek/grffile.sty
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/ifpdf.sty)
(c:/texlive/2016/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
(c:/texlive/2016/texmf-dist/tex/latex/oberdiek/kvoptions.sty
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/etexcmds.sty
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/ifluatex.sty
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty))
(c:/texlive/2016/texmf-dist/tex/latex/tools/longtable.sty)
(c:/texlive/2016/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
(c:/texlive/2016/texmf-dist/tex/latex/graphics/rotating.sty
(c:/texlive/2016/texmf-dist/tex/latex/base/ifthen.sty))
(c:/texlive/2016/texmf-dist/tex/generic/ulem/ulem.sty)
(c:/texlive/2016/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(c:/texlive/2016/texmf-dist/tex/latex/amsmath/amstext.sty
(c:/texlive/2016/texmf-dist/tex/latex/amsmath/amsgen.sty))
(c:/texlive/2016/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(c:/texlive/2016/texmf-dist/tex/latex/amsmath/amsopn.sty))
(c:/texlive/2016/texmf-dist/tex/latex/base/textcomp.sty
(c:/texlive/2016/texmf-dist/tex/latex/base/ts1enc.def
(c:/texlive/2016/texmf-dist/tex/latex/base/ts1enc.dfu)))
(c:/texlive/2016/texmf-dist/tex/latex/amsfonts/amssymb.sty
(c:/texlive/2016/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
(c:/texlive/2016/texmf-dist/tex/latex/capt-of/capt-of.sty)
(c:/texlive/2016/texmf-dist/tex/latex/hyperref/hyperref.sty
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
(c:/texlive/2016/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
(c:/texlive/2016/texmf-dist/tex/latex/oberdiek/auxhook.sty)
(c:/texlive/2016/texmf-dist/tex/latex/hyperref/pd1enc.def)
(c:/texlive/2016/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
(c:/texlive/2016/texmf-dist/tex/latex/url/url.sty))

Package hyperref Message: Driver (autodetected): hpdftex.

(c:/texlive/2016/texmf-dist/tex/latex/hyperref/hpdftex.def
(c:/texlive/2016/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty)) (.//tmp.aux
) (c:/texlive/2016/texmf-dist/tex/latex/base/ts1cmr.fd)
(c:/texlive/2016/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to 

[O] Bug: Capital lettered plain lists export as numbered

[Scott Otterson]

In my org file, I have ordered capital lettered plain lists like this:

A. Item A
B. Item B
a. subitem a
b. submitem b
C. Item C


But when I export them to a pdf via latex, they look like this:

1. Item A
2. Item B
(a) subitem a
(b) submitem b
3. Item C


Is this a bug or is it expected behavior?

--- test .org file 

A. Item A
B. Item B
   a. subitem a
   b. submitem b
C. Item C

-- my setup 
Emacs  : GNU Emacs 25.1.1 (i686-w64-mingw32)
 of 2016-09-17
Package: Org mode version 9.0.1 (9.0.1-elpa @
c:/Users/scott/OneDrive/scotto/.emacs.d/elpa/org-20161118/)

Re: [O] Bug: Windows-unfriendly filename in org-preview-latex-process-alist customization

[Scott Otterson]

Happy to try it out.  Should I expect the change on elpa/org sometime soon?

Scott

On Sun, Nov 27, 2016 at 12:12 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Scott Otterson <sco...@sharpleaf.org> writes:
>
> > Thanks Fabrice.  After more experimentation, I found that image-converter
> > field of the customization alist should be:
> >
> > ("dvipng -fg %F -bg %B -D %D -T tight -o \"%o%b\.png\" %f")
> >
> > If this also works for *nix, then I hope that the org-mode maintainers
> will
> > make this string the new default.  If it doesn't work on linux, then I
> hope
> > that it's possible to come up with a string that works in both OS
> families
> > (and that could be the new default).  I'll be back on Linux in a few
> > months, and would love to keep a simple, cross-platform .emacs file.
>
> I introduced %O, which is the absolute output file name, as
> a replacement for %o%b.extension.
>
> Could you confirm the bug is fixed?
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Bug: Windows-unfriendly filename in org-preview-latex-process-alist customization

[Scott Otterson]

Thanks Fabrice.  After more experimentation, I found that image-converter
field of the customization alist should be:

("dvipng -fg %F -bg %B -D %D -T tight -o \"%o%b\.png\" %f")

If this also works for *nix, then I hope that the org-mode maintainers will
make this string the new default.  If it doesn't work on linux, then I hope
that it's possible to come up with a string that works in both OS families
(and that could be the new default).  I'll be back on Linux in a few
months, and would love to keep a simple, cross-platform .emacs file.

On Sat, Nov 26, 2016 at 5:35 PM, Fabrice Popineau <
fabrice.popin...@supelec.fr> wrote:

>
>
> 2016-11-26 16:41 GMT+01:00 Scott Otterson <sco...@sharpleaf.org>:
>
>> In my Windows build of emacs, when I put the cursor in a latex equation
>> and run
>>
>> M-x org-toggle-latex-fragment
>>
>>
>> then things chug along for a second but then fail.  In the *Org Preview
>> LaTex Output* buffer, I see the message:
>>
>> This is dvipng 1.15 Copyright 2002-2015 Jan-Ake Larsson
>> [1
>> dvipng: Fatal error, cannot open output file
>> c:/Users/scott/AppData/Local/Temp/"orgtex4628hQG.png
>>
>>
>> The reason for the failure is the leftover quote (...Temp/"orgtex...) in
>> the expected png output file.  With some hackery, I can see that the
>> command that's being run is:
>>
>> dvipng -fg "rgb 0 0 0" -bg "rgb 1 1 1" -D "102.0" -T tight -o
>> "c:/Users/scott/AppData/Local/Temp/""orgtex4628hQG".png
>> "c:/Users/scott/AppData/Local/Temp/orgtex4628hQG.dvi"
>>
>>
>> If I paste that into a cygwin xterm, it runs fine on the .dvi file that's
>> still in the Temp directory.  But the command fails in a Windows cmd
>> window; if I remove the extra quotes, then the command works in the cmd
>> window too.
>>
>> The extra quote comes from the default customization for the dvipng
>> image-converter field of org-preview-latex-process-alist:
>>
>> dvipng -fg %F -bg %B -D %D -T tight -o %o%b.png %f
>>
>>
>>
> This command should read :
>
> dvipng -fg %F -bg %B -D %D -T tight -o "%o%b.png" %f
>
> and the args shouldn't be quoted before.
> Unquoting those strings will possibly require to change other command
> strings.
>
> Fabrice
>

[O] Bug: Windows-unfriendly filename in org-preview-latex-process-alist customization

[Scott Otterson]

In my Windows build of emacs, when I put the cursor in a latex equation and
run

M-x org-toggle-latex-fragment


then things chug along for a second but then fail.  In the *Org Preview
LaTex Output* buffer, I see the message:

This is dvipng 1.15 Copyright 2002-2015 Jan-Ake Larsson
[1
dvipng: Fatal error, cannot open output file
c:/Users/scott/AppData/Local/Temp/"orgtex4628hQG.png


The reason for the failure is the leftover quote (...Temp/"orgtex...) in
the expected png output file.  With some hackery, I can see that the
command that's being run is:

dvipng -fg "rgb 0 0 0" -bg "rgb 1 1 1" -D "102.0" -T tight -o
"c:/Users/scott/AppData/Local/Temp/""orgtex4628hQG".png
"c:/Users/scott/AppData/Local/Temp/orgtex4628hQG.dvi"


If I paste that into a cygwin xterm, it runs fine on the .dvi file that's
still in the Temp directory.  But the command fails in a Windows cmd
window; if I remove the extra quotes, then the command works in the cmd
window too.

The extra quote comes from the default customization for the dvipng
image-converter field of org-preview-latex-process-alist:

dvipng -fg %F -bg %B -D %D -T tight -o %o%b.png %f


where the %o%b part of the customization concatenates two strings that are
already quoted. That's OK for *nix but apparently not for Windows.

I don't see a way to change the customization to fix this; can anyone take
a look at the elisp?

Thanks,

Scott

--- A test org file --

* Put cursor in the equation below and type C-c C-x C-l

\[
e^{i\pi} = -1
\]

--- My setup ---
Emacs  : GNU Emacs 25.1.1 (i686-w64-mingw32) of 2016-09-17
Package: Org mode version 9.0.1 (9.0.1-elpaplus @
c:/Users/scott/OneDrive/scotto/.emacs.d/elpa/org-plus-contrib-20161118/)


current state:
==
(too huge to send)

[O] org-store-link broken for bibtex file

[Scott Otterson]

Hi,  I've just updated to emacs 24.3.1 and org-mode 8.2, and the very
useful org-store-link function is now broken.

For years, I've been inserting bibtex file links into my org files with
this simple procedure:

  1. Put cursor on an article in a bibtex file
  2. C-c l
  3. Put cursor in org file
   4. C-c C-l

The result is a clean link in my org file that looks like this:

  Chow et al. 2010: Dynamic

But after the update, org-store-link (bound to C-c l) leaves the link
description empty, so that the link now looks like this:

  file:energy.bib::Chow10dynPCAintTransf

Does anyone know how I can recover the old org-store-link behavior?

Thanks,

Scott

Re: [O] org-store-link broken for bibtex file

[Scott Otterson]

Huh.

org-store-link worked perfectly after I ran my bibtex file through JabRef's
cleanup function.

I have not been able to isolate the change that caused the problem with
org-store-link, but apparently, the bad link description was my bibtex
file's fault.

Sorry for the false alarm!


On Mon, Sep 30, 2013 at 5:16 PM, Scott Otterson sco...@sharpleaf.orgwrote:

 Hi,  I've just updated to emacs 24.3.1 and org-mode 8.2, and the very
 useful org-store-link function is now broken.

 For years, I've been inserting bibtex file links into my org files with
 this simple procedure:

   1. Put cursor on an article in a bibtex file
   2. C-c l
   3. Put cursor in org file
4. C-c C-l

 The result is a clean link in my org file that looks like this:

   Chow et al. 2010: Dynamic

 But after the update, org-store-link (bound to C-c l) leaves the link
 description empty, so that the link now looks like this:

   file:energy.bib::Chow10dynPCAintTransf

 Does anyone know how I can recover the old org-store-link behavior?

 Thanks,

 Scott

[O] Feature request: hide target brackets

[Scott Otterson]

Targets and radio targets are great for ensuring that internal
hyperlinks go to the right place in your org document.  The problem with
them, though, is that they clutter up the text, making it less readable.

Attempts to get around this problem cause more problems.  For example, to
avoid the clutter, I often end up making a target below a headline that is
an exact copy of the headline text, like this:

* Correlation
* Mutual Information
  Mutual Information
  *** parametric
  *** non-parametric
* Correntropy

When the top headlines are collapsed, the above looks like:

* Correlation
* Mutual Information
* Correntropy

This is cleaner than putting the target in the headline, which would look
like this when collapsed:

* Correlation
* Mutual Information
* Correntropy

However, my redundant headline target is a maintenance mess (if you change
the headline, you need to remember to change the target) and when the
headline is expanded, things are even more cluttered.

So, here's my feature request:  Hide the target angle brackets in the same
way that square brackets are hidden for hyperlinks.  In other words,

targets or radio targets

should be displayed as

targets and radio targets

where a unique font tells you that they are targets.  The hidden angle
brackets could be exposed by hitting delete when at the right side of the
target (similar to how hidden hyperlink text is exposed now).

Code already exists to to do exactly this for [[hyperlinks]], and I thought
that it would be easy to reuse it for hiding targets.  But after
several hours of digging around, I realized that this is a job for the
experts.  Is anyone interested in taking it on?  I think it would be a big
improvement.

Thanks everybody for all the excellent work on org-mode!

Scott

Re: [O] ascii export problem/bug?

[Scott Otterson]

Thanks Jeff!  Of course, the missing install file was the problem.  I guess
org mode has evolved considerably since the last time I looked at the
manual...

Scott

On Thu, Apr 14, 2011 at 7:36 AM, Jeff Horn jrhorn...@gmail.com wrote:

 Do you have org-install.el in your init file?

 On Wed, Apr 13, 2011 at 8:08 AM, Scott Otterson sco...@sharpleaf.org
 wrote:
  When I start emacs and then edit an org file, ascii export fails (M-x
  org-export [return key] a).  No export file is created and I see the
  following message:
  Autoloading failed to define function org-export-as-ascii
  But if I type:
  M-x org-customize
  then export works.  The other way I can get this to work is to manually
 load
  org-ascii.el (which came with the org mode distribution).
  This is with org-mode version 7.5.
  Scott
 
 



 --
 Jeffrey Horn
 http://www.failuretorefrain.com/jeff/

[O] ascii export problem/bug?

[Scott Otterson]

When I start emacs and then edit an org file, ascii export fails (M-x
org-export [return key] a).  No export file is created and I see the
following message:

Autoloading failed to define function org-export-as-ascii

But if I type:

M-x org-customize

then export works.  The other way I can get this to work is to manually load
org-ascii.el (which came with the org mode distribution).

This is with org-mode version 7.5.

Scott

[Orgmode] feature request: C-k safety

[Scott Otterson]

For what must be the dozenth time, I've just accidentally deleted a large
tree by typing C-k while in a headline.

This is really easy to do because emacs users have C-k deletes to the end
of the line worn deeply into their neural pathways -- it's so automatic for
me that the keystroke is close to subconscious.  A mistaken C-k is
especially hard to detect because org-mode displays the result exactly like
what your subconscious expects, that is, a collapsed headline is deleted to
the end -- and the tree underneath is wiped out with no noticeable warning.

Feature request: add an option preventing tree deletion with C-k without
user confirmation.  Actually, I'd like an option to prevent it period.

If this option is already in there, then you're encouraged to tell me to
RTFM.  But then also please tell me where it is, because I can't find it.

Thanks much,

Scott
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Feature request: hide target brackets

[Scott Otterson]

Targets and radio targets are great for making sure internal links
go to the right place in your org document.  The problem with them, though,
is that they clutter up the text, making it less readable.

So, here's my feature request:  Hide the target angle brackets in the same
way that square brackets are hidden for hyperlinks.  In other words,
targets or radio targets should be displayed as targets and radio
targets, where a unique font tells you that they are targets.  The hidden
angle brackets could be exposed by hitting delete when at the right side of
the target (similar to how hidden hyperlink text is exposed now).

Thanks everybody for all the excellent work on org-mode!

Scott
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Org-mode version 6.30d; Hide stars

[Scott Otterson]

I also see this problem.  In addition, links are rendered in plain text 
instead of being hidden.  I'm using emacs 23 on OS X.


Scott

Carsten Dominic wrote:

Hi,

I cannot reproduce this.

- Carsten




___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] bugs in C-*

[Scott Otterson]

Thanks, Carsten.

Not only is this a bug fix, it's a nice improvement that increases  
consistency with other org operations.  I think it's fine touches like  
this that make org mode so intuitive.


Scott

On Jan 21, 2009, at 9:43 AM, Carsten Dominik wrote:


Hi,

following this thread,  I have revisited the commands
`C-c -' and `C-c *' and hope that they are now better
behaved and more useful:

...



___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] structure editing in brainstorming mode

[Scott Otterson]

On 12/29/2008 9:00 AM, Matthew Lundin m...@imapmail.org wrote:

  ...
"Rustom Mody" rustompm...@gmail.com writes:

..
  
2. Converting heading type
  
  
C-c - or S-left/right should do the trick.

This does replace '+' or whatever with '*' but it doesn't add the
leading stars, turning a list into a heading. But C-* does the trick.

Scott




___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] bugs in C-*

[Scott Otterson]

I just discovered the very handy C-* function -- I've been converting 
lists to headlines manually!   But I also discovered a couple of bugs:


If I select a region containing a plain list and then type C-*, org mode 
adds the leading stars but doesn't remove the plain list symbols, for 
example, this:


 * headline
   - list 1
   - list 2

is converted to this:

* headline
*** - list 1
*** - list 2

Also, if I'm at the end of a file so that the region can't be extended 
beyond the end of the last item in the list, then that item isn't 
converted.  In other words, I get this:


* headline
*** - list 1
 - list 2

Thanks,

Scott






___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] bugs in C-*

[Scott Otterson]

Yup, it's C-c *.  Thanks for updating the FAQ so quickly!

Scott

On 12/29/2008 12:19 PM, Matthew Lundin wrote:

...
I believe we've incorrectly typed the keybinding for org-ctrl-c-star.
In the previous posts and subject line, C-* should be C-c *.

Best,
Matt
  



___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] protecting ascii art

[Scott Otterson]

This great, but maybe it's not in the latest org version?  In 6.06b, 
when I type C-c ', I get sent to ffap.  This matches the comments in 
org-edit-special, which indicate that this is what will happen. 


Anyway, thanks for implementing this.

Scott

On 9/5/2008 2:58 PM, Carsten Dominik wrote:

...
This is a very good idea that fits right into the functionality of the
C-c ' command, so I have added it there.  If you now press C-c ' in
a region of lines starting with a colon, you get to edit this region in
artist-mode.  Also, if you press these keys in an empty line, a new
drawing is created.

I always wanted to have drawing in some way and even did some experiments
years ago - but I did not know of artist-mode.

Thanks for the ideas!

- Carsten

P.S. I believe that also the strikethrough problem is fixed by now.




Cheers

Will

--

Dr William Henney, Centro de Radioastronomía y Astrofísica,
Universidad Nacional Autónoma de México, Campus Morelia


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode





___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] protecting ascii art

[Scott Otterson]

Thanks!  Yes, this does work, and I'll definitely use it.

I wonder how hard it would be to automate those steps.

Scott

On 8/25/2008 5:26 PM, William Henney wrote:

Hi Scott
...
What seems to work is to first set aside some lines for your artistic
creation, select them, and do C-x n n (narrow-to-region) before
turning on artist-mode. Then, when you have finished, turn off
artist-mode and do C-x n w (widen).

This is a bit of a pain to remember the steps, but it does protect the
org file from getting clobbered.

Cheers

Will

  



___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] protecting ascii art

[Scott Otterson]

Yeah, that's what I thought about #+BEGIN_QUOTE too.

By the way, it would be lovely if it were possible to use emacs's 
built-in artist-mode:


   http://www.cinsk.org/emacs/emacs-artist.html

to draw diagrams inside of an org mode buffer.  Right now, hitting M-x 
artist-mode while already in org-mode clobbers the org file. 

But with some code twizzling, maybe it would be possible to use 
artist-mode to interactively draw ascii graphics, just like we can now 
create ascii tables.  That would make org-mode a complete text-based 
system -- a plain text paradise.


Scott

On 8/15/2008 6:34 PM, Eddward DeVilla wrote:

I think that's a bug.  prefixing the lines with : ought to do it.  It
prevents the | character from becoming tables, but it's not preventing
the + from creating strike throughs.  I would think that #+BEGIN_QUOTE
ought to work too, but it doesn't.  That maybe for export only.

Edd
  



___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] protecting ascii art

[Scott Otterson]

Is there a way to protect text regions from org mode parsing?  When I 
paste the following under an org mode headline:


  +---+  +-- future x
  ++  |predict|  |   +---+
 x --|TDL +--|   x   |--+--|   |
  ++  +---+  |predict|-- future y
 |   |
  ++ |   y   |
 y --|TDL +|   |
  ++ +---+

org mode scrambles it.  If I precede each line with a ':', org mode 
still scrambles it, but less so.


Thanks,

Scott



___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] html that looks like org mode in emacs

[Scott Otterson]

Ted, Bastien and Carsten.  Thanks for the tips! 


Of course, I'd forgotten that org-mode already had something built-in :

   #+OPTIONS: H:0

but

   org-jsinfo

is also pretty cool.   Finally, I'd never heard of

   htmlize.el

This gets the colors right but misses links.  Still, I will probably use 
it sometime to print out fontified code.


Scott


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] html that looks like org mode in emacs

[Scott Otterson]

Does anybody have a set of configurations that will produce exported 
html that looks like an org  file when viewed inside of emacs?


For example, I'd like to see this emacs orgmode buffer

* heading 1
  text for 1
** heading 1.1
   text for 1.1
** heading 1.2
   text for 1.2
* heading 2
* heading 3
   1. numbered 1
   2. numbered 2

Be exported to something that looks like this:

* heading 1
  text for 1
 o heading 1.1
   text for 1.1
 o heading 1.2
   text for 1.2
* heading 2
* heading 3
   1. numbered 1
   2. numbered 2

I'm asking because I spend the vast majority of my time in org mode, 
actually using it in emacs to organize stuff -- I shoot for a format 
that is easily readable in emacs itself.  Occasionally, I need to export 
the result to colleagues but the exported output is not very readable.


It would also be nice if there was a WYSIWYG ascii export mode.

Thanks,

Scott


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] bug in org-store-link

[Scott Otterson]

Yeah, I guess that instead of saying it was a small bug, I should have 
said that it's a bug of small consequence (for most users, but matters 
to me, least). 

The ambiguity problem you mention could be solved by matching more than 
one line.  To keep the string stored in the org link short, 
org-store-link could expand it to another line only when needed for a 
unique match.  Or, it could expand just enough _words_ to ensure 
uniqueness, plus maybe one word on each end for some insurance against 
future changes.


Future changes are the harder part.  In speech recognition, there's an 
analogous problem where there's a need to match a transcript to 
recognized speech, which may have a lot of word errors, insertions and 
deletions.  The simplest solution commonly employed is a word-level 
Levenshtein distance:


   http://en.wikipedia.org/wiki/Levenshtein_distance
   (this is for chars, but you get the idea)

Scott

Carsten Dominik wrote:
Hi Scott, this is not a small bug, but a problem that is really hard 
to solve.
Supposed I used the exact line text to search, then you still have two 
lines in the buffer

that would match.

This is really about what strategy should be used to find a location
in a file that has possibly changed.
I have no good answer to that.  Do you?

- Carsten 



___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] bug in org-store-link

[Scott Otterson]

Yes, starting with line numbers sounds like a good idea. So far, then,
the suggestion in its full glory is:

  link storage
  
include punctuation in matching pattern

  
  
expand matching pattern outwards until matching uniqueness is
assured across the whole file

store line number

  
  link search
  
start at stored line number
expand outwards until an exact match is found (update stored
line number if match has moved?)
if no exact match is found, scan the whole buffer for the best
soft match eg. minimum Levenshtein distance (update stored line number
and pattern if match has moved? Better ask the user.)

  

Scott

Nick Dokos (02/27/2008 08:20 AM) wrote:

  Two suggestions:

o Use a line number, instead of a search pattern and don't worry
about subsequent edits to the file that the link points to.

o Use the find-tag strategy: go to the line number as an initial
approximation. If the pattern is found there, done; if not, search
around that point for the pattern and keep expanding the area of the
search until found. I don't know if they still do it that way but I 
think that's how it was done some time ago.

Nick
  





___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] bug in org-store-link

[Scott Otterson]

Small bug in org store link.  To reproduce, put the cursor on line 1007 
and run org-store-link.  Then use the result to create a hyperlink in an 
org file, which for me looks like:


   
[[file:~/lib/c/pkgs/quicknet/qnstrn.cc::ftr1_window_offset%20ftr1_window_len][call]]


Then click on that hyperlink.  I get sent to line 899 instead of line 
1007. 

It looks like the reason is that org tosses out puncutation (+,).  I've 
found that, when linking to source code, punctuation is a big deal, so, 
if possible, it would be nice if org mode was made sensitive to it.


Keep up the good work,

Scott

#ifndef NO_RCSID
const char* qnstrn_rcsid = 
$Header: /homes/scotto/lib/cvsroot/lib/c/pkgs/quicknet/qnstrn.cc,v 1.5 2007/01/24 00:07:46 scotto Exp $;
#endif

#include QN_config.h
#include assert.h
#include float.h
#include stdio.h
#include stdlib.h
#include string.h
#include time.h
#ifdef QN_HAVE_LIMITS_H
#include limits.h
#endif
#ifndef EXIT_SUCCESS
#define EXIT_SUCCESS (0)
#define EXIT_FAILURE (1)
#endif
#include sys/types.h
#ifdef QN_HAVE_SYS_TIME_H
#include sys/time.h
#endif
#ifdef QN_HAVE_SYS_PARAM_H
#include sys/param.h
#endif
#include unistd.h

#if !QN_HAVE_DECL_SRAND48
extern C {
void srand48(long);
}
#endif

#ifdef QN_HAVE_SET_NEW_HANDLER
extern C {
typedef void (*new_handler)(void);
new_handler set_new_handler (new_handler);
}
#endif


#ifndef FILENAME_MAX
#define FILENAME_MAX (MAXPATHLEN)
#endif

#include QuickNet.h

static struct {
char* ftr1_file;
char* ftr1_format;
int ftr1_width;
char* ftr1_conf_file;
char* ftr2_file;
char* ftr2_format;
int ftr2_width;
char* unary_file;
char* hardtarget_file;
char* hardtarget_format;
char* softtarget_file;
char* softtarget_format;
int softtarget_width;
char* ftr1_norm_file;
char* ftr2_norm_file;
int ftr1_ftr_start;
int ftr2_ftr_start;
int ftr1_ftr_count;
int ftr2_ftr_count;
int hardtarget_lastlab_reject;
int window_extent;
int ftr1_window_offset;
int ftr2_window_offset;
int unary_window_offset;
int hardtarget_window_offset;
int softtarget_window_offset;
int ftr1_window_len;
int ftr2_window_len;
int ftr1_delta_order;
int ftr1_delta_win;
char* ftr1_norm_mode_str;
int ftr1_norm_mode;
double ftr1_norm_am;
double ftr1_norm_av;
int ftr2_delta_order;
int ftr2_delta_win;
char* ftr2_norm_mode_str;
int ftr2_norm_mode;
double ftr2_norm_am;
double ftr2_norm_av;
long train_cache_frames;
int train_cache_seed;
long train_sent_start;
long train_sent_count;
char* train_sent_range;
long cv_sent_start;
long cv_sent_count;
char* cv_sent_range;

QN_Arg_ListFloat init_random_bias_min;
QN_Arg_ListFloat init_random_bias_max;

QN_Arg_ListFloat init_random_weight_min;
QN_Arg_ListFloat init_random_weight_max;

int init_random_seed;
char* init_weight_file;
char* log_weight_file;
char* out_weight_file;
char* learnrate_schedule;
QN_Arg_ListFloat learnrate_vals;
long learnrate_epochs;
float learnrate_scale;
int unary_size;
int mlp3_input_size;
int mlp3_hidden_size;
int mlp3_output_size;
char* mlp3_output_type;
int mlp3_fx;		// NO LONGER USED
int mlp3_weight_bits;	// NO LONGER USED
int mlp3_in2hid_exp;	// NO LONGER USED
int mlp3_hid2out_exp;	// NO LONGER USED
int mlp3_bunch_size;
int mlp3_blas;
int mlp3_pp;
int threads;
int slaves;			// NO LONGER USED
char *cpu;			// NO LONGER USED
char* log_file;		// Stream for storing status messages.
int verbose;
int debug;			// Debug level.
} config;

static void
set_defaults(void)
{
static float default_learnrate[1] = { 0.008 };
static float default_bias_min[1] = { -4.1 };
static float default_bias_max[1] = { -3.9 };
static float default_weight_min[1] = { -0.1 };
static float default_weight_max[1] = { 0.1 };

config.ftr1_file = ;
config.ftr1_format = pfile;
config.ftr1_width = 0;
config.ftr1_conf_file = ;
config.ftr2_file = ;
config.ftr2_format = pfile;
config.ftr2_width = 0;
config.unary_file = ;
config.hardtarget_file = ;
config.hardtarget_format = ;
config.softtarget_file = ;
config.softtarget_format = pfile;
config.softtarget_width = 0;
config.ftr1_norm_file = ;
config.ftr2_norm_file = ;
config.ftr1_ftr_start = 0;
config.ftr2_ftr_start = 0;
config.ftr1_ftr_count = 0;
config.ftr2_ftr_count = 0;
config.hardtarget_lastlab_reject = 0;
config.window_extent = 9;
config.ftr1_window_offset = 0;
config.ftr2_window_offset = 4;
config.unary_window_offset = 3;
config.hardtarget_window_offset = 0;
config.softtarget_window_offset = 0;
config.ftr1_window_len = 9;
config.ftr2_window_len = 0;
config.ftr1_delta_order = 0;
config.ftr1_delta_win = 9;
config.ftr1_norm_mode_str = NULL;
config.ftr1_norm_mode = 

[Orgmode] Re: Release 5.22 (Carsten Dominik

[Scott Otterson]

Carsten Dominik wrote:

- M-RET no longer brakes a line in the middle, it will make a
  new line after the current or (if cursor is at the beginning
  of the line) before the current line.
  
I there a way to restore the old M-RET behavior? 

I use it all the time when brainstorming:  Often, when I see that the 
headline I'm typing is getting too complicated, I find that it needs to 
be broken into sub topics -- easy to do when you can walk the cursor 
through the headline and break it up with M-ret.


Suppose I've typed:

* Danish Bakfietsen: extended front wheel centers mass, adds steering 
linkage, cost, handling?


This is too long, and I have more info to add.  After a couple of 
M-ret's and M-right arrows, I have:


* Danish Bakfietsen
** extended front wheel centers mass
** adds steering linkage, cost, handling?

I realize that I will have a lot to say about cost and handling, so I 
M-ret again:


* Danish Bakfietsen
** extended front wheel centers mass
** adds steering linkage,
*** cost,
*** handling?

For me, one of the biggest org mode strengths is how quickly you can map 
out a thought and then reorganize with a few quick keystrokes -- the old 
M-ret behavior is just one example.  Based on listserv traffic, it 
sounds like most people use org mode for task tracking and GTD, so maybe 
my usage scenario is too outside of the mainstream, but still, I really 
liked  M-ret the way it was.


Keep up the good work,

Scott


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] org-export-region-as-latex exports more than region

[Scott Otterson]

Oops, I forgot to attach my .org file.  It's attached now. 

However, this bug may be fixed after the work of Nick and Bastien.  I'll 
check it out on the next release.


Scott

Scott Otterson wrote:
Huh, for me, both 'org-export-region-as-latex' and 
'org-export-as-latex' export all the tables, regardless of whether or 
not only one of them is highlighted.  I've attached an example org 
file.  If I select last table in the file, all tables are exported.  I 
wonder if this might have something to do with this particular 
document or maybe my .emacs?


Scott
* RUNS
*** Updated to Xavi's latest cvs on cluster and BeamformIt on 10/2/06

| corpus | data set |   run | comment   
   |

|+--+---+--|
| rt04s  | del4xs   |   63+ |   
   |

_Runs below with new code: [[CVS tag of my code w/ new PCA]]_ 
| corpus | data set|   run | comment
 |

|+-+---+-|
| rt05se | xc5 | 1598+ | 1416, no NR
 |
| rt04s  | NRall.xc1.0 | 1655+ | 1.0s XC, 0.5s ER, new PCA all NR   
 |
| rt05se | NRall.xc1.0 | 1677+ | 1.0s XC, 0.5s ER, new PCA all NR   
 |
_below, removed feat3/4 merge stream feats so that remStuckFrms.m will get 
called_
| devDD | broken speech tools 7226 | XC1ref, *, NR on, in case this matters 
for low dim pca input (dfw=1)  |
| tstDD |  broken 7262 | XC1ref, *, NR on, in case this matters 
for low dim pca input (dfw=1)  |

|---+--+---|
| dtDD  | 6474 | dimPick, ent1G, entNLG 
   |
| dtDD  | 6535 | dimPick, many new methods  
   |

* Reoptimize
*** TODO correlation manifold kernel support vectors from combinations of 
diariation speaker location models
*** Split CCA w/ do_feat_weights==1 :conclusion:

_Conclusions:_ 
1.) best perf is 13.42%, 
2.) beats baseline, 
3.) doesn't beat PCA-only dim reduction 
4.) but no gain over CCA-ER or XC dim reduction

  Total Diariz Error vs. Run [merged 5720, dev_DD, merged 5737, test_DD]

|  x |   feat | |   |  | dev,5720 |   | tst,5737 |  
 |  |  x |
| runNum | 3_nmix | feat3_pairFeats | worst | best |  tot |   |  tot | 
worst | best | runNum |
|++-+---+--+--+---+--+---+--+|
|  05703 |  1 | XCfCCA.CC.1 | 40.84 | 3.04 |18.21 |   | 15.5 | 
40.58 | 5.42 |  05720 |
  
*** Summary Table

||   |  |   |   |   |   |  ||   
  |
|+---+--+---+---+---+---+--++-|
|dev |   |  |   dev |   |   tst |   |  || dev   
  |
| runNum | worst | best |   tot |   |   tot | worst | best | runNum | note  
  |
|+---+--+---+---+---+---+--++-|
|  04677 | 49.26 | 2.75 | 18.04 |   | 17.29 | 46.08 | 2.96 |  04680 | baseline, 
dfw==0|
|  05739 | 44.36 |  3.3 | 16.01 |   | 15.03 | 40.15 | 1.96 |  05746 | baseline, 
dfw==1|
|  05386 | 36.36 | 2.58 | 15.17 |   | 13.03 |  24.3 | 3.65 |  05373 | XC-PCA
  |
|  05454 |  44.2 | 6.29 | 19.73 |   | 20.26 | 42.99 | 5.88 |  05455 | ER/XC 
  |
|  05716 | 36.39 | 2.36 | 15.22 |   | 13.42 | 30.47 | 2.34 |  05733 | 
XCfCCA.dMI.3|
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] org-export-region-as-latex exports more than region

[Scott Otterson]

Tables are one of the handiest org mode features, especially since I can 
export them into latex.  But there's a small bug:  If I select a single 
table in an org file, and then type:


   M-x org-export-region-as-latex

org mode exports all tables in that file, plus some miscellaneous headlines.

Scott


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] org-export-region-as-latex exports more than region

[Scott Otterson]

Tables are one of the handiest org mode features, especially since I can 
export them into latex.  But there's a small bug:  If I select a single 
table in an org file, and then type:


   M-x org-export-region-as-latex

org mode exports all tables in that file, plus some miscellaneous headlines.

Scott


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] up/down in tables

[Scott Otterson]

When I have the cursor in the middle of table and press the up or down 
key, the cursor moves up or down as expected, but it also goes to the 
left hand of the screen -- cumbersome when navigating wide tables, 
because you have to right-arrow back to the original column, if you can 
remember which column that was.


Is there a bugfix or a .emacs hack that would make the up/down keys keep 
the cursor in the original table column?


Thanks,

Scott




___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] up/down in tables

[Scott Otterson]

Nick and Eddward,

Thanks much for the quick replies. While generating a test case, I
killed the buffer containing the original .org file and then, when I
reloaded it, the problem went away! However, the "shift the cursor to
the left" problem has occurred many times before. If I can figure out
what sequence puts org mode into this state, I'll let you know.

Scott

Nick Dokos (12/30/2007 07:22 PM) wrote:

  Scott Otterson [EMAIL PROTECTED] wrote:

  
  
When I have the cursor in the middle of table and press the up or down
key, the cursor moves up or down as expected, but it also goes to the
left hand of the screen -- cumbersome when navigating wide tables,
because you have to right-arrow back to the original column, if you
can remember which column that was.

Is there a bugfix or a .emacs hack that would make the up/down keys
keep the cursor in the original table column?


  
  
I can't reproduce this on

  GNU Emacs 22.1.50.2 (i686-pc-linux-gnu, GTK+ Version 2.10.11)
  Org-mode version 5.15a

Nick
  





___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] emphasis customization error

[Scott Otterson]

While in the customization group Org Font Lock, I get this error message:

   scan error: unbalanced parenthesis, 22124, 47405

After I have set org hide emphasis markers to on and have clicked 
the set for current session button.


I'm using emacs 22.1.1 and org 5.15

Scott


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] sub-headline empahsis markers in 5.14

[Scott Otterson]

Now that the emphasis code has been simplified in 5.14, is it possible 
to go back and fix a lingering bug with emphasis and sub-headlines?  The 
problem is that emphasis doesn't work if it's applied on the first 
ub-headline character.  For example, emphasis fails for the first 
sub-headline below, but succeeds on the second.


* headline
*** _subheadline1_
***  _subheadline2_

By the way, the new ability to hide the emphasis markers is quite nice.


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Alt-rightArrow misses space

[Scott Otterson]

Just reporting  a small bug in org-mode 5.02...

In the outline between the dotted lines below, if I:

* put the cursor at the end of TODO confidence overlaps:
* hit M-ret
* hit M-rightArrow

A new subheadline under TODO confidence overlaps: is created, as
expected.  The problem is that the usual space after the right most
leading '*' is missing.   In other cases, the space is created correctly
but, for some reason, not this one.

Scott


* [[ASRU]] Paper (due 7/16/07)
*** TODO confidence and overlaps:
* remove



___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Feature request: HTML table formatting

[Scott Otterson]

I'll agree with Daniel that sometimes, it's useful to have vertical 
table separators.  Here's how I kind-of do it:


| asdlfj |   | alsjfdas |
|+---+--|
| alsdjf |   | aqsljf   |
| asdljf |   | asldjf   |

This is visible enough inside of org-mode and it yields a widish gap in 
exported html -- it's a horizontal screen space waster, though.  I 
suppose one way to denote a vertical separator without adding an extra 
symbol would be to allow tables in org-mode that look like this:


| asdlfj || alsjfdas |
|++--|
| alsdjf || aqsljf   |
| asdljf || asldjf   |

The exporter could then detect '||' and convert it to a vertical html line.

Scott

Date: Fri, 13 Apr 2007 06:23:16 +0200
From: Carsten Dominik [EMAIL PROTECTED]

On Apr 12, 2007, at 20:48, Daniel J. Sinder wrote:
  


 I think rejecting vertical rules as a matter of style is a mistake.
  Whether you consider org-mode tables to be a markup or a
 spreadsheet, it's peers -- HTML, LaTeX, Gnumeric, Excel, etc. --
 will all produce tables with vertical rules if asked to do so.  I'm
 wary of tools that enforce style.  I'd prefer to read the style
 guide and then decide for myself (that is, use it as a *guide* not
 an edict).



Fair enough.
  

 However, if vertical rules are too clunky, difficult,
 time-consuming, or low priority to implement, that's an entirely
 different matter that I can fully understand.



As I said, I don't want to have a special separator for this,
implementation would be very cumbersome and I'd like
to be able to have ! as a character in a table field.
Maybe something like a special #+FORMAT line above the table
to set special formatting directives.

- Carsten



___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] feature request: org-table-import without temp files

[Scott Otterson]

Lately, I've been creating a lot of tables from text from text files 
containing a mix of English text and columnar data (the stuff I'm 
importing).  This is pretty easy to do in org-mode:  save the columnar 
data to a temporary file and then run M-x org-table-import.  But it 
would be even easier if I could import the data without the temp file step.


One way to do this could be to add a new function, 
org-table-import-from-kill-ring:


  1. In the original text file, copy the tabular part into the kill
 ring with C-w or equivalent
  2. In the org file, with the cursor at the place for the new table,
 type M-x org-table-import-from-kill-ring

Another way could be to add a new function, org-table-import-to-kill-ring

  1. In the original text file, select the tabular data and type M-x
 org-table-import-to-kill-ring
  2. In the org file, put the cursor where you want the table and type C-y

Or, maybe there are more clever ideas?

Scott


___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Feature request: HTML table formatting

[Scott Otterson]

I'll agree with Daniel that
sometimes, it's useful to have vertical table separators. Here's how I
kind-of do it:

| asdlfj | | alsjfdas |
|+---+--|
| alsdjf | | aqsljf |
| asdljf | | asldjf |

This is visible enough inside of org-mode and it yields a widish
gap in exported html -- a horizontal screen space waster, though. I
suppose one way to denote a vertical
separator without adding an extra symbol would be to allow tables in
org-mode that look like this:

| asdlfj || alsjfdas |
|++--|
| alsdjf || aqsljf |
| asdljf || asldjf |


Scott


  Date: Fri, 13 Apr 2007 06:23:16 +0200
From: Carsten Dominik [EMAIL PROTECTED]

On Apr 12, 2007, at 20:48, Daniel J. Sinder wrote:
  
  

 I think rejecting vertical rules as a matter of style is a mistake.
  Whether you consider org-mode tables to be a markup or a
 spreadsheet, it's peers -- HTML, LaTeX, Gnumeric, Excel, etc. --
 will all produce tables with vertical rules if asked to do so.  I'm
 wary of tools that enforce style.  I'd prefer to read the style
 guide and then decide for myself (that is, use it as a *guide* not
 an edict).

  
  
Fair enough.
  
  
 However, if vertical rules are too clunky, difficult,
 time-consuming, or low priority to implement, that's an entirely
 different matter that I can fully understand.

  
  
As I said, I don't want to have a special separator for this,
implementation would be very cumbersome and I'd like
to be able to have ! as a character in a table field.
Maybe something like a special #+FORMAT line above the table
to set special formatting directives.

- Carsten






___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Feature request: HTML table formatting

[Scott Otterson]

I'll agree with Daniel that
sometimes, it's useful to have vertical table separators. Here's how I
kind-of do it:

| asdlfj | | alsjfdas |
|+---+--|
| alsdjf | | aqsljf |
| asdljf | | asldjf |

This is visible enough inside of org-mode and it yields a widish
gap in exported html -- a horizontal screen space waster, though. I
suppose one way to denote a vertical
separator without adding an extra symbol would be to allow tables in
org-mode that look like this:

| asdlfj || alsjfdas |
|++--|
| alsdjf || aqsljf |
| asdljf || asldjf |


Scott


  Date: Fri, 13 Apr 2007 06:23:16 +0200
From: Carsten Dominik [EMAIL PROTECTED]

On Apr 12, 2007, at 20:48, Daniel J. Sinder wrote:
  
  

 I think rejecting vertical rules as a matter of style is a mistake.
  Whether you consider org-mode tables to be a markup or a
 spreadsheet, it's peers -- HTML, LaTeX, Gnumeric, Excel, etc. --
 will all produce tables with vertical rules if asked to do so.  I'm
 wary of tools that enforce style.  I'd prefer to read the style
 guide and then decide for myself (that is, use it as a *guide* not
 an edict).

  
  
Fair enough.
  
  
 However, if vertical rules are too clunky, difficult,
 time-consuming, or low priority to implement, that's an entirely
 different matter that I can fully understand.

  
  
As I said, I don't want to have a special separator for this,
implementation would be very cumbersome and I'd like
to be able to have ! as a character in a table field.
Maybe something like a special #+FORMAT line above the table
to set special formatting directives.

- Carsten






___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] org-export gets mozilla; C-c C-o gets firefox

[Scott Otterson]

When I visit an org mode http link with C-c C-o, emacs opens up firefox
and goes to that url.  However, when I use:

org-export
b   

the Mozilla web browser pops up instead.  This is on a Linux machine,
org 4.68, and with the emacs variable browse-url-browser-function set to
browse-url-firefox.  I tried switching this browse-url-default-browser
and got the same behavior and then both org-export and C-c C-o pop up
Mozilla, so it appears that org-mode is ignoring the
browse-url-browser-function variable.

Does anybody know how I can make org-mode always pop up Firefox?

Thanks,

Scott


___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] internal links don't match other links

[Scott Otterson]

In org-mode 4.61, internal links don't match on external link 
description text.  Here's an example org file


--
* head1
 an internal link that should match the external link: [[BBC story]]
* head2
 [[http://news.bbc.co.uk/2/hi/americas/6262555.stm][BBC story]]
* head3
--

The behavior I was expecting was that a C-c C-o on the text BBC story 
under head1 would move the cursor to the link under head2.


When I'm writing big org files, I often create one headline per article 
I've read, and underneath it, I put an external link to the article and 
a bunch of text summarizing what I found interesting about it.  In other 
parts of the outline, I've tried to use internal links to that headline 
but I can't get it to work.


Scott


___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] link description -- selected text?

[Scott Otterson]

Thanks much, this is perfect!  Scott

Carsten Dominik (1/15/2007 10:44 PM) wrote:

I have implemented this behavior, thanks.
It has the side effect that the selected text is removed from the buffer,
even if you change the offered default description, but I guess this 
is ok.


- Carsten

On Jan 14, 2007, at 18:51, Scott Otterson wrote:

Here's a feature request:  If text is selected when the create link 
command is invoked (C-c C-l), then the selected text becomes the 
default contents for the link description mini-buffer.  If no text is 
selected, the description mini-buffer is blank, as it is now.


This would reduce substantially keystrokes for my usual style of 
editing, which is to first type in the outline text and then to go 
back and sprinkle it with links to references (to websites, bib 
entries, lines of code...).  For example, suppose I have written this 
sentence:


   Implement the RLS algorithm

And, suppose I've already stored a link to an RLS paper by typing C-l 
in in my bib file.  Then, while in the outline buffer, I'd like to be 
able to select the text RLS algorithm, and then hit:


   C-c C-l  (creates link minibuffer)
   enter  (enters stored link)
   enter  (enters selected text as link description)

As soon as it occurred to me that this would make org-mode more 
efficient, I realized that this is how other standard programs 
already handle html references; I'd guess that many would already be 
familiar with this small change in org-mode behavior.


Thanks for all the good work,

Scott



___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode




--
Carsten Dominik
Sterrenkundig Instituut Anton Pannekoek
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477




___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] internal links don't match other links

[Scott Otterson]

Can't a self-match just be excluded from the list of matches?  I don't 
know elisp regexps but in perl, the regexp would be:


   $match = $string =~/$description/  $string !~ /\[\[$description\]\]/;

This would match on $description in plain text or in external links and 
would exclude internal links.  This would be perfect for my uses 
although it's somewhat inconsistent because internal self links match on 
any plain text and this would be broadening that to only one type of 
link.   On the other hand, the current behavior is also inconsistent 
(doesn't match on any links).   For perfect consistency, I guess you 
could match on everything and then filter match positions to remove self 
matches.  This is probably harder, anyway, I think the semi-consistent 
approach is likely to be better for most use cases.


Well, you have excellent user interface taste, so I won't complain if 
you don't think this is worth your time!


Scott

Carsten Dominik (1/15/2007 1:21 PM) wrote:

That is on purpose, or a link would always find itself.

- Carsten

On Jan 15, 2007, at 18:28, Scott Otterson wrote:

In org-mode 4.61, internal links don't match on external link 
description text.  Here's an example org file


--
* head1
an internal link that should match the external link: [[BBC story]]
* head2
[[http://news.bbc.co.uk/2/hi/americas/6262555.stm][BBC story]]
* head3
--

The behavior I was expecting was that a C-c C-o on the text BBC 
story under head1 would move the cursor to the link under head2.


When I'm writing big org files, I often create one headline per 
article I've read, and underneath it, I put an external link to the 
article and a bunch of text summarizing what I found interesting 
about it.  In other parts of the outline, I've tried to use internal 
links to refer to that headline but I can't get it to work.


Scott




___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] internal links don't match other links

[Scott Otterson]

In org-mode 4.61, internal links don't match on external link 
description text.  Here's an example org file


--
* head1
an internal link that should match the external link: [[BBC story]]
* head2
[[http://news.bbc.co.uk/2/hi/americas/6262555.stm][BBC story]]
* head3
--

The behavior I was expecting was that a C-c C-o on the text BBC story 
under head1 would move the cursor to the link under head2.


When I'm writing big org files, I often create one headline per article 
I've read, and underneath it, I put an external link to the article and 
a bunch of text summarizing what I found interesting about it.  In other 
parts of the outline, I've tried to use internal links to refer to that 
headline but I can't get it to work.


Scott


___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] link description -- selected text?

[Scott Otterson]

Here's a feature request:  If text is selected when the create link 
command is invoked (C-c C-l), then the selected text becomes the default 
contents for the link description mini-buffer.  If no text is selected, 
the description mini-buffer is blank, as it is now.


This would reduce substantially keystrokes for my usual style of 
editing, which is to first type in the outline text and then to go back 
and sprinkle it with links to references (to websites, bib entries, 
lines of code...).  For example, suppose I have written this sentence:


   Implement the RLS algorithm

And, suppose I've already stored a link to an RLS paper by typing C-l in 
in my bib file.  Then, while in the outline buffer, I'd like to be able 
to select the text RLS algorithm, and then hit:


   C-c C-l  (creates link minibuffer)
   enter  (enters stored link)
   enter  (enters selected text as link description)

As soon as it occurred to me that this would make org-mode more 
efficient, I realized that this is how other standard programs already 
handle html references; I'd guess that many would already be familiar 
with this small change in org-mode behavior.


Thanks for all the good work,

Scott



___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Add a space with M-left/right (Carsten Dominik)

[Scott Otterson]

Carsten,

I can make this happen in the org file between the dashes:

* headline1
* headline2
* headline3
---
If I put the cursor at the end of headline2 and then hit M-enter, 
M-rightArrow, the result is a new headline with no space between the '*' 
and the cursor.


Scott

From: Carsten Dominik [EMAIL PROTECTED]

OK, next try:

I can reproduce this is a headline that contains only ***, bit no TODO 
keyword.

If there is a TODO keyword, the space is preserved.

I am also fixing this.

- Carsten

On Dec 16, 2006, at 21:03, Scott Jaderholm wrote:

  

Carsten,
I definitely have this problem in the middle of the buffer with 4.59. 
Console mode.


Thanks,
Scott

On 12/14/06, Carsten Dominik  [EMAIL PROTECTED] wrote:


 On Dec 13, 2006, at 17:37, Scott Jaderholm wrote:

  

Hi,

It is nice that M-RET adds a space after the last * so that you can
start typing right away. If I M-left/right the headline though 


before
  

I have typed anything then that charity space is eliminated, and I
often find myself accidently typing ***Something like this instead 


of
  

*** This. Can we make it so M-left/right preserves the space?


This is only a problem at the end of the buffer, I think.
For this case I have now fixed it, will be in 4.60.
If you also see that problem in the middle of the buffer,
let me know and we will dig deeper.

- Carsten

  

___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode




--
Carsten Dominik
Sterrenkundig Instituut Anton Pannekoek
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477





--

Message: 2
Date: Mon, 18 Dec 2006 10:29:23 +0100
From: Carsten Dominik [EMAIL PROTECTED]
Subject: Re: [Orgmode] Table questions
To: Michael [EMAIL PROTECTED]
Cc: emacs-orgmode@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Dec 14, 2006, at 17:19, Michael wrote:

  
I recently started using org-mode and love its table feature.  Here 
are some

questions that I have:

1. In table calculation, how to refer to a cell in a different column 
and
   different row?  Specifically, I want column 8 row 5 to be the ratio 
of

   column 7 row 5 and column 7 row 4.



You cannot, at least currently.  I am not sure how well this would
work, because the table editor makes it very easy to swap rows, columns,
to add and delete columns, and such references would become invalid
unless one would carefully track these changes.  There is a limit
of what is still reasonable with the concept of org-mode tables.
If you want to create really complicated tables, maybe you are better 
off

with a link to another file in which you use SES, or even Excel.

Having said this, I do want to do a bit more in this direction, but
this is nowhere near completion.

  
2. I think the table minor mode would be a fantastic tool in editing 
tables
   in a LaTeX file. I wonder whether it is possible to let orgtbl 
recognize
   \begin{tabular}\end{tabular} and use  as column delimiter rather 
than |

   (also respect end of line \\)?



Yes, I think it would and I have been thinking to make this possible.
However, once I allow this, people will want to use \multicolumn, and
this seems for me to be beyond the scope.

Have you tried

M-x align-current RET

in a LaTeX table?  It does wonders.

- Carsten





--

Message: 3
Date: Mon, 18 Dec 2006 10:39:32 +0100
From: Carsten Dominik [EMAIL PROTECTED]
Subject: Re: [Orgmode] Table questions
To: Eddward DeVilla [EMAIL PROTECTED]
Cc: Michael [EMAIL PROTECTED], emacs-orgmode@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII; format=flowed

I have no plans to make something as complicated as this work with
the orgtbl mode.  I agree it would be nice to have, but I would not know
where to start.

- Carsten


On Dec 15, 2006, at 17:08, Eddward DeVilla wrote:

  

I'll follow this up with a few more wishes.  Could the table minor
mode maybe be extended to allow the user to define delimiters?  Say
draw a picture?

struct hugeStaticTable initData = {
 // Draw a picture
 // ORG-ROW-DEF { /* key*/ $1 , /* name */ $2 , /* location */ {  /*
x */ $3 , /* y */ $4 } , /* comment*/ $5 },
 { /* key */ 0, /* name */ Bob, /* location */ { /* x */ 10.0, /* y
*/ 3.2 }, /* comment */ You know.  Bob!  Bob.  Good times... Good
times... }
 { /* key */ 1, /* name */ Joe, /* location */ { /* x */ 5.5, /* y
*/ 4.4 },  /* comment */ One fine batter. }
 ...
};

I code with a lot of static tables that are populated by hand.
Keeping them formatted is critical to keeping the code maintainable.
I'd think that this example might be too much for the table-minor
mode, but if there were a way to at least define a row beginning, end
and field separator, it might 

Re: [Emacs-orgmode] Re: [David O'Toole] Fwd: Re: org-publish future

[Scott Otterson]

How about using the agenda list of files to include selection method?  
Specifying files to be published is a similar problem so reusing the agenda method would 
be consistent in a way.  It works pretty well too.

Scott

Chris wallace [EMAIL PROTECTED] wrote:


PS.  On the subject of org-publish (sort of), one of the things I like most
about org-mode is that I can have Readme.org files scattered over a number
of directories and have them all included in the agenda.  However,
org-publish assumes all org files for a single project reside in a single
directory.  I wonder if I am the only one who has several directories per
project?



___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Emacs-orgmode] org-mouse 0.16: added support for checkboxes

[Scott Otterson]

Piotr,

With the latest org-mouse.el, when I right click on a headline, I get this 
error message in the mini-buffer:

 Symbol's function definition is void: find-if

Right clicks work fine if I'm not on a headline, though.

I'm using emacs 22.0.50.2

Scott



___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Emacs-orgmode] html export spacing, UI, links

[Scott Otterson]

Thanks, I didn't realize the shortcuts were arranged like that (I never 
manage to learn shortcuts for rarely used commands).  The nice thing 
about visible export is that it prompts you in the minibuffer after 
you've typed


   M-x org-export-visible

For the ordinary export commands, there aren't prompts, so if you don't 
know the shortcuts, you must type the whole thing eg.


   M-x org-export-as-html-and-open

There is always tab completion but the org-export-visible prompt is 
nicer.  I think that consistency in interface between the two types of 
export would also be nicer.  But it's a small touch...


Scott

Carsten Dominik (6/4/2006 2:54 PM) wrote:
I am not sure I understand what the problem is.  Are you saying that 
export-and open does not work with visible?  Or are you looking for 
simple and logical access to export commands.  There are keys for all 
of them, and the difference between visible and full export is 
simple.  For example, if ASCII export is on `C-c C-x a', then ASCII 
export of the visible part is C-c C-x v a'.  I.e. the keys are 
identical, you only need to sneak in a v after the C-x.


But as I say, I am not sure I understand correctly.

- Carsten

On Jun 3, 2006, at 0:51, Scott Otterson wrote:

I really like the interface Carsten created for visible exports, the 
one where you type:


M-x org-export-visible [RET]

and then hit a single key for ascii, html, or whatever.  For 
consistency, could this same approach be taken for the regular 
exports eg. org-export-as-html-and-open?


Thanks,

Scott





___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Emacs-orgmode] html export spacing, UI, links

[Scott Otterson]

I really like the interface Carsten created for visible exports, the one 
where you type:


M-x org-export-visible [RET]

and then hit a single key for ascii, html, or whatever.  For 
consistency, could this same approach be taken for the regular exports 
eg. org-export-as-html-and-open?


Thanks,

Scott


___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Emacs-orgmode] Export requests

[Scott Otterson]

I've got a couple of export requests:

1.) Remove the p's:   To me, at least, the list items in org-mode's 
exported html are spaced too vertically far apart.  However, I think the 
look is OK, when I just remove all of the p tags in the html file -- 
sort of matches the look of the ascii output that way too.   Is there a 
reason for those p's?  If so, could they optionally be removed?  I 
think it looks best to just wipe them all out, not just on the lists.


2.) html-like list lead characters in ascii export.  Conversely, it 
would be nice if the ascii exported list leading chars looked more like 
the html export.  In html, the list char changes with depth, starting 
with a solid bullet, then and empty one and then a square.  The ascii 
equivalent could be something like:


  * Level 1
- Level 2
  o level 3

I think allout.el had an option to let you set the correspondence 
between levels and lead chars, and this might be nice for org mode.  
True, I could come close to this behavior by just using plain lists in 
my outlines, and you are free to say so ;)


Thanks,

Scott


  



___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Emacs-orgmode] local variables for html export

[Scott Otterson]

I think there's an error in the org-mode manual.  The snippet at the end 
of section 9.2:


   * COMMENT HTML style specifications
   # Local Variables:
   # org-export-html-style:style type=\text/css\
  p {font-weight: normal; color: gray; }
  h1 {color: black; }
  /style
   # End: ***

needs to have prefixes and suffixes, like this:

* COMMENT HTML style specifications

# Local Variables: ***
# org-export-html-style:style type=\text/css\ ***
#p {font-weight: normal; color: gray; } ***
#h1 {color: black; } ***
#/style ***
# End: ***

At least this is the case with emacs 22.0.50.2

Scott





___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Emacs-orgmode] shell links [was: Version 4.19c]

[Scott Otterson]

Lot's of nice changes in 4.19.  I'm really impressed at how fast Carsten 
 Co. are cranking out new code and new fixes.


Looks like there are a few problems with shell links in 4.19c, though.

1.) If I type C-c C-l, and then at the link: prompt, type

shell:SPACE

   where SPACE means I hit the spacebar, then I get a [No Match] error
   message.  If I instead type:

shell:lsSPACE

   then I get the [No Match] error after the 'ls'

2.) If I manually make a shell link like this

 [[shell:ls *.org][shellcmd]]

and then type C-c C-o.  The minibuffer asks m:


  Execute   in the shel? (yes or no)

Even though there's a blank, the ls command works if I say yes

3.) If I put the cursor in the link and type C-c C-l, then
 the minibuffer says:

 Link: shell:ls%20*.org

If I cancel (C-g), C-c C-o still works.

Scott


___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode