Re: [BUG] org-cite-insert error on style part

[Ihor Radchenko]

Kierin Bell  writes:

> Hello,
> When I run 'org-cite-insert' with point before the initial colon of a
> citation element, Emacs signals a 'wrong-number-of-arguments' error.
>
> For example, 'C-c C-x @' with point below X in:
>   X
> [cite:@author2022]
>
> ...Produces:
> Debugger entered--Lisp error: (wrong-number-of-arguments (1 . 1) 0)
>   org-cite-basic--complete-style()

Thanks for reporting!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2b9f9646ef919534dcbf61174f31440f1cd1214c

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Undocumented convention for org-time-stamp-custom-formats to be "<...>"

[Ihor Radchenko]

Uwe Brauer  writes:

>> This is because Org expects the first and the last characters in
>> org-time-stamp-custom-formats to be opening/closing brackets.
>> (undocumented)
>
> So this should have been the correct setting?
>
> ("<%d.%m.%Y " . " %d.%m.%Y>")

No. ("< %d.%m.%Y>" . "< %d.%m.%Y>")

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Formatting in citation locator

[András Simonyi]

Dear All,

On Thu, 20 Oct 2022 at 07:23, Ihor Radchenko  wrote:
> M. ‘quintus’ Gülker  writes:
> > Thanks for the hint, but it does not work still even if I change the
> > line to contain the said zero-width space:
> > The buffer is now fontified as expected, but it does not work when
> > exported to HTML:
> No. It is some bug in org-cite-csl--create-structure.
> I am CCing the oc-csl maintainer.
> András, can you please take a look?

first of all, apologies for reacting that late. I had a look now, and
the reason of the behaviour is not an oc-csl bug, but rather a
citeproc-el limitation: formatting is not supported in locators, so if
present it is passed in an unparsed form through the processor and it
depends on the used citeproc output formatter what happens to it
during finalization. In practice, Org markup seems to go through
unchanged when the citeproc output format is set to Org. As a
consequence, a possible workaround for making the html export work
with formatted locators is to circumvent the citeproc-el html
formatter by exporting the Org document first to Org and then the
result to html. Of course, this solution might lose some advanced html
formatting produced by directly using citeproc such as small caps or
style-specific bibliography indentation.

Best wishes,
András

Re: [PATCH] ox-icalendar.el: customizable vevent summary prefix

[Ihor Radchenko]

Mikhail Skorzhisnkii  writes:

> Hi, Ihor,
>
> Sorry for the delay with fixes, took some time before I got time to finish 
> this. Thanks for your review and looking forward for the next iteration. See 
> new version in the attachment. Comments are inline.

Thanks!
Applied onto main with minor amendments (typos).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d4e7bcb4bd87afbcb08a013111ebc976e3cf3b58
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=55767b792ee7dce41e43e6a48d48813dd9ad7f7c
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c3aa6a6d43fd621bf82c4510c7a63dca7768e6dd

>>>  (defcustom org-outline-path-complete-in-steps t
>>>“Non-nil means complete the outline path in hierarchical steps.
>>> @@ -319,6 +320,11 @@ converted to a headline before refiling.”
>>>  (push (list (and (buffer-file-name (buffer-base-buffer))
>>>(file-truename (buffer-file-name 
>>> (buffer-base-buffer
>>>   f nil nil) tgs))
>>> +   (when (eq org-refile-use-outline-path ’title)
>>> + (push (list (or (org-get-title)
>>> + (and f (file-name-nondirectory f)))
>>> + f nil nil)
>>> +   tgs))
>>
>> We have very too many whens in this function. It will be more succinct
>> to use a single (pcase org-refile-use-outline-path …) instead.
>
> Yes. But then I will be refactoring quite a lot of (working) code that I have 
> not actually touching.
>
> I would prefer doing that in the separate patch. You’ve suggested some 
> changes in my patches which could be applied to some other places in org-mode 
> files I have seen. May be once we finish this discussion I would send a new 
> series of patches with restyling?

That would be great.

>> We generally use `code' for Elisp symbols and `#+TITLE:' for verbatim
>> non-code text. (This has not been consistently followed in etc/NEWS, but
>> at least please change `#+TITLE' to `#+TITLE'). See
>> doc/Documentation_Standards.org
>
> Ah, yes. There are many occasions in the ORG-NEWS where this is not followed. 
> Would you be interested in the patch fixing these irregularities?

Yes.

> And if you do, would you prefer to have a fixed-up commits for these ones or 
> just one big commit? I recently learned about existence of git absorb and 
> couldn’t recommend it enough.

We do not modify git logs on savannah servers.
Doing so would break user mirrors and could break commit links in the
mailing list.

>>>   (if filetitle
>>> - (org-clock-get-file-title file-name)
>>> + (org-get-file-title file-name)
>>> (file-name-nondirectory file-name))
>>>  (if level?”| “ ”“) ;level column, maybe
>>>  (if timestamp ”| “ ”“) ;timestamp column, maybe
>>
>> This may introduce a compiler warning. I suggest running make after
>> applying your patch and fix possible compiler warnings. (I suspect that
>> you may need to add declare-function on top of org-clock.el)
>
> Hm, I have tried it on the latest stable emacs (28.2) and it does not produce 
> me a warning. `make compile' was just clean. Could you please refer me to the 
> library/documentation why would I need to call `declare-function'? This is 
> something from cl library?

If there is no warning, I was wrong.

declare-function is used when we do not explicitly require the library
containing that function but know for sure that the function will be
defined on runtime. See 13.15 Telling the Compiler that a Function is
Defined section of Elisp manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH 2/2] doc/org-manual.org: Document org-clock-{in,out}-switch-to-state

[Ihor Radchenko]

"Samuel W. Flint"  writes:

> IR> Could you please explain in simple words when your new feature can be
> IR> useful?
>
> The variable `org-clock-in-switch-to-state` can be really handy,
> however, it wasn't documented in the manual which made discovery
> somewhat difficult.  The manual patch documents the variable, as well as
> a new variable exposed through customize to describe how states should
> change on clock-in/clock-out.  This means that instead of having to
> write a custom function to do this, it's provided and exposed through
> customize and thus should be more discoverable and hopefully usable.
> Patch 1/2 provides the implementation.
>
> Consider, for example, the following settings:
>
> (setf org-clock-in-switch-to-state 'org-clock-in-next-state-function
>   org-clock-in-next-state '(("TODO" . "WORKING")
> ("WAITING" . "WORKING")))

Such example would look nice in the patch to the manual.
Also, why not simply allow the alist to be another allowed value of
`org-clock-in-switch-to-state'? Using an extra function is cumbersome
and also confusing.

> This can be applied similarly for org-clock-out, though I'm not sure how
> useful that will be.

I really do not see much value in changing todo state on clock out.
Maybe others do.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH 2-v4] New: auto display inline images under subtree when `org-cycle'.

[Ihor Radchenko]

"Christopher M. Miles"  writes:

>> Sure. Can you please send the final version of the patch and the working
>> tests?
>
> I separated code patch and test into two patches. You can apply selectively.

Sorry, I was not very clear.
I meant to remove that patch that fails due to noninteractive and leave
the rest.

>  doc/org-manual.org|   6 +++
>  etc/ORG-NEWS  |   7 
>  lisp/org-cycle.el |  38 +-
>  lisp/org-keys.el  |   2 +-
>  lisp/org.el   |  21 ++
>  .../images/Org mode logo mono-color.png   | Bin 0 -> 7523 bytes

The image should belong to the test patch.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How to delete an instruction when it has expired

[Ihor Radchenko]

Renato Pontefice  writes:

> Hi,
> I’m wondering how can I delete, on my .org file, the line that have:
> - an old Timestamp (i.e. if I set a thing to be done today (<2022-10-24 Mon 
> 17:26>)
> - a TODO item (always with a past date) <2022-10-24 Mon 17:26>
>
> That to have a more clean .org file.
>
> Is it possible?
> How can I obtain it?

Could you please provide more details?

>From my reading, you may be able to utilize org-archive functionality
(see 9.2 Archiving section of Org manual).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ox.el: Refactor variable org-html--id-attr-prefix, ox-html.el: Add support for the ID property to org-html--reference

[Ihor Radchenko]

Feraidoon Mehri  writes:

> I have already signed the copyright assignment. (Though I used my
> other email rudiwillalwayslove...@gmail.com when signing it.)

Bastien, could you kindly check the FSF records?

> I have manually tested the changes with a custom value for
> `org-html--id-attr-prefix', and everything works.
>
> I did not change the behavior of `org-html-prefer-user-labels'; the ID
> property will not be used if `org-html-prefer-user-labels' is nil. IMO
> this behavior should be changed, and it should be always used, just
> like CUSTOM_ID.

Thanks for the patch!
See my comments below.

> * org/ox.el (org-html--id-attr-prefix): Refactor hardcoded "ID-" as a
> new private variable.

org-html-* variable do not belong to the general ox.el library.  It
should only be added to ox-html.el.

> -  (user-label
> -   (org-element-property
> -(pcase type
> -  ((or `headline `inlinetask) :CUSTOM_ID)
> -  ((or `radio-target `target) :value)
> -  (_ :name))
> -datum)))
> + (custom-id-p nil)
> + (user-label
> +  (or
> +   (org-element-property
> +(pcase type
> +  ((or `headline `inlinetask)
> +   (progn
> + (setq custom-id-p t)
> + :CUSTOM_ID))
> +  ((or `radio-target `target) :value)
> +  (_ :name))
> +datum)
> +   (if-let
> +   ((id-property (org-element-property
> +  :ID
> +  datum)))
> +   (progn
> + (setq custom-id-p nil)
> + (concat org-html--id-attr-prefix id-property))

This is a bit awkward to read.
Can you instead let-bind custom-id as a separate variable and leave :ID
to user-label? Then, you will not need to juggle setq custom-id-p and
the code will become more readable.

> diff --git a/lisp/org/ox-odt.el b/lisp/org/ox-odt.el
> index 7f2e8ba47f..d2c14237ac 100644
> --- a/lisp/org/ox-odt.el
> +++ b/lisp/org/ox-odt.el
> @@ -1802,7 +1802,7 @@ holding contextual information."
>  ;; Extra targets.
>  (extra-targets
>   (let ((id (org-element-property :ID headline)))
> -   (if id (org-odt--target "" (concat "ID-" id)) "")))
> +   (if id (org-odt--target "" (concat org-html--id-attr-prefix id)) 
> "")))

It is surprising that org-html-* variable has anything to do with ODT
export. Please define a separate constant in ox-odt.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

GPL violation related to Org by priprietary app (was: Best android app)

[Ihor Radchenko]

Jean Louis  writes:

> Additionally "Org Mode" qualifies as trademark in Sweden, where this
> company is registered. 
>
> I advise to Org Mode authors to defend against plagiarism, as they
> call it Emacs Org Mode -- which is not. I do not mind if anybody will
> complain or not -- I am only pointing out to not ethical behavior of
> that company.
>
> It would be fine to say that they use headings and TODO things
> similarly like Org Mode, but their wordings for proprietary software I
> find very deceptive. 
>
> ,
> | "Emacs Org mode Made Easy
> | 
> | EasyOrg is compatible and comes with many of the functionalities
> | provided by Emacs Org mode, but with more user friendliness. Both
> | Editor and Agenda provided."
> `
>
> These words cheat the reader by telling that it is "compatible"
> something, while it is not editor mode, it is probably whole editor
> and software without Emacs.

Are you saying that there is GPL violation of Org mode licence by this
"EasyOrg" app?

If it is true, could you please provide links to legal basis on from
GPL's and Swedish law's points of view?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [off-topic] E-readers and Org-Mode

[Fraga, Eric]

On Monday, 24 Oct 2022 at 18:34, Juan Manuel Macías wrote:
> The main problem I find is that they both also run
> closed and, presumably, proprietary software. 

They both run Linux but with proprietary user interfaces.

> I wonder if these devices are capable of exporting normal annotations in
> plain text or xml?

The annotations are not text: they are vector data corresponding to the
movement of the stylus.  You can extract that information (I have
software for the reMarkable that does so) but doing character
recognition would be challenging...

-- 
: Eric S Fraga, with org release_9.5.5-1023-g48b237 in Emacs 29.0.50

Re: Request for feedback: ox-linuxmag

[Ihor Radchenko]

Damien Cassou  writes:

> Ihor Radchenko  writes:
>> Why not using org-export-define-derived-backend?
>
> I didn't know this function exist. I changed the code to use it.

See A.4 Adding Export Back-ends section in Org manual ;)

>> Also, linuxmag might be confused with…
>
> What do you think about ox-linuxmag-fr as package name and linuxmag-fr
> as exporter name?

Sounds more accurate.

>>> (defconst ox-linuxmag--resources-dir
>>>   (expand-file-name "resources" (file-name-directory (or load-file-name 
>>> (buffer-file-name
>>>   "Directory containing the style and template XML files.")
>>
>> This will spoil the installation dir.
>
> What do you mean by that? Do you have a different way to do it? The odt
> exporter contains a similar variable and external files (see
> `org-odt-lib-dir`).

You are right. I somehow thought that you are writing to that directory.

>> Your template function has side effects. Side effects are usually
>> implemented inside the export function. like ox-linuxmag--export-to-odt
>
> I guess you are referring to `ox-linuxmag--write-meta-file` and
> `ox-linuxmag--write-styles-file`. I would be happy to move them to the
> export function but they depend on `info` and I don't know how to get
> that from there. Also, I copy/pasted the structure of ox-odt which does
> something similar in `org-odt-template`.
>
> Any recommendation?

I think :filter-final-output in :filters-alist will be more suitable.
It is called at the very end and may set some let-bound value to be used
in the ox-linuxmag-export-to-odt.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Fix match/maxlevel conflict in colview dynblock

[Ihor Radchenko]

Nick Dokos  writes:

> Specifying both `maxlevel' and `match' in a columnview dynamic block
> was broken: the `match' argument is ignored in that case. See the link
> below for a (not so minimal) ECM.
>
> Reported-by: Pablo A Perez-Fernandez
> Link: 
> https://emacs.stackexchange.com/questions/66658/filter-columnview-dblock-on-properties-or-tags

Thanks for the patch, and sorry for the late reply.
Would you also be able to supply a test for testing/lisp/test-org-colview.el?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How to delete an instruction when it has expired

[Ihor Radchenko]

[Adding Org mailing list back to CC]

Renato Pontefice  writes:

> Maybe this is not what I’m looking for:
> I have a simple line:
> ** TODO da xxx con y <2022-10-19 Wed 11:00>
> When the 19th I’ve done this, I change the state from RODO in DONE. I’m 
> wondering if it exist a way to definitely delete this line, because as lines 
> increase, my file get increased and confusing. So Im looking for socomand 
> that let me close and delete the line. A simple line deletion?
> May be…

Pressing C-k on the heading will delete the whole heading if you set
org-special-ctrl-k to non-nil.

Also, the archive functionality I mentioned can move the heading away to
a separate file. See org-archive-location.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] demarcate block splits block even when outside of src-block

[Ihor Radchenko]

dalanicolai  writes:

>  [9.5.4 (release_9.5.4 @ /usr/local/share/emacs/29.0.50/lisp/org/)]
>
> When trying to create a new src-block via `M-x
> org-babel-demarcate-block` immediately after a previous code block (only
> empty lines in between), then the command behaves like when splitting a
> src-block (inserting an #+end_src first, followed by a #+begin_src).
>
> However, as the point is outside of the source block, according to the
> docstring of the command, a new source block should be created.
>
> As a comment, normally when creating a new source block, Emacs prompts
> for the source block type. However, currently, when used as mentioned
> here, the command automatically sets the type (because it tries to
> split). I would say that is convenient behavior, so that effectively
> only the order of the inserted lines should get reversed.

Thanks for reporting!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cd835dcad87bc5b3855832449188dd007fce115c

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Error in html form of org manual [9.5.5 (9.5.5-ge58bd0 @ /home/jds6696/.emacs.d/straight/build/org/)]

[Max Nikulin]

On 25/10/2022 07:54, Justin Silverman wrote:


Try going to this link:
https://orgmode.org/manual/Images-in-LaTeX-export.html 

It just takes you to the Latex Export page. Most of the links on the 
latex export page don't seem to go anywhere.


I expect that the problem was fixed some time ago. Perhaps your browser 
cached old response from the HTTP server.


curl -I https://orgmode.org/manual/Images-in-LaTeX-export.html
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 25 Oct 2022 09:35:25 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 7418
Last-Modified: Sat, 15 Oct 2022 16:21:14 GMT
Connection: keep-alive
ETag: "634addfa-1cfa"
Accept-Ranges: bytes

Earlier it was 301 permanent redirection with the Location header. See 
the previous thread:


Bastien Guerry. Re: Some links in online manual do not work. Wed, 12 Oct 
2022 06:11:47 +0200. https//list.orgmode.org/87a661he9o@gnu.org


and the reason of server configuration changes caused the issue

Rudolf Adamkovič. [BUG] The documentation webserver gives 404s. Sun, 03 
Jul 2022 12:01:24 +0200. https://list.orgmode.org/m2sfni5xcb@me.com

Re: [BUG?] Wrong quote positions in exported CSL bib items when export is done with C-u C-e

[Ihor Radchenko]

András Simonyi  writes:

> Dear All,
>
> I'm experiencing the following mysterious problem with the csl
> citation export processor: exporting using the export dispatcher
> without a prefix argument works fine, but when I repeat the export
> action using C-u before C-e the exported bibliography items containing
> quotes have the quotes shifted to incorrect places, seemingly with a
> fix offset.
>
> Minimal example:
> ...
> The single bibliography item is the correct
>
>   Hobbs, Jerry R. 1985. “Ontological Promiscuity.” In /Proceedings of
>   the 23rd Annual Meeting of the Association for Computational
>   Linguistics/, 61–69. Chicago: Association for Computational
>   Linguistics.
>
> when exported with C-e and as an UTF-8 buffer
>
> but contains an incorrectly places quote:
>
>   Hobbs, Jerry R. 1985. “Ontological Promiscuity. In” /Proceedings of
>   the 23rd Annual Meeting of the Association for Computational
>   Linguistics/, 61–69. Chicago: Association for Computational
>   Linguistics.
>
> when exported (again) with C-u C-e.
>
> Emacs version: 28.1
> Org version:  9.5.4
> (Citeproc version is Melpa 20220702.2132)
>
> is anybody else seeing this behaviour?

Confirmed.
I managed to trace this down to the output value of
org-cite-csl--rendered-bibliographies (using M-x trace-function + M-x 
diff-buffers).

I suspect that it might be something to do with destructive list
modifications in some kind of cache.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ox-odt file: links are not pointing to the real files (was: [BUG] ox-odt fails for org-id links (e.g., from org-roam v2) [9.5.2 (9.5.2-gfbff08 @ /home/moritz/.emacs.d/elpa/27.2/develop/org-9

[Max Nikulin]

On 22/10/2022 12:03, Ihor Radchenko wrote:


Probably, href=file.org is treated as a link to resource packed inside
.odt file.


You are right. file.odt is a virtual folder representing ZIP container, 
so relative links to external files should be prefixed with "../".


https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part2-packages/OpenDocument-v1.3-os-part2-packages.html#__RefHeading__752821_826425813
3.7 Usage of IRIs Within Packages
in Open Document Format for Office Applications (OpenDocument) Version 
1.3. Part 2: Packages


https://bz.apache.org/ooo/show_bug.cgi?id=98211
98211 – Hyperlink to local file in filesystem generate a wrong relative path

Thanks to https://github.com/jgm (pandoc developer)

It seems, EPUB explicitly disallows relative links to external 
resources, however the discussion is long and I may the conclusion wrong.

https://github.com/w3c/epub-specs/issues/1888
What base URLs to use for URL parsing in EPUB?

Re: Dynamic block match fails on checkbox columns

[Ihor Radchenko]

"Daniel J. Sinder"  writes:

> I'm trying to use a dynamic block with :match to filter columnview for a
> checkbox column.  However, the match is failing.   Based on some variations
> that do work (described below the example), it seems the closing square
> bracket may be the problem.
>
> Here's a minimal example:
> * Things
>   :PROPERTIES:
>   :COLUMNS:  %20ITEM %CHKBOX{X/}
>   :ID:   Things
>   :CHKBOX_ALL: "[ ]" "[X]"
>   :END:
> *** One Thing
> :PROPERTIES:
> :CHKBOX:   [X]
> :END:
> *** Another Thing
> :PROPERTIES:
> :CHKBOX:   [ ]
> :END:
>
> * Dynamic Block
>   #+BEGIN: columnview :id Things :match "CHKBOX=\"[X]\""
>   | ITEM | CHKBOX |
>   |--+|
>   #+END:

Thanks for reporting!
It is kind of expected from the manual explanation about tag matchers:

   • If the comparison value is enclosed in double-quotes _and_ angular
 brackets (like ‘DEADLINE<​="<2008-12-24 18:30>"’), both values are
 assumed to be date/time specifications in the standard Org way...

However, the heuristics described in the manual is obvious wrong here.

I improved the match parser a bit to require a number inside brackets in
timestamps, but this whole syntax is overcomplicated and difficult to
understand.

In any case, your bug should be fixed now on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e022a0cea11a0e784ba20ac478a033da7fb1bb7f

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: GPL violation related to Org by priprietary app (was: Best android app)

[Jean Louis]

* Ihor Radchenko  [2022-10-25 10:30]:
> > These words cheat the reader by telling that it is "compatible"
> > something, while it is not editor mode, it is probably whole editor
> > and software without Emacs.
> 
> Are you saying that there is GPL violation of Org mode licence by this
> "EasyOrg" app?

I did not say that. Plagiarism is not always equal to license
violations. 

> If it is true, could you please provide links to legal basis on from
> GPL's and Swedish law's points of view?

In my opinion the term "Org Mode" is collective trademark:

Trademark FAQs | USPTO:
https://www.uspto.gov/learning-and-resources/trademark-faqs#type-browse-faqs_1934
valid only for US jurisdiction.

Trademarks need not be registered, especially when it is clear who was
first using it, there is no doubt that Org Mode is term used to
promote software and software is commercial subject.

Those who started using first "Org Mode", like author or whoever is
assigned to it, are free to tell to the website, to stop using it, or
demand part of their profits in Sweden.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [off-topic] E-readers and Org-Mode

[Eduardo Suarez-Santana]

FTR, I'm a happy Onyx Boox user.

I considered remarkable, but I read somewhere (can't find it) that handwritten
PDF annotations were not coded as vector graphics, so I went for Onyx.

Re: [BUG] demarcate block splits block even when outside of src-block

[dalanicolai]

Great! Thank you...

On Tue, 25 Oct 2022 at 11:41, Ihor Radchenko  wrote:

> dalanicolai  writes:
>
> >  [9.5.4 (release_9.5.4 @ /usr/local/share/emacs/29.0.50/lisp/org/)]
> >
> > When trying to create a new src-block via `M-x
> > org-babel-demarcate-block` immediately after a previous code block (only
> > empty lines in between), then the command behaves like when splitting a
> > src-block (inserting an #+end_src first, followed by a #+begin_src).
> >
> > However, as the point is outside of the source block, according to the
> > docstring of the command, a new source block should be created.
> >
> > As a comment, normally when creating a new source block, Emacs prompts
> > for the source block type. However, currently, when used as mentioned
> > here, the command automatically sets the type (because it tries to
> > split). I would say that is convenient behavior, so that effectively
> > only the order of the inserted lines should get reversed.
>
> Thanks for reporting!
> Fixed on main.
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cd835dcad87bc5b3855832449188dd007fce115c
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Formatting in citation locator

[Ihor Radchenko]

András Simonyi  writes:

>> No. It is some bug in org-cite-csl--create-structure.
>> I am CCing the oc-csl maintainer.
>> András, can you please take a look?
>
> first of all, apologies for reacting that late. I had a look now, and
> the reason of the behaviour is not an oc-csl bug, but rather a
> citeproc-el limitation: formatting is not supported in locators, so if
> present it is passed in an unparsed form through the processor and it
> depends on the used citeproc output formatter what happens to it
> during finalization. In practice, Org markup seems to go through
> unchanged when the citeproc output format is set to Org. As a
> consequence, a possible workaround for making the html export work
> with formatted locators is to circumvent the citeproc-el html
> formatter by exporting the Org document first to Org and then the
> result to html. Of course, this solution might lose some advanced html
> formatting produced by directly using citeproc such as small caps or
> style-specific bibliography indentation.

Maybe file a bug report to citeproc repo?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: GPL violation related to Org by priprietary app (was: Best android app)

[Ihor Radchenko]

Jean Louis  writes:

>> If it is true, could you please provide links to legal basis on from
>> GPL's and Swedish law's points of view?
>
> In my opinion the term "Org Mode" is collective trademark:
>
> Trademark FAQs | USPTO:
> https://www.uspto.gov/learning-and-resources/trademark-faqs#type-browse-faqs_1934
> valid only for US jurisdiction.
>
> Trademarks need not be registered, especially when it is clear who was
> first using it, there is no doubt that Org Mode is term used to
> promote software and software is commercial subject.
>
> Those who started using first "Org Mode", like author or whoever is
> assigned to it, are free to tell to the website, to stop using it, or
> demand part of their profits in Sweden.

If GPL is not violated I see no reason for current Org maintainers to
bother. I'd better focus on improving Org rather than trying to engage
into legal complexities.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Jean Louis]

This wish request is related to Emacs EWW and Org mode.

Please make EWW recognize Org file when served by WWW server. Currently
it does not recognize the MIME type text/x-org and opens the file as
text, it does not invoke the org mode. In my opinion, it should.

Inspect following file by using lynx:

$ lynx -head https://gnu.support/files/tmp/example.org

uHTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 25 Oct 2022 12:04:26 GMT
Content-Type: text/x-org
Content-Length: 364
Last-Modified: Tue, 25 Oct 2022 11:58:22 GMT
Connection: close
ETag: "6357cf5e-16c"
Accept-Ranges: bytes

One can see that Content-Type is text/x-org

My expectation is that EWW opens the Org file served by WWW server in
Org mode. But it doesn't. Can this be done?

This will open opportunity to directly serve Org files by using WWW
servers and to browse such files through Emacs, meaning, bunch of notes,
tasks and similar may be kept online, with or without protection and
directly accessed by Emacs. It becomes new area or WWO or World Wide Org
environment.



In GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.17.6, Xaw3d scroll bars) of 2022-10-10 built on
 protected.rcdrun.com
Repository revision: ed436db1320339862fad5ac754a6ec42de06c766
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Parabola GNU/Linux-libre

Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  mml-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort emacsbug mail-extr org-timer org-colview org-clock
org-attach org-id org-archive org-agenda org-refile ol-eww eww xdg
url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum shr pixel-fill kinsoku url-file svg dom browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs url-vars gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
parse-time gnus-spec gnus-int gnus-range message sendmail mailcap
yank-media puny rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util text-property-search mail-utils range mm-util
mail-prsvr wid-edit ol-docview doc-view filenotify jka-compr image-mode
exif dired dired-loaddefs ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi
reporter org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete pcomplete comint ansi-osc
ansi-color ring org-list org-faces org-entities noutline outline icons
org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic json map
byte-opt gv bytecomp byte-compile cconv bibtex iso8601 time-date subr-x
ol rx org-keys oc org-compat advice org-macs org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs cl-loaddefs cl-lib rmc
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-r

Re: [off-topic] E-readers and Org-Mode

[Juan Manuel Macías]

Fraga, Eric writes:

>> I wonder if these devices are capable of exporting normal annotations in
>> plain text or xml?
>
> The annotations are not text: they are vector data corresponding to the
> movement of the stylus.  You can extract that information (I have
> software for the reMarkable that does so) but doing character
> recognition would be challenging...

I see... I was referring to annotations entered as text. Can't you do
annotations on those devices like you do in a typical PDF reader,
Acrobat or Okular style, using an on-screen keyboard or a physical
keyboard? It's those kinds of annotations I was referring to, the ones
that are stored as metadata in the PDF.

As for the stylus notes, I think I would find them useful especially for
proof reading. But very often what I need is just to put text. In Org I
use Org-noter + pdf-tools a lot.

Re: GPL violation related to Org by priprietary app (was: Best android app)

[Tim Cross]

Ihor Radchenko  writes:

> Jean Louis  writes:
>
>>> If it is true, could you please provide links to legal basis on from
>>> GPL's and Swedish law's points of view?
>>
>> In my opinion the term "Org Mode" is collective trademark:
>>
>> Trademark FAQs | USPTO:
>> https://www.uspto.gov/learning-and-resources/trademark-faqs#type-browse-faqs_1934
>> valid only for US jurisdiction.
>>
>> Trademarks need not be registered, especially when it is clear who was
>> first using it, there is no doubt that Org Mode is term used to
>> promote software and software is commercial subject.
>>
>> Those who started using first "Org Mode", like author or whoever is
>> assigned to it, are free to tell to the website, to stop using it, or
>> demand part of their profits in Sweden.
>
> If GPL is not violated I see no reason for current Org maintainers to
> bother. I'd better focus on improving Org rather than trying to engage
> into legal complexities.

Even if it was violated, this is not something the maintainers are
empowered to act on anyway. Org mode is part of Emacs and the FSF owns
the copyright. If there is any GPL violation, the FSF has a whole legal
team which deal with such matters. It certainly isn't something
maintainers or arm chair lawyers are able to address.

Also, based on my limited legal experience and past dealings with
trademarks, copyright and licenses, I don't think there has been either
a GPL license violation or a trade mark violation.  However, if someone
believes differently, they should refer the matter to the FSF legal
office.

Re: GPL violation related to Org by priprietary app (was: Best android app)

[tomas]

On Wed, Oct 26, 2022 at 12:12:46AM +1100, Tim Cross wrote:

[...]

> Even if it was violated, this is not something the maintainers are
> empowered to act on anyway [...]

This depends perhaps on what one understands by "act on". If that
means "go to court" you are, of course, right. If that means just
"make aware FSF legal of a possible violation", then the question
here boils just down to "do we have enough confidence to justify
annoying FSF legal with this?

> Also, based on my limited legal experience and past dealings with
> trademarks, copyright and licenses, I don't think there has been either
> a GPL license violation or a trade mark violation.  However, if someone
> believes differently, they should refer the matter to the FSF legal
> office.

Exactly.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How ro delete DONE attemps

[Nick Dokos]

Renato Pontefice  writes:

> Hi,
> I’m wondering how can I delete, on my .org file, the line that have:
> - an old Timestamp (i.e. if I set a thing to be done today (<2022-10-24 Mon 
> 17:26>)
> - a TODO item (always with a past date) <2022-10-24 Mon 17:26>
>
> That to have a more clean .org file.
>
> Is it possible?
> How can I obtain it?
>

It's just text: you can use ordinary Emacs commands to modify the
file, e.g. C-k will kill a line, or you can use C-d to delete
characters or M-d to delete words.

-- 
Nick

Re: [off-topic] E-readers and Org-Mode

[Fraga, Eric]

On Tuesday, 25 Oct 2022 at 12:55, Juan Manuel Macías wrote:
> I see... I was referring to annotations entered as text. Can't you do
> annotations on those devices like you do in a typical PDF reader,

Not as far as I know (for the reMarkable; I have no experience with the
Elipsa).  The virtual keyboard, on the reMarkable, is not great in any
case.  Very rudimentary; enough for the job (naming files, connecting to
WiFi) but just barely.

> As for the stylus notes, I think I would find them useful especially for
> proof reading. 

Indeed and, for my use cases, for reviewing journal articles and
for giving feedback to students on their reports or theses.

-- 
: Eric S Fraga, with org release_9.5.5-1028-gcd835d in Emacs 29.0.50

Re: [off-topic] E-readers and Org-Mode

[Fraga, Eric]

On Tuesday, 25 Oct 2022 at 12:06, Eduardo Suarez-Santana wrote:
> I considered remarkable, but I read somewhere (can't find it) that
> handwritten PDF annotations were not coded as vector graphics, so I
> went for Onyx.

Conversion scripts (including my own adapted ones) take the rM notation
and create polylines (in creating an SVG version) so it is vector
graphics as far as I can tell.  But the input mechanism does no
smoothing etc. so the actual annotations may consist of many very small
line segments, depending on your handwriting, I guess.

-- 
: Eric S Fraga, with org release_9.5.5-1028-gcd835d in Emacs 29.0.50

Re: [PATCH v3] New: auto display inline images under subtree when `org-cycle'.

[Christopher M. Miles]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>>> Sure. Can you please send the final version of the patch and the working
>>> tests?
>>
>> I separated code patch and test into two patches. You can apply selectively.
>
> Sorry, I was not very clear.
> I meant to remove that patch that fails due to noninteractive and leave
> the rest.
>

Updated, I deleted testing and marked as TODO.

>>  doc/org-manual.org|   6 +++
>>  etc/ORG-NEWS  |   7 
>>  lisp/org-cycle.el |  38 +-
>>  lisp/org-keys.el  |   2 +-
>>  lisp/org.el   |  21 ++
>>  .../images/Org mode logo mono-color.png   | Bin 0 -> 7523 bytes
>
> The image should belong to the test patch.

Updated.

From 4cdf69001832bcc180e7c607c15c44c484954c82 Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Tue, 4 Oct 2022 12:36:32 +0800
Subject: [PATCH 1/2] org.el: Support auto display inline images when cycling

* lisp/org.el (org-toggle-inline-images): Support region.
(org-display-inline-images): Fix refresh argument logic.
(org-remove-inline-images): Support region.

* lisp/org-keys.el (org-toggle-inline-images): Update arguments.

* lisp/org-cycle.el (org-cycle-inline-images-display): Add new option to
control whether auto display inline images when cycling.
(org-cycle-display-inline-images): Add new hook function to auto display
inline images when cycling.
(org-cycle-hook): Add `org-cycle-display-inline-images' into cycling
hook by default.

* doc/org-manual.org (Exporting):
* etc/ORG-NEWS: Document the new option.
---
 doc/org-manual.org |  6 ++
 etc/ORG-NEWS   |  7 +++
 lisp/org-cycle.el  | 38 --
 lisp/org-keys.el   |  2 +-
 lisp/org.el| 21 +
 5 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ad584d7a5..18a050069 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11489,6 +11489,12 @@ command:
   - When set to nil, try to get the width from an =#+ATTR.*= keyword
 and fall back on the original width if none is found.
 
+
+#+vindex: org-cycle-inline-images-display
+Inline images can also be displayed when cycling the folding state.
+When custom option ~org-cycle-inline-images-display~ is set, the
+visible inline images under subtree will be displayed automatically.
+
 ** Captions
 :PROPERTIES:
 :DESCRIPTION: Describe tables, images...
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c18c03725..d87b49bd3 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -307,6 +307,13 @@ to pass the contents of a named code block as a string argument.
 The new property =ORG-IMAGE-ACTUAL-WIDTH= can override the global
 variable ~org-image-actual-width~ value for inline images display width.
 
+*** Outline cycling can now include inline image visibility
+
+New ~org-cycle-hook~ function ~org-cycle-display-inline-images~ for
+auto-displaying inline images in the visible parts of the subtree.
+This behavior is controlled by new custom option
+~org-cycle-inline-images-display~.
+
 *** New ~org-babel-tangle-finished-hook~ hook run at the very end of ~org-babel-tangle~
 
 This provides a proper counterpart to ~org-babel-pre-tangle-hook~, as
diff --git a/lisp/org-cycle.el b/lisp/org-cycle.el
index c1caa3fdc..14388caaf 100644
--- a/lisp/org-cycle.el
+++ b/lisp/org-cycle.el
@@ -208,8 +208,9 @@ the values `folded', `children', or `subtree'."
   :type 'hook)
 
 (defcustom org-cycle-hook '(org-cycle-hide-archived-subtrees
-		   org-cycle-show-empty-lines
-		   org-cycle-optimize-window-after-visibility-change)
+org-cycle-show-empty-lines
+org-cycle-optimize-window-after-visibility-change
+org-cycle-display-inline-images)
   "Hook that is run after `org-cycle' has changed the buffer visibility.
 The function(s) in this hook must accept a single argument which indicates
 the new state that was set by the most recent `org-cycle' command.  The
@@ -229,6 +230,13 @@ normal outline commands like `show-all', but not with the cycling commands."
   :group 'org-cycle
   :type 'boolean)
 
+(defcustom org-cycle-inline-images-display nil
+  "Non-nil means auto display inline images under subtree when cycling."
+  :group 'org-startup
+  :group 'org-cycle
+  :package-version '(Org . "9.6")
+  :type 'boolean)
+
 (defvar org-cycle-tab-first-hook nil
   "Hook for functions to attach themselves to TAB.
 See `org-ctrl-c-ctrl-c-hook' for more information.
@@ -775,6 +783,32 @@ STATE should be one of the symbols listed in the docstring of
 		   "Subtree is archived and stays closed.  Use \
 `\\[org-cycle-force-archived]' to cycle it anyway."))
 
+(defun org-cycle-display-inline-images (state)
+  "Auto display inline images under subtree when cycling.
+It works when `org-cycle-inline-images-di

Re: [off-topic] E-readers and Org-Mode

[Max Nikulin]

On 23/10/2022 22:16, Juan Manuel Macías wrote:


As I am beginning to have serious eye fatigue problems, I am thinking of
buying an e-ink device, not to read books but to read documents. My idea
is that it be an Android device and that it supports the installation of
apk, to be able to install Termux/Emacs/Org-Mode and Nextcloud to sync
with my desktop PC or my laptop.


E-ink displays are slow (my device was manufactured 15 years ago but I 
do not expect dramatic improvement), so applications should be heavily 
optimized to provide acceptable experience. I do not think that Emacs is 
suitable.


The wonderful property of reflective display is that its brightness 
follows ambient conditions. (Almost) direct sunlight during image 
refresh (page switching) may cause low contrast noisy image. A 
workaround is to move the book into shadow or close cover for a moment. 
For static image bright light is not a problem.


I am curious if pdf-tools is able to display annotations created on 
devices with stilus.

Re: [off-topic] E-readers and Org-Mode

[Payas Relekar]

Max Nikulin  writes:

> E-ink displays are slow (my device was manufactured 15 years ago but I do not
> expect dramatic improvement), so applications should be heavily optimized to
> provide acceptable experience. I do not think that Emacs is suitable.

There are people already using Emacs on e-ink displays, and from first
look its quite useful.

See https://twitter.com/ianthehenry/status/1481376985129500679?lang=en

Unsure on use for extended duration, I'll have to try out myself once
one is actually available in my country, but I'm liking the idea.

--

Org Haskell code blocks

[Dominik Schrempf]

Hello,

I have trouble using Haskell code blocks in Org Mode.

1. I need to use the following Org Mode file header:

#+property: :header-args:haskell: :prologue ":{\n" :epilogue ":}\n"

#+begin_src haskell :exports none :results none
:set prompt-cont ""
#+end_src

Otherwise, the results of Haskell code blocks are scrambled.

2. I need to set `haskell-process-type' to `ghci'. The default
interpreter `cabal-repl' does not find any external modules (even core
modules included with GHC).

However, I get the error message "org-babel-script-escape:
‘org-babel-script-escape’ expects a string", when executing the first
code block which starts the interpreter. Seemingly, the error has no
effect because everything works fine.

3. I have to set `org-edit-src-content-indentation` to 0, and always put
the source code to text column 0, otherwise syntax highlighting does not
work.

Do others have the same problems? If so, have there been discussions
about how to improve this situation?

Thank you for your help!

Dominik

Re: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Dr. Arne Babenhauserheide]

Jean Louis  writes:

> This wish request is related to Emacs EWW and Org mode.
>
> Please make EWW recognize Org file when served by WWW server. Currently
> it does not recognize the MIME type text/x-org and opens the file as
> text, it does not invoke the org mode. In my opinion, it should.

This sounds dangerous. Org mode can execute untrusted code, so this
could trick people into running untrusted code with the permissions of
their Emacs.

Links in org-mode can run shell scripts. Yes, they usually ask, but this
may be changed it a local Emacs, trusting that it will only be used to
open trusted local files.

The threat model of eww changes a lot when any file on the web can
request being opened with org-mode.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Org Haskell code blocks

[Dominik Schrempf]

I apologize, the settings described in Point 1 actually have no effect.
Multi line input works out of the box (at least with "ghci" as
described). However, the result output is still scrambled (e.g., empty
lines, unnecessary "ghci>" prompts in results)

Dominik

Dominik Schrempf  writes:

> Hello,
>
> I have trouble using Haskell code blocks in Org Mode.
>
> 1. I need to use the following Org Mode file header:
>
> #+property: :header-args:haskell: :prologue ":{\n" :epilogue ":}\n"
>
> #+begin_src haskell :exports none :results none
> :set prompt-cont ""
> #+end_src
>
> Otherwise, the results of Haskell code blocks are scrambled.
>
> 2. I need to set `haskell-process-type' to `ghci'. The default
> interpreter `cabal-repl' does not find any external modules (even core
> modules included with GHC).
>
> However, I get the error message "org-babel-script-escape:
> ‘org-babel-script-escape’ expects a string", when executing the first
> code block which starts the interpreter. Seemingly, the error has no
> effect because everything works fine.
>
> 3. I have to set `org-edit-src-content-indentation` to 0, and always put
> the source code to text column 0, otherwise syntax highlighting does not
> work.
>
> Do others have the same problems? If so, have there been discussions
> about how to improve this situation?
>
> Thank you for your help!
>
> Dominik

Re: [off-topic] E-readers and Org-Mode

[Fraga, Eric]

On Tuesday, 25 Oct 2022 at 21:37, Max Nikulin wrote:
> E-ink displays are slow (my device was manufactured 15 years ago but I

We are venturing well into OT for this list... ;-)

E-ink displays are getting significantly faster, with some claiming 60
Hz refresh rates (cf. the PineNote).  Often, however, they are tied to
low power and low performance processors given their use case: mostly
reading with some annotations.

-- 
: Eric S Fraga, with org release_9.5.5-1028-gcd835d in Emacs 29.0.50

Re: Best android app

[Max Nikulin]

On 23/10/2022 22:27, Ypo wrote:

https://git.sr.ht/~bzg/worg/tree/master/item/org-faq.org#L4502

I have cloned the "repository" hoping it works like in github, but I see 
no option to edit.


SourceHut does not have an online editor, it is necessary to clone the 
repository to local disk.


Alternatively, since Worg rules are not so strict as for Org source code 
repository,  you can download the .org file either from git.sr.ht or 
https://orgmode.org/worg/org-faq.org copy to org-faq.orig.org, edit, 
create diff


LANG=C.UTF-8 diff -u org-faq.orig.org org-faq.org

For details see info "(diffutils) Tips for Patch Producers"
https://www.gnu.org/software/diffutils/manual/html_node/Tips-for-Patch-Producers.html

For maintainers it is more convenient to work with result of "git 
format-patch" having properly formatted commit message.


My suggestion is to add only projects that you use and can recommend for 
others. It would be nice to have brief description that allows people to 
decide if they should try such application. I do not see any point in 
attempt to collect comprehensive list of ever seen software. PageRank 
algorithm buried manually filled web catalogues. There is no reason to 
participate in such desperate competition.

Re: Best android app

[Max Nikulin]

On 20/10/2022 06:46, Jean Louis wrote:

* Max Nikulin [2022-10-19 15:53]:



The person may be already familiar with that non-free apps. We had
a chance to ask about features missed in free applications and actual
experience. Perhaps the same tasks may be performed in a bit different
and less obvious way and no modification of Org and Co is required.
However you insist that we have to through away such possibilities and
adding outcome from such conversations to web site is prohibited, so it
makes it significantly harder to use obtained information in later
discussions.



Better balanced position is necessary otherwise it would be just weakness in
communication with people who do not care if some software is free.


Then such people have the chance to learn what is free software. Their
weakness is not to know what it is.


I mean weakness of free software proponents. People will learn nothing 
if they meet just unreasonably harsh reaction or absence of convincing 
arguments.



I find it unfortunate that some people create proprietary software
that uses Org files.


It sounds like you regret about absence of a kind of vendor lock. File
formats and communication protocols must be free. There are enough examples
when free software can not be developed due to lack of specifications. Why
would you expect cooperation from vendors if you wish to have fences at your
side in similar cases?


Vendor:
https://www.gnu.org/philosophy/words-to-avoid.html#Vendor


My mistake is that precise term should be "vendor lock-in". I am not a 
native English speaker, but I believe that the word "vendor" was used 
properly. I meant namely vendors, not suppliers.



You have misunderstood the idea. I have never mentioned "absence of a
kind of vendor lock" or similar.

So let us close that discussion and keep creating free software.


You expressed that you do not like that some proprietary software uses 
Org file. Such position is mirroring behavior of software vendors that 
are trying to prevent usage of file formats by other developers (vendor 
lock-in). More people considering restrictions on file formats 
acceptable means more obstacles for development of free software.

Re: [off-topic] E-readers and Org-Mode

[Ken Mankoff]

See also Dasung NotEReader. Full Android tablet, no lockdown like the
ReMarkable. Looks fast - can watch YouTube videos for example. If it's
really full Android, then it should be able to install and run emacs
natively. 10.3 or 7.8 inch versions.

  -k.

Please excuse brevity. Sent from tiny pocket computer with non-haptic
feedback keyboard.

On Tue, Oct 25, 2022, 08:27 Fraga, Eric  wrote:

> On Tuesday, 25 Oct 2022 at 21:37, Max Nikulin wrote:
> > E-ink displays are slow (my device was manufactured 15 years ago but I
>
> We are venturing well into OT for this list... ;-)
>
> E-ink displays are getting significantly faster, with some claiming 60
> Hz refresh rates (cf. the PineNote).  Often, however, they are tied to
> low power and low performance processors given their use case: mostly
> reading with some annotations.
>
> --
> : Eric S Fraga, with org release_9.5.5-1028-gcd835d in Emacs 29.0.50
>

Re: Org Haskell code blocks

[Bruno Barbier]

Hi,

Dominik Schrempf  writes:

> ...
> However, the result output is still scrambled (e.g., empty
> lines, unnecessary "ghci>" prompts in results)
>

For me, ghci is selected by default.

Here is the config I've used to test it:

  | emacs-version   |28.1 |
  | org-version |   9.5.2 |
  | haskell-process-type|auto |
  | org-babel-script-escape |  |


Here is my simple test:
  #+begin_src haskell
1+2
  #+end_src

  #+RESULTS:
  : 3

The variable 'org-babel-script-escape' doesn't exist in the version that
I'm using. And, the prompt is not "ghci>" but the current module name.

Which version of org are you using ? Could you try with a recent version
and provide a minimal complete example using a minimal configuration ?
(see the org mode manual (info "(org)Feedback")).

Thanks,


Bruno

[BUG] [ox-odt] Missing spaces around formatted spans and links

[András Simonyi]

Dear All,

using the most recent version of the main branch I've noticed some
problems with the spacing of documents exported with the odt exporter:
spaces around links and formatted (for instance, italicized) words are
missing, for example, the  Org line

text1 https://orgmode.org/ text2 /italics/

is exported without spaces between text1 and the link and text2 and
the italicized word.

I've not tested this extensively but my impression is that the bug was
introduced by commit
3502ce2db: ox-odt: Fix newlines replaced by spaces in Han script.
(I'm using Emacs 28.2.)

Thanks & best regards,
András

Re: Org Haskell code blocks

[Dominik Schrempf]

Hi Bruno,

glad to hear that it works for you.


Ad 'org-babel-script-escape': I use Org version 9.6. I do not temper
with 'org-babel-script-escape', it is used by the respective babel
modules --- 'ob-haskell' in this case. The error also occurs with
'cabal-repl' as process type.


Ad 'haskell-process-type': When I use 'haskell-process-type' 'auto', it
chooses 'cabal-repl' which will also fire up 'ghci' but the setup is
faulty, because it does not find any modules, as I described. I just
checked and this is not a fault of org-mode. The command 'cabal repl'
also fails to access any modules when executed in the terminal. I think
it requires a `.cabal` file, which I usually do not have when using an
Org file. I quote the help text from 'cabal repl':

Open an interactive session for a component within the project.

I think this is not the correct default for Org mode, because usually
there is no "project", but just an Org file.

If I use 'haskell-process-type' 'ghci', all modules I have installed
along with GHC are found, as I expect them to be.


Ad scrambling: The scrambling happens with multi-line input. For example

#+begin_src haskell :exports both :results output
let x = 10
let y = 12
x*y
[x,y]
#+end_src

#+results:
:
: ghci> 120
: [10,12]

Do you get syntax highlighting when the source code is indented (for
example in list items).

Thanks for your reply!

Dominik

Bruno Barbier  writes:

> Hi,
>
> Dominik Schrempf  writes:
>
>> ...
>> However, the result output is still scrambled (e.g., empty
>> lines, unnecessary "ghci>" prompts in results)
>>
>
> For me, ghci is selected by default.
>
> Here is the config I've used to test it:
>
>   | emacs-version   |28.1 |
>   | org-version |   9.5.2 |
>   | haskell-process-type|auto |
>   | org-babel-script-escape |  |
>
>
> Here is my simple test:
>
>   #+begin_src haskell
> 1+2
>   #+end_src
>
>   #+RESULTS:
>   : 3
>
> The variable 'org-babel-script-escape' doesn't exist in the version that
> I'm using. And, the prompt is not "ghci>" but the current module name.
>
> Which version of org are you using ? Could you try with a recent version
> and provide a minimal complete example using a minimal configuration ?
> (see the org mode manual (info "(org)Feedback")).
>
> Thanks,
>
>
> Bruno

Re: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Jean Louis]

* Dr. Arne Babenhauserheide  [2022-10-25 18:06]:
> > This wish request is related to Emacs EWW and Org mode.
> >
> > Please make EWW recognize Org file when served by WWW server. Currently
> > it does not recognize the MIME type text/x-org and opens the file as
> > text, it does not invoke the org mode. In my opinion, it should.
> 
> This sounds dangerous. Org mode can execute untrusted code, so this
> could trick people into running untrusted code with the permissions of
> their Emacs.

I can always do that in Emacs, execute untrusted code. There are no
trust mechanisms for plethora of Emacs packages and codes distributed
over Internet. 

That was not my request.

Do you know how to make this work?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

citar--library-file-action

[Henrik Frisk]

Hi,

After updating a bunch of packages I'm getting this error message when I
try to open an associated file via a reference:

[cite:@key]

Before it was working fine via emark either by clicking on the reference or
by running embark-act on it. Now I get this instead:

citar--library-file-action: Symbol’s function definition is void: open

Any suggestions?

/Henrik

Re: citar--library-file-action

[Bruce D'Arcus]

For citar support/bugs, you should report on the github issue tracker.

But my guess: you need to install citar-embark, as a while ago, we
moved the embark-related functionality into a separate package. If
it's been a few months since you've updated, that would likely explain
it.

On Tue, Oct 25, 2022 at 4:23 PM Henrik Frisk  wrote:
>
> Hi,
>
> After updating a bunch of packages I'm getting this error message when I try 
> to open an associated file via a reference:
>
> [cite:@key]
>
> Before it was working fine via emark either by clicking on the reference or 
> by running embark-act on it. Now I get this instead:
>
> citar--library-file-action: Symbol’s function definition is void: open
>
> Any suggestions?
>
> /Henrik
>

Re: citar--library-file-action

[Matt Price]

I’d look at the current function definition to be sure (C-h f
citar—library-file-action), but open is the standard macOS command for
opening files. The Linux equivalent is xdg-open. My guess is that somehow
you’ve told citar or  org or emacs to use open for these links. Or it’s
possible that the citar devs accidentally hard coded open into the
function.

On Tue, Oct 25, 2022 at 4:27 PM Henrik Frisk  wrote:

> Hi,
>
> After updating a bunch of packages I'm getting this error message when I
> try to open an associated file via a reference:
>
> [cite:@key]
>
> Before it was working fine via emark either by clicking on the reference
> or by running embark-act on it. Now I get this instead:
>
> citar--library-file-action: Symbol’s function definition is void: open
>
> Any suggestions?
>
> /Henrik
>
>

Re: citar--library-file-action

[Matt Price]

Bruce will know better than me!!!

On Tue, Oct 25, 2022 at 4:46 PM Matt Price  wrote:

> I’d look at the current function definition to be sure (C-h f
> citar—library-file-action), but open is the standard macOS command for
> opening files. The Linux equivalent is xdg-open. My guess is that somehow
> you’ve told citar or  org or emacs to use open for these links. Or it’s
> possible that the citar devs accidentally hard coded open into the
> function.
>
> On Tue, Oct 25, 2022 at 4:27 PM Henrik Frisk  wrote:
>
>> Hi,
>>
>> After updating a bunch of packages I'm getting this error message when I
>> try to open an associated file via a reference:
>>
>> [cite:@key]
>>
>> Before it was working fine via emark either by clicking on the reference
>> or by running embark-act on it. Now I get this instead:
>>
>> citar--library-file-action: Symbol’s function definition is void: open
>>
>> Any suggestions?
>>
>> /Henrik
>>
>>

Re: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Dr. Arne Babenhauserheide]

Jean Louis  writes:

> * Dr. Arne Babenhauserheide  [2022-10-25 18:06]:
>> > This wish request is related to Emacs EWW and Org mode.
>> >
>> > Please make EWW recognize Org file when served by WWW server. Currently
>> > it does not recognize the MIME type text/x-org and opens the file as
>> > text, it does not invoke the org mode. In my opinion, it should.
>> 
>> This sounds dangerous. Org mode can execute untrusted code, so this
>> could trick people into running untrusted code with the permissions of
>> their Emacs.
>
> I can always do that in Emacs, execute untrusted code. There are no
> trust mechanisms for plethora of Emacs packages and codes distributed
> over Internet. 

All of the Emacs packages have some amount of implicit trust. Even melpa
carefully vets packages nowadays. That’s not the case for some website
you visit.

> That was not my request.
>
> Do you know how to make this work?

If you ask me whether I can make this work safely: This would first
require the introduction of a safe-org-mode which strictly disables all
features that can execute remote code or disguise unsafe operations as
safe ones. If a user then decides to explicitly call M-x org-mode,
that’s their problem.

If you ask me whether I know how to make this work unsafely: It likely
won’t need a lot of elisp reading, but I do not, because I do not look
for it, because if I did, I would not.

I do not want to be the one who caused the systems of eww users to get
breached, or who helped opening that security hole.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> This sounds dangerous. Org mode can execute untrusted code, so this
> could trick people into running untrusted code with the permissions of
> their Emacs.
>
> Links in org-mode can run shell scripts. Yes, they usually ask, but this
> may be changed it a local Emacs, trusting that it will only be used to
> open trusted local files.

You are exaggerating the situation.
The "problem" with shell links you are describing is a question of
setting variables and is also disabled by default.

eww-mode, when loading Org page, could simply set
org-link-shell-confirm-function to its default value.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Ag Ibragimov]

Can't you just use one of hooks (e.g., eww-after-render-hook) where you
inspect the URL and if it's .org, just change the mode?

This should be trivial to do, I think.

Jean Louis  writes:

> This wish request is related to Emacs EWW and Org mode.
>
> Please make EWW recognize Org file when served by WWW server. Currently
> it does not recognize the MIME type text/x-org and opens the file as
> text, it does not invoke the org mode. In my opinion, it should.
>
> Inspect following file by using lynx:
>
> $ lynx -head https://gnu.support/files/tmp/example.org
>
> uHTTP/1.1 200 OK
> Server: nginx/1.14.2
> Date: Tue, 25 Oct 2022 12:04:26 GMT
> Content-Type: text/x-org
> Content-Length: 364
> Last-Modified: Tue, 25 Oct 2022 11:58:22 GMT
> Connection: close
> ETag: "6357cf5e-16c"
> Accept-Ranges: bytes
>
> One can see that Content-Type is text/x-org
>
> My expectation is that EWW opens the Org file served by WWW server in
> Org mode. But it doesn't. Can this be done?
>
> This will open opportunity to directly serve Org files by using WWW
> servers and to browse such files through Emacs, meaning, bunch of notes,
> tasks and similar may be kept online, with or without protection and
> directly accessed by Emacs. It becomes new area or WWO or World Wide Org
> environment.
>
>
>
> In GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo
>  version 1.17.6, Xaw3d scroll bars) of 2022-10-10 built on
>  protected.rcdrun.com
> Repository revision: ed436db1320339862fad5ac754a6ec42de06c766
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
> System Description: Parabola GNU/Linux-libre
>
> Configured using:
>  'configure --with-x-toolkit=lucid'
>
> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
> JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
> PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
> WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB
>
> Important settings:
>   value of $LC_ALL: en_US.UTF-8
>   value of $LANG: de_DE.UTF-8
>   value of $XMODIFIERS: @im=exwm-xim
>   locale-coding-system: utf-8-unix
>
> Major mode: Message
>
> Minor modes in effect:
>   mml-mode: t
>   tooltip-mode: t
>   global-eldoc-mode: t
>   show-paren-mode: t
>   electric-indent-mode: t
>   mouse-wheel-mode: t
>   tool-bar-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   line-number-mode: t
>   auto-fill-function: message-do-auto-fill
>   transient-mark-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   abbrev-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort emacsbug mail-extr org-timer org-colview org-clock
> org-attach org-id org-archive org-agenda org-refile ol-eww eww xdg
> url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
> nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
> gnus-sum shr pixel-fill kinsoku url-file svg dom browse-url url
> url-proxy url-privacy url-expand url-methods url-history url-cookie
> generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
> eieio eieio-core cl-macs url-vars gnus-group gnus-undo gnus-start
> gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
> parse-time gnus-spec gnus-int gnus-range message sendmail mailcap
> yank-media puny rfc822 mml mml-sec password-cache epa derived epg
> rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
> rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
> nnheader gnus-util text-property-search mail-utils range mm-util
> mail-prsvr wid-edit ol-docview doc-view filenotify jka-compr image-mode
> exif dired dired-loaddefs ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi
> reporter org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
> org-footnote org-src ob-comint org-pcomplete pcomplete comint ansi-osc
> ansi-color ring org-list org-faces org-entities noutline outline icons
> org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic json map
> byte-opt gv bytecomp byte-compile cconv bibtex iso8601 time-date subr-x
> ol rx org-keys oc org-compat advice org-macs org-loaddefs format-spec
> find-func cal-menu calendar cal-loaddefs cl-loaddefs cl-lib rmc
> iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
> lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
> tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
> newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
> rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
> font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
> simple cl-generic indonesian philippine cham georgian utf-8-lang
> misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
> cp51932 hebrew greek romanian slovak czech europe

Re: How ro delete DONE attemps

[Tim Cross]

Nick Dokos  writes:

> Renato Pontefice  writes:
>
>> Hi,
>> I’m wondering how can I delete, on my .org file, the line that have:
>> - an old Timestamp (i.e. if I set a thing to be done today (<2022-10-24 Mon 
>> 17:26>)
>> - a TODO item (always with a past date) <2022-10-24 Mon 17:26>
>>
>> That to have a more clean .org file.
>>
>> Is it possible?
>> How can I obtain it?
>>
>
> It's just text: you can use ordinary Emacs commands to modify the
> file, e.g. C-k will kill a line, or you can use C-d to delete
> characters or M-d to delete words.

The other thing you can do is use org's built-in archiving support. With
this, you can have 'old' items which are no longer relevant moved to a
separate archive file, creating a cleaner org file and keeping an
archive record of past items.

[no subject]

[Ag Ibragimov]

> I am unable to reproduce on my side using the latest main branch.
> Can you please provide detailed steps you performed to get the erroneous
> behaviour? See https://orgmode.org/manual/Feedback.html

I'm very sorry for wasting your time, it looks like I had
org-capture-after-finalize-hook pointing to a non-existing function.

Re: [BUG] Undocumented convention for org-time-stamp-custom-formats to be "<...>" (was: time-stamp in DONE tag is not really displayed)

[Ihor Radchenko]

Tim Cross  writes:

>> I propose to do the following:
>> 1. org-time-stamp-formats and org-time-stamp-custom-formats will be
>>treated as is, unless they contain "<" and ">" and the first and the
>>last char.
>> 2. If the formats do contain <...>, strip the "<" and ">".
>> 3. Document (2) in the docstrings.
>>
>> Any objections?
>
> Little unsure/confused regarding what is being proposed here.
>
> - If we are removing <...>, does that mean we just retain [..] for
>   inactive timestamps and all other timestamps are 'active' by default?

org-time-stamp-formats is a constant. Users are not supposed to change
it. So, the proposed stripping of "<" and ">" has a pure purpose of not
breaking third-party code that might be using its current default value.
It is more about some internal code assumptions.

org-time-stamp-custom-formats currently has the following docstring:

Custom formats for time stamps.  See format-time-string for the syntax.

These are overlaid over the default ISO format if the variable
org-display-custom-times is set.  Time like %H:%M should be at the
end of the second format.  The custom formats are also honored by export
commands, if custom time display is turned on at the time of export.

There is nothing in the docstring indicating that "<" and ">" are
required or used in any way. The current Org code assumptions only
create confusion among the users.

I propose to strip "<" and ">" just to avoid breakage if users happened
to set org-time-stamp-custom-formats to the value with "<...>" that is
required to make this defcustom working in older Org versions.

If users abused the undocumented behavior and used "[...]", we do not
need to worry as it is out of what was promised.

At the end, old user settings of org-time-stamp-custom-formats should
remain working within docstring promises.
Old user code using org-time-stamp-formats constant should also remain
working.
But users will not need to provide brackets in
org-time-stamp-custom-formats after the proposed change.

The above is the most safe way to retain backwards compatibility while
removing the existing confusion with the docstring.

> - How will this change impact code which distinguishes active/inactive
>   timestamps based on presence/absence of <..> and [..]?

org-time-stamp-formats value will not change.
org-time-stamp-custom-formats value had no impact on buffer text---just
the overlayed timestamp display. No code should be affected.

> - What impact will this have on existing org files?

None.

> - Will this cause issues in parsing when you may have dates/times which
>   are not supposed to be timestamps, but will look the same as
>   timestamps? How will you distinguish them?

No buffer text will be affected.

> Personally, I like the clear distinction between what is a timestamp and
> what isn't and what is an active timestamp and what is an inactive
> timestamp.

There is nothing about active/inactive timestamps in the discussed
variables. The usage of "<" and ">" is historical and mostly ignored by
Org code. First and last characters are simply stripped, and the required
brackets are being used when inserting the actual timestamps.

The proposed change simply aims to remove the undocumented requirement
about brackets.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Org Haskell code blocks

[Ihor Radchenko]

Dominik Schrempf  writes:

> Ad scrambling: The scrambling happens with multi-line input. For example
>
> #+begin_src haskell :exports both :results output
> let x = 10
> let y = 12
> x*y
> [x,y]
> #+end_src
>
> #+results:
> :
> : ghci> 120
> : [10,12]

I am unable to reproduce on the latest main.
Likely because of recent fixes in ob-comint.

> Do you get syntax highlighting when the source code is indented (for
> example in list items).

I have the above code fontified.
Could you please provide an example of the code that is not being fontified?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Undocumented convention for org-time-stamp-custom-formats to be "<...>" (was: time-stamp in DONE tag is not really displayed)

[Samuel Wales]

please feel free to ignore this post if it is off topic.  i cannot
tell if it is of topic or not.

long ago i wanted to mke it so that if i hovered over a timesamp it
woud produce a time span notation relative to .  and also i
wanted to make a custom time stamp format for the same purpose.  but i
think was not possible.

if any changes are actually done to custom format, perhaps, if not
already done, hooks can be strategically added or so.


On 10/25/22, Ihor Radchenko  wrote:
> Tim Cross  writes:
>
>>> I propose to do the following:
>>> 1. org-time-stamp-formats and org-time-stamp-custom-formats will be
>>>treated as is, unless they contain "<" and ">" and the first and the
>>>last char.
>>> 2. If the formats do contain <...>, strip the "<" and ">".
>>> 3. Document (2) in the docstrings.
>>>
>>> Any objections?
>>
>> Little unsure/confused regarding what is being proposed here.
>>
>> - If we are removing <...>, does that mean we just retain [..] for
>>   inactive timestamps and all other timestamps are 'active' by default?
>
> org-time-stamp-formats is a constant. Users are not supposed to change
> it. So, the proposed stripping of "<" and ">" has a pure purpose of not
> breaking third-party code that might be using its current default value.
> It is more about some internal code assumptions.
>
> org-time-stamp-custom-formats currently has the following docstring:
>
> Custom formats for time stamps.  See format-time-string for the syntax.
>
> These are overlaid over the default ISO format if the variable
> org-display-custom-times is set.  Time like %H:%M should be at the
> end of the second format.  The custom formats are also honored by
> export
> commands, if custom time display is turned on at the time of export.
>
> There is nothing in the docstring indicating that "<" and ">" are
> required or used in any way. The current Org code assumptions only
> create confusion among the users.
>
> I propose to strip "<" and ">" just to avoid breakage if users happened
> to set org-time-stamp-custom-formats to the value with "<...>" that is
> required to make this defcustom working in older Org versions.
>
> If users abused the undocumented behavior and used "[...]", we do not
> need to worry as it is out of what was promised.
>
> At the end, old user settings of org-time-stamp-custom-formats should
> remain working within docstring promises.
> Old user code using org-time-stamp-formats constant should also remain
> working.
> But users will not need to provide brackets in
> org-time-stamp-custom-formats after the proposed change.
>
> The above is the most safe way to retain backwards compatibility while
> removing the existing confusion with the docstring.
>
>> - How will this change impact code which distinguishes active/inactive
>>   timestamps based on presence/absence of <..> and [..]?
>
> org-time-stamp-formats value will not change.
> org-time-stamp-custom-formats value had no impact on buffer text---just
> the overlayed timestamp display. No code should be affected.
>
>> - What impact will this have on existing org files?
>
> None.
>
>> - Will this cause issues in parsing when you may have dates/times which
>>   are not supposed to be timestamps, but will look the same as
>>   timestamps? How will you distinguish them?
>
> No buffer text will be affected.
>
>> Personally, I like the clear distinction between what is a timestamp and
>> what isn't and what is an active timestamp and what is an inactive
>> timestamp.
>
> There is nothing about active/inactive timestamps in the discussed
> variables. The usage of "<" and ">" is historical and mostly ignored by
> Org code. First and last characters are simply stripped, and the required
> brackets are being used when inserting the actual timestamps.
>
> The proposed change simply aims to remove the undocumented requirement
> about brackets.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: yanking into body text ends up after the entry

[Samuel Wales]

thank you for trying to repro.  i will tolerat the bug until in the
future my setup is more compatible for reporting this bug or it
disappears.

On 10/16/22, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> imagine this
>>
>> * to yank
>> a
>> b
>> c
>> * x
>> ^sadfsadf
>> ^^*** y
>>
>> if i kill the to yank entry, then paste at ^,it ends up at ^^ instead.
>> this is logical in that to yank would swallow the body text, but i am
>> wondering when this behavior started.
>
> I am unable to reproduce.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [BUG] [ox-odt] Missing spaces around formatted spans and links

[Ihor Radchenko]

András Simonyi  writes:

> using the most recent version of the main branch I've noticed some
> problems with the spacing of documents exported with the odt exporter:
> spaces around links and formatted (for instance, italicized) words are
> missing, for example, the  Org line
>
> text1 https://orgmode.org/ text2 /italics/
>
> is exported without spaces between text1 and the link and text2 and
> the italicized word.
>
> I've not tested this extensively but my impression is that the bug was
> introduced by commit
> 3502ce2db: ox-odt: Fix newlines replaced by spaces in Han script.
> (I'm using Emacs 28.2.)

Thanks for the heads up!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bb40848458512fc26ffa47d20807e3cd0211ccad

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: idea for capture anywhere in x

[Samuel Wales]

hi max, thanks.

more below.

On 10/14/22, Max Nikulin  wrote:
> Samuel, I assume that you are quite happy with org-capture Firefox
> extension.

yes i rely on it and adore it.

although i always fear it breaking or silently failing, as i have
emacs in the bg behind ff when i run it and do not want to do more
mousing and inspecting to find out if worked each time.

i think last time it broke was some kind of mime stuff.  i know it
also has glitches of some kind but forgot what they were.
e.g. something about it not having enough of a firefox api to
distinguish whether you have changed tabs or some such.  but i ahve
not noticed any issues latelyu.  but then i do not look for them.

>
> Have you managed to setup capturing text from other applications? From
> my point of view all necessary moving parts have been discussed in this
> or later threads. Have you assembled them to a working solution suitable
> for you?

no, oi have not yet.  for unrelated reasons, it takes me a lot of time
to do things.

the most critical application to catpreu from is firefox itself for
which i have above org capture extension.

it looks like i can do:

>
> - Window manager menu item and shortcut calling
>emacsclient --eval '(org-capture nil "c")'

this as an item in .fluxbox/menu, for non-emacs apps.

> - Capture template that fetches X PRIMARY_SELECTION or CLIPBOARD.

with a capture template that has percents for th3ese or so?

[n.b. i  still have a mysterious capture bug where it puts newlines
above capturd entries. could be me, or version issue, or both.]

btw on occasion i wnt to capture from emacs using mouse only, but not
all modes have mouse context menu.

i am always either using keybaord or using mouse never both.  emacs
would be second application for capturing via mouse.

other applications are pdf displayers, deluge, urxvt, console.  other
stuff is rare.

> - Optionally try to get formatted text and convert it from HTML to Org
> using pandoc.

which is intruiguing but i will keep my expectations and needs and
priority low here but would want this to be using firefox cli/emacs
api or .mozilla files rather than e.g. a curl call for privacy.  i
will assume not doing this but curious about it.

> - Perhaps try to get window title of the active application.

interesting!  perhaps org-capture could run lisp to call one of those
xdo type tools or so.  it would take a bit ot of me to do.

>
> What I have not tried yet is if drag&drop API may provide more details
> than X selection, but I am unsure if such workflow is suitable for you.

intresting idea re details.  however, drag and drop per se is
impossible for me among apps as i always maximize and it irritates me
so much within that i trid to turn off due to the effects of mistaken
mouse movements or slwo machine.

>
> Probably it is better to discuss code in the context of particular
> applications. Despite you wish a general approach, amount of information
> exposed by applications may vary. Some code may depend on Emacs version

good point.  i'm assuming a little tweaking here and there might be
usful where possible for url/title or equivalent or any other stuff.
huh, gathering such might make a nce package if anybody had the same
idea and wanted to do it.  maybe spookfox will get more development
and include some features like this.  or the above.  merely
brainstorming.

one of th reasons i suggestd this anywhere in x idea was to act as a
fallback should org-capture break.

> an I am unsure which one you are using currently.
>

old as the hills.  hoping to try if poss to upgrade over next few
months/years to 26 27 28+.

[perhaps one day i will natively compile! i have super-modern lexical
binding and don't use (` bq.  :)  oh and although i realy like
ido/ido-hacks/id-clever-match very much i sort of eye embark and its
inter-operable gang.  someday in the futre.]

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: How ro delete DONE attemps

[Samuel Wales]

are those bare timestamps without planning tags like deadline:
scheduled: closed:?

then you will need something bespoke.  but if they are planning lines
which go after the headline, then you are in luck.  you can use org
archiving tools.  [boken in my version but i think has been fixed in
recent versions.]

On 10/24/22, Renato Pontefice  wrote:
> Hi,
> I’m wondering how can I delete, on my .org file, the line that have:
> - an old Timestamp (i.e. if I set a thing to be done today (<2022-10-24 Mon
> 17:26>)
> - a TODO item (always with a past date) <2022-10-24 Mon 17:26>
>
> That to have a more clean .org file.
>
> Is it possible?
> How can I obtain it?
>
> Thank you
>
> Renato
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH v3] New: auto display inline images under subtree when `org-cycle'.

[Ihor Radchenko]

"Christopher M. Miles"  writes:

>> Sorry, I was not very clear.
>> I meant to remove that patch that fails due to noninteractive and leave
>> the rest.
>>
>
> Updated, I deleted testing and marked as TODO.
>

Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=46b71f910844c14d8db1feb54c07de26d101cc05
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=87e50f467add3ddca635d32f97b9bd6061008faa

Thanks for your contribution!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: idea for capture anywhere in x

[Ihor Radchenko]

Samuel Wales  writes:

> although i always fear it breaking or silently failing, as i have
> emacs in the bg behind ff when i run it and do not want to do more
> mousing and inspecting to find out if worked each time.

You may hook notifications-notify to org-capture-after-finalize-hook to
see notification when the capture is successful.

>> - Capture template that fetches X PRIMARY_SELECTION or CLIPBOARD.
>
> with a capture template that has percents for th3ese or so?

Yes. From org-capture-templates docstring:

  %x  Content of the X clipboard.

> btw on occasion i wnt to capture from emacs using mouse only, but not
> all modes have mouse context menu.

What about menu bar entry?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: idea for capture anywhere in x

[Samuel Wales]

more below.

On 10/25/22, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> although i always fear it breaking or silently failing, as i have
>> emacs in the bg behind ff when i run it and do not want to do more
>> mousing and inspecting to find out if worked each time.
>
> You may hook notifications-notify to org-capture-after-finalize-hook to
> see notification when the capture is successful.

had not heard of this.  i see that it is part of a pacage called
org-notify?  it would flash screen discreetly or pop up a box in a
corner that would go away soon or some such thing?  sounds like it
could be reassuring if it is not obtrusive.

>
>>> - Capture template that fetches X PRIMARY_SELECTION or CLIPBOARD.
>>
>> with a capture template that has percents for th3ese or so?
>
> Yes. From org-capture-templates docstring:
>
>   %x  Content of the X clipboard.
>
>> btw on occasion i wnt to capture from emacs using mouse only, but not
>> all modes have mouse context menu.
>
> What about menu bar entry?

with my font size menu bar woud not be desirable.  for mouse
activation which is whati wouldneed it would need to be rclick.  but
thats mode specific so it sounds like a rather troublesome task to
make it work in all the poaces i'd want it to work.

> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [BUG] Undocumented convention for org-time-stamp-custom-formats to be "<...>" (was: time-stamp in DONE tag is not really displayed)

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>>> I propose to do the following:
>>> 1. org-time-stamp-formats and org-time-stamp-custom-formats will be
>>>treated as is, unless they contain "<" and ">" and the first and the
>>>last char.
>>> 2. If the formats do contain <...>, strip the "<" and ">".
>>> 3. Document (2) in the docstrings.
>>>
>>> Any objections?
>>
>> Little unsure/confused regarding what is being proposed here.
>>
>> - If we are removing <...>, does that mean we just retain [..] for
>>   inactive timestamps and all other timestamps are 'active' by default?
>
> org-time-stamp-formats is a constant. Users are not supposed to change
> it. So, the proposed stripping of "<" and ">" has a pure purpose of not
> breaking third-party code that might be using its current default value.
> It is more about some internal code assumptions.
>
> org-time-stamp-custom-formats currently has the following docstring:
>
> Custom formats for time stamps.  See format-time-string for the syntax.
> 
> These are overlaid over the default ISO format if the variable
> org-display-custom-times is set.  Time like %H:%M should be at the
> end of the second format.  The custom formats are also honored by export
> commands, if custom time display is turned on at the time of export.
>
> There is nothing in the docstring indicating that "<" and ">" are
> required or used in any way. The current Org code assumptions only
> create confusion among the users.
>
> I propose to strip "<" and ">" just to avoid breakage if users happened
> to set org-time-stamp-custom-formats to the value with "<...>" that is
> required to make this defcustom working in older Org versions.
>
> If users abused the undocumented behavior and used "[...]", we do not
> need to worry as it is out of what was promised.
>
> At the end, old user settings of org-time-stamp-custom-formats should
> remain working within docstring promises.
> Old user code using org-time-stamp-formats constant should also remain
> working.
> But users will not need to provide brackets in
> org-time-stamp-custom-formats after the proposed change.
>
> The above is the most safe way to retain backwards compatibility while
> removing the existing confusion with the docstring.
>
>> - How will this change impact code which distinguishes active/inactive
>>   timestamps based on presence/absence of <..> and [..]?
>
> org-time-stamp-formats value will not change.
> org-time-stamp-custom-formats value had no impact on buffer text---just
> the overlayed timestamp display. No code should be affected.
>
>> - What impact will this have on existing org files?
>
> None.
>
>> - Will this cause issues in parsing when you may have dates/times which
>>   are not supposed to be timestamps, but will look the same as
>>   timestamps? How will you distinguish them?
>
> No buffer text will be affected.
>
>> Personally, I like the clear distinction between what is a timestamp and
>> what isn't and what is an active timestamp and what is an inactive
>> timestamp.
>
> There is nothing about active/inactive timestamps in the discussed
> variables. The usage of "<" and ">" is historical and mostly ignored by
> Org code. First and last characters are simply stripped, and the required
> brackets are being used when inserting the actual timestamps.
>
> The proposed change simply aims to remove the undocumented requirement
> about brackets.

OK, thanks for clarifying. Based on this, I don't see any issues with
your proposed change.

Re: [BUG] [ox-odt] Missing spaces around formatted spans and links

[András Simonyi]

Dear Ihor,
thanks a lot for the super-quick fix!
best wishes,
András

On Wed, 26 Oct 2022 at 06:35, Ihor Radchenko  wrote:
>
> András Simonyi  writes:
>
> > using the most recent version of the main branch I've noticed some
> > problems with the spacing of documents exported with the odt exporter:
> > spaces around links and formatted (for instance, italicized) words are
> > missing, for example, the  Org line
> >
> > text1 https://orgmode.org/ text2 /italics/
> >
> > is exported without spaces between text1 and the link and text2 and
> > the italicized word.
> >
> > I've not tested this extensively but my impression is that the bug was
> > introduced by commit
> > 3502ce2db: ox-odt: Fix newlines replaced by spaces in Han script.
> > (I'm using Emacs 28.2.)
>
> Thanks for the heads up!
> Fixed on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bb40848458512fc26ffa47d20807e3cd0211ccad
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Stefan Kangas]

Ihor Radchenko  writes:

> The "problem" with shell links you are describing is a question of
> setting variables and is also disabled by default.
>
> eww-mode, when loading Org page, could simply set
> org-link-shell-confirm-function to its default value.

Note that with the suggested feature, any link you follow risks being
loaded in Org mode, before the user even has a chance to inspect the
file.  Which Org features, currently existing or introduced in the
future, would EWW have to add workarounds for?

It is very hard to foresee which parts of Org will be problematic and
have to be disabled.  See the security vulnerability in enriched-mode
that prompted the release of Emacs 25.3, for example.

Adding this opens a can of worms that will expose unsuspecting users to
a whole class of new problems.  And the only benefit is to save some
users from having to type "M-x org-mode RET", or adding call to a
suitable hook.

All in all, this seems like a bad trade-off.  So I don't think we should
add such a feature.

desktop notifications (Re: idea for capture anywhere in x)

[Max Nikulin]

On 26/10/2022 12:05, Samuel Wales wrote:



You may hook notifications-notify to org-capture-after-finalize-hook to
see notification when the capture is successful.


sounds like it
could be reassuring if it is not obtrusive.


Try the following command to get impression

notify-send "summary" "text"

Since you are using fluxbox, likely you need to add some daemon to 
autostart (unless the package has an /etc/xdg/autostart entry active for 
fluxbox)


apt-cache search notification-daemon

As a KDE user I can not suggest particular one. Perhaps 
notification-daemon package is enough.


It is better to protect "&<>" characters as HTML entities "&" etc. 
since the spec allows some basic formatting and active links.

Re: [ANN] The 2022 Emacs User Survey is now open!

[Christopher M. Miles]

Completed

Timothy  writes:

> Hi All,
>
> I’m thrilled to announce that the Emacs User Survey 2022 is now open to
> responses. It is my hope that this may help emacs-devel, Emacs package
> maintainers, and the wider Emacs community develop a better understanding of
> how people experience Emacs on a day-to-day basis.
>
> 
>
> The survey will be open from October 24th to November 30th.
>
> This time there are /no/ non-free Javascript or user-tracking caveats as this
> features a bespoke survey framework written from scratch for the Emacs User
> Survey to support a pure HTML-forms + CSS approach with server-side rendering
> 🎉.
>
> See the [FAQ] for more information on the survey itself.
>
> It would be fantastic for this to be shared as far and wide as possible, to 
> get
> responses from a large swathe of the community. If you can share this with 
> Emacs
> communities you are a part of, as well as any friends or colleagues that use
> Emacs, that would be much appreciated.
>
> We can look forward to a discussion of the (preliminary) results in EmacsConf:
> .
>
> All the best,
> Timothy


-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: desktop notifications (Re: idea for capture anywhere in x)

[Samuel Wales]

i have the daemon and the binary but notify-send "summary" "text"
seems to do nothing obvious.  called from shell mode.  my emacs is
maximized.  so is firefox.

On 10/25/22, Max Nikulin  wrote:
> On 26/10/2022 12:05, Samuel Wales wrote:
>>
>>> You may hook notifications-notify to org-capture-after-finalize-hook to
>>> see notification when the capture is successful.
>>
>> sounds like it
>> could be reassuring if it is not obtrusive.
>
> Try the following command to get impression
>
>  notify-send "summary" "text"
>
> Since you are using fluxbox, likely you need to add some daemon to
> autostart (unless the package has an /etc/xdg/autostart entry active for
> fluxbox)
>
>  apt-cache search notification-daemon
>
> As a KDE user I can not suggest particular one. Perhaps
> notification-daemon package is enough.
>
> It is better to protect "&<>" characters as HTML entities "&" etc.
> since the spec allows some basic formatting and active links.
>
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [ANN] The 2022 Emacs User Survey is now open!

[Samuel Wales]

done

last time i only got the preliminary results but wow it looked like
emacs was thriving.  not that we did't already know that from all the
blogs and sacha's list but still it was amazing.


On 10/25/22, Christopher M. Miles  wrote:
>
> Completed
>
> Timothy  writes:
>
>> Hi All,
>>
>> I’m thrilled to announce that the Emacs User Survey 2022 is now open to
>> responses. It is my hope that this may help emacs-devel, Emacs package
>> maintainers, and the wider Emacs community develop a better understanding
>> of
>> how people experience Emacs on a day-to-day basis.
>>
>> 
>>
>> The survey will be open from October 24th to November 30th.
>>
>> This time there are /no/ non-free Javascript or user-tracking caveats as
>> this
>> features a bespoke survey framework written from scratch for the Emacs
>> User
>> Survey to support a pure HTML-forms + CSS approach with server-side
>> rendering
>> 🎉.
>>
>> See the [FAQ] for more information on the survey itself.
>>
>> It would be fantastic for this to be shared as far and wide as possible,
>> to get
>> responses from a large swathe of the community. If you can share this with
>> Emacs
>> communities you are a part of, as well as any friends or colleagues that
>> use
>> Emacs, that would be much appreciated.
>>
>> We can look forward to a discussion of the (preliminary) results in
>> EmacsConf:
>> .
>>
>> All the best,
>> Timothy
>
>
> --
>
> [ stardiviner ]
> I try to make every word tell the meaning that I want to express without
> misunderstanding.
>
> Blog: https://stardiviner.github.io/
> IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
> GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Org Haskell code blocks

[Dominik Schrempf]

Dear Ihor,

thank you, these are great news!

Syntax highlighting is not working, for example, with the following
snippet and code block:

begin_snippet

- An example of a function:

  #+begin_src haskell :exports code :results none
  f :: a -> b
  #+end_src

end_snippet

Note the indentation. The code block is indented by 2 spaces, because it
belongs to the list item above. The indentation makes the syntax
highlighting fail. It may well be that this is non-standard usage of
code blocks, but it is very convenient to preserve indentation in this
way.

I also fixed the detection of 'haskell-process-type'. It turns out, I
had some local configuration preferring 'cabal-repl', even without the
required project files. 'haskell-process-type' 'auto' works correctly, I
apologize.

Thank you for your help!

Dominik

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>> Ad scrambling: The scrambling happens with multi-line input. For example
>>
>> #+begin_src haskell :exports both :results output
>> let x = 10
>> let y = 12
>> x*y
>> [x,y]
>> #+end_src
>>
>> #+results:
>> :
>> : ghci> 120
>> : [10,12]
>
> I am unable to reproduce on the latest main.
> Likely because of recent fixes in ob-comint.
>
>> Do you get syntax highlighting when the source code is indented (for
>> example in list items).
>
> I have the above code fontified.
> Could you please provide an example of the code that is not being fontified?

Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Ihor Radchenko]

Stefan Kangas  writes:

> Ihor Radchenko  writes:
>
>> The "problem" with shell links you are describing is a question of
>> setting variables and is also disabled by default.
>>
>> eww-mode, when loading Org page, could simply set
>> org-link-shell-confirm-function to its default value.
>
> Note that with the suggested feature, any link you follow risks being
> loaded in Org mode, before the user even has a chance to inspect the
> file.  Which Org features, currently existing or introduced in the
> future, would EWW have to add workarounds for?

That's not the case. Org never loads arbitrary code on loading the file
without querying the user.

The problem raised above is what happens when user tries to open a shell
link and _also_ customized org-link-shell-confirm-function to nil (which
is explicitly marked as dangerous option).

Strictly speaking, even eww-mode may run arbitrary code given that user
puts something into eww-mode-hook.

> It is very hard to foresee which parts of Org will be problematic and
> have to be disabled.  See the security vulnerability in enriched-mode
> that prompted the release of Emacs 25.3, for example.
>
> Adding this opens a can of worms that will expose unsuspecting users to
> a whole class of new problems.  And the only benefit is to save some
> users from having to type "M-x org-mode RET", or adding call to a
> suitable hook.

I'd say that it will be safer to take care about necessary precautions
rather than leaving the user with the only option to run org-mode
manually.

If necessary, we can introduce a special variable in Org mode that will
disable all the potential third-party code evaluation, even if user has
customized Org to execute code without prompt.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Org Haskell code blocks

[Ihor Radchenko]

Dominik Schrempf  writes:

> Syntax highlighting is not working, for example, with the following
> snippet and code block:
>
> begin_snippet
>
> - An example of a function:
>
>   #+begin_src haskell :exports code :results none
>   f :: a -> b
>   #+end_src
>
> end_snippet

Works on my side (I think).
See the attached screenshot.
I am on the latest main.



-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Fill-paragraph issue with hidden emphasis markers and composed characters

[Ihor Radchenko]

Lucas Viana  writes:

> Steps to reproduce:
> 1. Start emacs -Q (no configuration)
> 2. Set some variables:
>
> (setq org-pretty-entities t
>   org-hide-emphasis-markers t
>   fill-column 80)
>
> 3. Create an empty org-mode buffer with the following paragraph:
> ""
> This is a /italic sentence for a buggy/ \alpha\beta\gamma\delta\nu\epsilon
> paragraph in terms of filling, see, it's not filled yet and still the line
> above
> ends early.
> ""
>
> So far so good, and with the previous config the emphasis markers are now
> hidden and the greek letters appear as unicode characters.
>
> 4. Hit M-q (either fill-paragraph or org-fill-paragraph, both have the same
> issue)
> The first line wrongly wraps after "buggy" and leaves a big empty space
> after that, as if the greek letters were not composed.

Confirmed.
This appears to be Emacs bug though.
I reported it in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58791
Let's see what Emacs devs reply.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at