Re: Possible bug report: URL capitalization in online manual

2020-02-08 Thread Bastien
Hi Ori,

Ori  writes:

> I'm not sure which repo this all lives in but I believe since
> information has been added to the paths, this should be easy. The
> other direction would be trickier and would need the old scheme.
>
> Wherever the current filename has capital letters after the first
> character, make an alias using the sentence-case version.
>
> Happy to take a stab at this if you can point me to the repo!

Thanks a lot for your help!

https://code.orgmode.org/bzg/org-mode/ is where doc/org-manual.org
lives.

By exporting the manual with ~$ make html and bisecting from Org's
repository, you may find the list of aliases that I can add.

I searched nginx docs on how to make URL matching case-insensible:
from what I understand, you can rewrite a case-sensibility-ignored
URL to another URL, but you cannot completely ignore case-sensibility.

If I am wrong, please let me know.

-- 
 Bastien



Re: Possible bug report: URL capitalization in online manual

2020-02-08 Thread Ori
I'm not sure which repo this all lives in but I believe since information
has been added to the paths, this should be easy. The other direction would
be trickier and would need the old scheme.

Wherever the current filename has capital letters after the first
character, make an alias using the sentence-case version.

Happy to take a stab at this if you can point me to the repo!

Ori

On Sat, Feb 8, 2020 at 2:15 PM Bastien  wrote:

> Hi Ori,
>
> Ori Barbut  writes:
>
> > Not sure if this was intentional?
>
> Yes -- old html manual pages where still around and I deleted them,
> because they confused people.
>
> > If so would it make sense to alias the old URLs for people who have
> > linked to the manual over the years?
>
> Yes, such aliases would make sense at the web server level.
>
> Can you track back on when the new scheme has been output when
> exporting the manual and provide an alias list I should add to
> the web server?
>
> That would really help a lot!
>
> Thanks,
>
> --
>  Bastien
>


Re: Possible bug report: URL capitalization in online manual

2020-02-08 Thread Bastien
Hi Ori,

Ori Barbut  writes:

> Not sure if this was intentional?

Yes -- old html manual pages where still around and I deleted them,
because they confused people.

> If so would it make sense to alias the old URLs for people who have
> linked to the manual over the years?

Yes, such aliases would make sense at the web server level.

Can you track back on when the new scheme has been output when
exporting the manual and provide an alias list I should add to
the web server?

That would really help a lot!

Thanks,

-- 
 Bastien



Possible bug report: URL capitalization in online manual

2020-02-08 Thread Ori Barbut
It seems that sometime in the past week the capitalization scheme of URLs
generated for the online manual has changed. For example I see as
of 2020-02-02 per the cache on Bing, the following url worked:
https://orgmode.org/manual/Structure-of-code-blocks.html

The new URL is:
https://orgmode.org/manual/Structure-of-Code-Blocks.html

This seems to be true for many urls with title capitalization, some other
examples:
https://orgmode.org/manual/Column-view.html
https://orgmode.org/manual/Sparse-trees.html

Not sure if this was intentional? If so would it make sense to alias the
old URLs for people who have linked to the manual over the years?


Re: Src blocks laid out side-by-side

2020-02-08 Thread Steve Downey
Only needs to be in the exported document, and doesn't necessarily need to
render that way within org. However, I'd like to avoid having to choose the
export form with custom markup in the org document. I often have documents,
or parts of docs, that are exported to both HTML and latex.

The equivalent that I'm doing in markdown are custom fenced blocks that
pandoc post-processes.

I suppose I could write some markup that on export gets processed to the
appropriate html or latex.

On Sat, Feb 8, 2020, 05:13 Fraga, Eric  wrote:

> On Friday,  7 Feb 2020 at 17:59, Steve Downey wrote:
> > I have a need to lay out source blocks side by side, in order to present
> > before and after changes to the source. If I could embed a block in a
> > table, that would do it.
>
> Do you need this layout in org file itself or only in an exported
> document from the org file?
>
> For the latter, you can use inline directives to achieve this.  E.g. if
> you were exporting to PDF via LaTeX, you could start/end minipages
> around each src block.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
>


Re: Src blocks laid out side-by-side

2020-02-08 Thread Berry, Charles



> On Feb 8, 2020, at 2:13 AM, Fraga, Eric  wrote:
> 
> On Friday,  7 Feb 2020 at 17:59, Steve Downey wrote:
>> I have a need to lay out source blocks side by side, in order to present
>> before and after changes to the source. If I could embed a block in a
>> table, that would do it.
> 
> Do you need this layout in org file itself or only in an exported
> document from the org file?
> 
> For the latter, you can use inline directives to achieve this.  E.g. if
> you were exporting to PDF via LaTeX, you could start/end minipages
> around each src block.
> 


Right. And the side-by-side issue for markdown is handled with inline html like 
this:

https://stackoverflow.com/questions/43232279/how-can-one-display-tables-side-by-side-in-github-markdown

The trick is that 'md snippets fall back to html. So @@html:  @@ etc are 
needed.

HTH,

Chuck 





RE: attachment: link type export to HTML invalid attach dir

2020-02-08 Thread Gustav Wikström
Hi,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 7 februari 2020 15:28
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> > Hmm, maybe that is so.. Except raw-path is called path (not really an
> > issue though) and there is another property called raw-link. Not sure
> > how to interpret the use of both path and raw-link. And there are
> > things happening between parsing the actual buffer link and storing
> > the raw-link and path parameters.
> 
> There is some normalization involved, indeed. The intent of :raw-link is
> to provide the link almost as it was in the buffer, without any parsing.
> I agree there should not be any `org-link-unescape' and
> `org-link-expand-abbrev' involved there. Something to fix at some point.
> 
> :path, on the contrary is parsed. It is the part of the link between the
> type and the search options, i.e., [[type:path::search]], [[type:path]],
> or [[path]].

Unless search-option applies as a general construct for all link types I don't 
think it should be in the parser. Given the discussion we've had about design 
of the parser from before. I.e. if the parser isn't supposed to know anything 
about the specific types themselves, all properties of the parsed elements have 
to make sense for all types of links. So either search-option remains but is 
parsed in exactly the same way for all link types, or it's not there at all. 
And if it's not available in the parser, the file link interpreters (that still 
might need to be constructed) gets to parse the :search-option from the 
raw-link as it wishes itself. 

Given the above paragraph, the :path and :search-option property doesn't make 
sense in the parser. :raw-link is enough. Less ambiguous names for :path and 
:search-option would be :file-path and :file-search-option. But that's 
sub-typing. We've already concluded that that should not belong to the parser.

> > In the end, what made me consider the sub-typing I've been writing
> > about could very well just have been the ambiguities regarding what's
> > what, and the lack of treatment for parts that arguably could be seen
> > as additional parameters to the link-path. For example the
> > "::extra_content" suffix in file links, that by the parser currently
> > is just a part of the path itself.
> 
> In [[file:name::extra_content]] :path is "name", and :search-option is
> "extra_content". As you noted, :search-option is not valid in non-file
> links, so it belongs to the path.
> 
> It seems there is some friction about this search option part. IIUC, you
> want attachment links to support this link-specific syntax. This is
> indeed not possible. As I commented earlier, letting libraries decide
> what the parser should do is not an option. There are a few options,
> though:
> 
> 1. Allow every link with an explicit type (i.e., not internal links) to
>have a search option, so you can write [[docview:filename::12]] or
>[[attachment:filename::*Section 2]]. IMO this is a waste, because
>most links do not need this, and it could become confusing
>[[https:www.orgmode.org::#sec2]].
> 
> 2. Provide a function in "ol.el" to do the parsing for you, so that
>every new link library doesn't have to re-invent the wheel. E.g.,
>(org-link-extract-search-options "foo::bar") => (:path
>"foo" :search-options "bar").
> 
> 3. Keep that way, i.e., any link library requiring to read the search
>part can do a dumb `match-string` and, in two or three lines of code,
>extract it. IOW, since this is so trivial, why bother?
> 
> WDYT?

I agree that option 1 is suboptimal. :search-option isn't obvious as a property 
for all link types. Since option 3 is fairly trivial, option 2 isn't necessary 
either. For attachment links to reuse the :search-option semantics, without the 
hard-coding we're currently doing, I see one option where attachment link 
higher order functions could reuse file link higher order functions. Those file 
link higher order functions don't exist yet as far as I know.

> > Maybe clearer documentation in the function of what each part is
> > /supposed/ to be, and the design principle that is applied, i.e. that
> > the path is the raw path with options included can help future me and
> > others who might want to understand. Thoughts on that?
> 
> There is some information in the manual, and the Org Syntax document.
> 
> > Hmm, don't really know if a link description should be regarded as
> > content. I for one hadn't considered it until now when you mentioned
> > it! But it preserves space in the parse tree I suppose.
> 
> This is unrelated to the size of the parse tree.
> 
> A description may contain Org specific markup, e.g., bold, so it needs
> to be parsed further. Therefore, a link with a description is not
> a leaf: it has contents.
> 
> > If the docstring of the link parser would make it clear what each
> > property is supposed to contain, in this 

Re: Src blocks laid out side-by-side

2020-02-08 Thread Fraga, Eric
On Friday,  7 Feb 2020 at 17:59, Steve Downey wrote:
> I have a need to lay out source blocks side by side, in order to present
> before and after changes to the source. If I could embed a block in a
> table, that would do it.

Do you need this layout in org file itself or only in an exported
document from the org file?

For the latter, you can use inline directives to achieve this.  E.g. if
you were exporting to PDF via LaTeX, you could start/end minipages
around each src block.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48



Re: How to intersperse commands with their output in RESULTS block?

2020-02-08 Thread Fraga, Eric
Excellent use of the :prologue and :epilogue header arguments!

-- 
: Professor Eric S Fraga; use plain text: http://useplaintext.email 
: https://www.ucl.ac.uk/chemical-engineering/people/prof-eric-fraga 
: PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D 



Re: org-adaptive-indent nil default

2020-02-08 Thread Texas Cyberthal
#+begin_quote alphapapa
I think you have a better case for changing this setting.  However, I
think there is another consideration: the default settings do not put
blank lines between headings and their entry text, and without any
indentation, headings and entry text on varying levels tends to blend
together, making for very poor readability.  Disabling this setting
would make this problem worse.
#+end_quote

I see what you mean now. Spacemacs lacks this problem thanks to org-bullets.

> the default settings do not put blank lines between headings and their entry 
> text,

It doesn't. However, it puts a blank line between entry text and the
next heading, when the current heading has a blank line preceding it.

I always took this as advice to separate entry text and headings with
blank lines. I assumed the lack of an automatic blank line immediately
after a heading was due to the fact that one might wish to place a
heading or a drawer on that line.

I see that under the vanilla defaults, with no blank lines, the little
adaptive indent at the start of the wrapped entry text helps one spot
the start of a heading's *

This is no big deal. Indenting the first line of a paragraph is a
matter of taste. I had it confused with org-indent-mode, which wastes
tons of space, but isn't enabled by default.

Anyway, vanilla Org has profound UI issues that can't be sufficiently
addressed to give normie-noobs a competitive modern induction
experience. So it may as well stay however makes the devs happiest.



mixed truncate/wrap mode for Org

2020-02-08 Thread Texas Cyberthal
#+begin_quote alphapapa
What would be useful would be if Emacs/Org could be configured to wrap
prose lines but not, e.g. tables and code blocks.  I don't think such
functionality exists in Emacs now, but here's a new package that may be
relevant: https://github.com/luisgerhorst/virtual-auto-fill
#+end_quote

That would be useful. mixed-pitch-mode already distinguishes codelike
from proselike. Which might help apply virtual-auto-fill only to
prose-like.

https://gitlab.com/jabranham/mixed-pitch

Seems this should be an Org feature, since it wants to combine prose,
tables and code.

#+begin_quote alphapapa
As well, it might be good to discuss on emacs-devel whether a feature
could be developed to truncate/wrap lines selectively; maybe
font-locking could be used to apply text properties to disable wrapping
dynamically (assuming that a feature could be developed to wrap based on
a certain text property).  Then we could have the best of both worlds,
and solve an existing problem, viz. that tables and code gets wrapped
when visual-line-mode is enabled.
#+end_quote

text-mode doesn't recognize org-mode tables or code blocks. Why would
it need selective truncation?



Re: org-babel strange html print in R

2020-02-08 Thread Jeremie Juste
Hello Jack,

Thanks for taking the time to reply.

> I think a more reliable implementation would be to avoid
> `org-babel-comint-with-output', and take the approach used in the
> ":results value" case, which reads the output from a temp file instead
> of directly from the shell.
I understand better now. Thanks
>
> Actually, that's the approach I use in my ob-session-async package [0],
> which re-implements ob-R sessions to allow async evaluation. It doesn't
> suffer from the bug you are reporting. I'll plan to extract that
> implementation and submit it as a patch here.

Your solution works just fine. I came across ob-session-async a recently
and find it very interesting thanks again.

#+begin_src R :results output html :cache no :async session
  library(xtable)
  x <- rnorm(100)
  y <- x + rnorm(100)
  a <- summary(lm(y ~ x))
  print(xtable(a),type="html",comment=FALSE)
#+end_src

#+RESULTS:
#+begin_export html

 Estimate   Std. Error   t value  
 Pr(|t|)   
(Intercept)   0.1249   0.0961   1.30   
0.1969  
x   0.9263   0.0879   10.53   
0.  
   
#+end_export

Best regards,
Jeremie



Re: babel comma escape with :wrap

2020-02-08 Thread Nicolas Goaziou
Hello,

Matt Huszagh  writes:

> There appears to be no way to disable the comma escape when using :wrap
> for a babel source block.
>
> I'm essentially trying to replicate this example from the manual
>
>  #+NAME: attr_wrap
>  #+BEGIN_SRC sh :var data="" :var width="\\textwidth" :results output
>
>echo "#+ATTR_LATEX: :width $width"
>echo "$data"
>  #+END_SRC
>
>  #+HEADER: :file /tmp/it.png
>  #+BEGIN_SRC dot :post attr_wrap(width="5cm", data=*this*) :results drawer
>
>digraph{
>a -> b;
>b -> c;
>c -> a;
>}
>  #+end_src
>
>  #+RESULTS:
>  :RESULTS:
>  #+ATTR_LATEX :width 5cm
>  [[file:/tmp/it.png]]
>  :END:
>
> But, my result type is a link not a drawer (which are mutually
> exclusive). So, to get the same wrapping effect, I need to use the :wrap
> argument. However, the comma escape negates attr_wrap's effect with this
> code

Could you clarify what you obtain, and what is wrong with it?

Thank you!

Regards,

-- 
Nicolas Goaziou



Re: babel link bug

2020-02-08 Thread Nicolas Goaziou
Hello,

Matt Huszagh  writes:

> -   (let ((file (and (member "file" result-params)
> -(cdr (assq :file params)
> +   (let ((file (cdr (assq :file params

This patch is wrong, with it, :file parameter alone would imply file
result, which is not sufficient. See commit
26ed66b23335eb389f1f2859e409f46f66279e15

"link" format is only meant to be used with "file" output.

Regards,

-- 
Nicolas Goaziou