Re: [O] [PATCH] ob-clojure.el and ob-clojure-literate.el support new header argument :ns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicolas Goaziou writes: > Hello, > > I applied the patches with some substantial changes to commit messages > (often incomplete), removed "subr-x.el" calls (`thread-last' is just > confusing) and fixed compilation warnings. Thanks. About the compilation warnings. I only did "make test". have not do compilation test. Do you mean compile whole org-mode project or compile a single file ob-clojure.el with [M-x byte-compile-file]? I will include this step in my future patch workflow. > > Please double-check as I might have fumbled in the process. After test on my ob-clojure examples. All works fine. > > I didn't change "ob-clojure-literate.el" but there are dangling parens > and whitespace issues to fix. Also, I don't see the need for `dash' > library, but since it's a contrib/ package, I won't insist of it. > I don't know how to replace `-map` and `-contains-p` functions. Is there any suggestions? > > Regards, BTW, I write some documents on Worg about ob-clojure :ns usage, ob-clojure-literate.el and ob-js :session usage etc. But I can't push to remote. Here is my steps. 1. clone. #+begin_src shell :dir "~/Code/Emacs/" # git clone https://code.orgmode.org/bzg/worg.git # or git clone g...@code.orgmode.org:bzg/worg.git #+end_src (I tried both https and git protocols) - - I have uploaded my SSH key to code.orgmode.org. - - Tell git to use your private key with worg by updating =~/.ssh/config= with: #+begin_src conf ## Org-mode SSH key Host code.orgmode.org HostName code.orgmode.org IdentityFile ~/.ssh/id_rsa #+end_src 2. Be sure to "pull" the last version of the repository. #+begin_src shell :dir "~/Code/Emacs/word/" git pull --rebase #+end_src 3. commit 4. push #+begin_src shell :dir "~/Code/Emacs/worg" git push #+end_src But got error: , | 0 git … remote set-url --add origin https\://code.orgmode.org/bzg/worg.git | 0 git … remote set-url --delete origin \^git\@code\\.orgmode\\.org\:bzg/worg\\.git\$ | 1 git … push -v origin master\:refs/heads/master | Pushing to https://code.orgmode.org/bzg/worg.git | Counting objects: 18, done. | Writing objects: 100% (18/18), 5.87 KiB | 1.17 MiB/s, done. | Total 18 (delta 13), reused 0 (delta 0) | POST git-receive-pack (6160 bytes) | Password for 'https://stardivi...@code.orgmode.org': | POST git-receive-pack (6160 bytes) | error: RPC failed; HTTP 403 curl 22 The requested URL returned error: 403 Forbidden | fatal: The remote end hung up unexpectedly | fatal: The remote end hung up unexpectedly | Everything up-to-date ` I have uploaded my SSH key to code.orgmode.org already. Magit prompt to ask for password: https://stardivi...@code.orgmode.org I inputted the password. But still upper error. - -- [ stardiviner ] don't need to convince with trends. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrSsL8ACgkQG13xyVro msMurgf8DnQRN/zorx3/fTVHyMN9iTpYl3iBMMvCCk/L2c+pIfbSf/bh1PuMV+Xk vkPQQtCCzgzOXxruYd83addjV/C4c/CJ06shkkxoqU9xo+nqJaxkaXD7tjfmZ+Xd 2w8sHNbTRuZfZUbSXe9oF8OOqlzJA7ui9e0TrDAUcSJ2bdAnx4f2kqlCukETe89h kmGogdDRkRYF/CMIiKtjqvgYgqSmFUboYMSabYQr5w/SWYEDbLmr6S7fDxISmFCt DjZO4PgU9G/5hxmLU8lRWIWtRf2HRpUtHqp+Djyv+ccgcp1HoDwgEKSlt36XFCx4 orvEkqI0u3n14+/0/AR2gUg9MqcVsA== =mbVh -END PGP SIGNATURE-
Re: [O] org-calc-default-modes not found!
Am Samstag, 14. April 2018, 21:07:34 CEST schrieb Nick Dokos: > AW writes: > > > > C-h v org-calc TAB > > > > results in [No match] > > > > Expected result: find variable org-calc-default-modes > > > > > > But why is the variable not found? > > Just a guess. > > You need to load org-table.el where the variable is defined. That file > is probably set up to be autoloaded when you invoke some table > functions, but if you have not invoked any of the autoloads yet, then > you might encounter this problem. Works! Thank you! I pointed the cursor into a tabular.
Re: [O] How to get 'repeating footnotes' please?
> On Apr 13, 2018, at 3:40 AM, Sharon Kimble wrote: > > "Berry, Charles" writes: > >>> On Apr 10, 2018, at 5:42 AM, Sharon Kimble >>> wrote: >>> >>> Samuel Wales writes: >>> [fn:apples: ...] [fn:apples] >>> >>> I'm sorry Samuel, but it seems like you haven't read all of my initial >>> question, where I stated 'All my footnotes are 4 digits like >>> '[fn:0010]'.' I'm not going to change my habits of using numerical >>> footnotes that have been in documents for over ten years now to alpha >>> footnotes. Sorry, its just not going to happen! >>> >>> But I am open to any other suggestions which involve numerical >>> footnotes? >>> >> >> >> Numerical footnotes work the same as alpha AFAICS. So, Samuel's suggestion >> works, but I think you >> may be asking a question about repeating the *text* of a footnote rather >> than merely referencing it >> from a different location. If so, there may be a latex solution for you. >> Perhaps this helps: >> >> http://www.tex.ac.uk/FAQ-repfootnote.html >> >> and the fixfoot package is what you need. >> ?? >> >> If not maybe you can elaborate on what the desired latex should be. > > Thanks Chuck. > > Yes it is 'repeating text' that I want in my reused footnotes. > > The problem with the latex solutions that you've proposed is that they > rely on what I call 'static footnotes' meaning that the footnote number > always stays the same, whereas org-mode uses 'dynamic footnotes' meaning > that if you insert one between 3 and 4 they are automatically renumbered > to "3 and new one 4 and 5". > > When you're writing a long document, be it a book or an article or even > a letter and you use footnotes, its very handy for them to be > recalibrated every time that you use or insert a footnote. This > recalibration or automatic renumbering is a godsend I've found, and is > one of the strengths of org-mode, especially when you're memory is > becoming increasingly problematic and you keep forgetting what you want > to say. > > And that's why I'm trying to get repeat text in org-modes dynamic > footnotes. In every experiment that I've made using [fn:0001] as my > reference point it has failed, seemingly due to an inability to graft > latex commands into an org-mode dynamic footnote, which is then exported > and published as an latexed PDF. Org has no concept of a `page', which is required to handle repetition on subsequent pages. I think you are stuck in needing to find a LaTeX solution. And then look at how you marry it to org. HTH, Chuck
Re: [O] org-calc-default-modes not found!
AW writes:
> Dear list!
>
> org-version: Org mode version 9.1.9 (9.1.9-8-gf05c2e-elpa @ .../.emacs.d/elpa/
> org-20180409/)
>
> [I shortened the path]
>
> C-h v org-calc TAB
>
> results in [No match]
>
> Expected result: find variable org-calc-default-modes
>
> But I'd like to set (float 8) to (float 16) in orgtbl-mode tables, because
> when I export them to LaTex, in my case I get some rounding errors I'd like
> to
> avoid.
>
> However, I'm really concerned about the fact that the whole variable isn't
> found.
>
> org-table.el is there and it contains the variable. I loaded org-mode via
>
> (add-to-list 'package-archives
> '("org" . "https://orgmode.org/elpa/";) t)
>
> No other org-mode around, as far as I can see.
>
> For testing I inserted into my .emacs under custom-set-variables these lines:
>
> '(org-calc-default-modes
>(quote
> (calc-internal-prec 12 calc-float-format
> (float 16)
> calc-angle-mode deg calc-prefer-frac nil
> calc-symbolic-mode nil
> calc-date-format
> ( "-" MM "-" DD " " Www
> (" " hh ":" mm))
> calc-display-working-message t)))
>
> As far as I can see, the calculation is correct, Example:
>
> | 105000200.77 |
> | 105000400.05 |
> |--|
> | 21600.82 |
>
> #+TBLFM: @3$1=@1$1+@2$1
>
> But why is the variable not found?
>
Just a guess.
You need to load org-table.el where the variable is defined. That file
is probably set up to be autoloaded when you invoke some table
functions, but if you have not invoked any of the autoloads yet, then
you might encounter this problem.
--
Nick
Re: [O] Error handling in org-make-link-string
Hello, Bob Newell writes: > Aloha, > > Either of your suggested solutions would work, of course, and limit > effects to org-xxx-copy-for-org-mode. I didn't go that way because I > didn't want to have to continually modify the core product on my own > :) > > The idea of > > (if (org-string-nw-p link-location > > etc. may be best because we can have a guaranteed nil on a bad link, > rather than ignore-errors which (I think?) may have a different > return. I didn't put an error message in my 'advice' workaround but it > would be a good idea. Done. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Error handling in org-make-link-string
Aloha, Either of your suggested solutions would work, of course, and limit effects to org-xxx-copy-for-org-mode. I didn't go that way because I didn't want to have to continually modify the core product on my own :) The idea of (if (org-string-nw-p link-location etc. may be best because we can have a guaranteed nil on a bad link, rather than ignore-errors which (I think?) may have a different return. I didn't put an error message in my 'advice' workaround but it would be a good idea. Regards, Bob On Sat, Apr 14, 2018 at 3:17 AM, Nicolas Goaziou wrote: > Hello, > > Bob Newell writes: > >> The problem? When org-make-link-string encounters an empty link (it >> doesn't happen often but it does happen), it uses the 'error' function >> to say that the link is empty. This means that the entire call to >> org-xxx-copy-for-org-mode is aborted, and consequently nothing is >> captured. >> >> Should this be the desired behavior? > > Your question is twofold. > > OTOH, it seems sane to expect `org-make-link-string' to throw an error > if you try to apply it on garbage. OTOH, I agree it is not desirable to > throw away all captured information because of a bad link. > > I think the problem lies in the logic of `org-eww-copy-for-org-mode' and > `org-w3m-copy-for-org-mode', which should handle better errors from > `org-make-link-string'. > > For example, > >(if (stringp link-location) >;; hint: link-location is different for form-elements. >(org-make-link-string link-location link-title) > link-title) > > could be replaced with > > (if (org-string-nw-p link-location) > ...) > > or even > > (or (ignore-errors (org-make-link-string ...)) > link-title) > > WDYT? > > Regards, > > -- > Nicolas Goaziou -- Bob Newell Honolulu, Hawai`i Sent via Linux Mint 17.
Re: [O] [PATCH] ob-clojure.el and ob-clojure-literate.el support new header argument :ns
Hello, stardiviner writes: > After about 5 times test, And about 4 times review. I decide to PR. Thank you. I applied the patches with some substantial changes to commit messages (often incomplete), removed "subr-x.el" calls (`thread-last' is just confusing) and fixed compilation warnings. Please double-check as I might have fumbled in the process. I didn't change "ob-clojure-literate.el" but there are dangling parens and whitespace issues to fix. Also, I don't see the need for `dash' library, but since it's a contrib/ package, I won't insist of it. Regards, -- Nicolas Goaziou
Re: [O] [BUG] Org manual without correct org-version
Vladimir Lomov writes: > I thought that for software versions 9.1 < 9.1.9 and means that 9.1 > preceding the 9.1.9. We are not talking about software version but manual version. > And first thing that comes to my mind about recent > changes is a "template" system, there was ' C-,'. The '9.1' version (org from git) has 'Structure Templates' while > '9.1.9' version (org shipped with Emacs) doesn't have that section. If you use Org from git master's branch (aka development branch), you should know that it is, for the time being, akin to Org 9.2-alpha. There, I suggest to use "org-manual.org" instead of Org info manual, which is bound to be outdated. If you use Org from maint branch, there is no such problem: the 9.1 manual is accurate. > I prefer search for information in most recent docs than in "out-dated" > (see example with 'Structure Templates' above). So simple check of > version would help to find out what document is 'fresh' enough. Again, this has nothing to do with manual version. See above.
Re: [O] [BUG] Org manual without correct org-version
Hello, ** Nicolas Goaziou [2018-04-14 16:43:31 +0200]: > Vladimir Lomov writes: > >> Earlier there was "full" "git" version in Manual and I found it convenient >> (I read the manual from time to time to find how to do something in org) >> but now when I open Info with Org manual I'm a bit puzzled, it shows >> version 9.1 while Org from Emacs (I use Emacs from git) shows version >> 9.1.9 and that confuses me completely, which version is "fresh"? > > Barring typos and rewording, Org 9.1.9 is expected to have the same > manual as 9.1.0, or 9.1.13. An Org 9.1 manual means it is accurate for > Org 9.1.9. There is nothing puzzling. I thought that for software versions 9.1 < 9.1.9 and means that 9.1 preceding the 9.1.9. And first thing that comes to my mind about recent changes is a "template" system, there was '> I understand that, but on the other hand, when I/someone uses Org from >> git explicitly it would worth to show the "actual" version in Org Manual >> (as seen by Info). WDYT? > > If you use Org from git, you know the manual is on par with HEAD. As > a developer, I don't need to know the "git" version in manual. I'm > curious: what information are you missing? I prefer search for information in most recent docs than in "out-dated" (see example with 'Structure Templates' above). So simple check of version would help to find out what document is 'fresh' enough. --- WBR, Vladimir Lomov -- Don't change the reason, just change the excuses! -- Joe Cointment
Re: [O] [BUG] Org manual without correct org-version
Vladimir Lomov writes: > Earlier there was "full" "git" version in Manual and I found it convenient > (I read the manual from time to time to find how to do something in org) > but now when I open Info with Org manual I'm a bit puzzled, it shows > version 9.1 while Org from Emacs (I use Emacs from git) shows version > 9.1.9 and that confuses me completely, which version is "fresh"? Barring typos and rewording, Org 9.1.9 is expected to have the same manual as 9.1.0, or 9.1.13. An Org 9.1 manual means it is accurate for Org 9.1.9. There is nothing puzzling. > I understand that, but on the other hand, when I/someone uses Org from > git explicitly it would worth to show the "actual" version in Org Manual > (as seen by Info). WDYT? If you use Org from git, you know the manual is on par with HEAD. As a developer, I don't need to know the "git" version in manual. I'm curious: what information are you missing?
Re: [O] org-file-apps regex matching against path not link
"Frankie Y. Liu" writes: > When you said you cannot reproduce it, does that mean it works/matches for > you? It does, indeed.
Re: [O] org-file-apps regex matching against path not link
Hi Nicolas, Sorry I mistyped in the message, I did have two colons when trying it out. I will look into the function you pointed out. When you said you cannot reproduce it, does that mean it works/matches for you? I am using Emacs 25.3.5 and org-20180226 -f On Sat, Apr 14, 2018 at 12:42 AM, Nicolas Goaziou wrote: > Hello, > > "Frankie Y. Liu" writes: > > > For: > > > > \\.pdf:\\([0-9]+\\)\\' > > You forgot a colon. > > > [0-9]+ vs \d+ same issue, since the path not the link is being > > matched. > > > > Example: > > file:foo.pdf::1 will be matching on file:foo.pdf and the ::1 is > > dropped. > > > I cannot reproduce it here. The function > `org-file-apps-entry-match-against-dlink-p' is responsible for deciding > if a link needs to be matched in full, or not. > > Regards, > > -- > Nicolas Goaziou0x80A93738 >
Re: [O] [BUG] Org manual without correct org-version
Hello, ** Nicolas Goaziou [2018-04-13 19:37:09 +0200]: > Hello, > > Vladimir Lomov writes: > >> I'm using org-mode from git and found that now it is not show the >> 'git' version but simply 9.1 in Info file. In doc/ there is >> 'org-version.inc', it is included into 'orgguide.texi' but not in >> 'org.texi'. >> >> As I understand the 'org.texi' is generated from 'org-manual.org', so >> 'org-manual.org' should either somehow includes that file or provide >> other way to get version information. > > Why should it include the exact commit? Manual is for users. I'm not > sure this has any value. Earlier there was "full" "git" version in Manual and I found it convenient (I read the manual from time to time to find how to do something in org) but now when I open Info with Org manual I'm a bit puzzled, it shows version 9.1 while Org from Emacs (I use Emacs from git) shows version 9.1.9 and that confuses me completely, which version is "fresh"? > Actually, "org-manual.org" strips, on purpose, the bugfix number and the > commit release. I understand that, but on the other hand, when I/someone uses Org from git explicitly it would worth to show the "actual" version in Org Manual (as seen by Info). WDYT? > Regards, > > -- > Nicolas Goaziou --- WBR, Vladimir Lomov -- After a time, you may find that "having" is not so pleasing a thing, after all, as "wanting." It is not logical, but it is often true. -- Spock, "Amok Time", stardate 3372.7
Re: [O] Error handling in org-make-link-string
Hello, Bob Newell writes: > The problem? When org-make-link-string encounters an empty link (it > doesn't happen often but it does happen), it uses the 'error' function > to say that the link is empty. This means that the entire call to > org-xxx-copy-for-org-mode is aborted, and consequently nothing is > captured. > > Should this be the desired behavior? Your question is twofold. OTOH, it seems sane to expect `org-make-link-string' to throw an error if you try to apply it on garbage. OTOH, I agree it is not desirable to throw away all captured information because of a bad link. I think the problem lies in the logic of `org-eww-copy-for-org-mode' and `org-w3m-copy-for-org-mode', which should handle better errors from `org-make-link-string'. For example, (if (stringp link-location) ;; hint: link-location is different for form-elements. (org-make-link-string link-location link-title) link-title) could be replaced with (if (org-string-nw-p link-location) ...) or even (or (ignore-errors (org-make-link-string ...)) link-title) WDYT? Regards, -- Nicolas Goaziou
Re: [O] Support showing stars as pretty bullets
Nicolas Goaziou writes: > Hello, > > Alex Branham writes: > >> But then users of global-prettify-symbols-mode don't see the pretty >> symbols in org buffers without knowing about and activating >> org-pretty-mode. Anyway, the attached patch moves it to org-pretty.el. > > [...] > >> I've left it as a defvar since there's no way for us to know about what >> people want prettified where. Hopefully the default >> prettify-symbols-compose-p function does an OK job, but people will have >> to modify that if they customize org-pretty-alist anyway. > > I think there's a misunderstanding. To me, `prettify-symbols-mode' is > the plumbing. Org Pretty users should not have to care about it. > Likewise, when you use Org Bullets, you don't really care about how it > is done internally. > > As such, we know what people want prettified if we provide the > appropriate defcustom. > > BTW, the plumbing should be `compose-region', not > `prettify-symbols-mode'. IMO ‘prettify-symbols-mode’ is not pluming. It’s an Emacs-wide equivalent of "org-pretty-entities" (or at least the result when that variable is non-nil). IMO, the goal would be to offload more stuff into prettify-symbols-mode. Since this involves a "regexp" in a sense, compose-region might be better. In any case, the particular patch overwrites ‘prettify-symbols-alist’, meaning which symbols will be displayed will depend on whether users have their own pretty symbols loaded before the variable is being overwritten. Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] Support showing stars as pretty bullets
Hello, Alex Branham writes: > But then users of global-prettify-symbols-mode don't see the pretty > symbols in org buffers without knowing about and activating > org-pretty-mode. Anyway, the attached patch moves it to org-pretty.el. [...] > I've left it as a defvar since there's no way for us to know about what > people want prettified where. Hopefully the default > prettify-symbols-compose-p function does an OK job, but people will have > to modify that if they customize org-pretty-alist anyway. I think there's a misunderstanding. To me, `prettify-symbols-mode' is the plumbing. Org Pretty users should not have to care about it. Likewise, when you use Org Bullets, you don't really care about how it is done internally. As such, we know what people want prettified if we provide the appropriate defcustom. BTW, the plumbing should be `compose-region', not `prettify-symbols-mode'. WDYT? Regards, -- Nicolas Goaziou0x80A93738
[O] Need help on write new link type for link URI.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have following code, check out the FIXME: comment tag. How to get the correct link here? , | ;;; `video:filename.mp4::start_timestamp' | (defcustom org-video-link-open-command "mplayer" | "Specify the program for openning video: link." | :type 'string) | | (defun org-video-link-open (uri) | "Open video file `URI' with video player." | (let* ((list (split-string uri "::")) | (path (car list)) | (start-timstamp (cadr list))) | (shell-command | (format | "%s -ss %s %s" | ;; FIXME: path has issue. | org-video-link-open-command start-timstamp (org-link-unescape path) | | (org-link-set-parameters "video" | :follow #'org-video-link-open | :complete #'org-file-complete-link) ` - -- [ stardiviner ] don't need to convince with trends. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrRzaUACgkQG13xyVro msP3nwf+JXnDDnnAgBuvBjkATJWuNryX5twTex/LBrqq9IP66j4DUC9ypmYIgpJ+ zVt/I1u7niGnyiMOtNotG7VJTae68HeDFQhMdURycI3gG6gUeoQw21bscQ7PYyl3 9Bx6xnLsJ6/XkPd3OnKbuNmI91B7b8x7KGCc6we2Atz27QKDPu9Z5Bcq2mdpsIBs U8vXH/cNeFC1n10uCMW08WhSpiRoqPgtzYUHDSywWcl38bh+9PUwJxiwEKI/wgrh OJXbLoiNxFakOcxvKwTrFEGWBEen8hMBOzAIm1L4y0eTUPbJiPO8sbOH2zCBokVZ Wbk1Y7N1QJMTWZIpS86RmS5ZPYVxng== =LYgd -END PGP SIGNATURE-
Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.
At 2018-04-14 15:44:00, "Nicolas Goaziou" wrote: >Hello, > >tumashu writes: > >> I do not know why must save-buffer, may be for information safe :-) > >If there is no objection, I suggest to simply remove this call to >`save-buffer' instead of introducing a new variable. > Agree this idea, If user want to save-buffer when capture finish, they can add save-buffer to org-capture-after-finalize-hook or just type C-x C-s >Regards, > >-- >Nicolas Goaziou0x80A93738
Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.
Hello, tumashu writes: > I do not know why must save-buffer, may be for information safe :-) If there is no objection, I suggest to simply remove this call to `save-buffer' instead of introducing a new variable. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] org-file-apps regex matching against path not link
Hello, "Frankie Y. Liu" writes: > For: > > \\.pdf:\\([0-9]+\\)\\' You forgot a colon. > [0-9]+ vs \d+ same issue, since the path not the link is being > matched. > > Example: > file:foo.pdf::1 will be matching on file:foo.pdf and the ::1 is > dropped. I cannot reproduce it here. The function `org-file-apps-entry-match-against-dlink-p' is responsible for deciding if a link needs to be matched in full, or not. Regards, -- Nicolas Goaziou0x80A93738
