Re: [O] [RFC] Change visibility for bracket links
Clément Pit--Claudel writes: Hi Clément, > Adam, what do you think of my earlier suggestion (displaying the > brackets when the pointer is on them, hiding them otherwise? (In the > style of prettify-symbols-mode with unprettify-symbol-at-point) Sorry, I missed that in the thread. That sounds like a great idea!
Re: [O] [RFC] Change visibility for bracket links
On 2016-10-07 22:38, Adam Porter wrote: > I understand the motivation for making this change, but I respectfully > request that this be made configurable. I much prefer the "clean" links > without visible brackets, and adding them would seem like a regression > to me. I'm guessing that many current Org users would also prefer to > keep the brackets invisible. Adam, what do you think of my earlier suggestion (displaying the brackets when the pointer is on them, hiding them otherwise? (In the style of prettify-symbols-mode with unprettify-symbol-at-point) Cheers, Clément. signature.asc Description: OpenPGP digital signature
Re: [O] [RFC] Change visibility for bracket links
Nicolas Goaziou writes: > I'd like to make the following change to bracket links display (i.e., > when `org-highlight-links' contains `bracket', which is the default). > > Basically, I want to leave a visible pair of brackets around the link, Hi Nicolas, I understand the motivation for making this change, but I respectfully request that this be made configurable. I much prefer the "clean" links without visible brackets, and adding them would seem like a regression to me. I'm guessing that many current Org users would also prefer to keep the brackets invisible. Thanks for your work on Org.
Re: [O] mass conversion?
Sharon Kimble writes:
> In an org-mode document which is then converted I'm using the latex
> glossary package, which shows my glossary items as '\gls{foo}'. I'm now
> getting to the stage of having a paper copy of the latexed PDF but am
> finding that the glossary items in the main text do not show at all when
> using just black text on a white background in the PDF.
>
> So what I'm trying to do is to underline each one in the org-mode text
> which converts very easily to underlined in the black/white paper PDF.
>
> But how can I do it globally please, using just a couple of commands to
> work on all instances in the org-mode file please?
I don't have much experience with LaTeX, but if I understand correctly,
what you're trying to do would typically be a candidate for a keyboard
macro in Emacs. As in, press F3, then use normal commands to search for
the next occurance and modify it (using commands that go
forward/backward by word or syntax), and then F4 when you've finished
modifying that instance. If you do it right, pressing F4 again should
modify the next instance, and so forth, until you reach the end of the
file.
There are also some handy packageson MELPA that will convert keyboard
macros to interactive commands/functions.
Hope this helps.
Re: [O] PDF font
Philip Hudson writes:
> On 7 October 2016 at 23:14, Nick Dokos wrote:
>> Philip Hudson writes:
>>
>>> Question: How do I specify how an Org element appears in the
>>> corresponding exported PDF? Specifically the typeface (font).
>>>
>>
>> E.g.
>>
>> #+LATEX_HEADER: \usepackage{palatino}
>
I should have said that this changes the font for the whole document.
> Right, that's one of the packages I found reference to. Nice, but not
> what I need.
>
What *do* you need exactly?
> Conclusion: There is no native Org-mode markup beyond
> bold/italic/underline that can change LaTeX/PDF text styling; it can
> only be done with embedded LaTeX escapes.
>
I think that's correct.
--
Nick
Re: [O] PDF font
On 7 October 2016 at 23:14, Nick Dokos wrote:
> Philip Hudson writes:
>
>> Question: How do I specify how an Org element appears in the
>> corresponding exported PDF? Specifically the typeface (font).
>>
>
> E.g.
>
> #+LATEX_HEADER: \usepackage{palatino}
Right, that's one of the packages I found reference to. Nice, but not
what I need.
>> Meta-question: Where might this question be answered that I haven't
>> looked? I haven't managed to find it in the manual or on Worg using a
>> fairly exhaustive variety of search terms. I've read an awful lot of
>> stuff that I more-or-less completely fail to understand about LaTeX,
>> something of which I currently know nothing, but I'm nevertheless
>> pretty sure none of what I've read actually addresses my question. The
>> nearest I came was reference to a small number of predefined packages
>> of three fonts each (serif, sans, mono) which I could switch between.
>> None of them match my requirement.
>
> This is indeed a LaTeX question,
I think that's really all I need to know.
Conclusion: There is no native Org-mode markup beyond
bold/italic/underline that can change LaTeX/PDF text styling; it can
only be done with embedded LaTeX escapes.
For my use case, I'll try changing to exporting to HTML with embedded
CSS, then converting the HTML to PDF using htmldoc.
Thanks, Nick.
--
Phil Hudson http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63
Re: [O] Bug: org-mode interprets * as a headline in text between #+BEGIN_.. and #+END_...
Hello, David Talmage writes: > What does the parser do with a drawer? How is that different from a > block? It seems that one can put text that looks like a headline in a > drawer and it won't be interpreted as a headline. Why couldn't blocks be > parsed the same way? Drawers behave in exactly the same way as blocks wrt headlines. Nothing can contain a headline. Regards, -- Nicolas Goaziou
Re: [O] PDF font
Philip Hudson writes:
> Question: How do I specify how an Org element appears in the
> corresponding exported PDF? Specifically the typeface (font).
>
E.g.
#+LATEX_HEADER: \usepackage{palatino}
> Meta-question: Where might this question be answered that I haven't
> looked? I haven't managed to find it in the manual or on Worg using a
> fairly exhaustive variety of search terms. I've read an awful lot of
> stuff that I more-or-less completely fail to understand about LaTeX,
> something of which I currently know nothing, but I'm nevertheless
> pretty sure none of what I've read actually addresses my question. The
> nearest I came was reference to a small number of predefined packages
> of three fonts each (serif, sans, mono) which I could switch between.
> None of them match my requirement.
This is indeed a LaTeX question, and if you are lucky enough to find a package
that sets up the font of your choice, the answer is as simple as the
example above. But if you don't, life gets *much* harder *very* quickly.
http://stackoverflow.com/questions/877597/how-do-you-change-the-document-font-in-latex
contains a sampling of a few of the different possibilities.
If you want to dig deeper, you might consult
https://www.tug.org/pracjourn/2006-1/schmidt/schmidt.pdf
--
Nick
[O] PDF font
Question: How do I specify how an Org element appears in the corresponding exported PDF? Specifically the typeface (font). Meta-question: Where might this question be answered that I haven't looked? I haven't managed to find it in the manual or on Worg using a fairly exhaustive variety of search terms. I've read an awful lot of stuff that I more-or-less completely fail to understand about LaTeX, something of which I currently know nothing, but I'm nevertheless pretty sure none of what I've read actually addresses my question. The nearest I came was reference to a small number of predefined packages of three fonts each (serif, sans, mono) which I could switch between. None of them match my requirement. -- Phil Hudson http://hudson-it.ddns.net @UWascalWabbit PGP/GnuPG ID: 0x887DCA63
Re: [O] [BUG] TRAMP error in PDF export
On 7 October 2016 at 14:31, Aaron Ecay wrote: > Org isn’t currently set up to handle compiling Latex documents on a > remote machine. I suppose the relevant function should detect such an > attempt, and immediately error out. Over the longer term, remote > compilation support could be added. Thanks for confirming that, Aaron. I agree that erroring out is the best short-term fix. Longer term, is remote compilation necessarily the right thing to do? We could instead (or also?) support local compilation. I see minuses both ways. Maybe the right thing would be to offer a config option. WDYT? -- Phil Hudson http://hudson-it.ddns.net @UWascalWabbit PGP/GnuPG ID: 0x887DCA63
Re: [O] Bug: org-mode interprets * as a headline in text between #+BEGIN_.. and #+END_...
Nicolas Goaziou writes: > Hello, > > Nick Dokos writes: > >> Is the "* on column 0 is a headline" convention a consequence of the >> dependence on outline.el? Or is it just historical baggage? I cannot >> remember the grammar rules, but I'm wondering if the parser could be >> made to say "not a headline" in this situation, and if so, what the >> consequences might be (particularly, the bad consequences). >> >> I'm not sure whether Nicolas has actually explained this situation in >> the past, but, with gmane non compos mentis, I did not attempt to find >> an earlier discussion. > > This is inherent on how the syntax is defined, and how the parser is > implemented. As an outliner, the main syntactic element in an Org > document is the headline. Everything else has a lower priority. > Therefore, a block will not be parsed before a headline. > > The good side of headlines being top level elements is that parsing > (without cache) only needs to start from the closest headline above. If > blocks could be parsed before headlines, parsing should start from the > beginning of the document every time. > Thank you. I appreciate both your patience and your explanations. -- Nick
[O] Bug?: Performance problem when loading file
Hello, I'm using Org-mode version 8.3.4 (release_8.3.4-1034-gadcaf9 @ /home/hs/.emacs.d/git/org-mode/lisp/) on emacs 25.1/25.2. With this version (also newer versions) I have a problem with loading files. I normally switch all files with extensions ".org" and also ".txt" to org-mode, even if the files are not a normal org file. This was no problem in the past. The problem happens on Linux and also on Windows (but more slow then on Linux). With current version it is a performance problem if the file contains following lines: 11.22 3 [xx_xxx]<0x> <<>> XX X XX XX->XX Data(hex): ff => 04 The content is from a log file and the problematic content is the "<<>>" part. (If I change the "<<<", ">>>" to "<<", ">>" the loading time in org-mode is ok.) If I have a file with around 160 lines as above and switch this file from fundamental-mode to org-mode it costs several seconds. A file with around 400K containing much of this lines costs minutes. I made an elp-instrumented measurement and the problematic part seems to be org-element-object-lex which called around 25760 times for the 160 lines file. With a bigger file it is much more. org-mode 1 1.089653152 1.089653152 org-update-radio-target-regexp1 1.073683384 1.073683384 org-element-context 160 1.071594578 0.0066974661 org-element--object-lex 25760 0.9774005559 3.794...e-05 org-element-radio-target-parser 12880 0.2644946760 2.053...e-05 org-element-subscript-parser 12880 0.1016634290 7.893...e-06 org-element-link-parser 12880 0.0978871550 7.599...e-06 org-element-verbatim-parser 12720 0.0708337510 5.568...e-06 org-element-at-point 160 0.0616519250 0.0003853245 org-element--parse-to 160 0.0577311660 0.0003608197 org-element--current-element 160 0.0327868739 0.0002049179 org-element-paragraph-parser 160 0.0264464149 0.0001652900 org-element-timestamp-parser 12880 0.0113777200 8.833...e-07 org-mode-reftex-setup 1 0.005703614 0.005703614 .. Question: Is there a bug in org-element or is this behaviour intended? With kind regards, Stefan -- Stefan-W. Hahn It is easy to make things. It is hard to make things simple.
Re: [O] Bug: org-mode interprets * as a headline in text between #+BEGIN_.. and #+END_...
On Fri, Oct 7, 2016 at 2:09 AM, Nicolas Goaziou wrote: > Hello, > > Nick Dokos writes: > > > Is the "* on column 0 is a headline" convention a consequence of the > > dependence on outline.el? Or is it just historical baggage? I cannot > > remember the grammar rules, but I'm wondering if the parser could be > > made to say "not a headline" in this situation, and if so, what the > > consequences might be (particularly, the bad consequences). > > ... > > This is inherent on how the syntax is defined, and how the parser is > implemented. As an outliner, the main syntactic element in an Org > document is the headline. Everything else has a lower priority. > Therefore, a block will not be parsed before a headline. > > ... That's interesting. Thanks for the explanation. What does the parser do with a drawer? How is that different from a block? It seems that one can put text that looks like a headline in a drawer and it won't be interpreted as a headline. Why couldn't blocks be parsed the same way?
Re: [O] [BUG] TRAMP error in PDF export
Hi Phil, Org isn’t currently set up to handle compiling Latex documents on a remote machine. I suppose the relevant function should detect such an attempt, and immediately error out. Over the longer term, remote compilation support could be added. -- Aaron Ecay
[O] Exporting big org file with contents split in other org files
Dear all, I know org-mode has an #+INCLUDE directive for header and initialization code. I was wondering whether this works also for creating contents below headlines. E.g. #+BEGIN_SRC org-mode * Chapter 1 #+INCLUDE: chapter-1-with-two-stars-headlines.org * Chapter 2 #+INCLUDE: chapter-2-with-two-stars-headlines.org #+END_SRC Otherwise, what is the preferred way of organizing very long documents which are better maintained as splitted, but still need to be exported together? Thanks a lot Giacomo
[O] Multi-line macros (again)
Greetings. I think I have discussed multiline Org macros here before. But I bumped into the issue again. One of the most useful properties of LaTeX is \newcommand, which allows you to reuse document structures. I really, _really_ miss this feature in Org. Org has #+MACRO, but it is limited to a single line. That is very inconvenient for any larger structures. I was thinking (awfully sorry, will stop soon). Could we have multiline macros, something like #+BEGIN_MACRO name #+END_MACRO where everything between the begin and end would be expanded just like (single line) macros are right now. With newlines included in the expansion. How about it? Jarmo
