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

[Jean Louis]

* Jean Louis  [2022-10-25 15:14]:
> 
> 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.

Now is clear that main problem here is that Org advertises somewhere
to be "text" in MIME context, while it is not, it is by default
"application" and thus unsafe, see:

Application Media Types
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5

and understand difference to:

Text Media Types
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1

Thus I suggest that Org changes its MIME type and stop falsely
claiming to be "text" in MIME context, but that content type:
"application/x-org" become adopted, as that way it will become clear
that it is unsafe opening Org as falsely claimed "plain" text.

Main reason to change MIME for Org files is that Org is opened mainly
by Emacs -- and Emacs itself has programming language built-in. It is
equivalent to opening Perl file example.pl with "perl" command.

Quote from RFC6838:
---

For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates.  An
intelligent user agent would use this information to conduct a dialog
with the user, and might then send additional material based on that
dialog.  More generally, there have been several "active" languages
developed in which programs in a suitably specialized language are
transported to a remote location and automatically run in the
recipient's environment.  Such applications may be defined as subtypes
of the "application" top-level type.

Other comments: one can see from above that MIME types are useful to
execute remote programs, and there is nothing fundamentally wrong with
it. We can't just speak of safety alone when we are in general
computing environment, we must also speak of usefulness.

My initial request was not to execute Babel code in Org files or any
other code in Org files, but the basic viewing, browsing and linking
capacity of Org files, similarly to HTML. 

My notes are on meta level, they export to Org for presentation
purposes. Not really for execution purposes. Though it is also useful.

All I want is to access my personal read-only Org files by using WWW
and browse from one to the other by using links. 

While one may achieve similar hyperlinking features with HTML export,
exporting to HTML and making sure of details is very bloated activity
that also requires much supervision of the presentation.  It generates
work and takes time. It also requires browsers, separate software to
handle Org objects innate to Emacs. Why?

Generating Org files with all relational referencing and making them
accessible from WWW straight to Emacs makes life simpler.

It implies teaching Emacs EWW how to open various content types. 


--
Jean

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

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

Re: [BUG][Security] begin_src :var evaluated before the prompt to confirm execution

[Max Nikulin]

On 27/10/2022 11:22, Jean Louis wrote:

* Max Nikulin [2022-10-27 06:21]:

Expected result:
No code from the Org buffer and linked files is executed prior to
confirmation from the user.


Should that be or is it a general policy for Org mode?


I am afraid, it is unrealistic. Spreadsheet feature will be unusable. 
And it is another reason why I am strongly against formats designed for 
personal use rather than for web in browser context.



I consider such issues as a reason why it is bad idea to use Emacs as a
handler for Org files downloaded from web.


I am lost here. Should people then use Vim as handler for Org files? 


I will respond if you ask the same in another thread. I created this one 
to track particular issue: arguments of source code blocks evaluated 
without a prompt. Content-Type will not help fix this issue.


Perhaps closely related issues exist with noweb references or some other 
way to use code outside of particular #+begin_src body. I am unsure if 
such problems should be discussed in this thread or in dedicated ones. I 
am still suffering from deja vu and I should just bump an earlier thread.

Re: [PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Ihor Radchenko]

"Samuel W. Flint"  writes:

> * lisp/org-clock.el (org-clock-in-switch-to-state,
> org-clock-out-switch-to-state): Allow
> `org-clock-{in,out}-switch-to-state` to be an alist of
> current/next-state pairs.
>
> (org-clock-in, org-clock-out): Add logic to handle
> `org-clock-{in,out}-switch-to-state` as alists.

Thanks!

Before we continue, could you please confirm if you have FSF copyright
assignment? My records show that you have made two commits to Org mode
previously, and they total LOC is 15, which is maximum allowed
contribution that does not require copyright assignment. See
https://orgmode.org/worg/org-contribute.html#copyright

>"Set task to a special todo state while clocking it.
>  The value should be the state to which the entry should be
> -switched.  If the value is a function, it must take one
> -parameter (the current TODO state of the item) and return the
> -state to switch it to."
> +switched.  It may also be an alist of `(CURRENT . NEXT)' pairs.

Maybe "`(CURRENT . NEXT)' TODO state pairs"? It will be slightly more
clear.

>  (defcustom org-clock-out-switch-to-state nil
>"Set task to a special todo state after clocking out.
>  The value should be the state to which the entry should be
> -switched.  If the value is a function, it must take one
> -parameter (the current TODO state of the item) and return the
> -state to switch it to."

Same here.

The rest looks good.

If you can, please also add tests.

-- 
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

[tomas]

On Wed, Oct 26, 2022 at 11:16:15PM +0200, Dr. Arne Babenhauserheide wrote:

[...]

> > That is not business of web server, HTTP or browser. Those are
> > delivery, retrieval and presentation tools
> 
> Yet there is so such separation between eww and org-mode.
  

I think this was a typo for "no".

> If you want that separation, you have to open the org-file in a second
> Emacs process.
> 
> If you don’t want that separation, you have to add other precautions.

Agree fully.

And to those saying "...but you do M-x package install, too": it is
much easier to trust a couple of sources (ELPA, the Debian archives,
what have you) than to trust the whole of the Internet (or, to put
it in less confrontative terms, some random web site).

Yes, those few sources can (and ocassionaly do!) go rogue. But trust
is like that.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [BUG][Security] begin_src :var evaluated before the prompt to confirm execution

[Jean Louis]

* Max Nikulin  [2022-10-27 06:21]:
> Expected result:
> No code from the Org buffer and linked files is executed prior to
> confirmation from the user.

Should that be or is it a general policy for Org mode?

> Emacs-26.3, Org version is current main HEAD:
> 
> 6bbd08f5a 2022-10-26 15:15:42 +0800 Ihor Radchenko:
> org-datetree-insert-line: Fix blank line insertion
> 
> I consider such issues as a reason why it is bad idea to use Emacs as a
> handler for Org files downloaded from web. 

I am lost here. Should people then use Vim as handler for Org files? 

In general, browsers use text/html and other content types they
consider safe, while they let to users decide how to handle various
content types.

The core of the problem is that MIME type such as text/x-org shall be
text and nothing else.

It is up to Org developers to understand MIME types and content types.

It is IMHO obligatory for Org developers NOT to advise people using
incorrect MIME type "text/x-org" -- because Org file by default is not
just text, it is combination of application processing data and text.

Here some references:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5

Now what we have at hand is not official MIME type: "text/x-org" which
is by default opened by Emacs text editor, and Emacs does not treat it
exclusively as text, but as combination of application and text.

And that is wrong.

Now is up to developers to understand that combined condition and to
help Emacs to get two distinct Org treatments:

- Org mode as MIME type (Content Type) "text/x-org" which NEVER
  executes any code, but treats Org mode exclusively as text; by
  teaching Emacs not to run or process code in such Org files with
  such content type;

between the condition:

- Org mode as MIME type "application/x-org" which has inside of Org file
  executable functions which Emacs would execute by opening it;

One can provide regular expressions to tools like `file' to recognize
if the Org file is "application/x-org" or just "text/x-org" (remove x-
when MIME type becomes official).

For reference, please see:
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5

Or otherwise -- if the above job cannot be done, then please stop
advertising the content type "text/x-org" -- because Org is not text
in the context of RFC6838:
https://datatracker.ietf.org/doc/html/rfc6838

> Such files should be inspected in some viewer unable to execute
> embedded code at first. A strong reason should be necessary to call
> Emacs for a file from non-trusted source.

See above. It is up to Org developers to decide if Org file is
"application" in MIME sense, or if they wish to keep it truly "text"
in MIME sense or if they wish to make different mode for viewing Org
files and allowing Org files to be application

> To be honest, this is the only real issue I have noticed since
> people on this list tried to convince me 2 years ago that Org is
> quite safe in respect to unsolicited execution of embedded code.

I hope that people will understand that Org is "application" and not
just "plain text" as advertised.

And thanks for pointing it out as it helps in resolving confusions.

-- 
Jean

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

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

Re: [PATCH][oc-csl] Improve reference parsing

[Ihor Radchenko]

András Simonyi  writes:

> the attached patch improves the parsing and exporting of cite
> prefixes, suffixes and locators -- the most noticeable change is
> probably the  support for formatted locators and of underlining in
> general.  Comments are welcome.

Thanks!

> +(defconst org-cite-csl--export-backend
> +  (org-export-create-backend
> +   :transcoders
> +   '((plain-text . (lambda (text _info) text))
> + (bold . (lambda (_bold contents _info) (concat "" contents "")))
> + (italic . (lambda (_italic contents _info) (concat "" contents 
> "")))
> + (underline . (lambda (_underline contents _info)
> + (concat "" contents "")
> +  "Custom backend for exporting citation affixes and locators.")

This will render e.g. strike-through empty.
Note that citation references may contain the following Org markup objects:
'(bold code entity italic
  latex-fragment strike-through subscript
  superscript underline verbatim)

And we may add more, as discussed in
https://orgmode.org/list/87k04xhhw3.fsf@localhost

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

Re: [PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Max Nikulin]

On 26/10/2022 21:53, Samuel W. Flint wrote:

* lisp/org-clock.el (org-clock-in-switch-to-state,
org-clock-out-switch-to-state): Allow
`org-clock-{in,out}-switch-to-state` to be an alist of
current/next-state pairs.


Samuel, please, consider using --in-reply-to and perhaps --thread 
options of git format-patch while preparing messages. It should help 
mail user agents to group all versions of your patches.

[PATCH] org-manual: Suggest to wait for one month and followup when reporting bugs (was: org-datetree-insert-line and org-blank-before-new-entry)

[Ihor Radchenko]

Richard Walker  writes:

> Thank you so much. (I did wonder if anyone had seen my report.)

Actually, your report did slip through the cracks. I just happened to go
through some old mailing list threads without replies.

I think we can expose our mailing list policy a bit more in the manual.
We generally reply for new mails within 1 month. If it does not happen,
it may be a good idea to followup reminding the maintainers about the
unanswered bug report.

I am attaching tentative patch for manual that details this.
Any objections?

Bastien, WDYT?

>From d8efe969e916f33ea6681046bcb6c72c4e8d0b97 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Thu, 27 Oct 2022 11:57:48 +0800
Subject: [PATCH] org-manual: Detail one month response time in the mailing
 list

* doc/org-manual.org (Feedback): Ask to wait up to one month for the
bug review and followup otherwise.
---
 doc/org-manual.org | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 18a050069..5f6a53f93 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -231,7 +231,8 @@ ** Feedback
 respect the
 [[https://www.gnu.org/philosophy/kind-communication.html][GNU Kind
 Communications Guidelines]] when sending messages on this mailing
-list.
+list.  Please allow up to one month for the response and followup if
+no response is received on the bug report.
 
 #+findex: org-version
 #+findex: org-submit-bug-report
-- 
2.35.1



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

Re: Org 9.6-pre and Bash sessions

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Thank you for investigating, explaining, and also fixing the problem!  I
> pulled the latest 'main' and everything works a bit, it seems.
>
> Then, to avoid walking in circles, I decided to write some tests, for I
> think shell blocks should never, never, never break in such basic ways,
> let alone in production Emacs.

Thanks!
I will not look much into details of the patch for now. Let's discuss
the general expectations from shell blocks first. You seem to be
missing several things described in the documentation.

> I noticed that the following tests do not pass:
>
> 1. ob-shell/error-output-after-success
>
>We seem to trash error output, such as warnings, on success.  I think
>we should not do this.  Now, on the execution of "echo X &>2", Org
>says "Code block produced no output."  But that does hold true.  The
>block did produce output, just on the other output stream, namely
>error output.

Trashing error output is expected by default.
I suggest you to read through
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html

The default :results argument is output, which implies:

output returns stdout, default

As expected, stdout is empty in your example. ob-shell follows the spec
here.

Another question is if users may want to obtain strerr in some cases. A
new feature like :results stderr might be implemented. Though users can
already do the usual 2>&1 to merge stderr into stdout.

> 2. ob-shell/error-output-after-failure
>
>We seem not to show the exit code in this case.  Why?

Exit code was not shown in the past until my commit
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ab7eff9d9c0968392bd9783d72c56a4023bd10be

I guess that showing the error code unconditionally (when exit code is
non-0) could be an option.

Now done in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d87a496b54b502d98e49f8bd6596e0562be9d105

> 3. ob-shell/exit-codes
>
>Should we add a newline after the exit code message?

Done.

-- 
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:

> This is interesting. For me, syntax highlighting works partially. For
> example, keywords are highlighted, but function names are not. See below.

I confirm the issue with your example.
It is a known problem with indentation-sensitive languages.

The problem is that org-src-font-lock-fontify-block does not strip
indentation from the block. This can be fixed. Although, I planned to
work on this bug together with
https://orgmode.org/list/87ee7c9quk.fsf@localhost.

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

Re: [BUG] cant normally edit tables created with table-insert [9.5.2 (release_9.5.2-25-gaf6f12 @ c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

ELECTRUM BIKES  writes:

> Hi. Tables created in org-mode by inserting manually | works fine, but
> if I use table-insert I can't manipulate table, I get "use C-c `"
> notification in minibuffer when I click  to move to next cell.

"C-c '", not C-c `.

> If I click C-c `, I get "not a table" response. In such tables I can
> only insert text but not use shortcuts and they're generally broken. I
> tried it on emacs -q and it looks it's not my configuration fault,
> same behavior.

Please provide more details on what you have tried.

I tried


+--+--++
|  |  ||
|  |  ||
+--+--++
|  |  |Text editing inside the table   |
|  |  |cell produces reasonably|
|  |  |expected results.-!-|
+--+--++
|  |  ||
|  |  ||
+--+--++

with point at the top left cell, after C-c ', I can  across cells
in the edit buffer.

> Also, there seems to be problem with handling top and bottom borders,
> if I insert
> (for example, 3 column table) +-+-+ at the top or bottom of a working table,
> it breaks to exactly same state as command-inserted tables, so probably
> top and bottom border handling breaks tables (command created tables
> does have this borders).

Sorry, I do not understand what you are referring two. Detailed steps
explaining what text you inserted and what key bindings you pressed
would help a lot.

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

[BUG][Security] begin_src :var evaluated before the prompt to confirm execution

[Max Nikulin]

Hi,

At first I am apologizing. I believed that a dedicated report raising 
this issue was posted to this mailing list by somebody. I can not find 
such message and in my notes the heading is linked to a quite general 
discussion related to source blocks.


Consider the following source block

 >8 
#+begin_src elisp :var a=(message "%s" "pwnd")
  a
#+end_src
 8< 

Open the "*Messages*" buffer (C-h e) and try to evaluate the source 
block (C-c C-c).


Actual result:
"pwnd" message appears in "*Messages*" simultaneously with user prompt 
whether the code should be executed.


Expected result:
No code from the Org buffer and linked files is executed prior to 
confirmation from the user.


Emacs-26.3, Org version is current main HEAD:

6bbd08f5a 2022-10-26 15:15:42 +0800 Ihor Radchenko: 
org-datetree-insert-line: Fix blank line insertion


I consider such issues as a reason why it is bad idea to use Emacs as a 
handler for Org files downloaded from web. Such files should be 
inspected in some viewer unable to execute embedded code at first. A 
strong reason should be necessary to call Emacs for a file from 
non-trusted source.


I never considered this issue as a really urgent one because a user 
should at least hit C-c C-c to activate malicious code. It has similar 
severity as refreshing table cell formulas that would be almost unusable 
if protected by user prompt.


To be honest, this is the only real issue I have noticed since people on 
this list tried to convince me 2 years ago that Org is quite safe in 
respect to unsolicited execution of embedded code.

Re: org-datetree-insert-line and org-blank-before-new-entry

[Richard Walker]

On Wed, 26 Oct 2022 at 18:28, Ihor Radchenko  wrote:
> Richard Walker  writes:
> ...
> > Change (assq 'heading org-blank-before-new-entry)
> > to (org--blank-before-heading-p) here?
>
> You are indeed right.
> Fixed on main now.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6bbd08f5aa81bd0b6b2b2f448a858516f388702a

Thank you so much. (I did wonder if anyone had seen my report.)

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

[Tim Cross]

"Dr. Arne Babenhauserheide"  writes:

> [[PGP Signed Part:Undecided]]
>
> Ihor Radchenko  writes:
>
>> 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.
>
> If that would be part of org-mode, this would be close to a
> safe-org-mode.
>
> An important part in what I wrote about safe-org-mode is that it has to
> ensure that what is shown cannot trick the user into thinking something
> else would get run.
>
> A way to reduce risk would be to introduce a domain-allow-list (or
> prefix-allow-list) in eww for filetypes that could be unsafe, so you
> could for example add "orgmode.org" to your allowlist and for those
> domains org-files would auto-open in org-mode.
>
> Such security risks have a tendency of getting weaponized down the road
> when they really hurt. Like when people didn’t care about npm
> dependencies and had them suddenly deleting their files. And opening in
> the currently used Emacs may give a malicious file access to remote
> files opened via tramp, even if you (by virtue of being careful) require
> a password for the connection to sensitive servers. That way, running
> something in Emacs can be even more dangerous than running it in the
> shell.
>

and people constantly use M-x package-install to install packages
from GNU ELPA, nonGNU ELPA and MELPA, often with this misguided belief
that these packages are being vetted by the security fairies. 

As was seen after the openssl security failures, just because lots of
people use something and just because lots of people may work on and
look at the code, it is no guarantee the code is secure or has no
malicious content. Our systems have become far too complex for such ad
hoc processes providing any assurance. Likewise, as has been shown with
NPM and various browser 'extension stores', packages which were once
trustworthy can easily become owned/developed by new parties with less
ability or are less trustworthy. 

While adding the sorts of controls you outline is not a bad idea, I
think it is far more important to train people to accept that their
system simply is not secure. You should start from the position that
Emacs is not secure. Why? Because it is a large, complex and powerful
piece of software which has no formal security analysis or testing and
is usually augmented with numerous packages of unknown quality from
largely unknown sources. Essentially, Emacs already suffers from all the
same issues identified for systems like node and the NPM ecosystem. 

The only think which is really providing protection for us Emacs users
is that the rewards for compromising Emacs are too low for the effort
required. Similar to why you don't see many viruses on macOS - it isn't
that it is significantly more secure than Windows (these days), but
rather the pool of potential 'targets' and scale of rewards are higher
when you focus on the Windows environment. It is all about return on investment.

Security is a huge challenge for open source. The effort and resources
required to constantly analyse and test projects for security issues is
too high for most medium to large projects. The fact many open source
projects also rely on other open source projects for various libraries
etc also means that in addition to worrying about the security of the
code in a project, the project also has to worry about 'supply chain'
security i.e. ensure the external project dependencies are also secure
and securely managed.

So what do we do? In the famous words of Douglas Adams "Don't Panic!

Rather than worry if some package or change will make Emacs less secure,
assume it already is insecure and then examine how you use it and
consider both the likelihood of being compromised and the impact when
that occurs. This will differ depending on who you are and what you
do. For example, if your a researcher working in a field where your
research has high commercial value or a journalist working in countries
with a poor human rights history and government parties may want to
compromise your sources etc, both the likelihood and consequences could
be high and you may need to take additional measures or modify how you
use emacs (e.g. only use packages you have reviewed and tested and only
update after formal review and testing of updated version, don't use
Emacs for email or web browsing, only run emacs in an isolated locked
down container etc). On the other hand, if your just a keen hobbyist,
the likelihood and consequences of a security breach are both likely low
and you may decide adding additional packages is an acceptable risk.
Even if you decide your risks are low, you may still decide to not use
Emacs for some purposes. For example, you might decide not to use Emacs
for password management or not use Emacs packages which require you to
keep sensitive data (toekns, passwords, API keys etc) using insecure
mechanisms etc. Keep in mind 

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

[indieterminacy]

On 26-10-2022 20:37, Jean Louis wrote:


I do not have special opinion of "publishing Org files" for unknown
people, if such people are not member of the group. That would require
training them to know what is Org mode, and finally why? Emacs is poor
general browser tool.

Greatest benefit of Org files being served and properly parsed by
Emacs by using HTTP is personal and group based. It is not mainly for
public use.

But one could think of it being analogous to Gemini.

https://gemini.circumlunar.space/

Public who does not use Emacs will not be interested in such.

They may download Org files and open it from file system. Same
insecurity exists by downloading them and opening them.



Just typical that Id raise Gemini just as you bring it up yourself (so 
many mails to sift through) :)



Sometimes Org developer and maintainers do not have enough resources
to react to security-related reports. An issue not so dangerous in
the current state becomes really weird if Org mode becomes a default
handler for files fetched from net.


Your interpretation is improper, as you mentioned "default handler for
files fetched from net" -- and I was very specific, for text/x-org
content type that EWW get possibility to invoke org mode on such
files.

Quite logical. Emacs, Org mode and EWW, those shall work together. I
am surprised that it does not.

At least Russian Nginx WWW server supports me as user to configure it
so to serve Org files as text/x-org.

Though personally I have already found buggy solution with Emacs Lisp
modification to eww render function. I must improve it.



It is worth emphasizing that Gemini is conventionally designed to serve 
and receive files in isolation and that browsers are not expected to do 
anything beyond recognising the simple types of lines.


As such ceteris paribus Id like to thing that it should operate to 
minimise threats of vulnerabilities such as spreadsheets being used to 
interact with banking services.


Besides, the size and range of Gemini browsers and clients met with the 
size of these tools - combined with the acutal size of the Gemini 
community (let alone their competence grade) would make it a low 
priority for troublemakers to prioritise.


--
Jonathan McHugh
indieterminacy@libre.brussels

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

[Tim Cross]

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?
>
> 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.

This concern seems to be based on FUD rather than any real or identified
risk.

The risk here is no different to risks associated with opening any org
document from a foreign source e.g. in an ELPA package. Note that org
mode's default configuration wrt code execution is to ask the user for
permission to execute. If the user can run M-x org-mode on eww buffer
containing a text file which is an org file, the same risks apply and
any vulnerability would need to be addressed anyway.

This is also very different to the issues encountered with enrich text
some years back. The problem then was with elisp code embedded in text
properties. It was a bug in how enriched text processed the data. 

However, I think we are probably looking at this problem from the wrong
level. It isn't really about how to get eww to render org files in
org-mode. This issue is really about being able to customize what
function is called to 'render' the data retrieved based on the
content-type header of the content.

Currently, it is fairly straight-forward to define a custom handler
based on the URL, but not based on content-type. Being able to easily
associate a function to handle downloaded content based on the
content-type would be useful. Users could then easily add whatever
functionality they wanted based on what the server told them about the
content type. 

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

[Dr. Arne Babenhauserheide]

Jean Louis  writes:
> Browser like EWW, being able to accept content types, should give to
> user the option to decide if to open PDF file by integrated PDF viewer
> or any external PDF viewer, or to download the file, or to open the
> file by user's customized function, mode or program.

I’m not sure why you keep pressing for this: people agreed that enabling
users to configure that (as long as it’s not the default) is a good
idea. There’s no discussion there.

Your reply was to Max saying that this must not be the default, and that
using "safe" as part of the function name is a bad idea.

> Is there much of difference of opening Org file by using EWW or
> sending link to Org file to be downloaded and THEN opened by Emacs?

There is a difference, yes: A browser only opens inline what is deemed
safe with the session-data. PDFs are only opened with pdf.js (more
restricted compared to a pdf reader). Javascript is heavily restricted
(with good reason).

Opening org-files clicked in eww directly with org-mode is like opening
a spreadsheet with active fields inline in the browser, so a rogue
formula can steal the session of your banking login.

> That is not business of web server, HTTP or browser. Those are
> delivery, retrieval and presentation tools

Yet there is so such separation between eww and org-mode.

If you want that separation, you have to open the org-file in a second
Emacs process.

If you don’t want that separation, you have to add other precautions.

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


signature.asc
Description: PGP signature

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

[indieterminacy]

On 26-10-2022 10:24, Jean Louis wrote:

* Ihor Radchenko  [2022-10-26 09:52]:
Strictly speaking, even eww-mode may run arbitrary code given that 
user

puts something into eww-mode-hook.


eww-mode-hook is a variable defined in ‘eww.el’.

Its value is (org-eww-extend-eww-keymap)

Please help me recognize content type by using eww-mode-hook, so that
I can invoke org mode when there is "text/x-org"

It is very useful to browse my personal notes from my personal WWW
server without invoking external browser.


Consider hacking with regards to the Gemini protocol within Emacs, its 
minimalism may provide the appropriate playground for you to do things 
you expect (it already provides junctures to switch to (or at least 
load) html content with another non Gemini browser.


Im killing a couple of tasks my end so I cant do this for you.

However, it may be worth you experimenting with a Gemini server which 
contains orgmode files.


I expect you should be able to view orgmode files (I guess they would be 
treated as non Gemtext and therefore binary). If you could toggle the 
appropriate mode inside something like emacs-elpher it may work to your 
needs.


--
Jonathan McHugh
indieterminacy@libre.brussels

Re: Request for feedback: ox-linuxmag

[Damien Cassou]

Hi Ihor,

Ihor Radchenko  writes:
> 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.

I'm not really sure what you mean with the last sentence. In my last
commit, I made use of :filter-final-output:

https://github.com/DamienCassou/ox-linuxmag-fr/commit/195f154d5f76f50a94e4bdc95f27c8400e77992d

(please note the new URL of the project reflecting its new name).

As you can see, I didn't change ox-linuxmag-fr-export-to-odt. Do you
suggest some changes there as well?

I took care of all your other feedback. Thank you so much for taking the
time to help me.

Best

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

[PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option

[dziltener]

From: Daniel Ziltener 

* ob-tangle.el, ob-core.el, test-ob-tangle.el, org-manual.org: Add a
"strip-tangle" noweb option to strip the noweb tags when tangling, but
keep and expand them otherwise.
---
 doc/org-manual.org |  6 ++
 lisp/ob-core.el|  6 +++---
 lisp/ob-tangle.el  |  4 +++-
 testing/lisp/test-ob-tangle.el | 27 +++
 4 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 18a050069..cb85f4702 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18993,6 +18993,12 @@ tangled, or exported.
   Expansion of noweb syntax references in the body of the code block
   when tangling.  No expansion when evaluating or exporting.
 
+- =strip-tangle= ::
+
+  Expansion of noweb syntax references in the body of the code block
+  when evaluating or exporting. Removes noweb syntax references
+  when tangling.
+
 - =no-export= ::
 
   Expansion of noweb syntax references in the body of the code block
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 518831ec6..ae77182ef 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2880,9 +2880,9 @@ parameters when merging lists."
   "Check if PARAMS require expansion in CONTEXT.
 CONTEXT may be one of :tangle, :export or :eval."
   (let ((allowed-values (cl-case context
- (:tangle '("yes" "tangle" "no-export" "strip-export"))
- (:eval   '("yes" "no-export" "strip-export" "eval"))
- (:export '("yes")
+ (:tangle '("yes" "tangle" "no-export" "strip-export" 
"strip-tangle"))
+ (:eval   '("yes" "no-export" "strip-export" "eval" 
"strip-tangle"))
+ (:export '("yes" "strip-tangle")
 (cl-some (lambda (v) (member v allowed-values))
 (split-string (or (cdr (assq :noweb params)) "")
 
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2da92efaf..d9d847195 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -536,7 +536,9 @@ non-nil, return the full association list to be used by
 (body
  ;; Run the tangle-body-hook.
   (let ((body (if (org-babel-noweb-p params :tangle)
- (org-babel-expand-noweb-references info)
+  (if (string= "strip-tangle" (cdr (assq :noweb (nth 2 
info
+  (replace-regexp-in-string (org-babel-noweb-wrap) 
"" (nth 1 info))
+   (org-babel-expand-noweb-references info))
(nth 1 info
(with-temp-buffer
  (insert
diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index a0003ee40..455745e5c 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -510,6 +510,33 @@ another block
(org-split-string (buffer-string
  (delete-file file))
 
+(ert-deftest ob-tangle/strip-tangle ()
+  "Test if strip-tangle works correctly when tangling noweb code blocks."
+  (should
+   (equal '("1")
+  (let ((file (make-temp-file "org-tangle-")))
+(unwind-protect
+(progn
+  (org-test-with-temp-text-in-file
+   (format "
+#+name: block1
+#+begin_src elisp
+2
+#+end_src
+
+#+begin_src elisp :noweb strip-tangle :tangle %s
+1<>
+#+end_src
+"
+   file)
+   (let ((org-babel-noweb-error-all-langs nil)
+ (org-babel-noweb-error-langs nil))
+ (org-babel-tangle)))
+  (with-temp-buffer
+(insert-file-contents file)
+(org-split-string (buffer-string
+  (delete-file file))
+
 (ert-deftest ob-tangle/detangle-false-positive ()
   "Test handling of false positive link during detangle."
   (let (buffer)
-- 
2.35.3

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

[Jean Louis]

* Max Nikulin  [2022-10-26 20:10]:
> If you were just requested mapping of Content-Type to some mode in
> eww, perhaps it would pass.

That is exactly what I need, thanks

> You demanded Org mode configured by default.

Hmm, that could be some misunderstanding. I have .mailcap file and I
know I can configure any browser to open any content type how I wish
and want.

My e-mail client Mutt is opening Org files sent by Sacha Chua in org
mode with Emacs. It is my choice as user to skip downloading such
files and inspecting them.

If Mutt supports me, and Iceweasel, to open Org files with Emacs, why
not Emacs's EWW cannot support me to open Org files with Emacs??  

That is completely not logical.

That is what I need and expect from EWW, it is more general and more
useful to let user customize any content type to be opened how user
wish and want.

This is because in Org files I may have links and wish to open
Gnumeric spreadsheet.

For example, if I get text/markdown (or equivalent) it would invoke
Markdown mode, for Org mode, it would invoke Org mode.

> Org have enough means to execute arbitrary code with minimal efforts
> from user side.  E.g. value of table cell may be recalculated.

Those are not issues of EWW, but of Org mode in general. Similarly,
I can open spreadsheets by using Libreoffice or Gnumeric and such
spreadsheets can execute macros, I do not know how "dangerous" it is,
but that is my choice to decide upon it.

Browser like EWW, being able to accept content types, should give to
user the option to decide if to open PDF file by integrated PDF viewer
or any external PDF viewer, or to download the file, or to open the
file by user's customized function, mode or program.

Setting up content types is freedom for users to do what they want
with files. 

The security aspect is in this moment highly hypothetical as victims
are not there. And it is matter of Org mode in general.

Is there much of difference of opening Org file by using EWW or
sending link to Org file to be downloaded and THEN opened by Emacs?

User not knowledgable may execute arbitrary code anyway.

Please do not blame the communication channel and users how some Org
feature is unsafe.

That is Org security issue, and not EWW issue.

HTTP is for delivery of files.

What user does with files is user's choice.

In general any Emacs package offered for download is in general
security risk, and we freely recommend them to each others. It is
quite clear that it is not safe executing software which one does not
understand or cannot decipher.

https://www.gnu.org/software/emacs/manual/html_node/efaq/Security-risks-with-Emacs.html

Me, as user, I am totally free to configure WWW server to serve
something like "application/e-lisp" as content type, and to open that
type with `emacs --batch file.el' if I want. 

"Insecurity" is thus integral part of user's choice.  

As Ihor and others mentioned, then it will be maybe up to user to use
Org safe mode or similar.

That is not business of web server, HTTP or browser. Those are
delivery, retrieval and presentation tools

> Org files originating from non-trusted sources must be carefully
> evaluated before opening them in Emacs.

Same applies to ANY kind of files that may be inherently
insecure. While HTML is considered secure, Javascript less than HTML,
but still contained, there are many many content types that may be
insecure, startin with APK, proprietary sotware, EXE Windows files,
any kind of programming languages, plugins, etc. Warnings are
everywhere. 

Let users decide what is trusted or non trusted source. 

Programmers of free software shall give users freedom.

I have full freedom to download Emacs Lisp packages and execute them
on my computer. That is same. I just want it faster.

And I also want it executed. I find it excellent that I can instruct
web server to serve me Emacs lisp which I can then execute, great. It
may not be your common usage scenario to find any use of it. I do.

There is freedom to configure browser to open packages and install
them right away, without inspecting anything. 

In proprietary software world that is exactly what billion of people
already do, they download and execute proprietary software, there is
plethora of insecurity issues there.

That is up to Org mode to solve.

It is similar to Emacs warning you about local variables. So put some
warnings in Org mode.

But do not blame browser.

Browser is download, presentation and forwarding tool.

In Firefox, Content type that otherwise is not configured in browser,
may be either saved by default or browser may ask user how to open it
by default.

It is users' decision if something is safe to open or not.

I am sure that safe Org mode will solve that issue. 

Instead of speaking hypothetically of insecurities about delivering
Org mode over HTTP, let us look at numerous advantages of it, they are
analogous to WWW HTML files:

- Publish your Org notes on WWW, and use them from anywhere in the
  world, from any 

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

[Jean Louis]

* Andreas Schwab  [2022-10-26 16:58]:
> On Okt 26 2022, Jean Louis wrote:
> 
> > * Andreas Schwab  [2022-10-26 15:48]:
> >> On Okt 26 2022, Jean Louis wrote:
> >> 
> >> > If there is way to extend EWW and Emacs in such way that I can tell
> >> > EWW what to do on certain content type, just as I do with other
> >> > browsers, that would solve the problem.
> >> 
> >> This is what browse-url-handlers is for.
> >
> > Content type is not an URL scheme.
> 
> The predicate can do whatever it needs to determine the handler.

With "predicate" do you mean URI scheme?

browse-url-handlers ⇒ (("gemini:" . elpher-go) ("gopher:"
. elpher-handler-go) ("about:" . hyperscope-about) ("hyperscope:"
. hyperscope-go) ("e2dk://" . amule-handler))

An alist with elements of the form (REGEXP-OR-PREDICATE . HANDLER).
Each REGEXP-OR-PREDICATE is matched against the URL to be opened
in turn and the first match’s HANDLER is invoked with the URL.

Then -- if URL structure would provide content type, it would work.

Otherwise it is not related to my wish. The URI scheme I wish to use
is `https:' and nothing else.

--
Jean

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

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

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

[Max Nikulin]

On 26/10/2022 15:21, Jean Louis wrote:


(defun browse-safe-url (url  arg)




   "Browse URL with b"
   (let ((username "joedoe")) ;; different username than my own
 ;; Insecurity settings for personal DISPLAY only
 (shell-command "xhost +")
 ;; Browse URL with different username
 (async-start-process "sudo" "sudo" nil "su" "-c" "--" username "-c"
 (format "exec iceweasel \"%s\"" url

-^^

Do not name "safe" a function having security vulnerabilities. Leaving 
aside XAuth issues, it allows arbitrary command execution if URL for 
some reason is not properly percent-encoded.


Do you think your reasoning related to security is still convincing?

If you were just requested mapping of Content-Type to some mode in eww, 
perhaps it would pass. You demanded Org mode configured by default. Org 
have enough means to execute arbitrary code with minimal efforts from 
user side. E.g. value of table cell may be recalculated.


Org files originating from non-trusted sources must be carefully 
evaluated before opening them in Emacs.


Sometimes Org developer and maintainers do not have enough resources to 
react to security-related reports. An issue not so dangerous in the 
current state becomes really weird if Org mode becomes a default handler 
for files fetched from net.


You may fight for your right to freely shoot your legs but you must be 
careful enough to not injury people around. Reputation of Emacs may be 
significantly affected by the requested change.


I am strongly against Org mode as a default handler for files downloaded 
from web sites. Eww user option, if implemented, should have prominent 
warning that particular mode may not be ready for such usage and each 
case should be carefully evaluated for security issues.

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

[Fraga, Eric]

On Wednesday, 26 Oct 2022 at 16:31, L.C. Karssen wrote:
> Another happy reMarkable user here. It looks like the upcoming v3.0 of
> the software will allow entering text via the on-screen keyboard.

Interesting.  Thanks for the heads up on this.  Some interesting
updates.

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

Re: Formatting in citation locator

[András Simonyi]

Dear All,

On Tue, 25 Oct 2022 at 13:16, Ihor Radchenko  wrote:
> Maybe file a bug report to citeproc repo?

I've ended up making the necessary changes in citeproc and also posted
a patch here which should enable formatting in locators. Marvin, I'd
appreciate it if you could test it.

best wishes,

András

On Tue, 25 Oct 2022 at 13:16, Ihor Radchenko  wrote:
>
> 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: [PATCH] ox.el: Refactor variable org-html--id-attr-prefix, ox-html.el: Add support for the ID property to org-html--reference

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  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?

Yes, I confirm the FSF record is here.

-- 
 Bastien

[PATCH][oc-csl] Improve reference parsing

[András Simonyi]

Dear All,

the attached patch improves the parsing and exporting of cite
prefixes, suffixes and locators -- the most noticeable change is
probably the  support for formatted locators and of underlining in
general.  Comments are welcome.

best wishes,
András
From 5bec7025f66eb65f13a701dc616aca2440110c1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Wed, 26 Oct 2022 12:15:42 +0200
Subject: [PATCH] oc-csl.el: Improve reference parsing

* lisp/oc-csl.el (org-cite-csl--export-backend): New constant to
provide a trivial export back-end for exporting reference affixes and
locators with the simple html-based markup expected by citeproc.
(org-cite-csl--parse-reference): Do not construct the reference
locator and include it in the result, since citeproc does not make use
of it.  Start the suffix immediately after the locator's ending,
skipping the ending comma if necessary.  Use
`org-cite-csl--export-backend' to export reference affixes and
locators.
---
 lisp/oc-csl.el | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 1ccb74e92..30eac9f1a 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -140,9 +140,10 @@
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-put-property "org-element" (element property value))
 
-(declare-function org-export-data "org-export" (data info))
+(declare-function org-export-data-with-backend "org-export" (data backend info))
 (declare-function org-export-derived-backend-p "org-export" (backend  backends))
 (declare-function org-export-get-footnote-number "org-export" (footnote info  data body-first))
+(declare-function org-export-create-backend "org-export" ( transcoders))
 
 
 ;;; Customization
@@ -310,6 +311,16 @@ If nil then the Chicago author-date style is used as a fallback.")
   "Regexp matching a label in a citation reference suffix.
 Label is in match group 1.")
 
+(defconst org-cite-csl--export-backend
+  (org-export-create-backend
+   :transcoders
+   '((plain-text . (lambda (text _info) text))
+ (bold . (lambda (_bold contents _info) (concat "" contents "")))
+ (italic . (lambda (_italic contents _info) (concat "" contents "")))
+ (underline . (lambda (_underline contents _info)
+		(concat "" contents "")
+  "Custom backend for exporting citation affixes and locators.")
+
 
 ;;; Internal functions
 (defun org-cite-csl--barf-without-citeproc ()
@@ -476,11 +487,10 @@ property in INFO."
 INFO is the export state, as a property list.
 
 The result is a association list.  Keys are: `id', `prefix',`suffix',
-`location', `locator' and `label'."
-  (let (label location-start locator-start location locator prefix suffix)
+`locator' and `label'."
+  (let (label location-start locator-start locator prefix suffix)
 ;; Parse suffix.  Insert it in a temporary buffer to find
-;; different parts: pre-label, label, locator, location (label +
-;; locator), and suffix.
+;; different parts: pre-label, label, locator, and suffix.
 (with-temp-buffer
   (save-excursion
 (insert (org-element-interpret-data
@@ -506,12 +516,15 @@ The result is a association list.  Keys are: `id', `prefix',`suffix',
 (let ((re (rx (or "," (group digit)
   (when (re-search-backward re location-start t)
 (goto-char (or (match-end 1) (match-beginning 0)))
-(setq location (buffer-substring location-start (point)))
-(setq locator (org-trim (buffer-substring locator-start (point
+(setq locator
+  (org-cite-parse-objects
+   (buffer-substring locator-start (point))
+   t))
 ;; Skip comma in suffix.
+(when (= (following-char) ?,) (forward-char))
 (setq suffix
   (org-cite-parse-objects
-   (buffer-substring (match-end 0) (point-max))
+   (buffer-substring (point) (point-max))
t)
   (setq prefix
 (org-cite-concat
@@ -525,18 +538,16 @@ The result is a association list.  Keys are: `id', `prefix',`suffix',
(lambda (data)
  (org-string-nw-p
   (org-trim
-   ;; When Citeproc exports to Org syntax, avoid mix and
-   ;; matching output formats by also generating Org
-   ;; syntax for prefix and suffix.
-   (if (eq 'org (org-cite-csl--output-format info))
-   (org-element-interpret-data data)
- (org-export-data data info)))
+   ;; Export the parsed prefix, suffix, and locator  
+   ;; with a custom backend, which produces the simple
+   ;; html markup expected by citeproc.
+   (org-export-data-with-backend
+data org-cite-csl--export-backend info))
   `((id . 

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

[Samuel W. Flint]

* doc/org-manual.org (Clocking commands): Document operation of
org-clock-{in,out}-switch-to-state.
---
 doc/org-manual.org | 25 +
 1 file changed, 25 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ad584d7a5..95acf9170 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6583,6 +6583,27 @@ about what to do with it.
   C-u C-u)}}} prefixes, force continuous clocking by starting the
   clock when the last clock stopped.
 
+  #+vindex: org-clock-in-switch-to-state
+  The variable ~org-clock-in-switch-to-state~ controls how a current
+  task's TODO state is changed on clock-in.  No change (a ~nil~) is
+  the default.  A specific state may be forced with a string value.
+  Additionally, a function which takes a current state and returns
+  either a new state or ~nil~ for no change may be used.  Finally, an
+  alist may be used to provide a mapping from state to state.
+  Consider the following example, where ~TODO~ becomes ~WORKING~, and
+  ~WAITING~ becomes ~WORKING~ on clock-in.
+
+  #+begin_src emacs-lisp
+  (setf org-clock-in-switch-to-state '(("TODO" . "WORKING")
+   ("WAITING" . "WORKING")))
+  #+end_src
+
+  The
+  ~org-clock-in-next-state~ alist may be utilized by setting it to
+  ~org-clock-in-next-state-function~, or a custom function may be
+  used.  This custom function should take the current state, and
+  return either a new state or ~nil~ to keep the current state.
+
   #+cindex: @samp{CLOCK_MODELINE_TOTAL}, property
   #+cindex: @samp{LAST_REPEAT}, property
   #+vindex: org-clock-mode-line-total
@@ -6618,6 +6639,10 @@ about what to do with it.
   timestamp[fn:: The corresponding in-buffer setting is: =#+STARTUP:
   lognoteclock-out=.].
 
+  #+vindex: org-clock-out-switch-to-state
+  The variable ~org-clock-out-switch-to-state~ may be configured
+  similarly to ~org-clock-in-switch-to-state~.
+  
 - {{{kbd(C-c C-x C-x)}}} (~org-clock-in-last~) ::
 
   #+kindex: C-c C-x C-x
-- 
2.37.0



-- 
Samuel W. Flint
4096R/FA13D704
  (F50D 862B 4F65 5943 A8C2  EF0E 86C9 3E7A FA13 D704)
λs.(s s) λs.(s s)
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

[PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Samuel W. Flint]

* lisp/org-clock.el (org-clock-in-switch-to-state,
org-clock-out-switch-to-state): Allow
`org-clock-{in,out}-switch-to-state` to be an alist of
current/next-state pairs.

(org-clock-in, org-clock-out): Add logic to handle
`org-clock-{in,out}-switch-to-state` as alists.
---
 lisp/org-clock.el | 60 ++-
 1 file changed, 39 insertions(+), 21 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 6332399bb..f5ffb515f 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -148,28 +148,34 @@ out time will be 14:50."
 (defcustom org-clock-in-switch-to-state nil
   "Set task to a special todo state while clocking it.
 The value should be the state to which the entry should be
-switched.  If the value is a function, it must take one
-parameter (the current TODO state of the item) and return the
-state to switch it to."
+switched.  It may also be an alist of `(CURRENT . NEXT)' pairs.
+If the value is a function, it must take one parameter (the
+current TODO state of the item) and return the state to switch it
+to."
   :group 'org-clock
   :group 'org-todo
   :type '(choice
  (const :tag "Don't force a state" nil)
  (string :tag "State")
- (symbol :tag "Function")))
+  (alist :key-value  (string :tag "Current State:")
+ :value-type (string :tag "Next State   :"))
+  (symbol :tag "Function")))
 
 (defcustom org-clock-out-switch-to-state nil
   "Set task to a special todo state after clocking out.
 The value should be the state to which the entry should be
-switched.  If the value is a function, it must take one
-parameter (the current TODO state of the item) and return the
-state to switch it to."
+switched.  It may also be an alist of `(CURRENT . NEXT)' pairs.
+If the value is a function, it must take one parameter (the
+current TODO state of the item) and return the state to switch it
+to."
   :group 'org-clock
   :group 'org-todo
   :type '(choice
  (const :tag "Don't force a state" nil)
  (string :tag "State")
- (symbol :tag "Function")))
+  (alist :key-value  (string :tag "Current State:")
+ :value-type (string :tag "Next State   :"))
+  (symbol :tag "Function")))
 
 (defcustom org-clock-history-length 5
   "Number of clock tasks to remember in history.
@@ -1348,17 +1354,23 @@ the default behavior."
 (run-hooks 'org-clock-in-prepare-hook)
 (org-clock-history-push)
 (setq org-clock-current-task (org-get-heading t t t t))
-(cond ((functionp org-clock-in-switch-to-state)
-   (let ((case-fold-search nil))
- (looking-at org-complex-heading-regexp))
-   (let ((newstate (funcall org-clock-in-switch-to-state
-(match-string 2
- (when newstate (org-todo newstate
+(cond ((listp org-clock-in-switch-to-state)
+(let ((case-fold-search nil))
+  (looking-at org-complex-heading-regexp))
+(when-let ((state-pair (assoc (match-string 2) 
org-clock-in-switch-to-state))
+   (new-state (cdr state-pair)))
+  (org-todo new-state)))
+   ((functionp org-clock-in-switch-to-state)
+   (let ((case-fold-search nil))
+ (looking-at org-complex-heading-regexp))
+   (let ((newstate (funcall org-clock-in-switch-to-state
+(match-string 2
+ (when newstate (org-todo newstate
   ((and org-clock-in-switch-to-state
 (not (looking-at (concat org-outline-regexp "[ \t]*"
-   org-clock-in-switch-to-state
-   "\\>"
-   (org-todo org-clock-in-switch-to-state)))
+ org-clock-in-switch-to-state
+ "\\>"
+   (org-todo org-clock-in-switch-to-state)))
 (setq org-clock-heading (org-clock--mode-line-heading))
 (org-clock-find-position org-clock-in-resume)
 (cond
@@ -1720,6 +1732,12 @@ to, overriding the existing value of 
`org-clock-out-switch-to-state'."
  (org-back-to-heading t)
  (let ((org-clock-out-when-done nil))
(cond
+ ((listp org-clock-out-switch-to-state)
+  (let ((case-fold-search nil))
+(looking-at org-complex-heading-regexp))
+  (when-let ((state-pair (assoc (match-string 2) 
org-clock-out-switch-to-state))
+ (new-state (cdr state-pair)))
+(org-todo new-state)))
 ((functionp org-clock-out-switch-to-state)
  (let ((case-fold-search nil))
(looking-at org-complex-heading-regexp))
@@ -1728,10 

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

[Quiliro Ordóñez]

El 2022-10-26 08:31, L.C. Karssen escribió:
> https://support.remarkable.com/s/article/Software-release-3-0-beta

No remarkable.com or support.remarkable.com web page is viewable without
activating Javascript.

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

[Andreas Schwab]

On Okt 26 2022, Jean Louis wrote:

> * Andreas Schwab  [2022-10-26 15:48]:
>> On Okt 26 2022, Jean Louis wrote:
>> 
>> > If there is way to extend EWW and Emacs in such way that I can tell
>> > EWW what to do on certain content type, just as I do with other
>> > browsers, that would solve the problem.
>> 
>> This is what browse-url-handlers is for.
>
> Content type is not an URL scheme.

The predicate can do whatever it needs to determine the handler.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Jean Louis]

* Rudolf Adamkovič via "Bug reports for GNU Emacs, the Swiss army knife of text 
editors  [2022-10-26 16:10]:
> So, I evaluated
> 
>   (add-to-list 'mailcap-mime-data
>(list "org"
>  (cons 'viewer 'org-mode)
>  (cons 'type "text/x-org")))
> 
> but it did not work.  What the hack!
> 
> To satisfy my curiosity, I decided to look at the source code.

Thank you for understanding!

> TL;DR EWW hard-codes a couple of MIME types.
> 
> You could improve the situation in various ways.
> 
> For example, you could
> 
> (1) patch EWW to expose the eww-content-type for the user to use, or
> (2) patch EWW to look up MIME for not just the PDF.

Thank you for understanding. You have given me pointers what to do, my
personal case is closed, though I am not the one who knows how to
properly patch it, and I do not see yet that there is consensus, as
few people did not understand about user preferences and rather speak
how EWW should even take care of security issues for user instead of
giving user freedom.

I have done following to make it work personally:

(defvar eww-content-type nil)
(put 'eww-content-type 'permanent-local t)
;;; in eww-render I put:
;;; (setq eww-content-type content-type)

(defun rcd-eww-content-type ()
  (cond ((string-match-p "text/x-org" (car eww-content-type)) (org-mode))
 (t (eww-mode

It is not working best, help me if you know how. I wish normal
eww-mode when it is not org-mode.

(add-hook 'eww-after-render-hook 'rcd-eww-content-type)

And now I can browse Org files from within Emacs.

Video is here:
https://gnu.support/images/gnu-emacs/2022/10/2022-10-26/2022-10-26-16:35:20.ogv


-- 
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

[L.C. Karssen]

On 25-10-2022 15:55, Juan Manuel Macías wrote:

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.


Another happy reMarkable user here. It looks like the upcoming v3.0 of 
the software will allow entering text via the on-screen keyboard. 
Whether that is only for 'regular' notes or also for PDF annotation is 
not yet clear to me (source: 
https://support.remarkable.com/s/article/Software-release-3-0-beta).



Best regards,

Lennart.



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.



--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Re: Org 9.6-pre and Bash sessions

[Rudolf Adamkovič]

Rudolf Adamkovič  writes:

> I pulled the latest 'main' and everything works a bit, it seems.

I meant to say "a bit better" not "a bit". :)

Rudy
-- 
"It is no paradox to say that in our most theoretical moods we may be
nearest to our most practical applications."
-- Alfred North Whitehead, 1861-1947

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

[Jean Louis]

* Andreas Schwab  [2022-10-26 15:48]:
> On Okt 26 2022, Jean Louis wrote:
> 
> > If there is way to extend EWW and Emacs in such way that I can tell
> > EWW what to do on certain content type, just as I do with other
> > browsers, that would solve the problem.
> 
> This is what browse-url-handlers is for.

Content type is not an URL scheme.

Jean

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

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

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

[Stefan Kangas]

Ihor Radchenko  writes:

>> 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.

We seem to be miscommunicating.  In the above, I was merely referring to
whether org-mode is run when visiting some URL or not, which AFAIU is a
binary thing (it either does, or it doesn't).

You seem to be talking about security features in org-mode itself, which
is related, but not the same thing.  I agree that there are various
security features in org-mode.  I still don't think that we should run
org-mode just because some URL requests it.

To reiterate what I said, security problems are hard to audit and
discover.  We shouldn't expose users to additional risks just to add
such a minor convenience feature.  It is not a good trade-off.

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

My concern is not that the users should run their own code, but that
they will inadvertently run (potentially malicious) code provided by
others.

> 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.

Adding a `safe-org-mode' would be an improvement, but orthogonal to
whether or not we should automatically load org-mode when visiting any
URL that presents itself as serving an org file.  I think we should not
do the latter.

> 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.

That would also be an improvement, yes.  It would be even better if such
a variable supported whitelisting, so that users could mark only
specific files as safe for these purposes.

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

[Rudolf Adamkovič]

Jean Louis  writes:

>> This should be trivial to do, I think.

+1 and I say: consider contributing to EWW!

I noticed that the EWW manual says

  PDFs are viewed inline, by default, with doc-view-mode, but this can
  be customized by using the mailcap (see mailcap in Emacs MIME Manual)
  mechanism, in particular mailcap-mime-data.

For some reason, it made me think that EWW uses MIME correctly.

So, I evaluated

  (add-to-list 'mailcap-mime-data
   (list "org"
 (cons 'viewer 'org-mode)
 (cons 'type "text/x-org")))

but it did not work.  What the hack!

To satisfy my curiosity, I decided to look at the source code.

In eww.el, the eww-render procedure parses the content-type header and
stores its value in a local let binding.  After that, it dispatches to
the various "display" procedures EWW comes with, such as

((equal (car content-type) "application/pdf")
(eww-display-pdf))

The eww-display-pdf procedure then looks up the MIME viewer for the
application/pdf MIME type specifically.

If no dispatch fits, EWW ends up calling eww-display-raw.

TL;DR EWW hard-codes a couple of MIME types.

You could improve the situation in various ways.

For example, you could

(1) patch EWW to expose the eww-content-type for the user to use, or
(2) patch EWW to look up MIME for not just the PDF.

You could hack something local to you as well, but a patch would make
EWW better for all of us.  So, win-win!

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

[Andreas Schwab]

On Okt 26 2022, Jean Louis wrote:

> If there is way to extend EWW and Emacs in such way that I can tell
> EWW what to do on certain content type, just as I do with other
> browsers, that would solve the problem.

This is what browse-url-handlers is for.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Jean Louis]

* Dr. Arne Babenhauserheide  [2022-10-26 14:58]:
> I may have misunderstood what you want.
> 
> Do you want eww to open text/x-org files in org-mode by default, or do
> you search for a way how you can modify your local eww to open
> text/x-org files with org-mode?
> 
> My worries apply to the first, not to the second (there users know what
> they get into).

If there is way to extend EWW and Emacs in such way that I can tell
EWW what to do on certain content type, just as I do with other
browsers, that would solve the problem.

Then I can say, please EWW, open "text/x-org" content type with
org-mode.

-- 
Jean

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

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

[BUG] cant normally edit tables created with table-insert [9.5.2 (release_9.5.2-25-gaf6f12 @ c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/org/)]

[ELECTRUM BIKES]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report? See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Hi. Tables created in org-mode by inserting manually | works fine, but
if I use table-insert I can't manipulate table, I get "use C-c `"
notification in minibuffer when I click  to move to next cell. If I
click C-c `, I get "not a table" response. In such tables I can only insert
text but not use shortcuts and they're generally broken. I tried it on
emacs -q and it looks it's not my configuration fault, same behavior.
Also, there seems to be problem with handling top and bottom borders, if 
I insert

(for example, 3 column table) +-+-+ at the top or bottom of a working table,
it breaks to exactly same state as command-inserted tables, so probably
top and bottom border handling breaks tables (command created tables
does have this borders).

Emacs  : GNU Emacs 28.1 (build 52, x86_64-w64-mingw32)
 of 2022-04-04
Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ c:/Program 
Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/org/)

Re: Org 9.6-pre and Bash sessions

[Rudolf Adamkovič]

Ihor,

Thank you for investigating, explaining, and also fixing the problem!  I
pulled the latest 'main' and everything works a bit, it seems.

Then, to avoid walking in circles, I decided to write some tests, for I
think shell blocks should never, never, never break in such basic ways,
let alone in production Emacs.

Please, see the WIP patch attached to this message.

I noticed that the following tests do not pass:

1. ob-shell/error-output-after-success

   We seem to trash error output, such as warnings, on success.  I think
   we should not do this.  Now, on the execution of "echo X &>2", Org
   says "Code block produced no output."  But that does hold true.  The
   block did produce output, just on the other output stream, namely
   error output.

2. ob-shell/error-output-after-failure

   We seem not to show the exit code in this case.  Why?

3. ob-shell/exit-codes

   Should we add a newline after the exit code message?

Rudy

>From 90432170552a6e922d48d51138b2062aa11e5575 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Wed, 26 Oct 2022 13:35:26 +0200
Subject: [PATCH] WIP test-ob-shell: Add tests for some recent changes

---
 testing/lisp/test-ob-shell.el | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/testing/lisp/test-ob-shell.el b/testing/lisp/test-ob-shell.el
index 4c00faa49..8cd967343 100644
--- a/testing/lisp/test-ob-shell.el
+++ b/testing/lisp/test-ob-shell.el
@@ -170,6 +170,66 @@ ob-comint.el, which was not previously tested."
 	  "#+BEGIN_SRC sh :results table\necho 'I \"want\" it all'\n#+END_SRC"
 	(org-babel-execute-src-block)
 
+;;; Standard output
+
+(ert-deftest ob-shell/standard-output-after-failure ()
+  "Test standard output after exiting with a non-zero code."
+  (should (= 1
+ (org-babel-execute:sh
+  "echo 1; exit 2" nil
+
+;;; Error output
+
+(ert-deftest ob-shell/error-output-after-success ()
+  "Test that error output shows in the error buffer after exiting
+with a zero code."
+  (should
+   (string= "1
+[ Babel evaluation exited with code 2 ]"
+(progn (org-babel-eval-wipe-error-buffer)
+   (org-babel-execute:sh
+"echo 1 >&2" nil)
+   (with-current-buffer org-babel-error-buffer-name
+ (buffer-string))
+
+(ert-deftest ob-shell/error-output-after-failure ()
+  "Test that error output shows in the error buffer, alongside the
+exit code, after exiting with a non-zero code."
+  (should
+   (string= "1
+[ Babel evaluation exited with code 2 ]"
+(progn (org-babel-eval-wipe-error-buffer)
+   (org-babel-execute:sh
+"echo 1 >&2; exit 2" nil)
+   (with-current-buffer org-babel-error-buffer-name
+ (buffer-string))
+
+;;; Exit codes
+
+(ert-deftest ob-shell/exit-code ()
+  "Test that the exit code shows in the error buffer after exiting
+with a non-zero return code."
+  (should
+   (string= "[ Babel evaluation exited with code 1 ]"
+(progn (org-babel-eval-wipe-error-buffer)
+   (org-babel-execute:sh
+"exit 1" nil)
+   (with-current-buffer org-babel-error-buffer-name
+ (buffer-string))
+
+(ert-deftest ob-shell/exit-codes ()
+  "Test that multiple exit codes show in the error buffer after
+exiting with a non-zero return code more than once."
+  (should
+   (string= "[ Babel evaluation exited with code 1 ]
+[ Babel evaluation exited with code 2 ]"
+(progn (org-babel-eval-wipe-error-buffer)
+   (org-babel-execute:sh
+"exit 1" nil)
+   (org-babel-execute:sh
+"exit 2" nil)
+   (with-current-buffer org-babel-error-buffer-name
+ (buffer-string))
 
 (provide 'test-ob-shell)
 
-- 
2.38.1

-- 
"One can begin to reason only when a clear picture has been formed in
the imagination."
-- Walter Warwick Sawyer, Mathematician's Delight, 1943

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> 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.

If that would be part of org-mode, this would be close to a
safe-org-mode.

An important part in what I wrote about safe-org-mode is that it has to
ensure that what is shown cannot trick the user into thinking something
else would get run.

A way to reduce risk would be to introduce a domain-allow-list (or
prefix-allow-list) in eww for filetypes that could be unsafe, so you
could for example add "orgmode.org" to your allowlist and for those
domains org-files would auto-open in org-mode.

Such security risks have a tendency of getting weaponized down the road
when they really hurt. Like when people didn’t care about npm
dependencies and had them suddenly deleting their files. And opening in
the currently used Emacs may give a malicious file access to remote
files opened via tramp, even if you (by virtue of being careful) require
a password for the connection to sensitive servers. That way, running
something in Emacs can be even more dangerous than running it in the
shell.

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

[Dr. Arne Babenhauserheide]

Jean Louis  writes:

>> 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.
>
> Thanks, though, that was not my request.
>
> Please note that you miss very important issue, and that is that all
> browsers support customization on how to open specific content types,
> so it is quite trivial to customize in browser to open Common Lisp
> program with Common Lisp. 

I may have misunderstood what you want.

Do you want eww to open text/x-org files in org-mode by default, or do
you search for a way how you can modify your local eww to open
text/x-org files with org-mode?

My worries apply to the first, not to the second (there users know what
they get into).

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


signature.asc
Description: PGP signature

Re: Org babel and Guile/Scheme: noise from... Geiser?

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Can someone with scheme installed try to reproduce on the latest main?

With

- GNU Emacs 29 (Git 55eabe96c9)
- Org 9.6-pre (Git 2f5e7103e)
- Geiser 20221016.2109
- Geiser Guile 20220922.52

given

#+name: mklst/define
#+begin_src scheme
  (define-syntax mklst
(lambda (s)
  (syntax-case s ()
((_ e ...) #'(list e ...)
#+end_src

#+name: mklst/test/0
#+begin_src scheme :noweb yes :results drawer output
  <>
  (format #t "~S\n" (mklst 'a 22 "foo"))
#+end_src

I get

#+RESULTS: mklst/test/0
:results:
(a 22 "foo")
:end:

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Tikz ugly hack

[Fraga, Eric]

On Wednesday, 26 Oct 2022 at 08:52, edgar wrote:
> I just want to share a way to combine Tikz (LaTeX) with figures (svg,
> png...).

I wonder if, instead of a new LaTeX command you create a new environment
which you can then invoke using org special blocks?  For instance,

#+begin_BoundingBox

#+attr_latex: :height 1cm
[[image file]]

#+end_BoundingBox

where you have

#+latex_header: \newenvironment{BoundingBox}{
#+latex_header: % commands before the body of the environment
#+latex_header: \begin{tikzpicture}
#+latex_header: }
#+latex_header: {
#+latex_header: % command after the body of the environment
#+latex_header: \end{tikzpicture}
#+latex_header: }

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

Re: Org Haskell code blocks

[Dominik Schrempf]

Ihor Radchenko  writes:

> 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.
>
> [2. image/png; haskell-fontification.png]...

This is interesting. For me, syntax highlighting works partially. For
example, keywords are highlighted, but function names are not. See below.

Tikz ugly hack

[edgar]

Dear Org users,

I just want to share a way to combine Tikz (LaTeX) with figures (svg, 
png...). This may be needed to add elements (e.g. annotations) to your 
figure. The figure may still be exported with other back-ends (without 
annotations). If you know of a better way of doing this, please, let me 
know. Thanks.


#+latex_header: \usepackage{adjustbox,tikz}
#+latex_header: \newcommand*{\DrawGrid}{\draw[step=.2cm,help lines] 
(current bounding box.south west) grid (current bounding box.north 
east);}
#+latex_header: \newcommand*{\DrawBoundingBox}[2]{% 
https://tex.stackexchange.com/a/542819

#+latex_header: \draw [red, very thick, rounded corners]
#+latex_header: ([shift={(#1)}]current bounding box.south west)
#+latex_header: rectangle
#+latex_header: ([shift={(#2)}]current bounding box.north east);}
#+begin_export latex
\begin{tikzpicture}
  % left bottom right top
  \node {\adjustbox{height=0.7\textheight,trim=45.6mm 0mm 155mm 20mm, 
clip=true}{

#+end_export
  #+attr_latex: :height "" :width "" :options "" :center nil
  [[file:../diagram.svg]]
#+begin_export latex
  }};
  \DrawBoundingBox{5.7cm,0.71cm}{-0.1cm,-3.6cm}
  % \DrawGrid
\end{tikzpicture}
#+end_export

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

[Max Nikulin]

On 26/10/2022 15:07, Samuel Wales wrote:


can dunst go away after a short period?


I have never tried it. Unsure if it has enough configuration options.

Does it mean that you get notification displayed? Have you tried?

notify-send --expire-time 2000 ...


i launch dbus manually as fluxbox is not a dm
eval $(dbus-launch --sh-syntax --exit-with-session)


I believe, notification daemon should be running is addition to d-bus 
daemon. Notification daemon just register an additional interfaces on 
d-bus and responsible for notification windows.



unfamiliar with notifications.el. if recommended i can look into it.


I am unsure what is more convenient in your case to avoid shell 
commands, org-notify from org-clock.el or functions from notifications.el

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

[Jean Louis]

* Ag Ibragimov  [2022-10-26 01:13]:
> 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.

I need to inspect content type. Not extension.

My WWW file may be of HTML content type, while ending with .org, that
is not the way: https://www.example.com/my.file.org could have
text/html content type. 

Using extension on WWW is incorrect.

-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko  [2022-10-26 09:52]:
> Strictly speaking, even eww-mode may run arbitrary code given that user
> puts something into eww-mode-hook.

eww-mode-hook is a variable defined in ‘eww.el’.

Its value is (org-eww-extend-eww-keymap)

Please help me recognize content type by using eww-mode-hook, so that
I can invoke org mode when there is "text/x-org"

It is very useful to browse my personal notes from my personal WWW
server without invoking external browser.

-- 
Jean

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

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

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

[Jean Louis]

* Stefan Kangas  [2022-10-26 09:08]:
> 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.

See my previous e-mail to Arne and explanation that in almost any
browser, it is user's choice on how to open various content types.

It implies, there are numerous risks involved, and users customizing
their browsers have responsibility for their computing.

Does user need group of people to dictate what is safe and what is not
safe? That is contrary to free software principles, let users decide
how they wish to open their files.

I maybe have Common Lisp on my server and wish to open it with SBLC on
my computer. That is my choice.

Let me have that choice in EWW, which is native to Emacs for Org mode,
which is native to Emacs. It is natural.

Note that I can open Org files with other browser. But I wish to
browse my Org notes directly from within Emacs , and not just invoke
external browser, which in turn invokes again `emacsclient'. That
works well already. I hope you understand it.

> Which Org features, currently existing or introduced in the
> future, would EWW have to add workarounds for?

Only to recognize content type text/x-org and invoke Org mode. And let
users decide if to invoke org mode on content type "text/x-org".

I am even now convinced that I should be able to customize how to open
various content types, but I do not get it.

I was thinking eww will recognize at least mailcap file, as in email
client I open Org files without problems.

I see in eww.el that there is function `mailcap-view-mime' but I do
not see it is used to recognize my mailcap file where I have this
line:

text/x-org; edit %s; nametemplate=%s.org;

my "edit" script invokes emacsclient

> 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.

There is no need to disable anything by default please, leave that to
user choice.

I can open ALL kinds of files from WWW servers and decide how to open
them.  That was since beginning of Internet user's choice. It is not
up to browser to tell me I should not open specific content type, or
for browser to disable how I view or use the file.

- EWW is browser

- it shall recognize content-type

- it shall then invoke ANY application by users' choice for that
  content-type

Maybe I wish to open text/x-org with mousepad editor, so let me do
that. Maybe I wish to invoke different Emacs instance, let me do
that. If I wish to isolate the Emacs instance I can isolate it
without problems, but that shall be my users' choice.

Sample method of isolation of browser on single computer:

(defun browse-safe-url (url  arg)
  "Browse URL with b"
  (let ((username "joedoe")) ;; different username than my own
;; Insecurity settings for personal DISPLAY only
(shell-command "xhost +")
;; Browse URL with different username
(async-start-process "sudo" "sudo" nil "su" "-c" "--" username "-c"
 (format "exec iceweasel \"%s\"" url

> Adding this opens a can of worms that will expose unsuspecting users to
> a whole class of new problems.

It does not.

Review well customization of content types on various browsers, it
existed since beginning of WWW.

Browser is not for HTML only, there are many content types. 

> And the only benefit is to sapve some users from having to type "M-x
> org-mode RET", or adding call to a suitable hook.

It is not only benefit. Every browser shall give option to users to
decide how to open any content type.

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

What if I want to open Gnumeric spreadsheet with eww? You do not want
to add that feature?

Help me open Gnumeric spreadsheet by using eww and its content type by
customization, and I will not ask you to open Org by eww, because at
that point of time I will be able to customize how to open Org content
type myself.

-- 
Jean

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

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

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

[Samuel Wales]

i called notify-send from the cli in emacs shell mode running bash,
with emacs maximized as most of my apps are.

in fluxbox terminology at least, maximized means takes up the whole
screen.  fullscreen would mean occupies the top.

no text result and no gui result from notify-send.

can dunst go away after a short period?

i launch dbus manually as fluxbox is not a dm
eval $(dbus-launch --sh-syntax --exit-with-session)

for context, with org-capture firefox says captured briefly but that
is no guarantee back from emacs which is why we are seeking
confirmation; i used to think it meant that it was captured but when
broken it id not capture.

unfamiliar with notifications.el. if recommended i can look into it.
plauing a sound would irritate me.

On 10/26/22, Max Nikulin  wrote:
> On 26/10/2022 13:22, Samuel Wales wrote:
>> 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.
>
> Does notify-send complain (with some delay) concerning timeout during
> attempt to connect to d-bus?
>
> I have found an Eric's message recommending dunst as a notification
> daemon for fluxbox.
>
> Firefox has a fallback implementation to display notifications in the
> case of d-bus failure, so it is not the best app to test their appearance.
>
> Fluxbox released versions (e.g. from Debian and Ubuntu packages) has a
> bug that may cause some applications, in particular Firefox, to be
> displayed above other windows. So it may hide a notification window.
> However if you have a terminal application in front of you, it should
> not be your case.
>
> I am unsure if functions from notifications.el are better than
> notify-send in respect to error reporting.
>
> Have you considered playing a tune as a notification?
>
>
>
>
>


-- 
The Kafka Pandemic

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

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

[Jean Louis]

Forgot this attached file, so you can see how easy it is to customize
Iceweasel to open Org files, it works well.

Org files are native to Emacs, I wish to open Org files by using EWW.


-- 
Jean

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

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


signature.asc
Description: PGP signature

Re: [BUG] Emacs tries to recenter / rescroll when it hits hidden org emphasis [9.4.6 (9.4.6-798-g738759.dirty-elpaplus @ .emacs.d/elpa/develop/org-plus-contrib-20210929/)]

[Ihor Radchenko]

Chris Findeisen  writes:

> To reproduce this:
> 1. Load the repro emacs settings.
> 2. Scroll down in a buffer, such that top of buffer is not visible on
> screen.
> 3. Create an emphasized word at the beginning of the 2nd visual-line in a
> visually-wrapped line.
> 4. Move your point to the start of that emphasized word
>
> It's a little difficult to describe, so I'll give an example. Assume
> that the visual-line wrapping is happening at the place indicated by
> "$".

Sorry for the late reply.
I can reproduce. However, it does not look like the issue is Org
mode-related.

I have forwarded this bug report to Emacs bug tracker.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58793

-- 
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

[Jean Louis]

* Dr. Arne Babenhauserheide  [2022-10-26 01:02]:
> All of the Emacs packages have some amount of implicit trust.

Users are unaware what package may do, and packages are everywhere on
Internet. That is not a problem that I wish to solve.

> 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.

Thanks, though, that was not my request.

Please note that you miss very important issue, and that is that all
browsers support customization on how to open specific content types,
so it is quite trivial to customize in browser to open Common Lisp
program with Common Lisp. 

Thus all of browsers who allow content type customization are
analogous to problem you are presenting, which in fact is no practical
problem at all. 

Find the victim first, then present the problem.

To understand is that content type opening is generally not secure and
that it is user choice.

I am user of Org mode, and all I wish is to adapt eww to invoke
command "org-mode" once content type text/x-org has been recognized.

This way I can browse Org files directly, it is very useful for me as
I have bunch of files.

> 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.

Well then 

> 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.

See above, all other content types and URL links may be customized by
user to be opened how users want it. 

Your security presentation lacks the background knowledge.

See the attached screenshot how easy it was to customize IceWeasel or
Firefox derivate to open Org files by using Emacs client. I have
script called "edit" which invoces emacsclient.

-- 
Jean

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

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

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

[Max Nikulin]

On 26/10/2022 13:22, Samuel Wales wrote:

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.


Does notify-send complain (with some delay) concerning timeout during 
attempt to connect to d-bus?


I have found an Eric's message recommending dunst as a notification 
daemon for fluxbox.


Firefox has a fallback implementation to display notifications in the 
case of d-bus failure, so it is not the best app to test their appearance.


Fluxbox released versions (e.g. from Debian and Ubuntu packages) has a 
bug that may cause some applications, in particular Firefox, to be 
displayed above other windows. So it may hide a notification window. 
However if you have a terminal application in front of you, it should 
not be your case.


I am unsure if functions from notifications.el are better than 
notify-send in respect to error reporting.


Have you considered playing a tune as a notification?

Re: when exporting to odt or html, latex equations are not exported when in soure block: BUG?

[Ihor Radchenko]

Uwe Brauer  writes:

> Hi 
>
> I run a relative recent GNU Emacs and org master, however please
> consider the following example:
>
> When exporting to html or odt (using dvipng in both cases) the first set
> of equations in the source block are ignored.
>
> Can somebody please confirm this, and tell me whether I should open a
> BUG report.
> ...
> * A source block provides to export latex equations
> #+begin_src latex :results latex replace :exports results :eval t

Of course, the source block is ignored.
According to 16.6 Results of Evaluation section of the manual,

‘latex’
 Results enclosed in a ‘BEGIN_EXPORT latex’ block.  Usage example:
 ‘:results value latex’.

So, you are exporting results of the evaluation, which is latex export
block. Such block will only get exported to latex. By definition.

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

Re: Where does CDATA come from?

[Ihor Radchenko]

Diego Rodriguez  writes:

> Hello,
>
> I am customizing my org-mode installation but there is something that I
> don't understand.
>
> When I execute the following statement:
>
> ```
> (setq org-html-mathjax-template
>
> "
> 

Re: ob-clojure eval error when has comment at end of code line

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> I have following Clojure source block:
>
> #+begin_src clojure
> (re-find #"\d+" "I've just finished reading Fahrenheit 451");; => "451"
> (re-find #"Bees" "Beads aren't cheap.");; => nil
> #+end_src
>
> When I press =[C-c C-c]= to evaluate source block, got error:
>
> When there is no comments behind code lines. No this error.
>
> #+begin_example
> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>   replace-regexp-in-string("nil" "" nil)

Daniel, could you please take a look?

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

Re: org-datetree-insert-line and org-blank-before-new-entry

[Ihor Radchenko]

Richard Walker  writes:

> A follow-up to the changes made to org-datetree-insert-line
> in September 2020.
>
> The definition now begins:
>
> (defun org-datetree-insert-line (year  month day text)
>   (delete-region (save-excursion (skip-chars-backward " \t\n") (point)) 
> (point))
>   (when (assq 'heading org-blank-before-new-entry)
> (insert "\n"))
> ...
>
> ...
> (setf org-blank-before-new-entry '((heading . nil) (plain-list-item . nil)))
>
> Such a setting seems to be consistent with the help text of
> org-blank-before-new-entry, and what org--blank-before-heading-p
> expects to find. But, having made this setting,
>   (when (assq 'heading org-blank-before-new-entry)
> (insert "\n"))
> still does the insertion, since (assq 'heading org-blank-before-new-entry)
> is non-nil.
>
> Change (assq 'heading org-blank-before-new-entry)
> to (org--blank-before-heading-p) here?

You are indeed right.
Fixed on main now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6bbd08f5aa81bd0b6b2b2f448a858516f388702a

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

Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> I bellowing example:
>
> #+begin_src org
> ,#+NAME: ob-clojure-table-test
> | a | b | c |
> |---+---+---|
> | 1 | 2 | 3 |
>
> ,#+NAME: ob-clojure-table-test-2
> | a | b | c |
> |---+---+---|
> | 1 | 2 | 3 |
>
> ,#+begin_src clojure :var kk=ob-clojure-table-test :var 
> kk2=ob-clojure-table-test-2 :results output
> (println kk2)
> (println kk)
> ,#+end_src
>
> #+end_src
>
> Without this patch, it will report error "class java.lang.ClassCastException" 
> from CIDER.

Bastien, could you please take a look? I was unable to setup clojure dev
environment on my machine for testing. So, I am not able to confirm if
the issue exists.

>;; Variables binding.
>(if (null vars) (org-trim body)
> -(format "(let [%s]\n%s)"
> -(mapconcat
> - (lambda (var)
> -   (format "%S %S" (car var) (cdr var)))
> - vars
> - "\n  ")
> -body))
> +   ;; variable's value is a list from org-mode passed table 
> or list.
> +(if (listp (cdr (car vars)))

This test is fishy. It only tests for the first variable assignment.
What if you have multiple vars some being tables and some not?

-- 
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 

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#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

[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: [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: 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!

[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

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: 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.