-export-copy-buffer ( to-buffer drop-visibility
drop-narrowing drop-contents
base-commit: 3e4c89e55649f95cffbf70fcf64dcbc69760f96f
--
2.45.2
Emacs : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0)
Package: Org mode version 9.7.3 (9.7.3-2f1844 @
/home/user/.emacs.d/elpa/org-9.7.3/)
--
Suhail
Suhail Singh writes:
> Ihor Radchenko writes:
>
>> Accidentally deleted newline here* Heading 2
>
> Are there situations which result in such accidental newline deletions
> that are likely to not be immediately caught if not prompted by the
> checker? Or was the checker added preemptively?
I
Ihor Radchenko writes:
> Accidentally deleted newline here* Heading 2
Are there situations which result in such accidental newline deletions
that are likely to not be immediately caught if not prompted by the
checker? Or was the checker added preemptively?
Perhaps the checker should simply be
Suhail Singh writes:
> On a related note, what specific situation(s) was this checker intended
> to help the user in? I.e., what are the situations that could result in
> misplaced headings?
For example,
* Heading 1
* Heading 2* Heading 3
* Heading 4
or
* Heading
Some te
begin_src org :tangle /tmp/misplaced-heading-mre-3.org
| Blah | Hello** world |
| | |
#+call: blah :var foo="hello** world"
#+end_src
On a related note, what specific situation(s) was this checker intended
to help the user in? I.e., what are the situations t
Ihor Radchenko writes:
> Oops.
> I amended the fix now.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6c862699a
It's better, but not quite there. For instance, tangle the block below
into an org file and observe the reported warning.
#+begin_src org :tangle
Suhail Singh writes:
>> Fixed, on bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b8497aa7f
>
> This doesn't seem fixed as of 9.7.3 (the MRE above still shows spurious
> warning). It seems that org-at-block-p returns nil when point is within
> the block.
Oops.
I
Ihor Radchenko writes:
> "Suhail Singh" writes:
>
>> When there is, say, an "example" result block that is indented (i.e.,
>> the entire block including the delimiters is indented) and it contains
>> some asterisks in the middle, org-lint considers it to be a possible
>> case of
//git.sr.ht/~bzg/worg/commit/7f498b97
>> Further, the distant goal is to implement integration of org-lint into
>> flycheck/flymake. And we do need user-level config for which checkers
>> should be enabled for "full" org-lint check and for "quick" check on
>>
ome much more
complicated as a result of it.
> Further, the distant goal is to implement integration of org-lint into
> flycheck/flymake. And we do need user-level config for which checkers
> should be enabled for "full" org-lint check and for "quick" check on
>
ther, the distant goal is to implement integration of org-lint into
flycheck/flymake. And we do need user-level config for which checkers
should be enabled for "full" org-lint check and for "quick" check on the
fly then.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Lear
Ihor Radchenko writes:
> This would work, but it modifies the checker list destructively.
Yes, as does org-lint-add-checker. In the same vein,
org-lint-remove-checker is intended to be able to undo the "effect" of
one or more org-lint-add-checker invocations.
> What about introducing some
Suhail Singh writes:
> Ihor Radchenko writes:
>
>> There is currently no such way. Although, it would be nice to have such
>> a feature. Patches welcome!
>
> See attached.
Thanks!
> +;;;###autoload
> +(defun org-lint-remove-checker (name names)
> + "Remove checker(s) from linter.
> +NAME is
Ihor Radchenko writes:
> There is currently no such way. Although, it would be nice to have such
> a feature. Patches welcome!
See attached.
>From 7d7a240d82202fcb3323453648dd2d8b78d22a6f Mon Sep 17 00:00:00 2001
From: Suhail
Date: Wed, 5 Jun 2024 11:55:10 -0400
Subject: [PATCH] org-lint: Add
uages in general wouldn't it be
> better to consult something like the output of #'org-src-get-lang-mode
> and see if that mode is either defined or can be loaded (depending on
> whether or not we require the user to ensure whether the feature
> representing the mode is already loaded or
Ihor Radchenko writes:
> Org mode has no idea which languages are intended to be executed, but
> happen to not have their ob-lang.el backend loaded; and which
> languages do not need execution. So, Org mode warns just in case.
If the primary function of this check is to ensure that
"Suhail Singh" writes:
> When there is, say, an "example" result block that is indented (i.e.,
> the entire block including the delimiters is indented) and it contains
> some asterisks in the middle, org-lint considers it to be a possible
> case of misplaced-heading. Case in point:
>
>
"Suhail Singh" writes:
> Any code block in a language that isn't intended to be executed results in a
> warning from 'suspicious-language-in-src-block checker. For instance:
>
> #+begin_src conf
> [Unit]
> Description=Blah
> #+end_src
>
> In the above example, conf-mode exists and is used
to provide
syntax highlighting and yet, org-lint reports a warning.
Emacs : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @
/home/user/.emacs.d/elpa/org-9.7.2/)
--
Suhail
ro version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @
/home/user/.emacs.d/elpa/org-9.7.2/)
--
Suhail
> > \begin{equation}
> >x = 1
> > \end{equation}
> >
> > cref:eq:x
> > ---
> >
> > exports with a mix of org labels and user labels:
> >
> > ---
> > \begin{equation}
> > \label{orgf29908c}
> > x = 1
> > \end{equa
Stefano Ghirlanda writes:
> There may be an issue with using #+name: labels when exporting to
> non-latex backends. For example:
> ...
> #+name: eq:x
> \begin{equation}
>x = 1
> \end{equation}
>
> cref:eq:x
> ---
>
> exports with a mix of org labels and us
---
exports with a mix of org labels and user labels:
---
\begin{equation}
\label{orgf29908c}
x = 1
\end{equation}
equation \ref{eq:x}
---
This does not affect latex export because one can set
org-latex-prefer-user-labels, but most other backends do not seem to
have this setting. I think
Ruiyang Wu writes:
> I recently started to get the following warning from emacs when loading org
> mode:
> Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by
> aliasing to ‘org-cycle-hide-block-startup’
>
> I have this in my init file:
> (setq org-hide-block-startup t)
>
>
Hi there,
Thanks for maintaining this great piece of software.
I recently started to get the following warning from emacs when loading org
mode:
Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by
aliasing to ‘org-cycle-hide-block-startup’
I have this in my init file:
s safe if file:///ssh:host:org/test.org is
> added to `org-safe-remote-resources'. I was considering a case when
> there is no matching entry in `org-safe-remote-resources'. The user
> opens (C-x C-f) /ssh:host:org/test.org and likely it is enough to
> consider /ssh:host:org/inclu
, actually it resides on the same host as
the current document. Perhaps user consent is redundant.
`org--safe-remote-resource-p' checks the containing Org file as well, in
addition to #+included URL.
If my reading of the code is correct then it considers
/ssh:host:org/include.org as safe
s something similar.
>>
>> May you please elaborate?
>
> Consider a file opened as /ssh:host:org/test.org that has
>
> #+setupfile: /ssh:host:org/include.org
>
> Formally it is a remote file, actually it resides on the same host as
> the current documen
as /ssh:host:org/test.org that has
#+setupfile: /ssh:host:org/include.org
Formally it is a remote file, actually it resides on the same host as
the current document. Perhaps user consent is redundant.
On the other hand, the file likely either contains
#+setupfile: include.org
or the user has
Max Nikulin writes:
> On 07/02/2024 23:12, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> #+setupfile: /dav:localhost#8000:/msg-123456.org
> [...]
>> I think we can enable checking for anything where `file-remote-p'
>> returns non-nil.
> ... In addition, TRAMP locations should be
>
On 07/02/2024 23:12, Ihor Radchenko wrote:
Max Nikulin writes:
#+setupfile: /dav:localhost#8000:/msg-123456.org
[...]
I think we can enable checking for anything where `file-remote-p'
returns non-nil.
It is a bit more tricky. Current file may be remote as well. Browsers
have concept of
uffer:
>
> Tramp: Opening connection for localhost using dav...failed
> ...
> No dialog whether the file should be downloaded is displayed.
>
> My expectation is that Org should not connect to remote servers in
> default configuration unless it is explicitly approved by the user
ocalhost#8000:/msg-123456.org"
No dialog whether the file should be downloaded is displayed.
My expectation is that Org should not connect to remote servers in
default configuration unless it is explicitly approved by the user.
I am unsure what user option may be changed to mitigate the is
gerard.vermeu...@posteo.net writes:
> I think that it is inconsistent that `org-latex-reference-command'
> is a safe file local variable while `org-latex-prefer-user-labels' is
> not (it makes no sense to set the first at file scope, while the second
> is nil at global scope). Furth
Hi,
I think that it is inconsistent that `org-latex-reference-command'
is a safe file local variable while `org-latex-prefer-user-labels' is
not (it makes no sense to set the first at file scope, while the second
is nil at global scope). Furthermore, `org-html-prefer-user-labels'
is also a safe
Suhail Singh writes:
> Running M-x org-lint on an org file with below contents results in a
> spurious "Link escaped with obsolete percent-encoding syntax" warning.
>
> #+begin_src org
> * org-lint url percent-encoding syntax warning
> [[https://www.example.com?param=hello%20world][test url]]
>
][test url]]
#+end_src
I would expect the above org file to not yield any warnings.
Emacs : GNU Emacs 29.1 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.18.0)
Package: Org mode version 9.6.13 ( @ /home/user/.emacs.d/elpa/org-9.6.13/)
--
Suhail
Aaron Madlon-Kay writes:
>> This particular change should fit within TINYCHANGE, I think. So, you do
>> not need a copyright assignment (unless you have already exhausted the
>> 15LOC limit on Emacs patches, which I do not see in git logs).
>
> Ah, yes, that should be OK then. Please see
> On Dec 12, 2023, at 23:15, Ihor Radchenko wrote:
>
> This particular change should fit within TINYCHANGE, I think. So, you do
> not need a copyright assignment (unless you have already exhausted the
> 15LOC limit on Emacs patches, which I do not see in git logs).
Ah, yes, that should be OK
Aaron Madlon-Kay writes:
> OK this was also wrong, because seq only matches a finite sequence. I couldn’t
> find a way to match an arbitrary-length list with pcase, so here’s my final
> attempt:
>
> ...
> This seems to handle all cases correctly, but again of course I leave the
> details to the
t; existing
> function is correct except that the list case should be wrapped in (seq …).
OK this was also wrong, because seq only matches a finite sequence. I couldn’t
find a way to match an arbitrary-length list with pcase, so here’s my final
attempt:
(defun org-entities--user-safe-p (v)
&q
defun org-entities--user-safe-p (v)
"Non-nil if V is a safe value for `org-entities-user'."
(pcase v
(`nil t)
((seq `(,(and (pred stringp)
(pred (string-match-p "\\`[a-zA-Z][a-zA-Z0-9]*\\'")))
,(pred stringp) ,(pred booleanp) ,(pred stringp)
.
Local definitions for `org-entities-user` are not recognized as "safe"
even when they are in the correct format. For instance, including the
following local variables list in an org-mode file will still result in
Emacs prompting you to accept the value
Ihor Radchenko writes:
> I don't think so. We intentionally keep Org mailing list as a single
> place for all the discussions, not just Org development.
> AFAIU, Bastien is firmly into this policy (CCing him in case if I
> misunderstood).
You didn't misunderstood: I firmly believe that we
Ihor Radchenko writes:
> David Masterson writes:
>
>>> Would it help if we change it to
>>>
>>> It is made of numerous .org files from https://git.sr.ht/~bzg/worg.
>>>
>>> ?
>>
>> Perhaps:
>>
>> Follow the link https://git.sr.ht/~bzg/worg for information (including
>> cloning) on the WORG
David Masterson writes:
>> Would it help if we change it to
>>
>> It is made of numerous .org files from https://git.sr.ht/~bzg/worg.
>>
>> ?
>
> Perhaps:
>
> Follow the link https://git.sr.ht/~bzg/worg for information (including
> cloning) on the WORG Git repository at SourceHut
Ihor Radchenko writes:
> David Masterson writes:
>
>> I see no mention of "~bzg/org" in worg-about.
>
> Would it help if we change it to
>
> It is made of numerous .org files from https://git.sr.ht/~bzg/worg.
>
> ?
Perhaps:
Follow the link https://git.sr.ht/~bzg/worg for information
David Masterson writes:
>> FYI, WORG is listed in "Repositories" right at https://sr.ht/~bzg/org/
>
> I see no mention of "~bzg/org" in worg-about.
> ... I think my lack of
> experience for many years is showing -- I didn't think to click on the
> ~bzg/worg link which would've told me about
Ihor Radchenko writes:
> David Masterson writes:
>
>> In worg-about, it looks like the repo is ~bzg/worg on src.ht, but "worg"
>> doesn't come up in the project search on src.ht (but "org" does). Is
>> the repo hidden (I don't have an account on src.ht yet -- perhaps
>> sourcehut should be
David Masterson writes:
> In worg-about, it looks like the repo is ~bzg/worg on src.ht, but "worg"
> doesn't come up in the project search on src.ht (but "org" does). Is
> the repo hidden (I don't have an account on src.ht yet -- perhaps
> sourcehut should be explained a bit in worg-about).
Corwin Brust writes:
> On Tue, Nov 14, 2023 at 8:16 PM David Masterson wrote:
>>
>> Max Nikulin writes:
>>
>> > On 14/11/2023 15:36, Russell Adams wrote:
>> >> On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
>> >>>
>> >>> Was thinking I'd like to see an archive of tagged
Russell Adams writes:
> On Tue, Nov 14, 2023 at 06:14:43PM -0800, David Masterson wrote:
>> Russell Adams writes:
>>
>> > On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
>> >> Just a suggestion (or maybe this is already handled?).
>> >>
>> >> Was thinking I'd like to see an
On Tue, Nov 14, 2023 at 06:14:43PM -0800, David Masterson wrote:
> Russell Adams writes:
>
> > On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
> >> Just a suggestion (or maybe this is already handled?).
> >>
> >> Was thinking I'd like to see an archive of tagged use-cases for Org
On Tue, Nov 14, 2023 at 8:16 PM David Masterson wrote:
>
> Max Nikulin writes:
>
> > On 14/11/2023 15:36, Russell Adams wrote:
> >> On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
> >>>
> >>> Was thinking I'd like to see an archive of tagged use-cases for Org that
> >>> could be
Russell Adams writes:
> On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
>> Just a suggestion (or maybe this is already handled?).
>>
>> Was thinking I'd like to see an archive of tagged use-cases for Org that
>> could be searched via tags or regexp. The use-cases should include
Max Nikulin writes:
> On 14/11/2023 15:36, Russell Adams wrote:
>> On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
>>>
>>> Was thinking I'd like to see an archive of tagged use-cases for Org that
>>> could be searched via tags or regexp.
> [...]
>> Have you looked at Worg?
>
>
On 14/11/2023 15:36, Russell Adams wrote:
On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
Was thinking I'd like to see an archive of tagged use-cases for Org that
could be searched via tags or regexp.
[...]
Have you looked at Worg?
Specifically there is
On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote:
> Just a suggestion (or maybe this is already handled?).
>
> Was thinking I'd like to see an archive of tagged use-cases for Org that
> could be searched via tags or regexp. The use-cases should include a
> description of the
Just a suggestion (or maybe this is already handled?).
Was thinking I'd like to see an archive of tagged use-cases for Org that
could be searched via tags or regexp. The use-cases should include a
description of the problem, a general description of the answer, blocks
of elisp (general code) to
hing else is necessary.
> - Lorenzo
>
>
>
> Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
> cairo version 1.16.0)
> of 2023-08-24
> Package: Org mode version 9.7 (9.
Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0)
of 2023-08-24
Package: Org mode version 9.7 (9.7-??-e90a8a69a @
/home/user/.emacs.d/.local/straight/build-29.1/org/)
current state:
==
(setq
org-link-elisp-confirm-function
"M. Pger" writes:
> I understand better, thanks. Would be a good opportunity for me to (try to)
> contribute; this weekend I will check carefully the link you've sent. I'll
> keep you posted, your assistance would be more than welcome :)
It has been a month since the last message in this
Hi,
I understand better, thanks. Would be a good opportunity for me to (try to)
contribute; this weekend I will check carefully the link you've sent. I'll keep
you posted, your assistance would be more than welcome :)
Best,
MP
Sent with Proton Mail secure email.
--- Original Message
"M. Pger" writes:
> Sorry for the possibly silly question, but by '+1', can I understand that you
> will implement this feature because you think it is worth it?
No, it just means that I think that this feature makes sense to be
implemented. Basically, upvote.
Whether I am going to implement
, but being able to truncate
breadcrumbs from both sides would be even nicer^^
Best,
MP
--- Original Message ---
On Tuesday, July 11th, 2023 at 11:30 AM, Ihor Radchenko
wrote:
> "M. Pger" mp...@protonmail.com writes:
>
> > Feature request: adjust ~org-agenda-format
"M. Pger" writes:
> Feature request: adjust ~org-agenda-format-item~ to let the user choose the
> first level included in breadcrumbs
+1
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at
Dear All,
Including "%b" in the org agenda prefix formats (org-agenda-prefix-format)
allows to display entries' outline paths, which is super useful to get
project-oriented agenda views/todo-list.
Consider a project 'Foobar Report'. In the agenda view/todo-list, it would look
like the
Sébastien Miquel writes:
> Subject: [PATCH] test-org-src.el: Work around `current-column' bug in older
> emacs
>
> * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Work
> around `current-column' not working in the presence of display strings
> in older emacs.
Applied, onto main.
Ihor Radchenko writes:
We should probably reserve the workaround to Emacs 28 and older and
eventually remove it when Org drops Emacs 28 support.
Ok.
I tested using Emacs 28 and 27 and your patch is passing all the tests.
Thanks.
--
Sébastien Miquel
From
Sébastien Miquel writes:
> Ihor Radchenko writes:
>> The cause is the following line in `org-list-struct-apply-struct'
>> [[file:~/Git/org-mode/lisp/org-list.el::indent-line-to (+
>> (org-current-text-indentation) delta)))]]
>>
>> It calls `indent-line-to' that replaces spaces with tabs
Sébastien Miquel writes:
> Ihor Radchenko writes:
>> Sebastien, it looks like one of the tests is failing on the older Emacs:
>> https://builds.sr.ht/~bzg/job/1020247
>
> Does this specify anywhere what version of emacs it is using ?
Yup. In the full log
Ihor Radchenko writes:
The cause is the following line in `org-list-struct-apply-struct'
[[file:~/Git/org-mode/lisp/org-list.el::indent-line-to (+
(org-current-text-indentation) delta)))]]
It calls `indent-line-to' that replaces spaces with tabs according to
current value of
Ihor Radchenko writes:
Sebastien, it looks like one of the tests is failing on the older Emacs:
https://builds.sr.ht/~bzg/job/1020247
Does this specify anywhere what version of emacs it is using ?
Most likely, because `current-column' did not take into account 'display
property until
Ihor Radchenko writes:
> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2e2ed4055
Sebastien, it looks like one of the tests is failing on the older Emacs:
https://builds.sr.ht/~bzg/job/1020247
Most likely, because `current-column' did not take into
Using a similar example, another indentation bug has been revealed:
1. emacs -Q
2. Create an Org file with the following contents:
- 1
- 2
- 3
- 4
- 5
#+begin_src yaml
a:
b:
c:
d:
#+end_src
Everything indented using spaces, including "d:" that uses 8
Sébastien Miquel writes:
> Ihor Radchenko writes:
>> May you now rebase the patch onto the latest main, add a Link: to this
>> discussion to the commit message, and apply the attached extra comments?
>
> Here it is. Thanks for helping with this.
Applied, onto main.
Ihor Radchenko writes:
May you now rebase the patch onto the latest main, add a Link: to this
discussion to the commit message, and apply the attached extra comments?
Here it is. Thanks for helping with this.
--
Sébastien MiquelFrom 7906d7b7fa2d376e95156ab7177494f2cececaff Mon Sep 17
Sébastien Miquel writes:
> From 9d31a71bc0ab7cfd466ecad60037d00c62bdd9f6 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
> Date: Tue, 27 Jun 2023 09:23:01 +0200
> Subject: [PATCH] org-src.el: Use native value of `indent-tabs-mode' for
> indentation
Thanks! This looks good
Ihor Radchenko writes:
For the second scenario, no special treatment of current line is needed.
For the first scenario, why do we need to do it all the way in
`org-src--contents-for-write-back'? Why not directly in
`org-indent-line'?
Ah, yes, that is much better.
--
Sébastien MiquelFrom
.
> 5. =org-src--contents-for-write-back= sees the current line is empty,
> but it should indent it (with org indentation) nonetheless.
Ok. I understand better now (I think).
We are talking about
\t#+begin_src bash
\tcd foo
\t#+end_src
and user pressing
Then, the expected result is
\
Ihor Radchenko writes:
What happens is: in the org buffer, the line is not empty, because it
has the org indentation (which was possibly just added by
org-indent-line), but in the edit buffer, the line is empty, because
the common org indentation was removed. In that case, we want to add
back
Sébastien Miquel writes:
> On second thought, I don't think moving the LaTeX fragment logic away
> from `org-src--contents-for-write-back` makes sense. This part of the
> function does the opposite of `org-do-remove-indentation`, and the
> latter has a boolean argument `skip-fl`, so it makes
.
I've taken this part off the patch for now.
If source code in the edit buffer contains non-empty blank lines, it is
not Org's responsibility to clear them. In fact, it will go against
possible user settings!
So, I agree that we should not indent empty lines. However, I do not
agree that we should
e code in the edit buffer contains non-empty blank lines, it is
not Org's responsibility to clear them. In fact, it will go against
possible user settings!
So, I agree that we should not indent empty lines. However, I do not
agree that we should not indent non-empty blank lines.
---
The code in your
Ihor Radchenko writes:
But why do we need to avoid indenting empty lines?
In the following link, Greg Minshal argues for preserving empty lines:
https://list.orgmode.org/725763.1632663...@apollo2.minshall.org/T/
(CCing the mailing list)
--
Sébastien Miquel
Sébastien Miquel writes:
> + ;; Trim contents: `org-src--contents-for-write-back' may have
> + ;; added indentation at the beginning, which we remove.
May you also mention that we remove the indentation to avoid adding
spaces to latex fragments in the middle of a paragraph?
>>>
Hi Ihor,
Thank you for the feedback.
Ihor Radchenko writes:
+ ;; Apply WRITE-BACK function on edit buffer contents.
+ (goto-char (point-min))
+ (when (functionp write-back) (save-excursion (funcall write-back)))
(set-marker marker nil
`save-excursion' is no longer
dmg writes:
> I use org-yt (https://github.com/TobiasZawada/org-yt) to create
> thumbnails of a youtube video in the orgfile (eg: yt:)
>
> When there is no Internet, the function responsible for retrieving the
> thumbnail fails with an error. Unfortunately,
> org-display-user-
Sébastien Miquel writes:
> Here are two patches, the first that removes the special case logic
> for LaTeX fragments, and the second that implements what you suggest,
> and applies on top of the first one. Does that look ok to you ?
Thanks!
> + ;; Apply WRITE-BACK function on edit buffer
Ihor Radchenko writes:
This is not a problem. We can just apply appropriate 'display property
in `org-src-font-lock-fontify-block', manually replacing the tab with
appropriate number of spaces (as in the origin buffer).
Ok, that works, thanks.
Here are two patches, the first that removes the
Sébastien Miquel writes:
> Ihor Radchenko writes:
>> May you please provide an example for such breakage?
>> From my point of view, alignment is far lesser concern compared to
>> indentation breaking code execution/tangling/other functional parts of Org.
>
> Let's say tab-width is 8 and
Ihor Radchenko writes:
May you please provide an example for such breakage?
From my point of view, alignment is far lesser concern compared to
indentation breaking code execution/tangling/other functional parts of Org.
Let's say tab-width is 8 and elisp-mode uses tabs for indentation. In
Sébastien Miquel writes:
> On second thought, I don't think that's a good idea. I did not
> understand how tab characters worked: they do not have a fixed width,
> but align to the next tab column. This means that if we add a couple
> of spaces in front of a tab indented piece of code, we can
Sébastien Miquel writes:
Should we use native buffer's value of =indent-tabs-mode= to set
=use-tabs?= ? I think this trivial change should work.
It doesn't seem quite that easy. If we want to add 4 columns to a tab
indented line (and tab width is 8), we can either call =indent-to= to
indent
Hi Ihor,
Ihor Radchenko writes:
...But I guess
what you propose amounts to
...
You are right.
On second thought, I don't think that's a good idea. I did not
understand how tab characters worked: they do not have a fixed width,
but align to the next tab column. This means that if we add a
Ihor Radchenko writes:
> Side note: It looks like `org-edit-special' docstring does not mention
> all the cases it considers. In particular, latex fragments are not
> mentioned.
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f8b0b2bab
--
Ihor Radchenko //
Ihor Radchenko writes:
...But I guess
what you propose amounts to
...
You are right.
I'll try to write a patch, this week-end.
I was not aware of how we treated inline src blocks, but I don't think
so. LaTeX fragments, in particular $$…$$ fragments, can have
significant (for the user
t I don't think
>>> so. LaTeX fragments, in particular $$…$$ fragments, can have
>>> significant (for the user) newlines.
>>
>> May you provide an example?
>> AFAIK, LaTeX usually treats newlines as whitespace, same with " ".
>
> When I say significant, I d
what we do for inline src blocks. See `org-babel--normalize-body'.
I was not aware of how we treated inline src blocks, but I don't think
so. LaTeX fragments, in particular $$…$$ fragments, can have
significant (for the user) newlines.
May you provide an example?
AFAIK, LaTeX usually treat
for inline src blocks. See `org-babel--normalize-body'.
>
> I was not aware of how we treated inline src blocks, but I don't think
> so. LaTeX fragments, in particular $$…$$ fragments, can have
> significant (for the user) newlines.
May you provide an example?
AFAIK, LaTeX usually t
1 - 100 of 689 matches
Mail list logo
