rted every sentence in a
> paragraph would then have a space inbetween the strikethroughs.
Could you show an example of what you are trying to achieve?
Regards,
--
Nicolas Goaziou
I didn't find any way to fill correctly Org documents
using `fill-paragraph' mechanism. So I wrote the current implementation
of `org-fill-paragraph', which is a wrapper around `org-fill-element'.
Regards,
--
Nicolas Goaziou
fc-b2f1-47d6-9876-ea30c24ecbeb
> :END:
> blah
> ** A2
> :PROPERTIES:
> :ID: 60dbdfd7-04a6-4ef0-86ce-a267c16fb1e9
> :END:
> blah
> ** A3
> :PROPERTIES:
> :ID: 105dfe8b-8507-400c-862f-a25882448051
> :END:
>blah
> * B
FWIW, I cannot reproduce the issue.
Regards,
--
Nicolas Goaziou
These functions try to stop at interesting places, and skip mundane ones
(e.g., tables are treated as a single block) so navigation is still
fast.
I also added support for repeat argument.
WDYT? Also, what should be done with M-{ and M-}?
Regards,
--
Nicolas Goaziou
>From 4ba83f948f9d8ab26
in_src cpp
> std::size_t parameter_size() const; // (ref:parameter_size)
> #+end_src
Fixed. Thank you!
Regards,
--
Nicolas Goaziou
's no error and the
> orgstruct-mode seems to load just fine...
OrgStruct mode is no longer provided in Org.
Regards,
--
Nicolas Goaziou
xed the bug in `org-element-mark'. Thank you.
Regards,
--
Nicolas Goaziou
Hello,
Kevin Liu writes:
> Relatedly, would you be willing to take a look at the bug at hand with
> (org-next-visible-headline)?
I just fixed it, IIUC. Thank you.
Regards,
--
Nicolas Goaziou
"
> (org-overview)
> (org-cycle)
> (org-cycle)
> (org-next-visible-heading 1)
> (and (bolp) (org-at-heading-p
You cannot call `org-cycle' consecutively without care, because it
checks `last-command' and `this-command'. You need to fake their values
before calling `org-cycle' again.
Regards,
--
Nicolas Goaziou
is a good reason for this. If you insert text at (point-max), you
break the following headline.
OTOH `org-mark-element' should pay attention to buffer boundaries.
Regards,
--
Nicolas Goaziou
(org)Limit code
block evaluation")? Note the part related to noweb expansion. Does that
explain what you observe?
Regards,
--
Nicolas Goaziou
d discovered that the bug was introduced with
> commit 8b05c06d427e850d45684f69c5165cd7684e1071 on May 9.
Isn't it related to 88f5ed91c5cf9cb6962c1b441eac7dbab9a4734e instead?
Regards,
--
Nicolas Goaziou
ue here. Org checks if it should evaluate it, and cannot.
> Can anyone offer suggestions why it reports scanning 22 files, and how
> to speed it up since no code should be evaluated?
See above. Instead of wild guesses, you could use an appropriate tool.
Regards,
--
Nicolas Goaziou
ooking at that copy. If you do think this was the genuine
buffer, please provide an ECM.
Also, removing some source code headers is a natural part of the process.
Regards,
--
Nicolas Goaziou
(org-latex-export-as-latex nil nil nil t nil)
> )
> #+end_src
Isn't it what C-b is for in the export interface?
Regards,
--
Nicolas Goaziou
ntents-area-modified' to recognise
> the element type.
I fixed the commit message, made sure no line was getting past char 80,
and applied your patch.
Thank you.
Regards,
--
Nicolas Goaziou
Timothy writes:
> I had a look at that, to me this was cleaner than using multiple let
> bindings, like so
>
> (let ((context ...))
> (unless ... user error)
> (let* ((contents ...)
> (delim-length ...))
>...
>
> vs.
>
> (let* ((context ...)
>(_ (unless ... user error))
>drawers/blocks there again.
This is over-engineering. Again, please focus on local changes, as
discussed before.
> Recipe to have different (org-element-at-point) and
> (org-element-parse-buffer 'element)
> -
>
> :PROPERTIES:
> :CREATED: [2020-05-23 Sat 02:32]
> :END:
>
>
>
> -
I didn't look at this situation in particular, but there are cases where
different :post-blank values are inevitable, for example at the end of
a section.
Regards,
--
Nicolas Goaziou
e (search-forward "\n" nil t) (replace-match " ")))
> + )
Don't leave parenthesis alone.
Also, make sure your indentation is right, e.g., using M-q on the
definition.
You also need to add a proper commit message and use `git format-patch',
and an entry in ORG-NEWS (probably in Miscellaneous part).
Bonus points if you can add some tests in
"testing/lisp/test-org-src.el".
Could you remind me if you signed the FSF papers already?
Regards,
--
Nicolas Goaziou
Timothy writes:
> I have only a basic working understanding, but my impression was that
> in functioned as a 'best of both worlds' type thing.
I don't understand what would be the best of HTML email in that case.
You're neither inlining any image, nor using any fancy presentation.
Yet, your emai
TEC writes:
> <#multipart type=alternative><#part type=text/plain>
Please don't send HTML.
> Inline LaTeX, and Environments are indeed different. I failed to consider that
> there may be additional complications if switching an inline environment to an
> environment. Quite frankly I’m not too s
ies
> drawer, but I would prefer not to duplicate the label, of course.
You may want to look into `org-beamer--format-block' and see if there's
an appropriate place to insert it, probably extending
`org-beamer--get-label' to handle non-frame cases along the way.
Regards,
--
Nicolas Goaziou
TEC writes:
> This is what I thought. Might you have any suggestions on how
> I incorporate this logic? Something like `org-in-table-p' would be
> ideal :D
This is the following part, in `org-edit-footnote-reference':
--8<---cut here---start->8---
;; If footn
TEC writes:
> Just saying 'no' to new lines seems like a possible solution, but long
> equations can often be deperate for newlines when it comes to
> readability.
Saying no to new lines is only necessary in tables. Outside, we only
need to say no to blank lines.
Note that you cannot preserve
TEC writes:
> Thinking about this a bit more, I think this may not actually be desirable
> behaviour.
>
> Why? I considered the case where I’ve been writing a growing inline equation
> \( \),
> realised it should be displayed as an equation instead with \[ \] and edited
> the
> LaTeX marks such
TEC writes:
> - (end (progn (goto-char (org-element-property :end datum))
> - (search-backward "}" (line-beginning-position) t
> + (end (org-with-point-at (org-element-property :end datum)
> + (skip-chars-backward " \t")
> +
TEC writes:
> Nicolas Goaziou writes:
>> LaTeX fragments should not break paragraphs, or tables. So you need to
>> prevent inserting blank lines, or even newlines characters in the case
>> of tables.
>
> I don’t think we need to worry about newlines,
We
TEC writes:
> I’m trying to work out what it is that should be happening with this. Looking
> at
> `org-edit-footnote-reference’, as you pointed me to, and
> `org-edit-inline-src’:
>From `org-edit-footnote-reference':
--8<---cut here---start->8---
(add-text-
Hello,
Roland Coeurjoly writes:
> Sorry, I was working on the emacs git repo, which seems to be a bit behind
> the org mode one.
> Please find patch attached.
I removed some spurious blank lines and applied your patch.
Thank you.
Regards,
--
Nicolas Goaziou
(end (org-with-point-at (org-element-property :end datum)
(skip-chars-backward " \t")
(point)))
Regards,
--
Nicolas Goaziou
Nicolas Goaziou writes:
> I'm looking into it.
Fixed. Thank you.
t)
> + t))
You also need to put read-only property on fragment markers, and remove
any blank line as the final step. See `org-edit-footnote-reference'.
>(pcase (org-element-type context)
> (`footnote-reference (org-edit-footnote-reference))
> (`inlin
level
>> - Initial level for new item
>> -
> Whereas I would expect it to move the item to this position:
>
>> - "Parent" level
>> - Initial level for new item
>> -
> If it would do this, it would behave analogous to how it is implemented
> for headings, as described at
> https://orgmode.org/manual/Structure-Editing.html#Structure-Editing
> [2]:
I'm looking into it.
Regards,
--
Nicolas Goaziou
Hello,
Roland Coeurjoly writes:
> The assignment process with the FSF is complete.
Great news!
Unfortunately, now I cannot your patch anymore. Would you mind rebasing
it on top of master, and add an entry in ORG-NEWS, probably in
"Miscellaneous" function.
Regards,
--
Nicolas Goaziou
le, i.e., extract the "follow"
function from `org-link-open', handle completion, storage, with
dedicated functions, etc.
Help welcome.
Meanwhile, your best bet is to defadvice `org-activate-links'.
Regards,
--
Nicolas Goaziou
part early on, so you
cannot really delay it.
I /think/ the rest can be delayed, but I admit I'm not too sure either.
I think the expected way to do this is to add a SETUPFILE.
Regards,
--
Nicolas Goaziou
having
> to write it into each file/branch to be included. I assume there is an
> export hook before macro expansion at which I can include the file. Which
> hook? What function to include my file?
See `org-export-before-processing-hook'.
Regards,
--
Nicolas Goaziou
moved seems
> like a non-trivial task that might introduce some regressions…
>
>
> Can anyone confirm that this would (in principle) be the way forward, or
> tell me if I am missing something[3]?
Did you consider using SETUPFILE?
Regards,
--
Nicolas Goaziou
usly be using a bug tracker, I suggest to simply
advertise the current one, and add a Mumi interface somewhere.
As the final words, reviewers are welcome, too…
Regards,
--
Nicolas Goaziou
ly before?
I cannot remember. But the behaviour currently matches the
documentation; and it looks very reasonable to me. Likewise, {{{date}}}
refers to the DATE keyword.
{{{time}}} case is different. This macro requires a mandatory FORMAT
argument that you didn't provide.
Regards,
--
Nicolas Goaziou
(and (org-at-regexp-p org-link-bracket-re) (match-string 2)))
This one is fuzzier, it will get description in fake links too (e.g., in
comments, property drawers…), but will be faster. So there is no single
function that fits every need.
Regards,
--
Nicolas Goaziou
l Dauer
>
>
> Table of Contents
> _
>
> 1. test
>
>
> 1 test
> ==
>
> foo bar
>
>
>
> mist.org
> 1
> <<<
This looks correct. AFACT, {{{author}}} never returned user-full-name.
{{{author}}} is just a shortcut for {{{keyword(AUTHOR)}}}.
See (info "(org) Macro Replacement") for more information.
Regards,
--
Nicolas Goaziou
Hello,
"James R Miller" writes:
> This just might be the functionality that makes me learn elisp. :)
See. You'll soon thank me for removing the feature you liked ;)
Regards,
--
Nicolas Goaziou
Timothy writes:
> In your original email you wrote
> The new function can then be installed in `org-edit-special' from
> "org.el"
>
> I can't quite see how I would insert this. Since it sounds relatively
> simple, if you would be willing to cook up the necessary modification
> for me tha
The expected behavior is to expand to the value of user-full-name.
You lost me. Would you mind writing an ECM demonstrating the currently
observed defect in {{{author}}} macro from master branch?
Regards,
--
Nicolas Goaziou
Timothy writes:
> I see. Might you be willing to do & show me the modifications needed to
> use the `latex-fragment case?
I don't understand your question.
Timothy writes:
>> It sounds like you took the opposite route. I suggested to first write a
>> function, `org-edit-latex-fragment'.
> I wanted to see how it would fit in first ¯\_(ツ)_/¯
Sure. That's a good way to learn stuff. In this case, it's not the
easiest one, though.
>> Once done, you ca
Timothy writes:
As a side note, I think sending plain text messages, instead of HTML, is
better, at least on a (this?) mailing list.
> Indeed. Though my 2c on this sort of thing that the most important
> factor is consistency. IMO if org-html-checkbox-types exists, then an
> equivalent should al
d, that would be something to handle specifically. I.e.,
destructive modifications (i.e., those that unfold) could clear such
properties.
It is more work. I don't know if it is worth the trouble if we can get
out quickly of `after-change-functions' for unrelated changes.
> It was mostly an annoyance, because they returned different results on
> the same element. Specifically, they returned different :post-blank and
> :end properties, which does not sound right.
OK. If you have a reproducible recipe, I can look into it and see what
can be done.
Regards,
--
Nicolas Goaziou
Timothy writes:
> With your comments in mind I started by looking at org-edit-special,
> and managed to get as far as org-element--current-element: but at this
> point I'm stumped.
It sounds like you took the opposite route. I suggested to first write
a function, `org-edit-latex-fragment'.
Once
Timothy writes:
> Once again, thanks for taking the time to respond. I can assure you
> that it's much appreciated :)
You're welcome.
> By item filter, I assume you are referring to
> org-export-filter-item-functions. That looks quite promising. I just tried a
> minimal function to testit
> (
)
At first glance, it looks harmless. If the test suite passes, we can
apply it.
Thank you.
Regards,
--
Nicolas Goaziou
e significantly more time late june though :)
Great. For non-trivial (more than 15 locs) contributions to Org mode
(and more generally, to GNU projects), you need to sign FSF papers. You
might want to consider signing them beforehand.
Regards,
--
Nicolas Goaziou
Checkboxes
> - I also want to be able to tweak the checkboxes here.
This is trivial with an item filter.
Regards,
--
Nicolas Goaziou
e all LaTeX syntax. If
you cannot preview it, Org does not understand it. IOW, it would be
a poor experience if you preview something that doesn't exist, e.g.,
upon exporting the document.
OTOH, nothing prevents an external library to allow previewing any LaTeX
code (probably re-using AucTeX facilities).
Regards,
--
Nicolas Goaziou
"James R Miller" writes:
> It just seems like a regression to me instead of a fix. Functionality
> was removed instead of fixed.
I am not sure about how helpful your message is.
I am not opposed to the fancy indentation you want: if you want to fix
it properly, you can give it a go. The code d
uthor line.
>
> Would you please verify the fix. Maybe I did something wrong by checking
> out commit 965cdbfd4b3316cc9044854b0e5eb5cf69927ce6
I cannot reproduce the problem using master branch.
Regards,
--
Nicolas Goaziou
aracters for its syntax.
This would break this rule.
Regards,
--
Nicolas Goaziou
parse-buffer are not always consistent.
`org-element-at-point' is local, `org-element-parse-buffer' is global.
They are not equivalent, but is it an issue?
Regards,
--
Nicolas Goaziou
to
> contact to see how I can help
> if I know almost nothing about standards and technical writing.
Reading it and comparing with documentation might help.
Regards,
--
Nicolas Goaziou
nil is the latter also ignores `epa-file-encrypt-to' if
this happens to be set in the document.
Regards,
--
Nicolas Goaziou
It may be tricky though: at first glance,
the previous implementation worked, but it actually didn't.
Regards,
--
Nicolas Goaziou
Hello,
Mak Kolybabi writes:
> I noticed a copy-and-paste error in the doc string for ox-md-link,
> corrected in the attached patch.
Applied. Thank you.
Regards,
--
Nicolas Goaziou
l` in indirect buffers.
I pushed a fix in master. Could you try it?
Thank you.
Regards,
--
Nicolas Goaziou
re elaborate and
> correct format.
OK, documentation could be clearer here. Patches are welcome, of course!
Thank you.
Regards,
--
Nicolas Goaziou
he browser to work.
I have fixed it in master. Please let me know how it goes.
Thank you.
Regards,
--
Nicolas Goaziou
solve this.
It may be specific to the package providing
`pythonic-python-readable-file-name' instead. I suggest to look there.
Regards,
--
Nicolas Goaziou
the expected conversion. AUTHOR, like TITLE, expects Org
syntax, not LaTeX.
You could write, e.g.,
:EXPORT_AUTHOR: Gabriel S. X. Smith@@latex:\\@@ CMST220@@latex:\\@@ Professor
Voso
Regards,
--
Nicolas Goaziou
gt;
> I may be only a user but if I had I would have voted no.
You can voice your opinion in the thread, which is not closed. I hope
the Org community can find a consensus about this change.
Regards,
--
Nicolas Goaziou
user to decide whether to have this behavior or not.
I think you are looking for `org-blank-before-new-entry'.
Regards,
--
Nicolas Goaziou
silipwn writes:
> The current commit, still results in a error. I had a set the
> org-crypt-key to nil.
This is not a valid value: `org-crypt-key' must be a string.
> It still prompts to use a key.
I think setting `org-crypt-key' to nil means: use all keys in your key
ring. Some of them are n
a list of strings.
I am a bit surprised you even reached `epa-file-encrypt-to'. I assume
`org-crypt-key' was nil.
Anyway, I pushed a fix in master. Could you try it?
Thank you.
Regards,
--
Nicolas Goaziou
Hello,
Kévin Le Gouguec writes:
> Shouldn't the call to org-return be wrapped in (call-interactively …)
> though?
Indeed. Done. Thank you.
Regards,
--
Nicolas Goaziou
Hello,
Gregor Zattler writes:
> with `org-return-follows-link` set to `t` in a read-only
> buffer I now get a `Buffer is read-only: # notmuch-startpage.org>` error when pressing ENTER/RETURN
> with point on an org-mode link.
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
ocations" is not magical. It looks into
a predefined set of files. If the renaming moves the file out of this
set, there is no way it can associate again the ID to that file.
IOW, I wouldn't trust an ID more than a file name.
Regards,
--
Nicolas Goaziou
g, as
it sounds interesting.
Regards,
--
Nicolas Goaziou
think `org-remove-indentation' does about the same. It does not
systematically use first line as reference, though.
Regards,
--
Nicolas Goaziou
to do so.
Instead of creating a new variable, what about overloading
`org-adapt-indentation'? If it is a whole number, use it as indentation.
`nil' becomes an alias for 0.
WDYT?
Regards,
--
Nicolas Goaziou
Hello,
stardiviner writes:
> I attached the new patch.
Applied. Thank you.
Regards,
--
Nicolas Goaziou
d `org-startup-folded' default value to `showeverything'
yesterday.
You may want to use:
(setq org-startup-folded t)
to get the old behaviour back.
Regards,
--
Nicolas Goaziou
))
> +t))
You can remove the t
> + (should
> + (string-prefix-p
> +"#+begin_src emacs-lisp :session"
> +(org-test-with-temp-text "#+begin_src emacs-lisp :sess"
> + (pcomplete)
> + (buffer-string))
> +t)))
Ditto.
Regards,
--
Nicolas Goaziou
Matthew Lundin writes:
> Nicolas Goaziou writes:
>>
>> AFAIK, ID is associated to a file name, and possibly a location in it.
>> In this case, the ID is strictly equivalent to the file name, so why
>> bother?
>
> I'm not sure I understand the question. A
:05) 808b...]
Regards,
--
Nicolas Goaziou
> org-id-link-to-org-use-id was set to t or
> 'create-if-interactive-and-no-custom-id.
I don't understand what is the meaning of an ID property for a whole
document.
AFAIK, ID is associated to a file name, and possibly a location in it.
In this case, the ID is strictly equivalent to the file name, so why
bother?
Regards,
--
Nicolas Goaziou
Hello,
Stacey Marshall writes:
> Will do. sorry didn't realize I was over the Tiny change limit. I can
> sign FSF papers if still needed.
It is still needed :)
Please let me know once the process is complete, or if you have question
regarding the process.
Thank you!
Regards,
Hello,
Kyle Meyer writes:
> Kyle Meyer writes:
>
>> Okay, here's a patch for that to go along with the documentation patch.
>
> Pushed (7684b59c7, 75902a473).
Thank you!
Regards,
--
Nicolas Goaziou
Completing myself,
Nicolas Goaziou writes:
> However, I realize, a bit late, that you haven't signed FSF papers, and
> both patches are above the TINYCHANGE limit. Would you want to sign them
> so we can also apply the tests, too?
Also, would you mind adding a few words in
Would you want to sign them
so we can also apply the tests, too?
Regards,
--
Nicolas Goaziou
-babel-common-header-args-w-values
> +(when (boundp lang-headers) (eval lang-headers t)
(when ...) -> (and (bounp lang-headers)) (symbol-value lang-headers)
> +(while (pcomplete-here
> + (mapcar
> + (lambda (arg) (concat ":" (symbol-name (car arg
(concat ...) -> (format ":%s" (car arg))
> + headers)
It looks like you dropped the switches "-n", "-r", "-l".
Also, could you add a few tests in "test-org-pcomplete.el"?
Regards,
--
Nicolas Goaziou
Hello,
Tim Cross writes:
>
> +1 from me.
Thank to all of you for the feedback. I changed the default value in master.
Regards,
--
Nicolas Goaziou
Completing myself,
Nicolas Goaziou writes:
> Each syntactical element has a "sensitive part", a particular area that
> can change the nature of the element when it is altered. Luckily drawers
> (and blocks) are sturdy. For a drawer, there are three things to check:
>
>
de. Does anyone has good solution?
I think we can simply remove the angle brackets from the hash.
#+RESULTS[2020-05-12 13:24:05 808b4ccafd1eda0937f8a1dc6d9b569e297d38c6]:
This should solve the problem. WDYT?
Regards,
--
Nicolas Goaziou
ond question? I'm looking for something like a
> minlevel argument.
I didn't answer it, so I probably do not have a clue :)
Regards,
--
Nicolas Goaziou
a duplicate active time stamp in
a table.
IIRC, date computations in the spreadsheet return inactive timestamps.
So, if we don't want to conform to the documentation, we could insert an
inactive time-stamp instead, to be on the safe side.
WDYT?
Regards,
--
Nicolas Goaziou
Ihor Radchenko writes:
> Currently, `org-flag-region' only removes one SPEC type of overlays:
>
> (remove-overlays from to 'invisible spec)
>
> If we change it to
>
> (remove-overlays from to 'invisible spec)
> (when flag
> (remove-overlays from to 'invisible 'org-hide-drawer)
> ...
> )
>
> then
Ihor Radchenko writes:
> This should be better:
> https://gist.github.com/yantar92/e37c2830d3bb6db8678b14424286c930
Thank you.
> This might get tricky in the following case:
>
> :PROPERTIES:
> :CREATED: [2020-04-13 Mon 22:31]
>
> :SHOWFROMDATE: 2020-05-11
> :ID: e05e3b33-71ba-4bbc-abba-8
Ihor Radchenko writes:
> If you want, I can test the file without :LOGBOOK: lines tomorrow.
Don't worry, it doesn't matter now.
> No, there are only 9 'outline overlays in the folded buffer if we do not
> create overlays for drawers. This is because outline-hide-sublevels
> called by org-overvi
ligned otherwise.
2. They preserve indentation upon export.
> I just find them ugly and irritating.
Sorry about that. Note it is our best idea to solve both problems so
far. It you have something better, please tell us!
Regards,
--
Nicolas Goaziou
Ihor Radchenko writes:
> My response to you was blocked by your mail server:
>
>> 550 5.7.1 Reject for policy reason RULE3_2. See
>> http://postmaster.gandi.net
Aka "spam detected". Bah.
> The message landed on the mail list though:
> https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127972
Ihor Radchenko writes:
> I still do not feel much difference, so I used elp to quantify if there
> is any difference I cannot notice by myself. I tested the time to move
> from to bottom of the example file with next-logical-line.
>
> org master (7801e9236):
> 6(#calls) 2.852953989(tota
601 - 700 of 9824 matches
Mail list logo
