Re: [O] org-eldoc error on shell src blocks
Hello, "numbch...@gmail.com" writes: > After some dive in deeper > > - [X] emacs minimal init test, confirmed issue in org-mode. > - [X] from the error log, seems `org-eldoc` try to call `(progn (funcall > mode-func) ...`. This caused `shell-mode()`. > - [ ] check out `org-eldoc.el` source code, have not found any solution or > options. > Hope some org-mode hacker can help to fix this issue? I'm Cc'ing Org Eldoc author about it. > And this might be a unit test in Org-mode testing? We don't test contrib packages. However, they can provide their own tests. Regards, -- Nicolas Goaziou
Re: [O] org-eldoc error on shell src blocks
After some dive in deeper
- [X] emacs minimal init test, confirmed issue in org-mode.
- [X] from the error log, seems `org-eldoc` try to call `(progn (funcall
mode-func) ...`. This caused `shell-mode()`.
- [ ] check out `org-eldoc.el` source code, have not found any solution or
options.
Hope some org-mode hacker can help to fix this issue?
And this might be a unit test in Org-mode testing?
[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter: @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/
On Fri, Feb 2, 2018 at 9:32 AM, numbch...@gmail.com
wrote:
> When I enable `eldoc-mode` in org-mode.
> eldoc timer running when on `shell` src blocks like:
>
> #+begin_src shell
> git log $rev..origin/emacs-25 -- lisp/org doc/misc/org.texi \
> etc/refcards/orgcard.tex etc/ORG-NEWS etc/org \
> etc/schema/od-manifest-schema-v1.2-os.rnc \
> etc/schema/od-schema-v1.2-os.rnc
> #+end_src
>
> I got the following error.
>
> #+begin_example
> Debugger entered--Lisp error: (wrong-type-argument processp nil)
> process-command(nil)
> shell-mode()
> funcall(shell-mode)
> (progn (funcall mode-func) (setq doc-func (and
> eldoc-documentation-function (symbol-value 'eldoc-documentation-function)))
> (puthash lang doc-func org-eldoc-local-functions-cache))
> (unwind-protect (progn (funcall mode-func) (setq doc-func (and
> eldoc-documentation-function (symbol-value 'eldoc-documentation-function)))
> (puthash lang doc-func org-eldoc-local-functions-cache)) (and
> (buffer-name temp-buffer) (kill-buffer temp-buffer)))
> (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
> (funcall mode-func) (setq doc-func (and eldoc-documentation-function
> (symbol-value 'eldoc-documentation-function))) (puthash lang doc-func
> org-eldoc-local-functions-cache)) (and (buffer-name temp-buffer)
> (kill-buffer temp-buffer
> (let ((temp-buffer (generate-new-buffer " *temp*")))
> (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
> (funcall mode-func) (setq doc-func (and eldoc-documentation-function
> (symbol-value 'eldoc-documentation-function))) (puthash lang doc-func
> org-eldoc-local-functions-cache)) (and (buffer-name temp-buffer)
> (kill-buffer temp-buffer)
> (progn (let ((temp-buffer (generate-new-buffer " *temp*")))
> (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
> (funcall mode-func) (setq doc-func (and eldoc-documentation-function
> (symbol-value 'eldoc-documentation-function))) (puthash lang doc-func
> org-eldoc-local-functions-cache)) (and (buffer-name temp-buffer)
> (kill-buffer temp-buffer) doc-func)
> (if (fboundp mode-func) (progn (let ((temp-buffer (generate-new-buffer "
> *temp*"))) (save-current-buffer (set-buffer temp-buffer) (unwind-protect
> (progn (funcall mode-func) (setq doc-func (and eldoc-documentation-function
> (symbol-value 'eldoc-documentation-function))) (puthash lang doc-func
> org-eldoc-local-functions-cache)) (and (buffer-name temp-buffer)
> (kill-buffer temp-buffer) doc-func))
> (if (eq 'empty cached-func) (if (fboundp mode-func) (progn (let
> ((temp-buffer (generate-new-buffer " *temp*"))) (save-current-buffer
> (set-buffer temp-buffer) (unwind-protect (progn (funcall mode-func) (setq
> doc-func (and eldoc-documentation-function (symbol-value
> 'eldoc-documentation-function))) (puthash lang doc-func
> org-eldoc-local-functions-cache)) (and (buffer-name temp-buffer)
> (kill-buffer temp-buffer) doc-func)) cached-func)
> (let ((cached-func (gethash lang org-eldoc-local-functions-cache
> 'empty)) (mode-func (intern-soft (format "%s-mode" lang))) doc-func) (if
> (eq 'empty cached-func) (if (fboundp mode-func) (progn (let ((temp-buffer
> (generate-new-buffer " *temp*"))) (save-current-buffer (set-buffer
> temp-buffer) (unwind-protect (progn (funcall mode-func) (setq doc-func (and
> eldoc-documentation-function (symbol-value 'eldoc-documentation-function)))
> (puthash lang doc-func org-eldoc-local-functions-cache)) (and
> (buffer-name temp-buffer) (kill-buffer temp-buffer) doc-func))
> cached-func))
> org-eldoc-get-mode-local-documentation-function("shell")
> (let ((doc-fun (org-eldoc-get-mode-local-documentation-function lang)))
> (if (functionp doc-fun) (progn (funcall doc-fun
> (cond ((or (string= lang "emacs-lisp") (string= lang "elisp")) (if
> (fboundp 'elisp-eldoc-documentation-function)
> (elisp-eldoc-documentation-function)
> (let (eldoc-documentation-function) (eldoc-print-current-symbol-info
> ((or (string= lang "c") (string= lang "C")) (if (require 'c-eldoc nil t)
> (progn (c-eldoc-print-current-symbol-info ((string= lang "css") (if
> (require 'css-eldoc nil t) (progn (css-eldoc-function ((string= lang
> "php") (if (require 'php-eldoc nil t) (progn (php-eldoc-function ((or
> (string= lang "go") (string= lang "golang")) (if (require 'go-eldoc nil t)
> (pr
Re: [O] Ad-hoc, mix-and-match tag hierarchies?
I don't think you are missing anything. Your first example leverages
inheritance (and you can turn that off if you don't want it), and your second
example doesn't.
In any case, the order of the tags is irrelevant. To me the real question is
what do you want to use them for?
I use them in agenda queries, and there the order is not important. That
is a nice feature, since you don't have to know the hierarchy, and can
query emacs+lisp or lisp+emacs for example and get the same things.
Suppose you have the headers at the end of this email.
These:
(org-tags-view nil "emacs+lisp")
(org-tags-view nil "lisp+emacs")
both show in the agenda (these are in a file called 2018-02-03.org)
2018-02-03: header 1.1.1
:emacs:orgmode::lisp:
2018-02-03: header b
:emacs:orgmode:lisp:
2018-02-03: header B
:lisp:emacs:orgmode:
Note that header 1.1.1 has all the tags from inheritance, and the other
two have all the tags in different orders. You can use a query like
"emacs-orgmode" to get headlines tagged emacs and not tagged orgmode.
* header 1:emacs:
** header 1.1 :orgmode:
*** header 1.1.1 :lisp:
stuff about Emacs' org-mode's lisp code
* header a:emacs:
stuff about Emacs
* header b :emacs:orgmode:lisp:
stuff about Emacs' org-mode's lisp code
* header B :lisp:emacs:orgmode:
The tag order is not important
* header c :lisp:
stuff about just Common Lisp
* header d:emacs:orgmode:
stuff about Emacs' org-mode
* header e:emacs:
more stuff about Emacs
Lawrence Bottorff writes:
> So a left-to-right listing of (colon-separated) tags after the heading
> cannot imply a higher-to-lower hierarchical order? So there is no hierarchy
> unless you create it, e.g.,
>
> (setq org-tag-alist '((:startgrouptag)
>("GTD")
> (:grouptags)
> ("Control")
> ("Persp") ...
>
> -- is what I'm hearing.
>
> What I meant to do is to be able to use tags alone or together. And when
> used together, to somehow imply hierarchy. So if I have
>
> * header 1:emacs:
>
> ** header 1.1 :orgmode:
>
> *** header 1.1.1 :lisp:
> stuff about Emacs' org-mode's lisp code
>
> this implies subject hierarchy simply from the headers' hierarchy. However
> this
>
> * header 1 :emacs:
> stuff about Emacs
> * header 2 :emacs:orgmode:lisp
> stuff about Emacs' org-mode's lisp code
> * header 3 :lisp:
> stuff about just Common Lisp
> * header 4 :emacs:orgmode:
> stuff about Emacs' org-mode
> * header 5 :emacs:
> more stuff about Emacs
>
> is all peers header-wise, while the tags (if using left-to-right listing to
> mean higher to lower in hierarchy) tell us the depth level of
> specialization of a topic. The first set of headers is relying (clumsily)
> on the header level to indicate depth of specialization, which is not
> always realistic. If I wanted, ad-hoc, to indicate levels of some hierarchy
> with tags, that is, not be forced to create empty superior headers, it
> seems there's no prescribed way to do this. And creating tag hierarchies
> by hand, i.e., (setq org-tag-alist '((:startgrouptag)..., makes me play the
> combinatorics game of imagining all different possible hierarchy
> combinations. Or am I missing something?
>
> On Thu, Feb 1, 2018 at 10:36 AM, Kaushal Modi
> wrote:
>
>> On Thu, Feb 1, 2018 at 10:30 AM John Kitchin
>> wrote:
>>
>>> I was not aware of any implied hierarchy with tags. The order is not
>>> important as far as I know, and what you describe as mix-and-match seems
>>> ok. There is an idea of inheritance, e.g. sub-headings can inherit tags
>>> from higher headings.
>>>
>>
>> Same here.
>>
>>
>>> I am not sure about the org-mode tag.
>>>
>>
>> "-" is an invalid tag character.. the tag can be "org_mode", but not
>> "org-mode". Last time I tried using hyphen, I remember that the tag
>> auto-alignment would stop working (C-u C-c C-q) and also the tag face won't
>> be applied.
>>
>> @Lawrence:
>>
>> You can have tag inheritance this way:
>>
>> * Emacs :emacs:
>> Emacs stuff
>> ** Lisp :lisp:
>> Emacs lisp stuff here
>> *** Org :org_mode:
>> Emacs + Lisp + Org mode stuff
>> ** Org :org_mode:
>> Emacs + Org mode stuff (but not lisp)
>> --
>>
>> Kaushal Modi
>>
--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
Re: [O] non-space, paste, (???) character for inline results
Greg Minshall writes: >> Of course we do: just write >> >> foocall_foo() >> >> or >> >> foocall_foo() > > !!! :) > > (but, seems less intuitive. maybe my math/CS brainwashing, liking to > have lexical elements, etc.; that part of me would still vote for > reverting.) Hmmm, you may well be right. Fair enough. I reverted it. Thank you.
Re: [O] Exporting selected tags *with* its sub-tag hierarchy
Hello, Pierre-Luc Gauthier writes: > I have this tree of tags as explained here : > https://orgmode.org/manual/Tag-hierarchy.html > loaded at startup. E.g.: > > #+TAGS: [ @errands : bank groceries ] > > Filtering the @errands tag in the agenda todo view does lists all of > @errands sub tags as expected (i.e.: bank and groceries). Why then doesn't > SELECT_TAGS do the same on exporting? Good question. I implemented it as a bugfix in maint branch. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
Kaushal Modi writes: > 1. Download the attached Org file (property-auto-fill.org). > 2. emacs -Q property-auto-fill.org > 3. Navigate to the Heading, hit TAB, then to the PROPERTY drawer, hit TAB. > 4. Go to the end of the DESCRIPTION property, hit RET. Wait... What? Properties drawers do not contain blank lines. If you hit , this is no longer a properties drawer, but a regular one, where auto-filling is allowed. If you want to add a new property, use C-c C-x p, or, if you insist on typing it manually, use C-q instead.
[O] git://orgmode.org/org-mode.git --> g...@code.orgmode.org:bzg/org-mode.git : Now password is required
Hi, Short summary to bypass the TL;DR below: In order for me to do a 'git pull' into an existing local repo only for 'read-only' mode (not contributing changes back), I had to change my .git/config from: [remote "official"] url = git://orgmode.org/org-mode.git fetch = +refs/heads/*:refs/remotes/official/* to [remote "official"] url = https://code.orgmode.org/bzg/org-mode.git fetch = +refs/heads/*:refs/remotes/official/* Only after doing that could I do a 'git pull' without errors or password promptings. Maybe that is the way it is intended to work, but the instructions on the website imply it should work without any password requirement using the "git:" method and not the "https:" method. So I'm reporting this just in case there is some server issue, versus user error on my part. -- TL;DR: detail: I have local clone of org-mode from long ago that I'm needing to update again. My .git/config file contains: [remote "official"] url = git://orgmode.org/org-mode.git fetch = +refs/heads/*:refs/remotes/official/* [branch "master"] remote = official merge = refs/heads/master I tried doing a 'git fetch' today and it gave me: fatal: unable to connect to orgmode.org: orgmode.org[0: 45.77.206.30]: errno=Connection refused So I looked on the main website at https://orgmode.org/ and it showed that something had changed w.r.t. where to clone from which is: g...@code.orgmode.org:bzg/org-mode.git But cloning from that requires a password: $ git clone g...@code.orgmode.org:bzg/org-mode.git Cloning into 'org-mode'... g...@code.orgmode.org's password: Why is a password now required just to clone the repo? Note that this is separate from the need to push back into that repo, so my expectation is to be able to clone and use separate from committing changes back to the "official" master, all by using the normal "git:" method that is indicated as preferred on https://orgmode.org/worg/org-contribute.html (and I realized that is for contributing, but the main site still has the "git:" form listed with no indication that a password ritual is needed). Regards, Brent
[O] Broken links on orgmode.org site that point to Gmane
Hi Org Mode: At Sat Feb 3 12:27:14 PST 2018, I navigated to https://orgmode.org/community.html then saw "Browse it through Gmane" which has a link to: http://news.gmane.org/gmane.emacs.orgmode Clicking on that link gave a Page Not found error. Regards, bgoodr
Re: [O] Change mode in org-edit-special
On 2018-02-02 18:07, Berry, Charles wrote: On Feb 1, 2018, at 9:07 PM, ed...@openmail.cc wrote: Is there a safe way to change mode in an org-edit-special buffer? The safest thing would be to customize `org-src-lang-modes' so the buffer is created with the mode you want to edit in. Or if you want to edit in that mode only occasionally write a small function that let-binds `org-src-lang-modes` to the value you need and use that function as needed to create the buffer in that mode. As far as changing major mode while already editing, the responses here might help: https://emacs.stackexchange.com/questions/21940/avoid-minor-modes-from-turning-off-when-changing-restarting-major-mode HTH, Chuck Thanks. I will try :) - ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
Kaushal Modi writes: > On Sat, Feb 3, 2018 at 11:22 AM Nick Dokos wrote: > > FWIW, I tried it too both with emacs -Q and in my normal working emacs: I > cannot reproduce it. > > Hello Nick, Nicolas, > > Thank you for trying out the MWE. I don't know what we could be doing > differently. > > So here's a recorded screencast ( https://i.imgur.com/8u8KhAy.gifv ) to get > rid of any miscommunication. > Sorry, I was wrong: I'm not sure why I could not reproduce it earlier, but I just retried it both with -Q (9.1.6 -50) and my working org-mode (9.1.6 -392) and I do get auto-filled in both versions. Sometimes I think I'm going mad... -- Nick
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
On Sat, Feb 3, 2018 at 11:22 AM Nick Dokos wrote: > > FWIW, I tried it too both with emacs -Q and in my normal working emacs: I > cannot reproduce it. > Hello Nick, Nicolas, Thank you for trying out the MWE. I don't know what we could be doing differently. So here's a recorded screencast ( https://i.imgur.com/8u8KhAy.gifv ) to get rid of any miscommunication. Please follow this exact steps (just to reiterate, I am relying on auto-fill-mode to not trigger when RET is pressed.. I am not using M-q anywhere): 1. Download the attached Org file (property-auto-fill.org). 2. emacs -Q property-auto-fill.org 3. Navigate to the Heading, hit TAB, then to the PROPERTY drawer, hit TAB. 4. Go to the end of the DESCRIPTION property, hit RET. 5. Doesn't that property auto-fill for you? As you see in the screencast, the auto-filling happens for me. Here's the C-h l log as you see in the linked screencast: C-n [next-line] C-n [next-line] C-a [org-beginning-of-line] C-p [previous-line] C-a [org-beginning-of-line] [org-cycle] C-n [next-line] [org-cycle] C-n [next-line] C-e [org-end-of-line] [org-return] C-h l [view-lossage] And finally the emacs and Org versions in that emacs -Q session: - GNU Emacs 26.0.91 (build 4, x86_64-pc-linux-gnu, GTK+ Version 2.24.23) of 2018-01-31 built using repository revision http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=56c37bbdb60f201791b57a3af2f47b7517de810c - Org mode version 9.1.6 (release_9.1.6-50-g96b33f @ /home/kmodi/usr_local/apps/6/emacs/emacs-26/share/emacs/26.0.91/lisp/org/) -- Kaushal Modi property-auto-fill.org Description: Binary data
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
Kaushal Modi writes: > On Sat, Feb 3, 2018, 9:40 AM Nicolas Goaziou wrote: > > Kaushal Modi writes: > > I think I spotted your mistake. Considering (a part of) your ECM: > > * Heading > > :PROPERTIES: > > > There's a line between the heading and the properties drawer, so it is > a regular drawer, > > I don't follow. I don't have that extra line.. I wonder why it shows up like > that to you. > > You can see in this screenshot I pasted earlier that I have no empty line > between headline and property drawer: > http://lists.gnu.org/r/emacs-orgmode/2018-02/png5WGaeZ0gLm.png > > I don't see that empty line on the web too: > http://lists.gnu.org/r/emacs-orgmode/2018-01/msg00497.html > FWIW, I tried it too both with emacs -Q and in my normal working emacs: I cannot reproduce it. -- Nick
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
Kaushal Modi writes: > On Sat, Feb 3, 2018, 9:40 AM Nicolas Goaziou wrote: > >> Kaushal Modi writes: >> >> I think I spotted your mistake. Considering (a part of) your ECM: >> >>* Heading >> >>:PROPERTIES: >> >> >> There's a line between the heading and the properties drawer, so it is >> a regular drawer, >> > > I don't follow. I don't have that extra line.. I wonder why it shows up > like that to you. > > You can see in this screenshot I pasted earlier that I have no empty line > between headline and property drawer: > http://lists.gnu.org/r/emacs-orgmode/2018-02/png5WGaeZ0gLm.png > > I don't see that empty line on the web too: > http://lists.gnu.org/r/emacs-orgmode/2018-01/msg00497.html It may be Gnus, then, because the message above appears with a blank line below the heading. Anyways, I cannot reproduce your issue, even with local variables.
Re: [O] stop results drawers from folding?
hm. naturally even though this has bugged me for months, publically asking about it seems to have made the issue vanish! If I figure out what the issue was I will bring it up again later. Sorry for the noise. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Feb 1, 2018 at 2:44 PM, Nicolas Goaziou wrote: > Hello, > > John Kitchin writes: > > > I use results drawers for my src blocks alot, and for a while now every > > time I run one block, it folds all the other results drawers, unless I > use > > visible-mode. > > > > Is there a way to prevent this drawer folding so that they are open when > I > > open a document, and they stay open while running blocks? > > Would you have an ECM demonstrating the issue? > > Regards, > > -- > Nicolas Goaziou >
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
On Sat, Feb 3, 2018, 9:40 AM Nicolas Goaziou wrote: > Kaushal Modi writes: > > I think I spotted your mistake. Considering (a part of) your ECM: > >* Heading > >:PROPERTIES: > > > There's a line between the heading and the properties drawer, so it is > a regular drawer, > I don't follow. I don't have that extra line.. I wonder why it shows up like that to you. You can see in this screenshot I pasted earlier that I have no empty line between headline and property drawer: http://lists.gnu.org/r/emacs-orgmode/2018-02/png5WGaeZ0gLm.png I don't see that empty line on the web too: http://lists.gnu.org/r/emacs-orgmode/2018-01/msg00497.html > -- Kaushal Modi
Re: [O] non-space, paste, (???) character for inline results
> Of course we do: just write > > foocall_foo() > > or > > foocall_foo() !!! :) (but, seems less intuitive. maybe my math/CS brainwashing, liking to have lexical elements, etc.; that part of me would still vote for reverting.)
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
Kaushal Modi writes: > Did you copy and paste the whole ECM including the Local Variables? .. > because I can reproduce that in emacs -Q (emacs-26 branch). > > It's something about auto-fill-mode being on, that's different from > M-q. I think I spotted your mistake. Considering (a part of) your ECM: * Heading :PROPERTIES: :DESCRIPTION: This is a very long description that will auto fill at the =fill-column=. But this is inside a property drawer, so the auto-filling should be disabled. :END: There's a line between the heading and the properties drawer, so it is a regular drawer, where filling is allowed. `org-lint' warns you about this.
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
On Sat, Feb 3, 2018, 9:29 AM Nicolas Goaziou wrote: > It is already the case. See `org-adaptive-fill-function': it returns nil > when at a node property. > I thought so too, because the filling doesn't happen on M-q. So it took me a while to come with that complete ECM. I cannot reproduce your ECM. > Did you copy and paste the whole ECM including the Local Variables? .. because I can reproduce that in emacs -Q (emacs-26 branch). It's something about auto-fill-mode being on, that's different from M-q. > -- Kaushal Modi
Re: [O] Bug: org-feed-update-all stops on first error [9.0.9 (9.0.9-dist @ /usr/share/emacs/25.2/site-lisp/elpa/org-9.0.9/)]
Hello, Adrian Tritschler writes: > Using org-feed-update-all to read RSS feeds into org-mode, it will stop > with an error on the first problem encountered. eg, if I have twenty > RSS feeds and for some reason the second site is down, or certificate > has expired, only the first one is updated and the remaining feeds are > not attempted. There appears to be no way to have org-feed-update-all > make an attempt on all feeds in org-feed-alist Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] non-space, paste, (???) character for inline results
Greg Minshall writes: > thanks for the reply. i'd suggest reverting (most of) 7efa... so that > foocall_foo() *stays* as foocall_foo(). (i.e., put the "\\<" back in > front of "call_" and "sys_".) otherwise, we have no (straight forward) > way (am i right? sometimes my head hurts!) to get a plain > "foocall_foo()" in the output. Of course we do: just write foocall_foo() or foocall_foo() etc.
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
Hello, Kaushal Modi writes: > Hello, > > I am bumping this thread, as it very likely could have been missed. > > If fixing that was already on the radar, sorry for the bump. > > On Tue, Jan 30, 2018, 11:50 AM Kaushal Modi wrote: > >> Hello, >> >> I have noticed that auto-filling working on long (going past fill-column) >> values in property drawers. >> >> Here's a MWE: >> >> = >> #+TITLE: Test case showing auto-filling happening in Property drawers too >> * Heading >> :PROPERTIES: >> :DESCRIPTION: This is a very long description that will auto fill at the >> =fill-column=. But this is inside a property drawer, so the auto-filling >> should be disabled. >> :END: >> * COMMENT Local Variables >> # Local Variables: >> # fill-column: 70 >> # eval: (auto-fill-mode 1) >> # End: >> = >> >> The value of that DESCRIPTION property is in a single line (I believe some >> email clients auto-fill the text). Basically this is what it should look >> like in emacs -Q after M-x toggle-truncate-lines: >> >> [image: image.png] >> >> Now if you hit return at the end of that long description, auto-fill kicks >> in and turns that into this invalid drawer: >> >> = >> #+TITLE: Test case showing auto-filling happening in Property drawers too >> * Heading >> :PROPERTIES: >> :DESCRIPTION: This is a very long description that will auto fill at >> the =fill-column=. But this is inside a property drawer, so the >> auto-filling should be disabled. >> >> :END: >> * COMMENT Local Variables >> # Local Variables: >> # fill-column: 70 >> # eval: (auto-fill-mode 1) >> # End: >> = >> >> This looks like a bug. Can the auto-filling be disabled in property >> drawers? It is already the case. See `org-adaptive-fill-function': it returns nil when at a node property. I cannot reproduce your ECM. Regards, -- Nicolas Goaziou
Re: [O] non-space, paste, (???) character for inline results
Nico, thanks for the reply. i'd suggest reverting (most of) 7efa... so that foocall_foo() *stays* as foocall_foo(). (i.e., put the "\\<" back in front of "call_" and "sys_".) otherwise, we have no (straight forward) way (am i right? sometimes my head hurts!) to get a plain "foocall_foo()" in the output. (whereas, with 7efa reverted, we can get "foocall_foo()" in the output by writing exactly that, and, if we *really* want foo, for == results of executing call_foo(), we write foocall_foo().) thanks for the pointer to org-export-filter-final-output-functions. cheers, Greg
Re: [O] Prevent auto-fill-mode from filling Property values in drawers
Hello, I am bumping this thread, as it very likely could have been missed. If fixing that was already on the radar, sorry for the bump. On Tue, Jan 30, 2018, 11:50 AM Kaushal Modi wrote: > Hello, > > I have noticed that auto-filling working on long (going past fill-column) > values in property drawers. > > Here's a MWE: > > = > #+TITLE: Test case showing auto-filling happening in Property drawers too > * Heading > :PROPERTIES: > :DESCRIPTION: This is a very long description that will auto fill at the > =fill-column=. But this is inside a property drawer, so the auto-filling > should be disabled. > :END: > * COMMENT Local Variables > # Local Variables: > # fill-column: 70 > # eval: (auto-fill-mode 1) > # End: > = > > The value of that DESCRIPTION property is in a single line (I believe some > email clients auto-fill the text). Basically this is what it should look > like in emacs -Q after M-x toggle-truncate-lines: > > [image: image.png] > > Now if you hit return at the end of that long description, auto-fill kicks > in and turns that into this invalid drawer: > > = > #+TITLE: Test case showing auto-filling happening in Property drawers too > * Heading > :PROPERTIES: > :DESCRIPTION: This is a very long description that will auto fill at > the =fill-column=. But this is inside a property drawer, so the > auto-filling should be disabled. > > :END: > * COMMENT Local Variables > # Local Variables: > # fill-column: 70 > # eval: (auto-fill-mode 1) > # End: > = > > This looks like a bug. Can the auto-filling be disabled in property > drawers? > > I can recreate this issue on both: > - Org stable (9.1.6 that's on emacs-26 branch) :: Org version: Org mode > version 9.1.6 (release_9.1.6-50-g96b33f @ > /home/kmodi/usr_local/apps/6/emacs/emacs-26/share/emacs/26.0.91/lisp/org/) > - Org master ::Org mode version 9.1.6 (release_9.1.6-395-g8ecc4c @ > /home/kmodi/usr_local/apps/6/emacs/emacs-26/share/emacs/site-lisp/org/) > > Thanks. > -- > > Kaushal Modi > -- Kaushal Modi
[O] bug#30321: 25.3; Melpa ox- packages listed as incompatible
Hello, Glenn Morris writes: > Version: 26.1 > > Glenn Morris wrote: > >> I would guess this is because Org is not recognized as a built-in >> package (see https://debbugs.gnu.org/30310), > > This is now fixed for the next release of Emacs. Thank you. >> and no longer available from any of the standard elpas. > > If it's no longer to be on elpa.gnu.org, I guess you will have to add > https://orgmode.org/elpa to your packages-archives. Note that there is no intent to remove Org from GNU ELPA. Alas, at the moment, I have no clue (apart the fact we changed servers and moved to https) about why Org disappeared. Regards, -- Nicolas Goaziou
Re: [O] non-space, paste, (???) character for inline results
Hello, Greg Minshall writes: > one concern: if i essentially "revert" the changes in > 7efa0f2879226695ad9b309c9263a4d1b5d79e89, call_ and src_ all work, but i > get the ZERO WIDTH SPACE (ZSWP, \u200b) propagated into the resulting > output file (.html, .tex). it doesn't seem to do any "harm", but, i find > it disquieting (being an ASCII-type by birth, if not by current > usage). I don't want to revert 7efa0f2879226695ad9b309c9263a4d1b5d79e89 since it gives more options than before. You can, however, remove zero width spaces from output with an appropriate filter, e.g., `org-export-filter-final-output-functions'. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Trivial bug in ox-latex
Hello, Akater writes: > I can't answer this as I do not deal with org-export-with-toc > directly. I was setting tocdepth via > org-export-filter-options-functions, specialized explicitly to latex > backend: I didn't thought about filters, indeed. Fair enough, then. I changed `wholenump' to `integerp'. Thank you. Regards, -- Nicolas Goaziou0x80A93738
