Re: File Scoped Properties?
On Thursday, 5 Mar 2020 at 10:28, Tim Visher wrote: > I _am_ able to get it to work by adding a file local variable like > > ``` > # Local Variables: > # org-attach-id-dir: "~/.foo/data" > # End: > ``` > > but then whenever I open the file it tells me it's possibly not safe to set > that. You've already received a more org-ish response but I'll give you an Emacs response to this part of your post: Emacs is simply making sure you are aware that a variable is being set when visiting a file. It's a form of security to ensure you don't have a file do something you don't want it to do. If you are happy for that variable to be set by files in this way generally, Emacs does give you the option of saving this information in the customization file and you won't get asked again. It's not that setting this variable this way is dangerous per se. But, for instance, this variable could be set by some file you receive from somebody else to a destination that is off your computer, e.g. using tramp. This is the closest that Emacs comes to being vulnerable to viruses (computer, not COVID-19 ;-)). -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Bug: org-agenda fails to interpret UTF-8 filenames in some cases
On Thursday, 5 Mar 2020 at 11:41, Lubos Boucek wrote: > Hello, > > After adding file "úkoly.org" (filename written with Czech keyboard) > with `C-c [`, immediate `M-x org-agenda t` goes through. However, > after restarting emacs, the same command stops with warning > "Non-existent agenda file c:/Users/lubos/Documents/org/úkoly.org. > [R]emove from list or [A]bort?". This looks like an encoding issue. Have a look at your emacs customization file (.emacs, .emacs.d/init.el, wherever customized variable settings are placed in your case) and fix the file name properly there? I know that I have the following line (as the first line) in some of my emacs files: # -*- coding: utf-8; -*- Maybe put that in your org customization file? But I should warn you that I still find encoding issues perplexing in Emacs. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Nested quote blocks?
On Wednesday, 4 Mar 2020 at 12:57, Tim Visher wrote: > Thanks for responding, Eric. :) You're very welcome! > IIUC, your solution should work but it's necessarily tied to specific > export backends, right? It is partly but the general concept of using special blocks works for HTML also. You end up with code that looks like this: , | | | and this is the inner block | | | ` which means you can customize its appearance using appropriate CSS code. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Analyze tangled files
On Tuesday, 3 Mar 2020 at 19:17, Ag Ibragimov wrote: > Is there a way to compare all tangled files with the content of an Org > document and see a diff? Not as far as I am aware of. However, you can "untangle" source files back into the org file so you could do a diff on the org file with a previous version (especially easy if using version control). See info manual: (org) Extracting Source Code Take particular note of the :comments argument for the src blocks. Caveat: untangling has sometimes mangled my original org file. See version control above! HTH. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Nested quote blocks?
On Tuesday, 3 Mar 2020 at 12:57, Tim Visher wrote: > Is there a way to get nested quotes blocks to work? What is your actual goal? That is, what you do mean by "to work"? I ask because although, as Nicolas has said, you cannot do this directly with org, you can achieve some specific goals with special blocks and/or drawers. For instance, if your goal were to export to LaTeX, this code would do the job: #+begin_src org ,#+latex_header: \let\myquote\quote ,* testing nested blocks Joe said: ,#+begin_quote This is the outer block. ,#+begin_myquote and this is the inner block ,#+end_myquote followed by the outer block. ,#+end_quote and that is all folks. #+end_src -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: ob-python.el: questions about output
On Monday, 24 Feb 2020 at 08:18, Jack Kamm wrote: > This sounds interesting. Do you know of any documentation or examples > for :prologue and :epilogue? I checked the Worg page for ob-maxima, but > it didn't mention these header arguments. I don't know of any documentation. They basically simply provide strings that are included before and after the text within the src block before evaluation but are not exported in a code listing. I can give you an example of how I use these with maxima: #+header: :prologue "fpprintprec: 2; linel: 50;" #+header: :epilogue "print(solution);" #+begin_src maxima :exports both :results output :cache yes solution: exp(1.0); #+end_src which sets the printing precision for numbers to 2 and the line length to 50 and prints out the contents of the solution variable at the end. These are details that are not important for display; I use these settings all the time for my lecture slides. The above example gives the following when exported to ascii: , | solution: exp(1.0); ` , | 2.7 ` so the slides can concentrate on the material that is important. Adding such to ob-python etc. should not be difficult. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: ob-python.el: questions about output
On Monday, 24 Feb 2020 at 08:17, Jack Kamm wrote: > 1. noweb (as Eric mentioned). Then you only need to write the code > once, but note that it will be executed twice. Doesn't need to execute twice: maybe add ":eval no" to the first block, the one that will be included in the other one? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: ob-python.el: questions about output
On Monday, 24 Feb 2020 at 02:13, R C wrote:
> When exported I would like the line: return 'img/ex1.png' not to be
> included in the listing of the src block.
I don't think this is currently possible in the sense you want.
You could use :noweb where you have one src block referring to others
and only output the code for the main body. E.g. something along the
lines of
#+name: mainblock
#+begin_src python :results file :noweb yes
def f(x): return np.polyval(a, x)
a = [1, -4, 4.5, -1.5]
x = np.roots(a)
print(f'Roots of the polynomial are {x}')
x_ = np.linspace(np.min(x), np.max(x), 100)
#+end_src
#+name: full
#+begin_src python :results file :noweb yes
import numpy as np
import matplotlib.pyplot as plt
<>
plt.plot(x_, f(x_))
plt.plot(x, f(x), marker='o')
plt.savefig('img/ex1.png')
return 'img/ex1.png'
#+end_src
Longer term, better would be an implementation of :prologue and
:epilogue options for python src blocks like we have for Maxima. It
would probably make sense to provide these options for most if not all
src blocks?
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Limiting properties and property values
On Sunday, 23 Feb 2020 at 15:10, Vikas Rawal wrote: > I am thinking of using org-mode to compile a small database. Although org is fantastic, it is sometimes worth considering other tools (and with babel, these can often be brought into the org sphere of activity easily). For instance, GNU recutils [1] might suit you better. There's even an emacs mode [2]. Just my 2¢. Footnotes: [1] https://www.gnu.org/software/recutils/ [2] https://www.gnu.org/software/recutils/rec-mode-manual/rec-mode.html -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Bug or not a bug? dot expansion in ob-shell
On Friday, 21 Feb 2020 at 09:04, Bastien wrote: [...] > That said, we have three solutions: > > 1. Stick to a strict reading of Org and bash manuals: the absence of a >:results header means "return the value, i.e. the exit status". [...] > Obviously, nobody wants the first solution. Respectfully, I disagree! I think the first solution is the cleanest and most correct one. Yes, this means a change in the behaviour but the current behaviour, in my opinion, is wrong given org and bash documentation. I definitely do not like the third option (yet another variable). Thank you. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Item descriptions get surrounded by wrong curly braces in LaTeX export
On Wednesday, 19 Feb 2020 at 18:15, Bastien wrote: >> The problem, I think, seems to have been caused by commit 5acf4d4692 > > Indeed, it should be fixed now, thanks! Confirmed! Many thanks. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Exporting comments to comments?
On Wednesday, 19 Feb 2020 at 11:04, Allen S. Rout wrote:
> I thought about making a block of a 'comment' type, but of course all
I use drawers for this functionality. By default, I do not export
drawers (#+options: d:nil) but I can turn this on and then process
specific drawers using filters, as in:
#+begin_src elisp
(setq org-latex-format-drawer-function
(lambda (name contents)
(cond ((string= name "solution")
(format
"\\begin{mdframed}\\paragraph{Solution.} %s\\end{mdframed}"
contents))
(t (format "\\textbf{%s}: %s" name contents)
#+end_src
which I use for :solution: drawers when preparing courseworks/exams. If
you want to ignore all other drawers except specific ones, have no
action in the =t= clause of the =cond=.
Using this right now preparing a coursework for my students... ;-)
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: Item descriptions get surrounded by wrong curly braces in LaTeX export
The problem, I think, seems to have been caused by commit 5acf4d4692 which addressed problems with check boxes. I'm not sure how to fix it. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: Item descriptions get surrounded by wrong curly braces in LaTeX export
On Tuesday, 18 Feb 2020 at 00:50, Joon Ro wrote:
> Hi,
>
> I noticed that in LaTeX export, descriptions in description lists are
> surrounded by {} instead of [] in LaTeX export, making them not
> correctly rendered.
I can confirm this with the latest version of org from git. The outcome
is not what is desired nor what was previously the case.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 14:43, Bastien wrote:
> Note that currently (9.3) we have this:
[...]
> ... so the default today is not even to consider "the last command",
> but the output of all commands.
Maybe, if you wish to get version 9.4 out, the best approach would be to
fix that one outlier case ("." giving "0") for now and later handle
value/output distinction properly (should it be desired, of course)?
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: problem with org-capture for calendar invite
On Wednesday, 19 Feb 2020 at 13:38, Bastien wrote: > Yes, this was a mistake I made when trying to warn the user for > missing initial contents or annotation. > > Fixed now, thanks for reporting this, Confirmed. Thank you! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 14:00, Bastien wrote: > Anyway, I don't have yet a clue on how to add this new option. I'll > leave it to Eric first (if he has time) then look at it later this > week. Time is an issue (middle of teaching term). More importantly, my elisp-fu is not necessarily up to the level required. It would be best if somebody up to speed with org babel attempt this. In any case, it would be interesting to know if people do depend on value being somehow the output of the last command in a shell script. I'd never even considered that possibility, at least not consciously! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-345-g415083
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote: > "0" is the _exit code_ of the successful echo command, not the value > returned by the echo command. But echo does not "return" the string as a value. It outputs the string. To quote the man page for bash, "the return value of a simple command is its status". Further, a function does not actually return any value beyond the status of the last command or a value given on a =return= statement. > So In Vladimir's example, both ":results value" and ":results output" > should return the same result, i.e. ".". I disagree. I think the current behaviour (i.e. before your attempt to "correct"" this) is correct given the documentation you quoted! > Was it common to expect the exit code when executing shell code? Common? I have no idea. *I* did expect this. But that's maybe because I do use the shell a lot. I think there's a clear distinction between value and output for src blocks and blurring this distinction for shell src blocks would be misleading. The option to request the output as the outcome of the src block is already there. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-345-g415083
problem with org-capture for calendar invite
For a long time, I have been using this template for org-capture:
#+begin_src emacs-lisp
(add-to-list 'org-capture-templates
'("#"
"used by gnus-icalendar-org"
entry (file+olp+datetree "~/s/notes/diary.org")
"%i"
:immediate-finish t))
#+end_src
For some reason, this no longer works and I get the following error:
,
| Debugger entered--Lisp error: (error "Capture abort: Missing initial
annotation in this ...")
| signal(error ("Capture abort: Missing initial annotation in this ..."))
| gnus-article-read-summary-keys(nil)
| funcall-interactively(gnus-article-read-summary-keys nil)
| call-interactively(gnus-article-read-summary-keys nil nil)
| command-execute(gnus-article-read-summary-keys)
`
The problem is the %i in the template above. This will include any
"description" found in the calendar invite, if there, but should be
nothing if not. I am sure (but maybe I am wrong) that this capture
template used to work before.
In any case, if the initial contents are not defined, should this really
be an error?
org up to date from git as of a minute or two ago; emacs from git from a
couple of days ago.
Thank you.
PS - maybe it's gnus that is at fault here?
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-345-g415083
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 10:41, Bastien wrote: > It returned "0" for me, while I guess "." is expected. I expected 0 as that is the "value" (i.e. the status in a shell) of the last command. If you want ".", I would expect one to use :results output in the src block header? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 17:02, Vladimir Nikishkin wrote: > Could you check if the following block behaves as expected? It does for me. What did you expect and what did you get? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772
Re: suggest using E-M-S 3-line notation from HAL/S for super/subscripting
On Tuesday, 18 Feb 2020 at 00:43, VanL wrote:
> Question for the list. Can the HAL/S notation be used for editing a
> symbol, in expanded form, with prefix/postfix sub/superscript? The
> collapsed form is a single line pretty printing tiny sub/superscript
> before and after the symbol.
Maybe (probably?) not what you are looking for but if you want something
that meets the output requirements for LaTeX export (i.e. to PDF), you
can use the =mhchem= package [1] and typing
\(\ce{^{21}Ne}\) and \(\ce{^{3}He}\)
will generate what you want.
No special editing unfortunately.
HTH,
eric
Footnotes:
[1] https://www.ctan.org/pkg/mhchem?lang=en
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772
Re: Multiply alerts for icalendar export
On Wednesday, 12 Feb 2020 at 09:46, Bastien wrote: > Perhaps adding three different appointments to get three alerts is > good enough? Noting, of course, that you can have multiple time stamps (active ones in this case) associated with a single heading. I do this every so often. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Re: Short captions
On Tuesday, 11 Feb 2020 at 14:50, Anthony Cowley wrote: > They are described in section 12.8 Captions Thanks. Missed that. I was looking in the LaTeX export section of the manual which doesn't mention short captions! And, actually, the :caption option for tables, say, doesn't seem to support such? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Re: Short captions
On Monday, 10 Feb 2020 at 23:20, Anthony Cowley wrote: > I am having trouble understanding how short captions are supposed to > work. Consider this org document: [...] > The first matches my expectations. The second is an example of taking > the last bit of markup as the short caption. The third seems to lose > the short caption altogether. I can confirm (with a slightly out of date org) this behaviour which does seem to be inconsistent and/or wrong. However, I wasn't able to find any discussion of short captions in the org manual so I'm not sure if there are caveats on their use. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Re: Src blocks laid out side-by-side
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?
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: How to intersperse commands with their output in RESULTS block?
On Friday, 7 Feb 2020 at 16:26, Diego Zamboni wrote: > Quick follow up about this: following Eric's suggestion, I came up with the > following block, which cleans up all the cruft from the output of the > =script= command and produces a nicely formatted session transcript: You might like to add "--quiet" to the =script= command to reduce some of the cruft. Otherwise, I'm glad you got something working! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
Okay, I get it: Emacs (especially vanilla) just doesn't meet your requirements. So be it! Horse for courses, as they say here in the UK. All I can say is that I find most, if not all, other tools so frustrating. I can never get them to work the way I want. With Emacs, I can. Yes, this means that I have to work at customizing and this is not easy for a beginner. But I can. One minor point, in case anybody else reading this thread might find this useful: >> What about turning on whitespace-mode? > > That makes all the spaces visible, which isn't legible. As with all things Emacs, this is completely customizable. You can have whitespace mode show/highlight the bits you want and not the others. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
On Thursday, 6 Feb 2020 at 20:09, Texas Cyberthal wrote: > A blank line is useful, yes. Use of demi-paragraphs implies use of > line breaks to signal stronger transitions. E.g., from my recent > workflow: I get this. My own approach is to simply use - at the start of the line and then each of these demi-paragraphs becomes a list item which are wrapped nicely (whether with visual or fill mode). > What vanilla Emacs Org default visual-line-mode is missing for > informal prose notes: > - recognize sentences with a single space after terminal punctuation Does for me. Maybe I've customized something... that's the problem with a .emacs file that has elements that date back 37 years... ;-) > - word wrap Not sure what you mean here. Visual mode does this; so does fill mode. What I am failing to understand from you is your frequent reference to truncation but then wanting wrapping? I'm obviously missing something. > - more line spacing and a variable pitch font This is "look and feel" and easily addressed, as others have noted, by a theme. > - denote single line breaks with the absence of continuation marks, as > truncate lines nil does What about turning on whitespace-mode? > visual-line-mode's minor luxury of slightly easier navigation to > arbitrary visual line endpoints doesn't compensate for loss of the > critical ability to identify logical lines with single line breaks, > and the loss of keybinds for quick navigation to their endpoints. So turn off line-move-visual. I guess what I am saying is what I said earlier: a simple org mode hook with some settings would be all the customization you would need to achieve your desired writing experience and could easily be an example early in the org mode manual. Does spacemacs initialise things they way you want them? If so, go with it but I guess there are other things about spacemacs that you do not like? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
So, the only problem that you have, as far as I can tell, is that Emacs doesn't distinguish paragraphs by a single newline character but requires 2 instead? For me, a blank line between paragraphs is very useful to visually identify new paragraphs (or demi-paragraphs). For writing and for intra-paragraph navigation, what is necessary beyond visual-line-mode, next-line (C-n, ), forward-word (M-f), forward sentence (M-e), and forward-paragraph (M-}), and equivalent for opposite direction? (Okay, maybe a few others like begin/end of line, paging up and down, etc.) What does spacemacs provide that vanilla Emacs does not? (I've never used spacemacs so please excuse my ignorance.) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
On Thursday, 6 Feb 2020 at 17:46, Texas Cyberthal wrote: > auto-fill-mode definitely isn't what I want. Why not? Just curious. Before I switched to visual-line-mode for all org documents, I used auto-fill-mode for prose all the time. Together with fill-paragraph (M-q), this did the job very well. > Beyond that I don't understand your question. My question was: what do you mean by paragraph navigation? And, supplementary, what is missing in vanilla emacs in this respect? And, yes, if I had a beard, it would be grey. ;-) But I would be more than happy to see new users embrace Emacs & org mode. They are missing out on a fantastic system. Unfortunately, people are blind to the "it's all text" paradigm due to the frills of buttons, mice, and menus which paradoxically get in the way of productivity. The same issues arise in the LaTeX vs Word debate... and having to produce technical documents (articles, books, proposals, presentations) for a living, LaTeX is the only way to go. But this is for another day. :-) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
On Thursday, 6 Feb 2020 at 10:33, Texas Cyberthal wrote:
> Visual line mode is annoying and unnecessary; Spacemacs users do not
> need it because its defaults offer adequate paragraph navigation.
I'm not sure I understand the conflation of visual-line-mode with
paragraph navigation. Is it because you mean intra-paragraph navigation
as opposed to M-{ and M-} for navigating from paragraph to paragraph?
Maybe auto-fill-mode is what you want?
In any case, the solution may simply be some example org mode hooks
with, say, settings for writing prose and have these in the org mode
manual?
Fundamentally, emacs is challenging because it is both powerful and
completely customizable. I remember a colleague complaining that Linux
was not friendly because you had too much choice. Emacs takes that to
another level. And that's why many of us live in it...
--
: 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?
On Wednesday, 5 Feb 2020 at 18:25, Diego Zamboni wrote: > tl;dr: is there a way to have ob-shell (or some similar mode) run commands > one by one and include the commands, interspersed with their output, in the > #+RESULTS block? You haven't said on what type of system but, if Linux, you could try using =script= as a starting point: #+begin_src shell :results output script <
Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]
On Wednesday, 5 Feb 2020 at 09:14, Bastien wrote: [...] > Org-mode sets: > > (modify-syntax-entry ?< "(>") > (modify-syntax-entry ?> ")<") > > should we adapt Org's default syntax? Difficult to judge but my gut feeling would be to leave as is. My use case involves significant amount of coding, where < and > are logical operators. However, for many, these may make more sense as brackets. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Re: A few changes to test in master
On Wednesday, 5 Feb 2020 at 08:08, Bastien wrote: > I just fixed the scroll-bar issue, thanks! Confirmed! Many thanks. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-198-g06d36e
Re: sub super script export default
On Tuesday, 4 Feb 2020 at 15:31, Samuel Wales wrote: did you export your signature? I did! And, yes, org-htmlize interpreted the underscore in the version number. Does it look better now? I don't often use HTML emails, mind you. Thank you! – Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-198-g06d36e
Re: A few changes to test in master
On Wednesday, 5 Feb 2020 at 00:21, Bastien wrote: > This should be fixed now, thanks! Much better. See attached screenshots. One with scroll bar (which I normally don't have turned on) and one with line numbers (which I do usually have). >> org-table-header-line-mode: Symbol’s function definition is void: >> face-remap-remove-relative > > Mhh... this I cannot reproduce (with Emacs -Q and latest master). > Let me know if you find where lies the problem. This seems to have been fixed. Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-198-g06d36e
Re: A few changes to test in master
Bastien, the latest on the table header. With emacs -Q and org from a few minutes ago, I get the following: [screendump-20200204064315.png] when I open the file, invoke M-x org-table-header-line-mode RET and scroll down in the attached org file. Note also that if I invoke the above command before opening an org file, org complains (correctly) about the command not being suitable outside org but then, when I open the attached file and invoke the command again, I get: org-table-header-line-mode: Symbol’s function definition is void: face-remap-remove-relative Thank you. eric PS -signature out of date in this case. org up to date from 5 minutes ago now. – Eric S Fraga via Emacs 28.0.50, Org release9.3.2-198-g06d36e * Long table #+startup: shrink | name | cost | description| | | <6> | <20> | |--+--+| | an entry |1 | this is a very long description of the item we wish to buy | | an entry |2 | this is a very long description of the item we wish to buy | | an entry |3 | this is a very long description of the item we wish to buy | | an entry |4 | this is a very long description of the item we wish to buy | | an entry |5 | this is a very long description of the item we wish to buy | | an entry |6 | this is a very long description of the item we wish to buy | | an entry |7 | this is a very long description of the item we wish to buy | | an entry |8 | this is a very long description of the item we wish to buy | | an entry |9 | this is a very long description of the item we wish to buy | | an entry | 10 | this is a very long description of the item we wish to buy | | an entry | 11 | this is a very long description of the item we wish to buy | | an entry | 12 | this is a very long description of the item we wish to buy | | an entry | 13 | this is a very long description of the item we wish to buy | | an entry | 14 | this is a very long description of the item we wish to buy | | an entry | 15 | this is a very long description of the item we wish to buy | | an entry | 16 | this is a very long description of the item we wish to buy | | an entry | 17 | this is a very long description of the item we wish to buy | | an entry | 18 | this is a very long description of the item we wish to buy | | an entry | 19 | this is a very long description of the item we wish to buy | | an entry | 20 | this is a very long description of the item we wish to buy | | an entry | 21 | this is a very long description of the item we wish to buy | | an entry | 22 | this is a very long description of the item we wish to buy | | an entry | 23 | this is a very long description of the item we wish to buy | | an entry | 24 | this is a very long description of the item we wish to buy | | an entry | 25 | this is a very long description of the item we wish to buy | | an entry | 26 | this is a very long description of the item we wish to buy | | an entry | 27 | this is a very long description of the item we wish to buy | | an entry | 28 | this is a very long description of the item we wish to buy | | an entry | 29 | this is a very long description of the item we wish to buy | | an entry | 30 | this is a very long description of the item we wish to buy | | an entry | 31 | this is a very long description of the item we wish to buy | | an entry | 32 | this is a very long description of the item we wish to buy | | an entry | 33 | this is a very long description of the item we wish to buy | | an entry | 34 | this is a very long description of the item we wish to buy | | an entry | 35 | this is a very long description of the item we wish to buy | | an entry | 36 | this is a very long description of the item we wish to buy | | an entry | 37 | this is a very long description of the item we wish to buy | | an entry | 38 | this is a very long description of the item we wish to buy | | an entry | 39 | this is a very long description of the item we wish to buy | | an entry | 40 | this is a very long description of the item we wish to buy | | an entry | 41 | this is a very long description of the item we wish to buy | | an entry | 42 | this is a very long description of the item we wish to buy | | an entry | 43 | this is a very long description of the item we wish to buy | | an entry | 44 | this is a very long description of the item we wish to buy | | an entry | 45 | this is a very long description of the item we wish to buy | | an entry | 46 | this is a very long description of the item we wish to buy | | an entry | 47 | this is a very long description of the item we wish to buy | | an entry | 48 | this is a very long description of the item we wish to buy | | an entry | 49 | this is a very long description of the item we wish to buy | | an entry | 50 |
Re: A few changes to test in master
On Monday, 3 Feb 2020 at 09:17, Bastien wrote: > "Fraga, Eric" writes: > >> The header line is now 2 characters to the right of where it should be! >> I have looked at the code briefly but cannot figure out why this would >> be. >> >> I have not seen any difference in behaviour for shrunken columns. > > What is M-x org-version RET ? In my signature. > Can you send a reproducible ECM ? I'll try tomorrow. With respect to the placement of the table header, I should say that my line-number face is customized to have characters smaller than the default text. This will probably affect the placement and I'm sure will make it very difficult to adjust correctly (i.e. more difficult than is really worth the effort). Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Re: A few changes to test in master
On Friday, 31 Jan 2020 at 21:31, Bastien wrote: > "Fraga, Eric" writes: > >> 1. the header contents are placed at the leftmost column means the first >>row does not align with the table in two cases: >>1. when display-line-number-mode is active and/or >>2. when org-indent-mode is used. > > This concern should be gone now - if you can, please pull from master > and test again. The header line is now 2 characters to the right of where it should be! I have looked at the code briefly but cannot figure out why this would be. I have not seen any difference in behaviour for shrunken columns. Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-198-g06d36e
Re: A few changes to test in master
On Friday, 31 Jan 2020 at 17:50, Bastien wrote: > "Fraga, Eric" writes: >> 2. the display of the first row does not have column widths adjusted and >>so the entries do not line up if the table itself has adjusted column >>widths (C-c TAB). > > `org-table-automatic-realign' being t by default, I very seldom have a > problem with the alignment of the first row, so this one does not seem > to be very problematic to me. No, sorry, I think you misunderstood as I did not explain properly. If some columns are hidden or shrunk, the header line is not and so the columns are misaligned. This is independent of automatic realignment. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-164-g3d0282
Re: A few changes to test in master
On Friday, 31 Jan 2020 at 12:26, Bastien wrote: > I would like to highlight three changes from master that need to be > carefully tested before Org 9.4 can be released: > > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. This is very appealing and I'll be using it by default (despite issues; see below) as I often have long tables in my documents. Some issues which may or may not be easily fixable or may require more effort than is worth: 1. the header contents are placed at the leftmost column means the first row does not align with the table in two cases: 1. when display-line-number-mode is active and/or 2. when org-indent-mode is used. 2. the display of the first row does not have column widths adjusted and so the entries do not line up if the table itself has adjusted column widths (C-c TAB). Thank you. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-164-g3d0282
Re: customizing Org for legibility
On Friday, 31 Jan 2020 at 17:34, Texas Cyberthal wrote: > Along the way, I discovered mixed-pitch, which fixed most of my > complaint. mixed-pitch-mode is quite nice and does work well generally. It doesn't work well with org-indent-mode, unfortunately, as the spacing used by org to align subsequent text with the heading assumes fixed pitch. I imagine this could be fixed if somebody has the time and motivation. in any case, your efforts in making org more attractive to new users is welcome. for us old-timers, the look & feel of org is what we grew up with so we're comfortable with it... -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: C-c C-c to close the buffer in *Org Src ...* buffers
On Friday, 31 Jan 2020 at 12:03, Bastien wrote: > Hi all, > > I'd like to make an equivalent to in Org Src buffers > so that hitting will close the buffer, which seems natural. It does seem natural and generally support this idea. However, it could potentially cause me a minor annoyance: I often (in manuals and other forms of dissemination) use org src blocks (i.e. src blocks with org code) and I would expect C-c C-c to do whatever it would normally do in an org file (e.g. add tag) while editing that block. Would the normal C-c C-c behaviour take precedence? If not, this is a very minor issue so I'm sure I would adjust! -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: debugging why a latex preview fails
On Wednesday, 29 Jan 2020 at 14:11, Nick Dokos wrote: [...] > It would be nice to have the ability to inhibit the cleanup more > easily: it would make preview almost as easy to debug as export. I agree. Debugging babel is easier as the temporary files are left around so you can manually run commands to see what happens. It would be good to have the same possibility for LaTeX snippets. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: LaTeX export failure
On Wednesday, 29 Jan 2020 at 15:22, Thomas S. Dye wrote:
> Here is the offending bit, which worked fine last November but
> fails today:
>
> #+caption: Compare figure\nbsp{}[[fig:mqs3_op]].
This works fine for me. Sorry; that probably doesn't help you
much... :-(
--
Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: debugging why a latex preview fails
On Wednesday, 29 Jan 2020 at 11:20, Fabrice Popineau wrote: > First of all: look into the *Org PDF LaTeX Output* buffer to see why Thank you. But maybe you meant *Org Preview LaTeX Output* instead? In any case, thanks for the pointer: I hadn't realized that this buffer was created. Although it's empty in my case but maybe that's because the LaTeX snippet works fine for me? Alan may see something different (hopefully). -- Eric S Fraga via Emacs 28.0.50, Org release_9.2.3-379-gff2bf2
Re: debugging why a latex preview fails
On Wednesday, 29 Jan 2020 at 08:39, Alan Schmitt wrote: > I'm trying to add some diagrams in a note, and I want to use latex > preview for that. Unfortunately the result is not what I expect: I do > see an image, but there seem to be errors in the latex processing. How > can I see what latex is produced to find where the issue is? Your example works for me. Maybe you need other packages as well (e.g. tikz itself)? I don't know the best way to debug, however. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-95-gf93020
Re: preview src blocks that generate image files
On Sunday, 26 Jan 2020 at 00:11, Matt Huszagh wrote: > Is anyone else interested in this feature? Any general thoughts/feature > requests? This sounds quite appealing. The only issue might be the need to be able to distinguish between images that are purely there because of a link and those that correspond to a src block. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: code.orgmode.org maintainance for the next two hours
On Saturday, 25 Jan 2020 at 11:47, Bastien wrote: > code.orgmode.org is now back online and usable. Thank you! -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: noweb
My approach to this is to create three blocks that are tangled and a separate block (or more than one if you have different tests you want to perform) for evaluation that references those three blocks (via noweb) but is not tangled. -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: Src block fontification when scrolled off window
On Tuesday, 14 Jan 2020 at 07:21, Aaron Jensen wrote: > In one of my org files, I will occasionally see src blocks lose their > formatting. [...] > > Is this expected behavior? Is there a way to increase the lookback amount? I don't see this behaviour. You might want to look at jit-lock-chunk-size but that's me grasping at straws... -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Hiding a node title in export but not the content
On Thursday, 9 Jan 2020 at 16:09, alain.coch...@unistra.fr wrote: > It seems to me that this is what you are referring to, Eric: using the > :ignore: tag in conjunction with package 'ox-extra'. Thanks. I haven't tried it but, looking at the documentation & code, it does what my little snippet does and a lot more. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Hiding a node title in export but not the content
On Thursday, 9 Jan 2020 at 11:38, Sven Bretfeld wrote: > Works like a charm! Almost perfect. Thank you very much. One problem: > For some reason the :ignoreheading: tag causes the PROPERTY drawer to be > exported. Ah, probably because the property drawer is now not in the right place (i.e. immediately after a headline) so prop:nil doesn't affect it. You may need to disable export of all drawers (d:nil) which may or may not cause you other problems... -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Hiding a node title in export but not the content
On Thursday, 9 Jan 2020 at 09:20, Sven Bretfeld wrote: > Hi everybody > > Is this possible? > > ** headline <-- not exported >:PROPERTIES: <-- not exported >Some content. <-- exported yes. I do this all the time to add structure to a document, structure that is not required in the exported version. I have the following code: #+begin_src emacs-lisp (defun esf/remove-lines-with-ignore-heading-tag (backend) (message "Deleting lines with ignore heading tag") (while (search-forward-regexp "^\\*+.*[ \t]+[a-ZA-Z0-9:]*:ignoreheading:[a-ZA-Z0-9:]*$" (point-max) t) (cond ((eq backend 'latex) (replace-match "#+latex: % \\&" )) ((eq backend 'html) (replace-match "#+html: " )) (t (replace-match "" (message "... done deleting ignored headings.")) (add-hook 'org-export-before-processing-hook 'esf/remove-lines-with-ignore-heading-tag) #+end_src which then causes any headline with the ignoreheading tag to be removed, leaving the subtree under that headline present. One caveat: the subtree content inherits behaviour from the previous headline. For instance, if the previous headline was one that would not be exported at all, then this subtree will also not be exported. E.g.: #+begin_src org ,* heading 1 Text that will be exported ,* heading 2:ignoreheading: Text that will also be exported but without the heading ,* heading 3 :noexport: Text that will not be exported. ,* heading 4:ignoreheading: Text here will also not be exported because it ends up being under "heading 3" which has the :noexport: tag. #+end_src Note that my implementation is old and it could very well be that later versions of org have introduced something to cater for this use case. I have org customizations going back over 10 years... -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: excluding noweb references completely from exports
On Monday, 6 Jan 2020 at 14:35, Samuel Wales wrote: > fyi i dimly recall that in babel's infancy, as a user new to lp and > using babel infrequently, i got confused about the difference while > reading the manual. in fact, i wondered if the two features could be > the same thing but refactored. Tangling is for extracting code(s) from a document; exporting is for presentation or dissemination of that document. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Confused about src vs example and LaTeX export
On Monday, 6 Jan 2020 at 09:43, Norman Walsh wrote: > The trick turned out to be > > (setq org-latex-listings t) Ah, yes, that needs to be set. I changed the default so long ago now... Anyway, glad you figured it out. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-379-gff2bf2
Re: Confused about src vs example and LaTeX export
On Sunday, 5 Jan 2020 at 10:53, Norman Walsh wrote:
> In the simple case, both EXAMPLE and SRC export as {verbatim}
> environments; that’s fine as a default. In the second case, the
> ATTR_LATEX request for the {lstlisting} environment works on EXAMPLE
> but appears to be ignored on SRC.
Not for me. I have lstlisting for both cases.
I would use example blocks for content that should not be parsed and src
blocks for actual code (whether LaTeX, lisp, or anything else).
--
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: excluding noweb references completely from exports
On Sunday, 5 Jan 2020 at 06:27, David Bremner wrote: > The attached exports with a blank line after the comment, which I don't > want. The comment is just added to highlight the problem, so normally > the blank line is at the beginning of the exported code block. Oh, I see. One approach would be to have a src block that uses noweb to bring in *all* the various code snippets and have each snippet not include anything else. The former would be tangled but the others not. This is what I do generally: the noweb code block has no actual code but just includes all the various bits. HTH, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: excluding noweb references completely from exports
On Saturday, 4 Jan 2020 at 14:15, David Bremner wrote: > Any better ideas for how to do this? In case it's not clear, I want > include files in my tangled output that don't show in the beamer > export. Export and tangling are orthogonal to each other and are controlled independently by their respectively keywords in the src header lines. In other words, I am not sure I understand what one has to do with the other. Would you please give an example that does not work the way you want it? -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Long links
On Saturday, 4 Jan 2020 at 20:57, Steven Penny wrote: > But as you can imagine, I dont only work with Org Mode files. I also work with > Python files, Go, Dart and a number of other types. And none of these other > types get the wrapping on GitHub. As it may be. But maybe I'm missing the point as well. I do not see what github's behaviour has to do with org mode's display of links (angle brackets or not). Should you be asking github to change? Your original post simply said you wished to wrap long lines and you said "Does Org Mode have some way to deal with this?". Trey gave you one way: use visual-line-mode (which is also what I use and have done for years). His response was on-topic. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: very strange LaTeX error
On Friday, 20 Dec 2019 at 17:28, Stefan Nobis wrote: > Hmmm... but it should be solvable. Maybe something along the lines of > this (rough sketch, I have next to no experience with the org code > base): It should be solvable and something like what you have written looks promising. But it's beyond my elisp-fu so I hope others can chime in! -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: very strange LaTeX error
On Friday, 20 Dec 2019 at 15:29, Stefan Nobis wrote: > As the org-table does not support all the fancy features of LaTeX > tables and the LaTeX row/line break is generated implicitly, I would > say the LaTeX export should always emit the additional \relax. I agree. I shouldn't have to be this aware of LaTeX idiosyncrasies to export what looks like a straightforward table! However, it seems that simply adding \relax does not work if there is an \hline immediately following so the solution is not that straightforward. Thanks again, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: very strange LaTeX error
On Friday, 20 Dec 2019 at 13:33, Joost Kremers wrote: > Few people seem to realise that the double backslash `\\` in LaTeX is > a macro that can actually take an optional argument, a measure > specifying the height of the newline. Ah ha! That makes perfect sense. Thank you. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
very strange LaTeX error
Hello all,
this may not belong in this mailing list as it's arguably a LaTeX issue
but I'm having a problem exporting a table to PDF via LaTeX. I hope
somebody can help me out.
I've reduced my problem file to a small (hopefully minimal) example and
verified this with emacs -Q, using emacs 27.x which comes with org 9.3:
#+begin_src org
,* some results
,#+name: atable
|+--+--+-|
| x | z1 | z2 | g |
|+--+--+-|
| [0.0005, 0.05, 0.5]| 9.0 | 0.05 | 0.0 |
| [0.000787451, 0.0575948, 0.5] | 11.0 | 0.05759476698672508 | 0.0 |
|+--+--+-|
#+end_src
If I export this to LaTeX, I get something that looks reasonable (elided):
#+begin_src latex
\documentclass{scrartcl}
\begin{document}
% packages deleted, none of which is used anyway in the following
\tableofcontents
\section{some results}
\label{sec:org4f5891c}
\begin{table}[hbtp]
\label{atable}
\centering
\begin{tabular}{lrrr}
\hline
x & z1 & z2 & g\\
\hline
[0.0005, 0.05, 0.5] & 9.0 & 0.05 & 0.0\\
[0.000787451, 0.0575948, 0.5] & 11.0 & 0.05759476698672508 & 0.0\\
\hline
\end{tabular}
\end{table}
\end{document}
#+end_src
I get errors like this when compiling with pdflatex:
#+begin_example
! Illegal unit of measure (pt inserted).
,
l.18 [0.000787451, 0.0575948, 0.5]
& 11.0 & 0.05759476698672508 & 0.0\\
! Missing = inserted for \ifdim.
#+end_example
What am I doing wrong? If LaTeX cannot handle [...] in a table (it has
no problem with similar text in a normal paragraph), the LaTeX exporter
should do something about this. But I do not see why LaTeX should have
a problem in any case. Any pointers welcome!
Note: LaTeX does not complain about the first line in the table, only
the second (and following ones in the original org file from which I
took this code snippet).
Thank you.
--
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: backup of abbrev_defs
On Wednesday, 18 Dec 2019 at 11:02, Sharon Kimble wrote: > I've tried using a symlink to the file held in another directory, but > when I restarted emacs the symlink wasn't followed and it created a new > abbrev_def file from somewhere, I don't know where. This is strange. I have my .abbrev_defs symlinked to elsewhere and it works just fine. I've been doing this for years, probably from emacs v22 onwards (but that's just a guess). To answer your original question, I use version control (e.g. src or git) to manage that file along with other dotfiles. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Can Org warn me if I create a time conflict?
On Tuesday, 17 Dec 2019 at 14:05, David Rogers wrote: > Is there any method to get org-mode to alert me (by an error message, > or a red mark in the agenda, or whatever) that I've created a conflict None that I know of. I've trained myself to only create meetings from the agenda view for this reason. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Emacs bug 37890; killing capture buffer
On Tuesday, 17 Dec 2019 at 17:07, Samuel Wales wrote: > i encountered this problem today. i added a task and duplicated it. > this caused the corruption. it also screwed up the stars level, but > never mind that. I've encountered the problem in the past week or two when I was tweaking one of my capture templates. I had to add a \n to the end of the template string to avoid the problem but didn't explore more than that. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: restore window configuration after org-edit-src-exit
On Tuesday, 17 Dec 2019 at 06:28, Jack Kamm wrote: > Basically, when org-src-window-setup is current-window, it never makes > sense to restore the original layout. But when org-src-window-setup is > reorganize-frame (the default), it always makes sense to restore the > original layout. This makes sense to me. While we're talking about org-src-window-setup, I set it to 'split-window-right on my large monitor. Sometimes, I make the src window full frame but then, when trying to go back to the org buffer (C-c '), I get the error: delete-window: Attempt to delete minibuffer or sole ordinary window This would be fixed if the original layout were restored instead of simply deleting the src window, I guess. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Custom time stamps in column view
On Sunday, 1 Dec 2019 at 19:57, Fraga, Eric wrote: > I guess I'm making a feature request: to be able to use custom time > display in column views. Would this be possible? (or, knowing me, it > might already be possible so would somebody tell me how?) I found some time today to explore and have managed to answer my own question. Unsurprisingly, org has what I need! Using the answer given to a related question on StackExchange [1], I came up with this simple function: #+begin_src emacs-lisp (defun esf/todo-column-display-filter (column-title value) (when (and value (not (string= value "")) (or (string= column-title "SCHEDULED") (string= column-title "DEADLINE"))) (format-time-string "%e %b %A" (org-time-string-to-time value (setq-local org-columns-modify-value-for-display-function #'esf/todo-column-display-filter) #+end_src Makes my column view much easier to read for seeing my todo list! Thank you, eric Footnotes: [1] https://emacs.stackexchange.com/questions/54027/org-column-view-with-date-calculations -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Issues with nested begin..end blocks in inline math environments
On Friday, 6 Dec 2019 at 11:42, Matt Huszagh wrote: > I'm experiencing incorrect and seemingly inconsistent behavior when nesting > `\begin` `\end` environments inside `\(\)` or `$$`. For example, the > following is valid latex code: The identification of LaTeX fragments is somewhat fragile (in my experience). I would suggest you enclose complex LaTeX code fragments within an #+begin_export latex ... #+end_export environment. Assuming your export target is LaTeX and/or PDF. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Bug: LaTeX export does not handle .pgf/.tikz images [9.3 (9.3-elpaplus @ .emacs.d/elpa/org-plus-contrib-20191203/)]
On Friday, 6 Dec 2019 at 17:47, Arthur wrote: > Since my last org update (today or yesterday I would say) I have been > having an issue with exporting .pgf or .tikz file to LaTeX. The > exporter always returns `nil`. Your example works just fine for me with git up to date as of a few minutes ago (and also with org from a week ago, give or take). Maybe something in your configuration? -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Re: Removing horizontal space in latex fragments
Not really worried about which alternative is chosen. I was just exhibiting my inner compulsive nature... ;-) -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3
Re: Removing horizontal space in latex fragments
On Thursday, 5 Dec 2019 at 11:03, Matt Huszagh wrote: > Is anyone else interested in this modification? Should I submit it as a > patch? I think so. And I am not sure all those \n's are necessary. Without them, you can probably also remove many of the %s. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3
Re: Gnus org-mode link problems in org 9.3
On Wednesday, 4 Dec 2019 at 14:39, Bob Newell wrote: > This occupied a few hours but it wasn't good beach weather today. :-) Glad you tracked this down. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3
Re: [ANN] C-c C-c to quit column-view
Although I've not tried your enhancement yet, it is very welcome. Thank you. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3
Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
You need to type C-c TAB to get the column to adjust to the specification. Did you do that? -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-21-g36753e
Re: Gnus org-mode link problems in org 9.3
On Wednesday, 4 Dec 2019 at 08:14, Bob Newell wrote: > Just updated to latest org (9.3 of 3 December) on Emacs 26.3.1 > and my gnus link functions seem to have quit. > > Now, whenever I do C-c C-o on an email link I get something like this: I updated both Emacs and org mode (both from git) this morning and have had no problems with opening gnus email links from org, something I've been doing quite a lot today in fact. Just a data point... -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-21-g36753e
Re: org-custom-id-goto?
On Wednesday, 4 Dec 2019 at 10:26, Matt Price wrote: > Is there a quasi-equivalent of ~org-id-goto~ or > ~org-babel-goto-named-src-block~ which will jump to a header in the > current buffer? If by header you mean headline or heading, I don't think there is anything exactly how you might want it but you should maybe look at "org-goto" and "org-occur" (or both in combination). -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-21-g36753e
Custom time stamps in column view
Hello all, I use column view quite a lot. Very useful, especially for editing properties. I also use it for task management, having moved to Marcin Swieczkowski's approach [1]. For managing my tasks, the column view I have defined includes scheduled and deadline dates. I would like to be able to use a custom time stamp display. That works for normal view but not in the column view. I guess I'm making a feature request: to be able to use custom time display in column views. Would this be possible? (or, knowing me, it might already be possible so would somebody tell me how?) Thanks, eric Footnotes: [1] https://media.emacsconf.org/2019/09.html -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-572-gbe7e88
Re: org-mime-htmlize and signature
On Saturday, 30 Nov 2019 at 18:37, Pankaj Jangid wrote: > It converts the text in the message buffer into multipart message. But > the conversion doesn't work well at the point of signature. For these cases, I usually put a colon at the start of each line of the signature which htmlize then converts as preformatted text. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-572-gbe7e88
Re: org 9.2.6 and org 9.1.9
On Wednesday, 27 Nov 2019 at 17:00, Tim Cross wrote: > I would agree that org should be a package in elpa and not bundled into > emacs core. I would argue the opposite! I would like to see org tightly integrated into Emacs, in the same way that gnus now is. Development of org would be in step with the development of Emacs. This would avoid any dependency issues entirely. But I have no problem with the current situation even if I have had to be very careful in how I load org in my initialisation files... -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: Question: export with tags but hide "export" tag
On Saturday, 23 Nov 2019 at 11:59, w...@mm.st wrote: > Any ideas about how to export using this workflow without showing > the "export" tag? You could maybe use this hook: ,[ C-h v org-export-before-processing-hook RET ] | org-export-before-processing-hook is a variable defined in ‘ox.el’. | | Documentation: | Hook run at the beginning of the export process. | | This is run before include keywords and macros are expanded and | Babel code blocks executed, on a copy of the original buffer | being exported. Visibility and narrowing are preserved. Point | is at the beginning of the buffer. | | Every function in this hook will be called with one argument: the | back-end currently used, as a symbol. ` *if* it is invoked after the tag selection is done (I'm not sure if it is or not). You would have to write some emacs lisp to remove the :export: tags. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: Org BABEL plantuml bug--mindmap mode
On Sunday, 10 Nov 2019 at 13:11, Spenser Truex wrote: > PlantUML has an "org-compatible" outlining mode to generate graphical tree > images. It is ironically not org /babel/ compatible, since org does not like > having lines starting with =*= in a source code block. Have tried with a comma (,) at the start of each * line? If you edit the uml code within the proper mode (C-c ' on the src block), you'll find that org will insert those commas for you. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: DST and appointments in other timezones
On Wednesday, 13 Nov 2019 at 23:26, Leo Gaspard wrote: > Well, ideally org-mode could be adapted to support timestamps in > arbitrary timezones, but I guess there are reasons why that's not > supported? In principle, it is possible to extend org to handle time zones. The challenges are a) somebody stepping up to do it and b) doing it in an upwards compatible way to avoid breaking all existing org documents. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3
Re: Display problems
On Monday, 11 Nov 2019 at 17:12, Fabrice Popineau wrote: > - with global-hl-line-mode: the cursor disappears on empty lines, > quite disturbing in my opinion Known problem in latest versions of Emacs with extended faces (hl-line face is one such face). If you customize the face and remove the :extend property, everything is fine in terms of the cursor but, of course, the face will no longer extend across the window. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
[O bug] table debugging does not preserve window configuration
Hello all,
If I turn debugging on for table updates (C-c {), when the debugging is
finished, the original window configuration is not remembered.
Should be simple to fix, but possibly beyond my emacs-lisp-fu.
Thanks,
eric
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: Truncate lines option on file startup
On Sunday, 10 Nov 2019 at 18:12, Dmitrii Korobeinikov wrote: > PS if this turns out to be hairy, I can use .dir-locals.el, but the feature > would still be a nice-to-have. You could use file local variables for this, e.g. # Local Variables: # truncate-lines: t # End: at the end of your org file or # -*- truncate-lines: t; -*- as the first line of your file. This is not org specific so I guess there is no real justification for an org variable for this feature. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: customized link pointing at a src block
You want the equivalent of the LaTeX exporter's ,[ C-h v org-latex-prefer-user-labels RET ] | org-latex-prefer-user-labels is a variable defined in ‘ox-latex.el’. | Its value is t | Original value was nil | | You can customize this variable. | | | This variable was introduced, or its default value was changed, in | version 26.1 of Emacs. | | Documentation: | Use user-provided labels instead of internal ones when non-nil. | | [...] | | For headlines that do not define the CUSTOM_ID property or | elements without a NAME, Org will continue to use its default | labeling scheme to generate labels and resolve links into proper | references. ` I don't think the HTML exporter has anything similar but it should be possible to implement... -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: Bug: Cursor Disapears in Org-Src Blocks in Indent Mode [9.2.6 (release_9.2.6-559-ga01a8f @ /Users/djm/.emacs.d/straight/build/org/)]
On Friday, 8 Nov 2019 at 10:41, Dylan McDowell wrote: > Expected Behavior: My cursor is always visible throughout my entire > org-document > > Actual Behavior: When moving through org-src blocks, my cursor is > visible until I move it to the end of the line. Then my cursor disapears > and only shows up when the cursor is placed in the middle of the line. I imagine this is a bug in Emacs, not org, one that people are currently trying to track down. See the emacs developers mailing list. The problem has to do with faces that have the :extend attribute set and especially those with a different background. On the developers list, they are looking for an easily reproducible example starting from emacs -Q, by the way... -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
calc embedded mode and org tables
Hello all, I use calc embedded mode for many simple calculations. I have the need to refer to some previously calculated values using calc in an org table. So, for instance, if I have the embedded formula x := 3 + ln(10) => 5.303 in my org buffer, is there some way to access the value of x in an org table? I've tried a formula with '(calc-eval "x") but that did not work. Thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: Bug: LaTeX output of numbered TODO plain list items lose numbering. [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/27.0.50/lisp/org/)]
On Friday, 8 Nov 2019 at 21:28, Brian Carlson wrote: > So it seems that the numbering of numbered items in a plain list are not > maintained when the numbered item is also a TODO plain list item. This is a "feature", not a bug. The intention was to export check box lists nicely to LaTeX, showing which were done and which were not. This doesn't mix well with any other type of list except for simple bullet points unfortunately. The only way around it is to have them as separate lists (e.g. two empty lines between the check box item and the numbered items) and start the numbered list with the desired number ([@2], I believe). -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: Finally figuring out some ob-sqlite stuff -- for worg?
This looks quite useful and would be nice to have on Worg. Thanks. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: How to move from inline tasks to drawers? [was: How to change the width of a latex exported inlinetask?]
Again, very impressive. I do some of this with drawers but there could indeed be much more support built-in for such aspects. Navigating drawers in org mode should be easier. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: How to move from inline tasks to drawers? [was: How to change the width of a latex exported inlinetask?]
On Tuesday, 5 Nov 2019 at 07:49, John Kitchin wrote:
> I use it when editing papers mostly. The main difference is I can put
> them inline {>~ @jk here is a comment.~<} in a paragraph.
Very interesting. The inline aspect can be quite useful. Thanks for
the description!
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: How to move from inline tasks to drawers? [was: How to change the width of a latex exported inlinetask?]
On Monday, 4 Nov 2019 at 15:14, John Kitchin wrote:
> I have been exploring the use of something I call editmarks for this
Out of curiousity, what do these give you that drawers would not? I use
:todo: and :note: drawers.
For syntax highlighting, I use hi-lock-mode with, for instance, this
pattern to highlight todo drawers:
# Hi-lock: (("^:todo:" (0 'hi-yellow prepend)))
thanks,
eric
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: included text
On Sunday, 3 Nov 2019 at 12:37, Samuel Wales wrote: > ah, or do you mean you refer the reader to the text by a regular link > instaed of including? that's not what i am lokoing for here as these > are separate posts. Yes, this is what I meant, in case the adjusted use case were of some use. But it would seem that it won't help you in this case. Therefore, I would suggest macros for short amounts of text or #+include for larger text blocks. Mind you, an alternative could be #+CALL-ing a src block that generates the text as output? -- : Professor Eric S Fraga, http://www.homepages.ucl.ac.uk/~ucecesf : PGP/GPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D : Use plain text email when possible: https://useplaintext.email/
Re: How to move from inline tasks to drawers? [was: How to change the width of a latex exported inlinetask?]
On Saturday, 2 Nov 2019 at 14:01, alain.coch...@unistra.fr wrote:
> You also said that you had "already moved to using drawers for a large
> number of [your] inline task use cases, the ones that weren't really
> tasks!". Is this consistent with your "almost completely" above?
> This leads me to the question of what precisely _defines_ a "task";
Good question! I guess, for me, a task is one that will appear in my
agenda so has a TODO state (possibly) and/or scheduling/deadline
information. But the distinction is rather blurry.
So, in fact, when I am working on a long document, I have tasks of the
"must improve this section" type which are not tasks for scheduling (the
whole document is itself a task) or "notes" for processing later (by
myself or by others involved in the same document). I use drawers for
these types of activities. I then use the export formatting options to
make the pseudo-tasks and notes appear differently in the exported
output, whether for sharing or for printing/display. So, for instance,
I look for ":todo:" and ":note:" drawers.
If the document I am working on is a coursework or test, I use drawers
for storing the solutions, e.g. a drawer called ":solution:"! For this,
for instance, I have the following elisp in the document that is invoked
when I open the document:
#+begin_src emacs-lisp
(setq-local org-latex-format-drawer-function
(lambda (name contents)
(cond ((string= name "solution")
(format "\\begin{mdframed}\\paragraph{Solution.}
%s\\end{mdframed}" contents))
(t (format "\\textbf{%s}: %s" name contents))
)))
#+end_src
together with
#+latex_header: \usepackage[backgroundcolor=yellow!10!white]{mdframed}
to make the solution stand out clearly.
The nice thing about drawers is I can turn them on or off for exporting
via the "d:" document option:
HTH,
eric
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: included text
I use macros generally for this. For longer bits of text, I reword and, instead of repeating the text inline, I use internal links. These links can be inserted automatically if you use radio targets/links. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
