* Maxim Nikulin [2020-11-27 19:51]:
> 2020-11-11 Jean Louis wrote:
> >
> > Do you know how to disable control sequences?
>
> It is neither directly related to `cat -v` nor specific to org, but still a
> notable demonstration that inaccurate treatment of text to be inserted into
> a terminal
2020-11-11 Jean Louis wrote:
Do you know how to disable control sequences?
It is neither directly related to `cat -v` nor specific to org, but
still a notable demonstration that inaccurate treatment of text to be
inserted into a terminal could do some dangerous things due to hidden
control
Jean Louis,
> Like alias cat='sequence off; cat' something like that
>
> Somebody already mentioned there is cat -v to show nonprinting
> characters with notation ^- and M- so that may be the solution and I
> may be wrong there.
yes, 'cat -v' will do it for you. (or, i'd like to know if i've
* Maxim Nikulin [2020-11-11 20:17]:
> 2020-11-11 Jean Louis wrote:
> > * Maxim Nikulin [2020-11-10 19:31]:
> > > 2020-11-10 Greg Minshall wrote:
> > > >
> > > > i would guess
> > > > using 'cat -v' to read e-mail is 100% safe. even throwing in
> > > > uudecode(1), or whatever is needed to
2020-11-11 Jean Louis wrote:
* Maxim Nikulin [2020-11-10 19:31]:
2020-11-10 Greg Minshall wrote:
i would guess
using 'cat -v' to read e-mail is 100% safe. even throwing in
uudecode(1), or whatever is needed to decode base64, (and then piping
through 'cat -v', of course ), it's probably still
Jean Louis writes:
> * Tim Cross [2020-11-11 01:30]:
>>
>> Jean Louis writes:
>>
>> > * Maxim Nikulin [2020-11-10 19:31]:
>> >> 2020-11-10 Greg Minshall wrote:
>> >> >
>> >> > i would guess
>> >> > using 'cat -v' to read e-mail is 100% safe. even throwing in
>> >> > uudecode(1), or
* Tim Cross [2020-11-11 01:30]:
>
> Jean Louis writes:
>
> > * Maxim Nikulin [2020-11-10 19:31]:
> >> 2020-11-10 Greg Minshall wrote:
> >> >
> >> > i would guess
> >> > using 'cat -v' to read e-mail is 100% safe. even throwing in
> >> > uudecode(1), or whatever is needed to decode base64,
Maxim,
thanks. small note.
> The sour story is that it is unsafe to feed non-trusted files directly
> to terminal. A filter against control sequences is required.
thus, the '-v' argument to cat(1) (which Rob Pike famously considered
harmful. :)
cheers.
Tom Gillespie writes:
> This is a great sub-thread that should probably be its own top level
> thread on org security.
>
> Org files are mostly benign unless the user does something extremely
> dangerous like
> setting enable-local-eval t. However, there are some areas where
> arbitrary code
This is a great sub-thread that should probably be its own top level
thread on org security.
Org files are mostly benign unless the user does something extremely
dangerous like
setting enable-local-eval t. However, there are some areas where
arbitrary code can be
executed (as intended) that some
Jean Louis writes:
> * Maxim Nikulin [2020-11-10 19:31]:
>> 2020-11-10 Greg Minshall wrote:
>> >
>> > i would guess
>> > using 'cat -v' to read e-mail is 100% safe. even throwing in
>> > uudecode(1), or whatever is needed to decode base64, (and then piping
>> > through 'cat -v', of course ),
* Maxim Nikulin [2020-11-10 19:22]:
> > * Maxim Nikulin [2020-11-09 17:06]:
> > > 2020-11-08 Jean Louis wrote:
> > > > That is right, I am using it since years in ~/.mailcap that works well
> > > > for mutt email client.
> > > >
> > > > text/org; emacsclient %s; nametemplate=%s.org;
> > >
* Maxim Nikulin [2020-11-10 19:31]:
> 2020-11-10 Greg Minshall wrote:
> >
> > i would guess
> > using 'cat -v' to read e-mail is 100% safe. even throwing in
> > uudecode(1), or whatever is needed to decode base64, (and then piping
> > through 'cat -v', of course ), it's probably still safe.
>
2020-11-10 Greg Minshall wrote:
i would guess
using 'cat -v' to read e-mail is 100% safe. even throwing in
uudecode(1), or whatever is needed to decode base64, (and then piping
through 'cat -v', of course ), it's probably still safe.
Please, check that you have at least updated tmux before
* Maxim Nikulin [2020-11-09 17:06]:
2020-11-08 Jean Louis wrote:
That is right, I am using it since years in ~/.mailcap that works well
for mutt email client.
text/org; emacsclient %s; nametemplate=%s.org;
text/x-org; emacsclient %s; nametemplate=%s.org;
Just for curiosity,
:)
* Tim Cross [2020-11-10 00:50]:
>
> Maxim Nikulin writes:
>
> > 2020-11-08 Jean Louis wrote:
> >> That is right, I am using it since years in ~/.mailcap that works well
> >> for mutt email client.
> >>
> >> text/org; emacsclient %s; nametemplate=%s.org;
> >> text/x-org;emacsclient %s;
Greg Minshall writes:
> Tim,
>
>> No email can be considered 100% safe.
>
> "e-mail doesn't kill people; e-mail readers kill people". i would guess
> using 'cat -v' to read e-mail is 100% safe. even throwing in
> uudecode(1), or whatever is needed to decode base64, (and then piping
> through
Tim,
> No email can be considered 100% safe.
"e-mail doesn't kill people; e-mail readers kill people". i would guess
using 'cat -v' to read e-mail is 100% safe. even throwing in
uudecode(1), or whatever is needed to decode base64, (and then piping
through 'cat -v', of course ), it's probably
Maxim Nikulin writes:
> 2020-11-08 Jean Louis wrote:
>> That is right, I am using it since years in ~/.mailcap that works well
>> for mutt email client.
>>
>> text/org;emacsclient %s; nametemplate=%s.org;
>> text/x-org; emacsclient %s; nametemplate=%s.org;
>
> Just for curiosity, couldn't
* Maxim Nikulin [2020-11-09 17:06]:
> 2020-11-08 Jean Louis wrote:
> > That is right, I am using it since years in ~/.mailcap that works well
> > for mutt email client.
> >
> > text/org; emacsclient %s; nametemplate=%s.org;
> > text/x-org; emacsclient %s; nametemplate=%s.org;
>
> Just for
On 09/11/2020 15:04, Maxim Nikulin wrote:
> 2020-11-08 Jean Louis wrote:
>> That is right, I am using it since years in ~/.mailcap that works well
>> for mutt email client.
>>
>> text/org;emacsclient %s; nametemplate=%s.org;
>> text/x-org; emacsclient %s; nametemplate=%s.org;
>
> Just for
2020-11-08 Jean Louis wrote:
That is right, I am using it since years in ~/.mailcap that works well
for mutt email client.
text/org; emacsclient %s; nametemplate=%s.org;
text/x-org; emacsclient %s; nametemplate=%s.org;
Just for curiosity, couldn't it lead to execution of arbitrary
* Daniele Nicolodi [2020-11-02 14:10]:
> On 02/11/2020 10:02, TEC wrote:
> > I think there are absolutely some benefits for Org users. I am
> > personally interested in registering Org as an IANA MIME type.
>
> I don't think that registering Org as IANA MIME type will have the
> consequences you
I have collected below some quotations to try to represent the general
sentiments expressed so far in the conversation, upon which I would like to
express some thoughts. Most of these have been repeated several times in spirit,
so they are not just the opinions of the listed authors.
Daniele
Ken Mankoff writes:
On 2020-11-03 at 00:24 -08, David Rogers
wrote...
I disagree (in principle, not just because it would be
difficult) with
the idea of “expanding beyond Emacs”. Org-mode benefits greatly
from
current and future Emacs development, and asking to standardize
“just
the parts
Eric S Fraga writes:
On Tuesday, 3 Nov 2020 at 05:31, Ken Mankoff wrote:
But I'm weary of seeing all my colleagues say "Jupyter" and not
"Org"
+1 (not to mention the case of MSWord instead of Jupyter)
濫
So, yes, if TEC or others can get us there, I'm all for it but
they'll
have to
I'm coming at this from the viewpoint of accessibility. I am a blind
person, who is pretty technical, but not technical enough to bend Emacs to
my will as easily as some of you do. But I have begun bending Org-mode to
fit what I use it for, and love heading folding and having all things
pertaining
On Tuesday, 3 Nov 2020 at 05:31, Ken Mankoff wrote:
> But I'm weary of seeing all my colleagues say "Jupyter" and not "Org"
+1 (not to mention the case of MSWord instead of Jupyter)
So, yes, if TEC or others can get us there, I'm all for it but they'll
have to prise emacs out of hands when I
Hi Eric,
On 2020-11-03 at 05:00 -08, Eric S Fraga wrote...
> The benefits of org mode for me are that it is Emacs. [...] I find it
> difficult to see any further standardization that would provide any
> real benefits *to me*. If others see those benefits, excellent! All
> power to them and I
On Tuesday, 3 Nov 2020 at 04:14, Ken Mankoff wrote:
> Again: GitHub. Orgzly. The conversation should move from "it can't be
> done" or "it isn't helpful" (why so much negativity on this thread?)
> to
Hi Ken,
I'm sorry if I came across as being negative. I am not. I just think
that there is a
On Tue, Nov 03, 2020 at 04:14:41AM -0800, Ken Mankoff wrote:
> It seems like you have never used Orgzly or read on Org file on
> GitHub. Those are not ideas, but are actual current real-world
> win-win implementations of parts of Org outside of Emacs.
Supporting a subset of trivial formatting
On 2020-11-03 at 00:24 -08, David Rogers wrote...
> I disagree (in principle, not just because it would be difficult) with
> the idea of “expanding beyond Emacs”. Org-mode benefits greatly from
> current and future Emacs development, and asking to standardize “just
> the parts that are not
Asa Zeren writes:
Hi,
Even though I am new to the org-mode community, I would like to
share
some thoughts on the specification of org-mode, especially since
I
have seen some recent discussion of it in relation to
registering org
as a MIME type.
First, I would like to repeat the
Eric,
> For instance, in my recent org documents, I have added a #+calc: keyword
> which I use for embedded calc lines. This allows me to have a clearly
> labelled line that Calc will recognise and that I can process using a
> filter before export while also ensuring that other tools, e.g. ones
Eric S Fraga writes:
>
> A more subtle issue, and one that I raised earlier, is the underlying
> infinite customization provided by Emacs. Some of my macros are elisp
> code. A standard for the structure of org mode documents could exist
> but using such standard-compliant documents would be
Dear all,
this is an interesting discussion to read, and I think lots of clever
people have made this an interesting discussion. So I hesitated to even
join the discussion, because I am quite removed from current development
and no longer feel qualified to guide it. Still, my 5c.
For me, it
On Monday, 2 Nov 2020 at 16:23, Russell Adams wrote:
> #+BEGIN_RANT
> [...]
> #+END_RANT
Apologies for my comment then! :-( I am fully sympathetic to the views
you have expressed.
Let me rephrase, therefore: it could be interesting to see Emacs as a
SaaS which processes org mode documents.
Russell Adams writes:
On Mon, Nov 02, 2020 at 02:56:58PM +, Eric S Fraga wrote:
(as an aside, Emacs as an LSP could be interesting, especially
if
network based)
LSP is a standard from Microsoft:
https://github.com/Microsoft/language-server-protocol/
It allows networked JSON and
On Mon, Nov 02, 2020 at 02:56:58PM +, Eric S Fraga wrote:
> (as an aside, Emacs as an LSP could be interesting, especially if
> network based)
#+BEGIN_RANT
LSP is a standard from Microsoft:
https://github.com/Microsoft/language-server-protocol/
It allows networked JSON and telemetry, as
On Monday, 2 Nov 2020 at 17:22, Greg Minshall wrote:
> i wonder if it's possible (ignoring the possible utiltiy) to divide org
> mode into two (maybe three?) things.
Everything is possible! Whether it's desirable or not is a different
question. :-)
Although at first glance, it would seem
Eric,
i was thinking of replying to your earlier post on the power of emacs.
now i guess i'll ask my question or make my vague point or whatever.
i wonder if it's possible (ignoring the possible utiltiy) to divide org
mode into two (maybe three?) things.
first is "org mode as a document
Daniele Nicolodi writes:
On 02/11/2020 10:02, TEC wrote:
I think there are absolutely some benefits for Org users. I am
personally interested in registering Org as an IANA MIME type.
I don't think that registering Org as IANA MIME type will have
the
consequences you hope it has.
Hmmm.
+1 for everything that both Pankaj and Tim have said.
I've said this elsewhere: for me, the power of org mode is that it is
Emacs. Org allows me to leverage the power of Emacs more easily for
what I want to do (everything from project management to dissemination
of various sorts).
Anything that
On 02/11/2020 10:02, TEC wrote:
> I think there are absolutely some benefits for Org users. I am
> personally interested in registering Org as an IANA MIME type.
I don't think that registering Org as IANA MIME type will have the
consequences you hope it has.
> What will this do? Well, for
Russell Adams writes:
> On Sun, Nov 01, 2020 at 05:17:19PM -0800, Ken Mankoff wrote:
>>
>> To all who argue that Org is too tightly coupled to Emacs to
>> consider working with it outside of Emacs, I point to GitHub. The
>> fact that GitHub natively renders Org files "well enough" is a huge
>>
Daniele Nicolodi writes:
> On 02/11/2020 00:10, Dr. Arne Babenhauserheide wrote:
>>
>> Daniele Nicolodi writes:
>>> Maybe the standardization should cover only the "static" parts of Org
>>> (ie no table formulas, no babel, no agenda, no exporters, etc). However,
>>> in this case, what is left
Daniele Nicolodi writes:
Acceptance criterion for what? Adoption of what?
It seems to me that some see a the adoption of a simplified
version of
the Org markup language outside Emacs and the org-mode
implementation as
something desirable. However, I don't see what the Org community
would
On 02/11/2020 00:10, Dr. Arne Babenhauserheide wrote:
>
> Daniele Nicolodi writes:
>> Maybe the standardization should cover only the "static" parts of Org
>> (ie no table formulas, no babel, no agenda, no exporters, etc). However,
>> in this case, what is left is little more of a markup
On Sun, Nov 01, 2020 at 05:17:19PM -0800, Ken Mankoff wrote:
>
> To all who argue that Org is too tightly coupled to Emacs to
> consider working with it outside of Emacs, I point to GitHub. The
> fact that GitHub natively renders Org files "well enough" is a huge
> benefit to those of us who use
To all who argue that Org is too tightly coupled to Emacs to consider working
with it outside of Emacs, I point to GitHub. The fact that GitHub natively
renders Org files "well enough" is a huge benefit to those of us who use Org.
It is also useful for gaining new users (assuming more users
Daniele Nicolodi writes:
> Maybe the standardization should cover only the "static" parts of Org
> (ie no table formulas, no babel, no agenda, no exporters, etc). However,
> in this case, what is left is little more of a markup language with an
> editor that allows sections folding. You can have
On 01/11/2020 17:13, Russell Adams wrote:
> On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote:
>> First, I would like to repeat the importance of developing standards
>> for org-mode. If we want to expand the influence of org, tooling must
>> expand beyond Emacs.
>
> I disagree. There are
Dr. Arne Babenhauserheide wrote:
> Why should this be in a separate document? The obvious place for a
> standard is worg, and the way forward is to improve what’s there.
It does not necessarily need to be in a separate file, and if it is it should be
in worg or another communally owned place,
Hi all,
Thank you for your comments on my post "Thoughts on the Standardization of Org."
I appreciate all the feedback you have given me, I feel that, based off of the
responses, there have been a number of miscommunications as to my intention.
First, I did not mean the post to be
Hi Timothy,
TEC writes:
> I feel that this also ties into my earlier idea of putting Emacs
> as/inside an LSP server for Org. I suspect there may be a a lot
> of
> potential in making it dead easy to use Emacs as a tool.
I'm too busy to help on this, but I think it's a very good idea and
Dr. Arne Babenhauserheide writes:
Asa Zeren writes:
Also another note is that the worg syntax document does begin
to specify
this. My point is to bring this out into a separate document.
Why should this be in a separate document? The obvious place for
a
standard is worg, and the way
Asa Zeren writes:
> Also another note is that the worg syntax document does begin to specify
> this. My point is to bring this out into a separate document.
Why should this be in a separate document? The obvious place for a
standard is worg, and the way forward is to improve what’s there.
Best
On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote:
> First, I would like to repeat the importance of developing standards
> for org-mode. If we want to expand the influence of org, tooling must
> expand beyond Emacs.
I disagree. There are other open text based formats outside of
Emacs.
Thanks for the comments.
Both of you have raised some very good points, but I think that there has been
some confusion as to a number of my arguments. I hope to clarify some things
below.
On Sun Nov. 1, 2020, at 1:20AM Tom Gillespie wrote:
> My general take is that any active work toward
Asa
> Zeren
> Skickat: den 1 november 2020 01:22
> Till: emacs-orgmode@gnu.org
> Ämne: Thoughts on the standardization of Org
>
> Hi,
>
> Even though I am new to the org-mode community, I would like to share
> some thoughts on the specification of org-mode, especia
I feel that this also ties into my earlier idea of putting Emacs
as/inside an LSP server for Org. I suspect there may be a a lot
of
potential in making it dead easy to use Emacs as a tool.
I'm rather busy over the next few weeks, but I'd be happy to
spearhead a
project in this direction.
> see discussion on Mauro's thread about
> the fact that it is probably just easier to use Emacs directly if you
> need to export
> to a certain format in a specific way. It is free software after all.
I would like to add, that this is pretty easy to do, and also to make
independent of the users
Asa Zeren writes:
>
> In these concerns I see one major flaw. The way they are worded at present
> implies that the Emacs implementation of org is the "one true implementation,"
> and that all tools in other environments are auxiliary. I believe that if we
> want org to grow, then it needs to
Hi all,
Following what I've read on the list I've developed thoughts on
what the
best approach might be. My current thinking is that it may be
possible
to have Org registered as a standard in such a way that it does
not
constrain our development efforts.
How?
We forgo locking down the
Hi Asa,
My general take is that any active work toward standardization
would be premature. At the very least a full implementation outside
of Emacs would need to exist. In the absence of that there is little
point to standardization. There is ample existing documentation to
build a compliant
Asa Zeren writes:
> In these concerns I see one major flaw. The way they are worded at
> present implies that the Emacs implementation of org is the "one true
> implementation," and that all tools in other environments are
> auxiliary.
At present, that is the truth. Where are other
Tim Cross writes:
> I should state up-front, I am somewhat sceptical regarding an org-mode
> which is separate or independent of Emacs. Much of what makes org-mode
> so powerful and useful is due to features of Emacs. While most, if not
> all, of these features could be implemented in other
On Sat, Oct 31, 2020 at 8:40 PM Dr. Arne Babenhauserheide
wrote:
> The most important point I see here is to avoid hindering the
> development of org-mode within Emacs.
While I definitely support enabling the further development of org-mode, and not
restricting it via a standard, I do see some
I think there are a couple of important points to consider in
discussions of this type. I should state up-front, I am somewhat
sceptical regarding an org-mode which is separate or independent of
Emacs. Much of what makes org-mode so powerful and useful is due to
features of Emacs. While most, if
Asa Zeren writes:
> I would appreciate thoughts on these ideas about how to develop and
> org specification.
The most important point I see here is to avoid hindering the
development of org-mode within Emacs.
So the most important part of the standard would be areas it doesn’t
standardize:
Hi,
Even though I am new to the org-mode community, I would like to share
some thoughts on the specification of org-mode, especially since I
have seen some recent discussion of it in relation to registering org
as a MIME type.
First, I would like to repeat the importance of developing standards
72 matches
Mail list logo
