Re: [bug] args out of range upon meta-return in body of list item
thank you for looking into it.
Re: [bug] args out of range upon meta-return in body of list item
Samuel Wales writes:
> recent maint on emacs 25.
>
> i know this is an imperfect bug report with no mce that you can
> probably repro. but perhaps it can trigger an idea that could lead
> directly to a fix. my brain and computer limitations cannot do better
> at this time.
The example, instructions, and backtrace you provided are all very
helpful. Thanks.
> when i run m-ret at the caret i get this bt. my intent is to make a
> new list item containing prefer as its header.
>
>1) [ ] towels
> 1) [ ] 12 very large (asdfasdf asdfasdf) solid color,
> like the ones i use, thick -- asdafsdf -- ^prefer
> to get them slightly wider
> - not any ...
> - not any pattern (something like different color on
>end might be ok, dunno) or anything garish
> 2) [ ] 6 dark aasdfa dfnkajs dkfaskdf kasdn
> fkasdnkfanksdfn kasdfn
>2) asdfasdfasdf
>
> Debugger entered--Lisp error: (args-out-of-range -1 3)
> replace-match("1) " nil nil nil 1)
> #[771 ...
> org-list-struct-apply-struct(...
> org-list-write-struct(...
> org-insert-item(nil)
> funcall-interactively(org-insert-item nil)
> call-interactively(org-insert-item)
> org-meta-return(nil)
> funcall-interactively(org-meta-return nil)
> call-interactively(org-meta-return nil nil)
> command-execute(org-meta-return)
I don't have more time to spend on this at the moment, but some quick
notes.
* The error you show happens on maint, but doesn't on master. It
looks like it went away with 07a4a7286 (list: Fix regression when
inserting items, 2020-07-06), which was prompted by this report:
https://orgmode.org/list/CAE-tX7iH59DNO8K2a6O_Wu7_DqqRgPJ5r_y=zqdustcr5vr...@mail.gmail.com/
I think this can be cherry picked to maint.
* Although the error is gone, the result still looks off. In
particular, the "2) [ ] 6 dark" line loses its bullet.
I suspect that the remaining issue is related to the error you show
above. Here's a bit of context from org-list-struct-apply-struct:
(looking-at org-list-full-item-re)
;; a. Replace bullet
(unless (equal old-bul new-bul)
(replace-match new-bul nil nil nil 1))
;; b. Replace checkbox.
(cond
((equal (match-string 3) new-box))
((and (match-string 3) new-box)
(replace-match new-box nil nil nil 3))
((match-string 3)
The code downstream of (looking-at ...) assumes a match, but it seems
that's not valid, even after 07a4a7286. The patch below guards the
downstream code with (when (looking-at ...)) and fixes this particular
"lost bullet" case I mentioned above.
The change doesn't make any tests fail, but I'd need to look into the
code a bit more to be comfortable with the change. (For instance, is
the fact that there isn't a match here a sign that something's going
wrong upstream?) Also, the patch should include a test that is
distilled from your example.
diff --git a/lisp/org-list.el b/lisp/org-list.el
index 727d89c36..61d5def5b 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -1866,26 +1866,26 @@ (defun org-list-struct-apply-struct (struct old-struct)
(org-list-get-bullet item struct)))
(old-bul (org-list-get-bullet item old-struct))
(new-box (org-list-get-checkbox item struct)))
- (looking-at org-list-full-item-re)
- ;; a. Replace bullet
- (unless (equal old-bul new-bul)
-(replace-match new-bul nil nil nil 1))
- ;; b. Replace checkbox.
- (cond
- ((equal (match-string 3) new-box))
- ((and (match-string 3) new-box)
-(replace-match new-box nil nil nil 3))
- ((match-string 3)
-(looking-at ".*?\\([ \t]*\\[[ X-]\\]\\)")
-(replace-match "" nil nil nil 1))
- (t (let ((counterp (match-end 2)))
-(goto-char (if counterp (1+ counterp) (match-end 1)))
-(insert (concat new-box (unless counterp " "))
- ;; c. Indent item to appropriate column.
- (unless (= new-ind old-ind)
-(delete-region (goto-char (point-at-bol))
- (progn (skip-chars-forward " \t") (point)))
-(indent-to new-ind)))
+ (when (looking-at org-list-full-item-re)
+;; a. Replace bullet
+(unless (equal old-bul new-bul)
+ (replace-match new-bul nil nil nil 1))
+;; b. Replace checkbox.
+(cond
+ ((equal (match-string 3) new-box))
+ ((and (match-string 3) new-box)
+ (replace-match new-box nil nil nil 3))
+ ((match-string 3)
+ (looking-at ".*?\\([ \t]*\\[[ X-]\\]\\)")
+ (replace-match "" nil nil nil 1))
+ (t (let ((counterp
[bug] args out of range upon meta-return in body of list item
recent maint on emacs 25.
i know this is an imperfect bug report with no mce that you can
probably repro. but perhaps it can trigger an idea that could lead
directly to a fix. my brain and computer limitations cannot do better
at this time.
when i run m-ret at the caret i get this bt. my intent is to make a
new list item containing prefer as its header.
1) [ ] towels
1) [ ] 12 very large (asdfasdf asdfasdf) solid color,
like the ones i use, thick -- asdafsdf -- ^prefer
to get them slightly wider
- not any ...
- not any pattern (something like different color on
end might be ok, dunno) or anything garish
2) [ ] 6 dark aasdfa dfnkajs dkfaskdf kasdn
fkasdnkfanksdfn kasdfn
2) asdfasdfasdf
Debugger entered--Lisp error: (args-out-of-range -1 3)
replace-match("1) " nil nil nil 1)
#[771 ...
org-list-struct-apply-struct(...
org-list-write-struct(...
org-insert-item(nil)
funcall-interactively(org-insert-item nil)
call-interactively(org-insert-item)
org-meta-return(nil)
funcall-interactively(org-meta-return nil)
call-interactively(org-meta-return nil nil)
command-execute(org-meta-return)
Re: Website revamp?
On 8/4/20 11:48 AM, Maxim Nikulin wrote: As to installation, I believe that org-mode bundled with Emacs is more than enough for first try. It is a shorter path to become familiar with most prominent features just to start editing of an .org file (or to download a prepared demo .org). Getting the latest stable version could be a next step for the hooked users. I might disagree, slightly, mostly with the last sentence. This is one of the very few issues I feel semi-competent to comment on. It would be impolite to actually say what I thought the only meaning of 'lisp' was before Emacs, which I had tasted and spit-out a dozen times before really reading in depth about org-mode. I have expanded my Emacs horizons to include org-journal, emacs-w3m, org-roam, ERC, and writeroom modes, but I don't code. This is relevant because I had always been satisfied with the built-in org-mode. A couple of weeks ago, when I decided to give org-roam a try, my best guess is org-roam pulled in 9.3.6. That is my best guess because suddenly it was there, and that is the only recent package I had installed. That may not be the case, but regardless, I learned I had 9.3.6, which I never explicitly installed, when I ran into some errors. I can no longer competently describe exactly what I was doing, but I am pretty sure it related to calling org-journal. I know whatever I was doing caused an error message: "Invalid function: org-preserve-local-variables." I spent some quite frustrating hours searching, and this error was frequently mentioned with org-refile, and I think helm and babel. I was on the verge of mailing the list, but I wanted to say I had tried the best advice I found [1], and I did so by backing up my entire emacs.d and then deleting all .elc files. This worked. I've no understanding of the underlying technicalities, and I'm pretty sure I had never heard of byte-compiled files (except in the most general sense unrelated to Emacs). It was literally like magic ( maybe magit :-) ) to me when Emacs repopulated all my .elc files! I would, therefore, encourage any new users coming to org-mode and/or Emacs to start with the highest, most stable version of both that is available to them with their level of competence (for me that is always what is in my distro's package manager) and with the further explaination that they might run into issues down the road if they don't. It is true that "[g]etting the latest stable version could be a next step for the hooked users", but I have used org-mode for five years without doing so, and many people may be so excited (like I was) that they finally found the One True Note-taking Tool (tm) that they immediately start blindly build an entire system only to crash into a byte-compiled wall. Their very first TODO should be "upgrade org-mode soon," [2] like "Call Mom" is in the todo.txt examples. [1] https://github.com/syl20bnr/spacemacs/issues/11801 (I won't engage in the pretense of beginning my footnotes with 0 :-) ) [2] The idea that someone would use org-mode and not get "hooked" is paradoxically unimaginable. -- Bo Grimes
Re: Website revamp?
Your website update is looking great! A couple of comments: - If materials are presented that are not relatively recent, it may indicate to potential users a lack of project vitality. - Because so many people these days are enticed by videos, I wonder if links to a few selected, engaging videos could be made prominent on the home page. I know that creating such a list could be difficult, but perhaps some consensus could be reached on a few outstanding selections. -gyro On 8/4/2020 12:27 AM, TEC wrote: > > Good to hear from you! > > Eric S Fraga writes: >> I do like the animated images in the features page! > > Glad you like them! I recently converted the static images to SVGs with > the help of someone using Emacs27 w/ Cairo, would be nice go do > something like an animated SVG in the future, but that's for (much) > later :P > >> I do wonder about the order of the topics within that page, e.g. >> working with source code, although powerful, is probably not the lead >> item for new users. However, that's a minor point at this stage. > > Thanks for this feedback. I prioritised the source code blocks because: > a) my impression is that to Comp/Data Sci people, they are one of /the/ > most compelling features of Org-mode b) they're similar to elements > people are familiar with (Jupyter notebooks, R markdown), so the > Comp/Data Sci segment of our audience is already roughy familiar with > part of their capabilities > I shifted the agenda/capture/clocking/etc. features down because > a) they semantically seem like they should go together b) having them > near the top pushes down too many other features too much, IMO > > Absolutely worth considering the order, please share any further > thoughts you may have :) > >> More generally, can the column width for the text be a function of the >> window width and have images scaled so that they are not wider than >> the text column? It should be possible to have mobile friendly >> without making the columns too narrow for full desktop use. The fact >> that the images are much wider than the text makes the page look ugly, >> in my opinion. > > The column width already is. I just find long lines undesirable. 50-80 > characters is the standard in publishing for a reason. > > To quote from /The Elements of Typographic Style/, >> Anything from 45 to 75 characters is widely regarded as a satisfactory >> line length of line for a single-column page set in a serifed text >> face in a text size. The 66-character line (counting both letters and >> spaces) is widely regarded as ideal. For multiple-column work, a >> better average is 40 to 50 characters. If the type is well set and >> printed, lines of 85 or 90 characters will pose no problem in >> discontinuous texts, such as bibliographies, or, with generous >> leading, in footnotes. But even with generous leading, a line that >> averages more than 75 or So characters is likely to be too long for >> continuous reading. > > There's more to be said about line spacing and the reasons for this - if > I recall correctly /A practical guide to typography/ (available online) > goes over this. > > I look forward to hearing any further comments you may have! > > Timothy. > > pEpkey.asc Description: application/pgp-keys
Bug: inserting capture template [9.3.7 (release_9.3.7-705-gea9463 @ /home/nick/elisp/org-mode/lisp/)]
This was reported in
https://emacs.stackexchange.com/questions/59928/org-capture-at-point-as-sibling-of-heading
I was able to reproduce it starting from emacs -q with the following ECM:
emacs -q -l min.el foo.org
where min.el looks like this (adjust load-path to taste):
--8<---cut here---start->8---
(add-to-list 'load-path "~/src/org-mode/org-mode/lisp")
(require 'org-loaddefs)
(add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-cc" 'org-capture)
(global-set-key "\C-ca" 'org-agenda)
(setq org-capture-templates
'(("a" "Appointment or call" entry (file+headline "~/todo.org" "Tasks")
"* APPT %?\n %u")))
--8<---cut here---end--->8---
and foo.org looks like this (| is the position of the cursor):
--8<---cut here---start->8---
* foo
** one
*** two
three
|
four
--8<---cut here---end--->8---
In current Org mode, doing `C-0 M-x org-capture RET a' (where "a"
gets me an APPT template - see below), I get:
--8<---cut here---start->8---
* foo
** one
*** two
three
* APPT
[2020-08-04 Tue 12:58]
four
--8<---cut here---end--->8---
with the template at top level.
In 9.2, the same operation inserted a template as a sibling of the headline:
--8<---cut here---start->8---
* foo
** one
*** two
three
APPT
[2020-08-04 Tue 12:58]
four
--8<---cut here---end--->8---
The current behavior looks like a bug to me, so I bisected it to the following
commit:
--8<---cut here---start->8---
0201d1c0cc367fea0e561ba113f02f263b0ed501 is the first bad commit
commit 0201d1c0cc367fea0e561ba113f02f263b0ed501
Author: Nicolas Goaziou
Date: Sat Jul 6 15:59:12 2019 +0200
Fix inserting capture templates at point
* lisp/org-capture.el (org-capture):
(org-capture-set-target-location):
(org-capture-place-entry):
(org-capture-place-item):
(org-capture-place-table-line): Fix inserting capture templates at
point. Insert a new internal property for capture
template: :insert-here.
(org-capture-insert-template-here): Remove function.
* testing/lisp/test-org-capture.el (test-org-caputre/entry):
(test-org-capture/item):
(test-org-capture/table-line): Add tests.
Reported-by: Dominic Surano
etc/ORG-NEWS | 4 +-
lisp/org-capture.el | 126 +++
testing/lisp/test-org-capture.el | 58 +-
3 files changed, 104 insertions(+), 84 deletions(-)
--8<---cut here---end--->8---
HTH
---
Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32,
cairo version 1.16.0)
of 2020-06-15
Package: Org mode version 9.3.7 (release_9.3.7-705-gea9463 @
/home/nick/elisp/org-mode/lisp/)
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: File local setting for export directory?
Loris Bennett writes: > Hi Eric, > > Eric Abrahamsen writes: > >> "Loris Bennett" writes: >> >>> Hi, >>> >>> I want to export an org file to a pdf and have the pdf created in >>> subdirectory relative to the org file. >>> >>> What's the simplest way to set the export directory in a file local way? >> >> I suggested the attached diff a while ago, but no one seemed very >> interested. I think it might already do what you want. >> >> >> diff --git a/lisp/ox.el b/lisp/ox.el >> index 9cf62078a..77cafb20d 100644 >> --- a/lisp/ox.el >> +++ b/lisp/ox.el >> @@ -6417,6 +6417,20 @@ Return file name as a string." >>"Output file: " pub-dir nil nil nil >>(lambda (n) (string= extension (file-name-extension n t)) >> extension)) >> + (pub-dir (or pub-dir >> + (and subtreep (org-entry-get >> + nil "EXPORT_PUB_DIR" 'selective)) >> + (org-with-point-at (point-min) >> +(catch :found >> + (let ((case-fold-search t)) >> +(while (re-search-forward >> +"^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-" >> +nil t) >> + (let ((element (org-element-at-point))) >> +(when (eq 'keyword (org-element-type element)) >> + (throw :found >> + (org-element-property >> + :value element)) >> (output-file >>;; Build file name. Enforce EXTENSION over whatever user >>;; may have come up with. PUB-DIR, if defined, always has >> > > Thanks for the patch - it is exactly what I needed. > > I'm surprised no-one was interested, although I suppose back then I was > probably also one of the uninterested :-) Oh I'm not blaming anyone! There are a lot of patches coming down here, and a lot of ideas for Org, and it's hard to keep up. I don't think I did a very good job of stating my case, either. I actually hadn't thought of how the latex process might go haywire with an absolute export file name. My motivation was simply that "next to my *.org" files is pretty much never where I want exported files to end up. I want to send them to ~/tmp, or to a directory that's shared with colleagues via syncthing. In fact what I really want is to export to the value of ATTACH_DIR, because then I can immediately use all the attach tools on the exported files. Latex compilation is a nice additional argument, though! Eric
Re: Website revamp?
Right; shrink the banner. I meant to say "smaller" rather than "small". On Tue, Aug 4, 2020 at 12:26 PM TEC wrote: > > > Bruce D'Arcus writes: > > > On a large monitor, there's so much space that I think the features > > content would best fit underneath a small banner. > > Shrink the banner. Right - that sounds like something to try! > > I messed with the CSS a little using browser devtools (with one or two > unintended side-effects) to create a rough mock-up, and I like the result! > > As seen on my 27" monitor: https://i.imgur.com/zZUFlX3.png > > I'd be curious to know how that looks to you, > > Timothy.
Re: Website revamp?
Bruce D'Arcus writes: > On a large monitor, there's so much space that I think the features > content would best fit underneath a small banner. Shrink the banner. Right - that sounds like something to try! I messed with the CSS a little using browser devtools (with one or two unintended side-effects) to create a rough mock-up, and I like the result! As seen on my 27" monitor: https://i.imgur.com/zZUFlX3.png I'd be curious to know how that looks to you, Timothy.
Re: Website revamp?
On a large monitor, there's so much space that I think the features content would best fit underneath a small banner. On Tue, Aug 4, 2020 at 12:12 PM TEC wrote: > > > Thanks for the feedback! > > Maxim Nikulin writes: > > > 03.08.2020 12:11, TEC wrote: > >> > >> To see how orgmode.org currently appears, see > >> https://i.imgur.com/XPFfBaB.png > > > > Sorry for negative (and maybe discouraging) feedback. I would > > not mind if you just skip my complains since I am not a > > contributor to org-mode. > > Please, share your thoughts! > > > Concerning the screenshot, when first impression, that > > everything is broken and do not worth reading at all, is over, > > in my opinion, the text makes much more sense than "innovative" > > marketing stuff got priority on the demo of the new design. I > > consider the list of tasks, that org mode could help with, is > > the most important thing to attract new users. It should just be > > properly formatted. > > Re content for the index page, my current thoughts are: > - Some sort of informative introductory paragraph > - List of most common applications of org - Note latest version, > and when it was released > > I also have a styled equivalent of the screenshot on the current > site. > > These things just need to move from my mind, to the page :) > > Do let me know if you have any other specific ideas on content for > the index. > > > It seems that new variant is too mobile-centric. On a 24in > > monitor I expect something more than just a banner. There is > > plenty of room for brief news related to new releases, for more > > details of most important features (on the other hand I am > > against arbitrary scaled screenshots with excessively huge > > characters in comparison to surrounded text), etc. I am aware > > that my taste is against of modern design trends. > > If you have specific suggestions on how I could smoothly work in a > better design for the index on the desktop, I'd love to hear them. > If you could pair any such suggestions with reference to my > earlier thoughts* on the purpose of each page that will make it > easier to glimpse your thought process, and how it compares to my > own. > > \* see email in reply to Colin sent on Mon 03 Aug 07:53 UTC > > > A couple of remarks unrelated to new look but should be > > addressed in the case of rework. > > > > I am surprised that Emacs is explicitly mentioned only in html > > head title. The relation should be clear for new visitors. > > That's: > a) been removed from the head title. I couldn't find a browser > which would > display the whole thing without chopping it off the last > ~third > b) going to be mentioned prominently in the body, at least in my > current thoughts > > > As to installation, I believe that org-mode bundled with Emacs > > is more than enough for first try. It is a shorter path to > > become familiar with most prominent features just to start > > editing of an .org file (or to download a prepared demo .org). > > Getting the latest stable version could be a next step for the > > hooked users. > > Are you saying that you find the current mention of Emacs in the > instillation page works well? I'm currently just linking to Emacs. > Looking at the page though, I think I should make a more prominent > action to download Emacs. > > I love the idea of a demo org file! If anyone would like to help > out with creating one by sending in contenders / snippets that > would be brilliant! > > Even better - having two or three different demo files based on the use case > of > the new user - e.g. programmer, author, organisation - or something like that. >
Re: Website revamp?
Bruce D'Arcus writes: > On Tue, Aug 4, 2020 at 11:50 AM Maxim Nikulin wrote: > >> It seems that new variant is too mobile-centric. On a 24in monitor I >> expect something more than just a banner. > > I agree; it looked odd when I opened it on this 27-inch monitor. Hmm. Sounds like this design could do with re-visiting. To quote from my recent reply: > If you have specific suggestions on how I could smoothly work in a better > design > for the index on the desktop, I'd love to hear them. If you could pair any > such > suggestions with reference to my earlier thoughts* on the purpose of each page > that will make it easier to glimpse your thought process, and how it compares > to > my own. > > * see email in reply to Colin sent on Mon 03 Aug 07:53 UTC Thanks for the feedback, Timothy.
Re: Website revamp?
Thanks for the feedback! Maxim Nikulin writes: 03.08.2020 12:11, TEC wrote: To see how orgmode.org currently appears, see https://i.imgur.com/XPFfBaB.png Sorry for negative (and maybe discouraging) feedback. I would not mind if you just skip my complains since I am not a contributor to org-mode. Please, share your thoughts! Concerning the screenshot, when first impression, that everything is broken and do not worth reading at all, is over, in my opinion, the text makes much more sense than "innovative" marketing stuff got priority on the demo of the new design. I consider the list of tasks, that org mode could help with, is the most important thing to attract new users. It should just be properly formatted. Re content for the index page, my current thoughts are: - Some sort of informative introductory paragraph - List of most common applications of org - Note latest version, and when it was released I also have a styled equivalent of the screenshot on the current site. These things just need to move from my mind, to the page :) Do let me know if you have any other specific ideas on content for the index. It seems that new variant is too mobile-centric. On a 24in monitor I expect something more than just a banner. There is plenty of room for brief news related to new releases, for more details of most important features (on the other hand I am against arbitrary scaled screenshots with excessively huge characters in comparison to surrounded text), etc. I am aware that my taste is against of modern design trends. If you have specific suggestions on how I could smoothly work in a better design for the index on the desktop, I'd love to hear them. If you could pair any such suggestions with reference to my earlier thoughts* on the purpose of each page that will make it easier to glimpse your thought process, and how it compares to my own. \* see email in reply to Colin sent on Mon 03 Aug 07:53 UTC A couple of remarks unrelated to new look but should be addressed in the case of rework. I am surprised that Emacs is explicitly mentioned only in html head title. The relation should be clear for new visitors. That's: a) been removed from the head title. I couldn't find a browser which would display the whole thing without chopping it off the last ~third b) going to be mentioned prominently in the body, at least in my current thoughts As to installation, I believe that org-mode bundled with Emacs is more than enough for first try. It is a shorter path to become familiar with most prominent features just to start editing of an .org file (or to download a prepared demo .org). Getting the latest stable version could be a next step for the hooked users. Are you saying that you find the current mention of Emacs in the instillation page works well? I'm currently just linking to Emacs. Looking at the page though, I think I should make a more prominent action to download Emacs. I love the idea of a demo org file! If anyone would like to help out with creating one by sending in contenders / snippets that would be brilliant! Even better - having two or three different demo files based on the use case of the new user - e.g. programmer, author, organisation - or something like that.
Re: Website revamp?
On Tue, Aug 4, 2020 at 11:50 AM Maxim Nikulin wrote: > It seems that new variant is too mobile-centric. On a 24in monitor I > expect something more than just a banner. I agree; it looked odd when I opened it on this 27-inch monitor.
Re: Website revamp?
03.08.2020 12:11, TEC wrote: To see how orgmode.org currently appears, see https://i.imgur.com/XPFfBaB.png Sorry for negative (and maybe discouraging) feedback. I would not mind if you just skip my complains since I am not a contributor to org-mode. Concerning the screenshot, when first impression, that everything is broken and do not worth reading at all, is over, in my opinion, the text makes much more sense than "innovative" marketing stuff got priority on the demo of the new design. I consider the list of tasks, that org mode could help with, is the most important thing to attract new users. It should just be properly formatted. It seems that new variant is too mobile-centric. On a 24in monitor I expect something more than just a banner. There is plenty of room for brief news related to new releases, for more details of most important features (on the other hand I am against arbitrary scaled screenshots with excessively huge characters in comparison to surrounded text), etc. I am aware that my taste is against of modern design trends. A couple of remarks unrelated to new look but should be addressed in the case of rework. I am surprised that Emacs is explicitly mentioned only in html head title. The relation should be clear for new visitors. As to installation, I believe that org-mode bundled with Emacs is more than enough for first try. It is a shorter path to become familiar with most prominent features just to start editing of an .org file (or to download a prepared demo .org). Getting the latest stable version could be a next step for the hooked users.
Re: File local setting for export directory?
Russell Adams writes: > On Tue, Aug 04, 2020 at 08:25:13AM +0200, Loris Bennett wrote: >> > diff --git a/lisp/ox.el b/lisp/ox.el >> > index 9cf62078a..77cafb20d 100644 >> > --- a/lisp/ox.el >> > +++ b/lisp/ox.el >> > @@ -6417,6 +6417,20 @@ Return file name as a string." >> > "Output file: " pub-dir nil nil nil >> > (lambda (n) (string= extension (file-name-extension n t)) >> > extension)) >> > + (pub-dir (or pub-dir >> > +(and subtreep (org-entry-get >> > + nil "EXPORT_PUB_DIR" 'selective)) >> > +(org-with-point-at (point-min) >> > + (catch :found >> > +(let ((case-fold-search t)) >> > + (while (re-search-forward >> > + "^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-" >> > + nil t) >> > +(let ((element (org-element-at-point))) >> > + (when (eq 'keyword (org-element-type element)) >> > +(throw :found >> > + (org-element-property >> > +:value element)) >> > (output-file >> > ;; Build file name. Enforce EXTENSION over whatever user >> > ;; may have come up with. PUB-DIR, if defined, always has > > Regarding this patch, have you looked at setting up Org's Publish functions > in a > local variable? That has a "publish destination" which I believe is the > pub-dir > in that export function. > > https://orgmode.org/manual/Sources-and-destinations.html#Sources-and-destinations > > Perhaps this is fixed by another means? Maybe. I did look at "publish destination" but I couldn't get it to work, possibly because (a) I am not quite clear on difference between "exporting" and "publishing" and (b) I was feeling lazy and it seemed like an overly complex way of achieving what I wanted (not that patching the source can really be considered much less complex :-/ ). Cheers, Loris -- This signature is currently under construction.
Re: Macro replacement inside +attr_latex line
Found the answer in the mailing list archives (https://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00234.html). Not allowed. Vikas On Tue, 4 Aug 2020 at 18:33, Vikas Rawal wrote: > > Does orgmode macro replacement not work in an +attr_latex line? I was > thinking of using shortcuts for some complex latex syntax. > > Vikas
Macro replacement inside +attr_latex line
Does orgmode macro replacement not work in an +attr_latex line? I was thinking of using shortcuts for some complex latex syntax. Vikas
Re: How create a hook before export ONLY to text
On Mon, Aug 03, 2020 at 02:42:01PM +, pineiden wrote: > I discovered the plantuml language to create nice charts, also I have minted > configured to transform in latex to pdf. But minted doesn't have the lexer so > throws error. Sounds common enough, new languages hitting an export issue. > To parse or use 'sed' i don't know yet. To change the "#+BEGIN_SRC plantuml" > to "#+BEGIN_SRC text" or similar. Can you post a minimum working example of a broken file, and a working file? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: File local setting for export directory?
On Tue, Aug 04, 2020 at 08:25:13AM +0200, Loris Bennett wrote: > > diff --git a/lisp/ox.el b/lisp/ox.el > > index 9cf62078a..77cafb20d 100644 > > --- a/lisp/ox.el > > +++ b/lisp/ox.el > > @@ -6417,6 +6417,20 @@ Return file name as a string." > > "Output file: " pub-dir nil nil nil > > (lambda (n) (string= extension (file-name-extension n t)) > >extension)) > > +(pub-dir (or pub-dir > > + (and subtreep (org-entry-get > > +nil "EXPORT_PUB_DIR" 'selective)) > > + (org-with-point-at (point-min) > > + (catch :found > > + (let ((case-fold-search t)) > > + (while (re-search-forward > > + "^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-" > > + nil t) > > + (let ((element (org-element-at-point))) > > + (when (eq 'keyword (org-element-type element)) > > + (throw :found > > +(org-element-property > > + :value element)) > > (output-file > > ;; Build file name. Enforce EXTENSION over whatever user > > ;; may have come up with. PUB-DIR, if defined, always has Regarding this patch, have you looked at setting up Org's Publish functions in a local variable? That has a "publish destination" which I believe is the pub-dir in that export function. https://orgmode.org/manual/Sources-and-destinations.html#Sources-and-destinations Perhaps this is fixed by another means? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: File local setting for export directory?
On Tue, Aug 04, 2020 at 01:42:56PM +0200, Loris Bennett wrote: > > Please remember maintainer time is limited. There are often edge cases > > for one user as well for a software as flexible as Org. > > I appreciate that, although some form of control of where things are > exported to seems to me to be fairly generic functionality and something > which might be of interest to a number of people. Of course. Be patient and let them process the incoming patches in their time. ;] > It was mainly just the idea of being able to add a entire subdirectory > to .gitignore which made me think it would be nice to have a way of > changing export directory. That's an interesting idea, and one supported by existing conventions. It's common for Makefiles to write all executables to a subdir, and it's common to have .hgignore (or git) ignore that directory. I think here this issue is that while Org has that ability to specify the output file, the third party tool (latex) which is being called is using the full name and so the output may end up in the current directory. I think that would qualify as an unintended side effect. I think you're correct that Org should try to honor that when calling out, so I hope that patch gets picked up into core. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: File local setting for export directory?
Russell Adams writes: > On Tue, Aug 04, 2020 at 08:25:13AM +0200, Loris Bennett wrote: >> I'm surprised no-one was interested, although I suppose back then I was >> probably also one of the uninterested :-) > > Please remember maintainer time is limited. There are often edge cases > for one user as well for a software as flexible as Org. I appreciate that, although some form of control of where things are exported to seems to me to be fairly generic functionality and something which might be of interest to a number of people. >> I only have one org file from which I generate a number of graphics as >> well a PDF which contains the graphics. Don't many people do a lot more >> of that kind of stuff and don't they want to exclude a directory with >> generated files from, say, Git? > > I produce all of my professional documentation for customers in Org to > Latex and PDF. I create a directory for each document where all the > files go, and so I expect my .org, .tex, and .pdf files to be in the > root of that directory. I will sometimes add subdirectories for small > files (images, source code, etc) that I include in the final > document. Which sounds like opposite the scheme you are using. > > This may also come from my history of code management, makefiles, etc. In actual fact I do also have something similar for, say, presentations. The .org file and all generated files are in one directory, with some other files such as logos and photographs included from another directory. It was mainly just the idea of being able to add a entire subdirectory to .gitignore which made me think it would be nice to have a way of changing export directory. Cheers, Loris -- This signature is currently under construction.
Re: File local setting for export directory?
On Tue, Aug 04, 2020 at 08:25:13AM +0200, Loris Bennett wrote: > I'm surprised no-one was interested, although I suppose back then I was > probably also one of the uninterested :-) Please remember maintainer time is limited. There are often edge cases for one user as well for a software as flexible as Org. > I only have one org file from which I generate a number of graphics as > well a PDF which contains the graphics. Don't many people do a lot more > of that kind of stuff and don't they want to exclude a directory with > generated files from, say, Git? I produce all of my professional documentation for customers in Org to Latex and PDF. I create a directory for each document where all the files go, and so I expect my .org, .tex, and .pdf files to be in the root of that directory. I will sometimes add subdirectories for small files (images, source code, etc) that I include in the final document. Which sounds like opposite the scheme you are using. This may also come from my history of code management, makefiles, etc. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Website revamp?
Good to hear from you! Eric S Fraga writes: I do like the animated images in the features page! Glad you like them! I recently converted the static images to SVGs with the help of someone using Emacs27 w/ Cairo, would be nice go do something like an animated SVG in the future, but that's for (much) later :P I do wonder about the order of the topics within that page, e.g. working with source code, although powerful, is probably not the lead item for new users. However, that's a minor point at this stage. Thanks for this feedback. I prioritised the source code blocks because: a) my impression is that to Comp/Data Sci people, they are one of /the/ most compelling features of Org-mode b) they're similar to elements people are familiar with (Jupyter notebooks, R markdown), so the Comp/Data Sci segment of our audience is already roughy familiar with part of their capabilities I shifted the agenda/capture/clocking/etc. features down because a) they semantically seem like they should go together b) having them near the top pushes down too many other features too much, IMO Absolutely worth considering the order, please share any further thoughts you may have :) More generally, can the column width for the text be a function of the window width and have images scaled so that they are not wider than the text column? It should be possible to have mobile friendly without making the columns too narrow for full desktop use. The fact that the images are much wider than the text makes the page look ugly, in my opinion. The column width already is. I just find long lines undesirable. 50-80 characters is the standard in publishing for a reason. To quote from /The Elements of Typographic Style/, Anything from 45 to 75 characters is widely regarded as a satisfactory line length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple-column work, a better average is 40 to 50 characters. If the type is well set and printed, lines of 85 or 90 characters will pose no problem in discontinuous texts, such as bibliographies, or, with generous leading, in footnotes. But even with generous leading, a line that averages more than 75 or So characters is likely to be too long for continuous reading. There's more to be said about line spacing and the reasons for this - if I recall correctly /A practical guide to typography/ (available online) goes over this. I look forward to hearing any further comments you may have! Timothy.
Re: Bug: Exporting internal link to special latex block [9.3.7 (9.3.7-14-gb2b587-elpa @ /home/lobo/.emacs.d/elpa/org-20200720/)]
On Tuesday, 21 Jul 2020 at 15:52, Marco Falconi wrote: > I am trying to export to html a labeled latex special block (a theorem > environment, [...] > the link does not href to "#thm:mv" as expected, but to an auto-generated > label: Confirmed with org from git a few minutes ago. The link using an auto-generated label would be fine if the label were the one for the special block but it's not. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-682-geac255
Re: File local setting for export directory?
Hi Eric, Eric Abrahamsen writes: > "Loris Bennett" writes: > >> Hi, >> >> I want to export an org file to a pdf and have the pdf created in >> subdirectory relative to the org file. >> >> What's the simplest way to set the export directory in a file local way? > > I suggested the attached diff a while ago, but no one seemed very > interested. I think it might already do what you want. > > > diff --git a/lisp/ox.el b/lisp/ox.el > index 9cf62078a..77cafb20d 100644 > --- a/lisp/ox.el > +++ b/lisp/ox.el > @@ -6417,6 +6417,20 @@ Return file name as a string." > "Output file: " pub-dir nil nil nil > (lambda (n) (string= extension (file-name-extension n t)) > extension)) > + (pub-dir (or pub-dir > + (and subtreep (org-entry-get > + nil "EXPORT_PUB_DIR" 'selective)) > + (org-with-point-at (point-min) > + (catch :found > + (let ((case-fold-search t)) > + (while (re-search-forward > + "^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-" > + nil t) > + (let ((element (org-element-at-point))) > + (when (eq 'keyword (org-element-type element)) > + (throw :found > + (org-element-property > + :value element)) >(output-file > ;; Build file name. Enforce EXTENSION over whatever user > ;; may have come up with. PUB-DIR, if defined, always has > Thanks for the patch - it is exactly what I needed. I'm surprised no-one was interested, although I suppose back then I was probably also one of the uninterested :-) I only have one org file from which I generate a number of graphics as well a PDF which contains the graphics. Don't many people do a lot more of that kind of stuff and don't they want to exclude a directory with generated files from, say, Git? Any way, +1 for the patch, which I would like to see in Org. Cheers, Loris -- This signature is currently under construction.
Re: Website revamp?
On Monday, 3 Aug 2020 at 10:03, to...@tuxteam.de wrote: > Emacs should run fine on PostmarketOS [1] [2]. Thus Org, too. Emacs runs perfectly fine on Android via termux and org works as well (as does gnus!). But the issue is the keyboard. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-682-geac255
Re: Website revamp?
I do like the animated images in the features page! I do wonder about the order of the topics within that page, e.g. working with source code, although powerful, is probably not the lead item for new users. However, that's a minor point at this stage. More generally, can the column width for the text be a function of the window width and have images scaled so that they are not wider than the text column? It should be possible to have mobile friendly without making the columns too narrow for full desktop use. The fact that the images are much wider than the text makes the page look ugly, in my opinion. thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-682-geac255
